[secdir] Secdir review of draft-ietf-ippm-2679-bis

Warren Kumari <warren@kumari.net> Mon, 10 August 2015 21:21 UTC

Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 66C381B2F14 for <secdir@ietfa.amsl.com>; Mon, 10 Aug 2015 14:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id A0C0oCCxpiQd for <secdir@ietfa.amsl.com>; Mon, 10 Aug 2015 14:21:07 -0700 (PDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753621B2F11 for <secdir@ietf.org>; Mon, 10 Aug 2015 14:21:07 -0700 (PDT)
Received: by obbfr1 with SMTP id fr1so96963912obb.1 for <secdir@ietf.org>; Mon, 10 Aug 2015 14:21:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WGM/puwuUko9j8+lJmk5k7parbj/7ezLF5L8Ec46Ro0=; b=Q3M+CBMJtEAYZ3cEHW/asRNjN07vnt9uvgrQAAKTWSYSdQt9ZJGECsZlJhsjYo5NLw aRxHL/DvvP+DKGt+ksC/DGwKeRRK5fgCibK9/EaPGrBZfPtopNs4bEr0VTEej4DejMyW OWH2Jz4edwjEJifUGTrrJp3Cym3prM3fADv/UQFCmJv2R7YSUZGc0Wn7hxUiWZVcBH3H 1SBMz2PQkEe6rkoBppeJPrEYX796I5+mxF5qNXcrmgQyag0K4KaMNzvX7WnZVwIUSOwQ Pv+vuNezVE3C+XNr3c0+ZNVib/EwNkStoV3bUHyoJFm2AKFPViXfvqN3Gw4EGcBS9q3N SVoQ==
X-Gm-Message-State: ALoCoQn5Pn0x3ItvQSFQt87ZSv6BuwJTK6I/xELfPSG59FC3eRAIFYX1Xg8vUpaYcjtLvTqMpUMM
MIME-Version: 1.0
X-Received: by with SMTP id wv4mr22323868obb.78.1439241666720; Mon, 10 Aug 2015 14:21:06 -0700 (PDT)
Received: by with HTTP; Mon, 10 Aug 2015 14:21:06 -0700 (PDT)
Date: Mon, 10 Aug 2015 17:21:06 -0400
Message-ID: <CAHw9_i+F3SS37w4ejJZTWPDYFpMQgtSJ+1fxbUD+G9mR2-aYYw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: IETF Security Directorate <secdir@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/KiP3keLcunHzYqdPlHU4fNKtDoI>
Subject: [secdir] Secdir review of draft-ietf-ippm-2679-bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 21:21:09 -0000

Be ye not afraid -- I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call

Version reviewed: draft-ietf-ippm-2679-bis-03

Summary: Ready with nits. IMO Sec ADs do not need to pay attention.

This document is well written and clear. I found only a small number of nits...

Security Considerations is well written and complete.

Section 1:
Note: This section's placement currently preserves minimal
differencer between this memo and RFC 2679.  The RFC Editor should

O: differencer
P: differences
R: typo

Section 3.5:
+ A given methodology will have to include a way to determine whether
a delay value is infinite or whether it is merely very large (and the
packet is yet to arrive at Dst).  As noted by Mahdavi and Paxson
[RFC2678], simple upper bounds (such as the 255 seconds theoretical
upper bound on the lifetimes of IP packets [RFC0791]) could be used,

O: could be used,
P: could be used;
R: grammar/otherwise it's a run-on sentence

Section 3.6:
+ At the Src host, select Src and Dst IP addresses, and form a test
packet of Type-P with these addresses.  Any 'padding' portion of the
packet needed only to make the test packet a given size should be
filled with randomized bits to avoid a situation in which the
measured delay is lower than it would otherwise be due to compression

O: otherwise be due to compression
P: otherwise be, due to compression
R: readability

Section 3.7.2:
To the extent that the difference between wire time and host time is
accurately known, this knowledge can be used to correct for host time
measurements and the corrected value more accurately estimates the

O: measurements and the corrected value more accurately estimates the
P: measurements, and the corrected value more accurately estimates the
R: Grammar/run-on sentence

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.