Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
Greg Mirsky <gregimirsky@gmail.com> Fri, 18 October 2019 22:06 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8C12010C; Fri, 18 Oct 2019 15:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0vXbwoEafA5; Fri, 18 Oct 2019 15:06:16 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 4C707120074; Fri, 18 Oct 2019 15:06:15 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id f5so7665711ljg.8; Fri, 18 Oct 2019 15:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9yl41eGPesfvrKqXYtRB+cUeOwD2sQmIZI12WMspY+U=; b=h1Qm070K5/3Nbnd0A5oOqYK8zZI1mlJJ68tP77BwuRsRg0tFxfHy9LZpC/XkABuAUF GoIEhoSxoBq3J3FtbLbCZZ52GsofzhHUi4/KmZ1928v+BVP7eRHIW+OZSva4Rmw6fcqd /YBvFbwLsdYX/zWRNY+Gx03E2pVWu71gK0HP7ZFrkcEtMAA/bJ1vsa6XTonwfsXzmYsx QBl5panrM11lMOrll33IBEMJcOu5hINy5Fxuz4s+PDzp0w4jM+dE8eWod4YwYEaGcwM7 CjFjuzPwa+0QMSjHAtPCIlKINi3cRnN9ULqZDhu/lzmWY9aLUuV9z76TKBh2tM8nyRi9 pr7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9yl41eGPesfvrKqXYtRB+cUeOwD2sQmIZI12WMspY+U=; b=qEPKt5DeX31A9Paqy1D7t6r9csTiIBp53j+3BTn7ho59XXVGjlx8WWuqVhRHElKr5q oYRRy0/5y/9sdM2EqNidO+BCKX7OaoCwYCVJbb3dQDtzPJLBTGdTXF4Xt95GEM3+Qm53 OnfH76HmqHjBFesYUmfYMTObuVX9CRp+muySo5X25qLOtWkX5j6hKbO1hvLHiSap2u1k rvk9oXLU7qMYwbsoLdpTREIbj5fge5uGaTCNgwZ5GQlnpqpxqH4Fw4R/eSUo6ZB8z9id bMk+y5Nk1XgISK6v8jNbS8BvDBDspAWJbhneqrmy8NwHFv7GvnSbU0bJOKcJdfJ09QlF 3PNA==
X-Gm-Message-State: APjAAAU4luyu+pAMkKW8zmFM8uzRICKwVQXaXoyWjaR2RtlBeL6lGNB9 C1+aZ8c8Cr/PIENubXSfQK7nwc1EMsZ7Nm5ffRY=
X-Google-Smtp-Source: APXvYqzlOMR3ow4MXtehglWZgJ+Uu78HJnkhZtfKk4GbJaGmAKIAf6MXJiPPbKxcBN6FqIGZAnhzTpojTASPBb5mNtI=
X-Received: by 2002:a2e:9e4c:: with SMTP id g12mr7776697ljk.103.1571436373191; Fri, 18 Oct 2019 15:06:13 -0700 (PDT)
MIME-Version: 1.0
References: <156764462100.22846.16937322291769285829.idtracker@ietfa.amsl.com> <CA+RyBmWQ9VgPe27gdrF0_7sdhWMwDTAMtYk6EUYiO9tQBKv4_w@mail.gmail.com> <20191015155618.GL61805@kduck.mit.edu> <CA+RyBmUFKCb7=AyBNFQTyhNhu+CtLuzEwjqPknLR6_A-BSap5A@mail.gmail.com> <20191018203308.GM43312@kduck.mit.edu>
In-Reply-To: <20191018203308.GM43312@kduck.mit.edu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 18 Oct 2019 15:06:00 -0700
Message-ID: <CA+RyBmVKp6P12aVRxewEYTtEm7jr7fNmDqo8WXLOq3+uYau6wA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-stamp@ietf.org, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cfb1e50595368a5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/os1TbvEbNBMg-_bkVx-nDxbZ7Ao>
Subject: Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 22:06:26 -0000
Hi Benjamin, many thank for the comments, the discussion and, most of, your patience. I'll use the suggested re-wording on the default timestamp format. Will publish -09 version shortly. Regards, Greg On Fri, Oct 18, 2019 at 1:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > On Wed, Oct 16, 2019 at 04:44:25PM -0700, Greg Mirsky wrote: > > Hi Benjamin, > > thank you for the additional details. Please find my answers below under > > GIM2>> tag. Also, the copy of the working version and its diff to -07 are > > attached. I greatly appreciate your feedback. > > > > Regards, > > Greg > > > > On Tue, Oct 15, 2019 at 8:56 AM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > > > Hi Greg, > > > > > > Sorry for the delayed response -- I was travelling last week. > > > > > > A couple notes on the -08 before I get into the inline replies: > > > > > > Thanks for continuing the dialogue with the gen-art reviewer; I'm > happy to > > > see those refinements made. > > > > > > In Section 4.1.1 we are now talking about both the "Z flag" and "Z > field"; > > > it's probably best to just pick one. > > > > > GIM2>> Changed to "Z field" as in RFC 8186. > > > > > > > > On Wed, Oct 09, 2019 at 08:37:26PM -0700, Greg Mirsky wrote: > > > > Hi Benjamin, > > > > thank you for your thorough review and detailed comments. Please find > > > > answers, notes, and the proposed updates below in-line tagged GIM>>. > > > > I much appreciate your feedback, suggestions to address your > concerns. > > > > > > > > Regards, > > > > Greg > > > > > > > > On Wed, Sep 4, 2019 at 5:50 PM Benjamin Kaduk via Datatracker < > > > > noreply@ietf.org> wrote: > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-ippm-stamp-07: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply to > all > > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > We don't ever clearly state that the protocol allows for packet > sizes > > > > > other than the listed 44- and 112-octet variants, that content > larger > > > > > than that is to be treated as padding unless directed otherwise by > > > > > configuration, that the reflected packet must be the same size as > the > > > > > incoming packet, and how a Session-Reflector should set any such > > > padding > > > > > that it needs to add in order to produce a same-sized packet. > > > > > > > > > GIM>> We had discussed this and the current working version of the > draft > > > in > > > > Section 4.2 refers to the STAMP Optional Extensions > > > > <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/> > > > draft: > > > > STAMP supports symmetrical test packets. The base STAMP Session- > > > > Sender packet has a minimum size of 44 octets in unauthenticated > > > > mode, see Figure 2, and 112 octets in the authenticated mode, see > > > > Figure 4. The variable length of a test packet in STAMP is > supported > > > > by using Extra Padding TLV defined in > > > > [I-D.ietf-ippm-stamp-option-tlv]. > > > > As discussed in Section 4.6 Interoperability with TWAMP Light, TWAMP > > > Light > > > > Session-Reflector will treat STAMP optional extensions as Padding > and, if > > > > configured to symmetrical packet size mode, will respond with > Padding as > > > > per RFC 6038. This draft defines the use of only base STAMP packets > and > > > the > > > > discussion of all extensions is in the > draft-ietf-ippm-stamp-option-tlv. > > > > > > I understand that this document only defines base STAMP packets, but it > > > also needs to cover the "protocol invariants" for STAMP, even when both > > > endpoints are STAMP and no TWAMP-Light is involved. So, adding the > > > sentence about variable length being supported by the padding TLV is > good, > > > but I still think we should have some discussion about, e.g., what a > > > receiver should do when it receives a packet larger than the base size > > > which does not parse properly as having trailing TLV(s), and what > bytes are > > > used to fill a reflected packet when it is larger than the base test > > > packet. I'm also still unclear on whether we always require the > reflected > > > packet to be the same size as the test packet -- Section 4 has a brief > not > > > that "[b]y default, STAMP uses symmetrical packets" but I did not find > any > > > discussion of when or how it would work otherwise. > > > > > GIM2>> I see your point and agree that that needs clarification in the > > spec. I think that Section 4.3 Session-Reflector Behavior and Packet > Format > > is the right place. Below is the updated paragraph: > > The Session-Reflector receives the STAMP test packet and verifies it. > > If the base STAMP test packet validated, the Session-Reflector, that > > supports this specification, prepares and transmits the reflected > > test packet symmetric to the packet received from the Session-Sender > > copying the content beyond the size of the base STAMP packet (see > > Section 4.2). > > That sounds good; thanks! > > > > > > > > > > > > > > This document hardcodes the truncated HMAC-SHA-256 algorithm. Per > BCP > > > > > 201, what is the procedure for cryptographic algorithm agility? > > > > > > > > > GIM>> Support of other cryptographic algorithms is important but the > WG > > > > agreed that in this specification only the use of HMAC-SHA-256 is > > > defined. > > > > Future specifications may define the use of other, more advanced > > > > cryptographic algorithms, possibly providing an update to the STAMP > YANG > > > > data model < > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/ > > > >. > > > > > > That's a reasonable approach for agility; I'd suggest adding a note to > the > > > document to indicate that this is the plan. > > > > > GIM2>> Would add the last sentence to Section 4.4 Integrity Protection in > > STAMP: > > Future specifications may define the use of other, more advanced > > cryptographic algorithms, possibly providing an update to the STAMP > > YANG data model [I-D.ietf-ippm-stamp-yang]. > > Sounds good. > > > > > > > > > > > > > Please also consider the discussion in BCP 107 about key > lifecycles and > > > > > key management, including whether it is appropriate to use a > > > > > key-derivation function to produce short-term (e.g., per flow) keys > > > from > > > > > a long-lived key (e.g., one fixed in static configuration). > > > > > > > > > GIM>> In the course of the discussion, we've clarified in the section > > > > Integrity Protection in STAMP that: > > > > HMAC uses its own key, and the definition of the > > > > mechanism to distribute the HMAC key is outside the scope of this > > > > specification. One example is to use an orchestrator to configure > > > > HMAC key based on STAMP YANG data model > [I-D.ietf-ippm-stamp-yang]. > > > > > > Hmm, I'm not sure I was a part of the discussion in question, since > this > > > text looks unchanged from what I balloted on for the -07. I'd suggest > to > > > clarify further "HMAC uses its own key" with respect to the scope of > the > > > key -- is it a unique key per test session? > > > > > GIM2>> HMAC key may be unique for each STAMP test session. Update to the > > sentence: > > OLD TEXT: > > HMAC uses its own key, and the definition of the > > mechanism to distribute the HMAC key is outside the scope of this > > specification > > NEW TEXT: > > HMAC uses its own key that may be unique for > > each STAMP test session; key management and the mechanisms to > > distribute the HMAC key is outside the scope of this specification. > > Okay. > > > > > > > > > > > > > > What is the input plaintext to the HMAC computation? In the case > of > > > > > future extensions, does the HMAC field remain at its current fixed > > > > > offset in the packet or move to always be the last 16 octets? Is > any > > > > > additional padding/TLV content protected by the HMAC? > > > > > > I see in the editor's copy that this is clarified to have the HMAC > cover > > > the first 96 bytes; okay. > > > > > > > > What error does the error estimate ... estimate? > > > > > Clock skew between sender and receiver? > > > > > > > > > GIM>> The Error Estimate field has been originally defined in RFC > 4656 > > > > One-Way Active Measurement Protocol. One flag (S) indicates whether > the > > > > originator of the timestamp has clock synchronized to UTC (GPS, NTP > or > > > > PTP). Other fields can be used to express the error estimate of the > > > > timestamping process. > > > > > > I looked at the linked section of RFC 4656 in my initial review, and > was > > > only able to find the interpretation of the 'scale' and 'multiplier' > fields > > > to form a combined "error estimate" in seconds (with sub-second > precision). > > > What I didn't find was a discussion of its abstract semantics -- what > is > > > the reference value and the measured value whose error is being > estimated > > > with respect to the reference? A timestamp of some form, given the > units > > > (seconds), but which one? > > > > > GIM2>> In my experience with OWAMP/TWAMP implementations, the value > > produced by the Error Estimate (Scale and Multiplier) was hard-coded and > > not reflective of how a timestamp obtained. That was the reason we've > > introduced the Timestamp Information TLV in > draft-ietf-ippm-stamp-option-tlv > > <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>. > > That's kind of unfortunate (hard-coding), but the text here does make more > sense with that context! I'll let this one go. > > > > > > > > > > > > > I think we need to require some level of cryptographic protection > > > > > whenever control information is included in a Session-Sender's test > > > > > packet. That is, that a Session-Reflector MUST NOT act on control > > > > > information received in unauthenticated packets. (That said, this > > > > > document itself does not describe a way to include control > information, > > > > > so perhaps the note about "optional control information > communicated in > > > > > the Session-Sender's test packet" in Section 4 is misplaced. > > > > > > > > > GIM>> Thank you for catching this. Clearly, it must be removed: > > > > OLD TEXT: > > > > STAMP Session-Reflector receives Session-Sender's packet and acts > > > > according to the configuration and optional control information > > > > communicated in the Session-Sender's test packet. > > > > NEW TEXT: > > > > STAMP Session-Reflector receives Session- > > > > Sender's packet and acts according to the configuration. > > > > > > > > In Section 4.2.1: > > > > > > > > > > o Timestamp and Receiver Timestamp fields are each eight octets > > > > > long. The format of these fields, NTP or PTPv2, indicated > by the > > > > > Z flag of the Error Estimate field as described in Section > 4.1. > > > > > > > > > > I think you need to explicitly say that "Timestamp" is echoed from > the > > > > > received packet and "Receiver Timestamp" is determined locally as > close > > > > > to (reciept? transmission?) as possible. > > > > > > > > > GIM>> You've helped find a typo that makes the name of the field > > > confusing. > > > > The field is tagged correctly in Figure 5 - Receive Timestamp. In > fact, > > > the > > > > Receive Timestamp is also the local to the Session-Reflector. It is > the > > > > time value the Reflector received the STAMP test packet. The value > in the > > > > Timestamp field is taken at the transmission of the reflected > packet. The > > > > Sender Timestamp field is a copy of the Timestamp field in the > > > > Session-Sender's test packet. I propose the update as follows: > > > > OLD TEXT: > > > > o Timestamp and Receiver Timestamp fields are each eight octets > > > > long. The format of these fields, NTP or PTPv2, indicated by > the > > > > Z flag of the Error Estimate field as described in Section 4.1. > > > > NEW TEXT: > > > > o Timestamp and Receive Timestamp fields are each eight octets > long. > > > > The format of these fields, NTP or PTPv2, indicated by the Z > flag > > > > of the Error Estimate field as described in Section 4.2. > Receive > > > > Timestamp is the time the test packet was received by the > Session- > > > > Reflector. Timestamp - the time taken by the > Session-Reflector at > > > > the start of transmitting the test packet. > > > > > > Thanks! > > > > > > > > > > > > > I think we need greater clarity on whether the normative > statements in > > > > > Section 4.4 apply only to STAMP peers that are aware they are > > > > > interacting with TWAMP Light, or apply to all STAMP peers (see > Comment > > > > > for further discussion on why the current text seems internally > > > > > inconsistent). > > > > > > [It looks like discussion of this is down in the Comment section] > > > > > > > > > > > > > In Section 4.1.1: > > > > > > > > > > o Timestamp is eight octets long field. STAMP node MUST > support > > > > > Network Time Protocol (NTP) version 4 64-bit timestamp format > > > > > [RFC5905], the format used in [RFC5357]. STAMP node MAY > support > > > > > IEEE 1588v2 Precision Time Protocol truncated 64-bit > timestamp > > > > > format [IEEE.1588.2008], the format used in [RFC8186]. > > > > > > > > > > I think a note that which one is in use will be configured by the > > > > > configuration/management function is in order. Except that the Z > bit > > > > > below confuses things terribly... > > > > > > > > > > The STAMP Session-Sender and Session-Reflector MAY use, not > use, > > > > > or set value of the Z field in accordance with the timestamp > > > > > format in use. This optional field is to enhance > operations, but > > > > > local configuration or defaults could be used in its place. > > > > > > > > > > ... since, as noted by the secdir reviewer, this line just confuses > > > > > everything. Either keep the "must be zero" semantics of 4656 or > the > > > > > "MUST match reality" semantics of 8186, but this middle case is > > > actively > > > > > harmful. > > > > > > > > > GIM>> As result of the discussion, this text is changed to: > > > > NEW TEXT: > > > > The STAMP Session-Sender and Session-Reflector MUST use the > NTP 64 > > > > bit format of a timestamp (Z field value of 0). as the > default. > > > > A configuration/management function MAY configure STAMP > Session- > > > > Sender and Session-Reflector to using the PTPv2 truncated > format > > > > of a timestamp (Z field value of 1). > > > > Hope it is clearer now. > > > > > > Yes, that language addresses my concerns. > > > > > > > > > > > > > (I also support Barry and Magnus' Discusses.) > > > > > > > > > GIM>> It took some time to address them. > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Section 1 > > > > > > > > > > I'll note several grammar nits, inline, though perhaps some of them > > > will > > > > > not apply after the rewrite in response to the secdir review: > > > > > > > > > > Development and deployment of Two-Way Active Measurement > Protocol > > > > > > > > > > "the Two-Way" > > > > > > > > > GIM>> Applied, thank you. > > > > > > > > > > > > > > (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that > defined > > > > > features such as Reflect Octets and Symmetrical Size for TWAMP > > > > > > > > > > comma after TWAMP > > > > > > > > > GIM>> Done. > > > > > > > > > > > > > > provided invaluable experience. Several independent > implementations > > > > > exist, have been deployed and provide important operational > > > > > performance measurements. At the same time, there has been > > > > > noticeable interest in using a more straightforward mechanism > for > > > > > active performance monitoring that can provide deterministic > > > behavior > > > > > and inherit separation of control (vendor-specific > configuration or > > > > > > > > > > "inherit" from what? > > > > > > > > > GIM>> Right, should have been "inherent". Now in the working version. > > > > > > Ah, that makes much more sense now :) > > > > > > > > > > > > > orchestration) and test functions. One of such is Performance > > > > > > > > > > "One such mechanism is" > > > > > > > > > GIM>> This passage updated to: > > > > Recent work on IP Edge to Customer Equipment using TWAMP Light > from > > > > Broadband Forum [BBF.TR-390] demonstrated that interoperability > among > > > > implementations of TWAMP Light is challenged because the > composition > > > > and operation of TWAMP Light were not sufficiently specified in > > > > [RFC5357]. > > > > > > > > > > > > > > Measurement from IP Edge to Customer Equipment using TWAMP Light > > > from > > > > > Broadband Forum [BBF.TR-390] used as the reference TWAMP Light > that, > > > > > > > > > > I'm not sure what the intent here is, but maybe ", which is used > as the > > > > > reference TWAMP Light". > > > > > > > > > GIM>> Replaced by the sentence I've copied above. > > > > > > > > > > > > > > according to [RFC8545], includes sub-set of TWAMP-Test > functions in > > > > > > > > > > I'd also suggest starting a new sentence for "According to > [RFC8545]" > > > > > (and adding the then-needed "this" and "a" for "this includes a"). > > > > > > > > > GIM>> Re-worded as follows: > > > > According to [RFC8545], TWAMP Light includes sub-set of > > > > TWAMP-Test functions to provide comprehensive solution requires > > > > support by other applications that provide, for example, control > and > > > > security. > > > > > > > > > > > > > > > > > > combination with other applications that provide, for example, > > > > > control and security. This document defines an active > performance > > > > > measurement test protocol, Simple Two-way Active Measurement > > > Protocol > > > > > (STAMP), that enables measurement of both one-way and round-trip > > > > > performance metrics like delay, delay variation, and packet > loss. > > > > > > > > > > I agree with the secdir reviewer that the relationship between > STAMP > > > and > > > > > TWAMP Light could be much more clear. > > > > > > > > > GIM>> The new paragraph at the closing of the Introduction section: > > > > This document defines an active performance measurement test > > > > protocol, Simple Two-way Active Measurement Protocol (STAMP), that > > > > enables measurement of both one-way and round-trip performance > > > > metrics like delay, delay variation, and packet loss. Some TWAMP > > > > extensions, e.g., [RFC7750] are supported by the extensions to > STAMP > > > > base specification in [I-D.ietf-ippm-stamp-option-tlv]. > > > > > > > > > > > > > > Section 2.1 > > > > > > > > > > MBZ May be Zero > > > > > > > > > > I commonly see this expand to "Must be zero"; requiring the sender > to > > > > > not set any bits seems more likely to preserve the ability to use > the > > > > > field for future extensibility, since a recipient that sees a > nonzero > > > > > bit knows it was consciously set (i.e., with intent to use the > > > > > extension) rather than inadvertently set by someone expecting it > to be > > > > > ignored. > > > > > (Also, if the bits are covered under the HMAC, then the recipient > can't > > > > > actually ignore them, since they have to be used to verify the > HMAC.) > > > > > > > > > GIM>> Changed MBZ full form to the Must-be-zero. Named padding > fields in > > > > unauthenticated mode - Reserved. Would that be acceptable? > > > > > > That's probably fine. I still wish we could do something to alleviate > the > > > dissonance between "ignored on receipt" and (presumably) needing to > use the > > > fields as input to HMAC validation. > > > > > GIM2>> This specification follows the language used in RFC 4656 OWAMP and > > RFC 5357 TWAMP to describe the authenticated mode for test components of > > the respective protocols. I agree, in the authenticated mode MBZ is not > > "ignored on receipt". I propose a note in the description of MBZ fields > in > > the authenticated mode. Below is the updated text of the Session-Sender's > > format: > > The field definitions are the same as the unauthenticated mode, > > listed in Section 4.2.1. Also, Must-Be-Zero (MBZ) fields are used to > > to make the packet length a multiple of 16 octets. The value of the > > field MUST be zeroed on transmission and MUST be ignored on receipt. > > Note, that the MBZ field is used to calculate a key-hashed message > > authentication code (HMAC) ([RFC2104]) hash. Also, the packet > > includes HMAC hash at the end of the PDU. The detailed use of the > > HMAC field is described in Section 4.4. > > And the updated text for the Session-Reflector's packet: > > The field definitions are the same as the unauthenticated mode, > > listed in Section 4.3.1. Additionally, the MBZ field is used to to > > make the packet length a multiple of 16 octets. The value of the > > field MAY be zeroed on transmission and MUST be ignored on receipt. > > Note, that the MBZ field is used to calculate HMAC hash value. Also, > > STAMP Session-Reflector test packet format in authenticated mode > > includes HMAC ([RFC2104]) hash at the end of the PDU. The detailed > > use of the HMAC field is in Section 4.4. > > I don't have any better alternatives, so thanks for this. > > > > > > > > > > > > > Section 3 > > > > > > > > > > be achieved through various means. Command Line Interface, > OSS/BSS > > > > > (operations support system/business support system as a > combination > > > > > of two systems used to support a range of telecommunication > > > services) > > > > > using SNMP or controllers in Software-Defined Networking using > > > > > Netconf/YANG are but a few examples. > > > > > > > > > > nit: if "using SNMP or controllers[...]" is supposed to be separate > > > from > > > > > "OSS/BSS", then some additional punctuation/conjunction is needed. > > > > > > > > > GIM>> Also re-worded as: > > > > The configuration and management of the STAMP Session- > > > > Sender, Session-Reflector, and management of the STAMP sessions > are > > > > outside the scope of this document and can be achieved through > > > > various means. A few examples are: Command Line Interface, > > > > telecommunication services' OSS/BSS systems, SNMP, and > Netconf/YANG- > > > > based SDN controllers. > > > > > > Looks great! > > > > > > > > > > > > > Section 4 > > > > > > > > > > number. A STAMP implementation of Session-Sender MUST be able > to > > > use > > > > > UDP port numbers from User, a.k.a. Registered, Ports and > Dynamic, > > > > > a.k.a. Private or Ephemeral, Ports ranges defined in [RFC6335]. > > > > > > > > > > Able to use as source, destination, or both? (We just talked about > > > > > destination but not source in the previous sentence.) > > > > > > > > > GIM>> The text is now in Section 4.1. Will clarify that it applies > to the > > > > destination port: > > > > A STAMP implementation of Session-Sender MUST be able to use as > the > > > > destination UDP port numbers from User, a.k.a. Registered, Ports > and > > > > Dynamic, a.k.a. Private or Ephemeral, Ports ranges defined in > > > > [RFC6335]. > > > > > > > > > > > > > > Section 4.1 > > > > > > > > > > Because STAMP supports symmetrical test packets, STAMP > > > Session-Sender > > > > > packet has a minimum size of 44 octets in unauthenticated mode, > see > > > > > Figure 2, and 112 octets in the authenticated mode, see Figure > 4. > > > > > > > > > > nit: I don't see how merely "support"ing (as opposed to > "require"ing or > > > > > "use"ing) symmetrical packets implies these minimum packet sizes. > > > (That > > > > > is, I find the word "because" unjustified absent some statement > that > > > > > requires the Session-Reflector packets to be that size and a > > > requirement > > > > > for the symmetry is present.) > > > > > > > > > GIM>> The use of the symmetrical test packets is the default > behavior: > > > > NEW TEXT: > > > > A STAMP Session-Reflector supports symmetrical size of test > packets > > > > [RFC6038] as the default behavior. Because of that, the base > STAMP > > > > Session-Sender packet has a minimum size of 44 octets in > > > > unauthenticated mode, see Figure 2, and 112 octets in the > > > > authenticated mode, see Figure 4. The variable length of a test > > > > packet in STAMP is supported by using Extra Padding TLV defined in > > > > [I-D.ietf-ippm-stamp-option-tlv]. > > > > > > Sorry for being dense, but I'm still not seeing the logical chain of > > > deductions that makes "because" applicable. It seems like the minimum > size > > > of a base packet is a decision that can be made independently of > whether to > > > use symmetrical test packets (and, furthermore, just because something > is a > > > default behavior does not mean that it can be used to justify any > > > authoritative statements about the whole system absent some discussion > of > > > permitted deviations from the default). > > > > > GIM2>> Here's an update to that text: > > NEW TEXT: > > A STAMP Session-Reflector supports the symmetrical size of test > > packets [RFC6038] as the default behavior. A reflected test packet > > includes more information and thus is larger. Because of that, the > > base STAMP Session-Sender packet is padded to match the size of a > > reflected STAMP test packet. Hence, the base STAMP Session-Sender > > packet has a minimum size of 44 octets in unauthenticated mode, see > > Figure 2, and 112 octets in the authenticated mode, see Figure 4. > > The variable length of a test packet in STAMP is supported by using > > Extra Padding TLV defined in [I-D.ietf-ippm-stamp-option-tlv]. > > Thank you! I understand what is going on here, now. > > > I agree that we'll discuss the control of the test packet length in more > > detail in draft-ietf-ippm-stamp-option-tlv. > > > > > > > > > > > > > > > Section 4.2 > > > > > > > > > > That implies that the STAMP Session-Reflector MUST keep a > state > > > > > for each accepted STAMP-test session, uniquely identifying > STAMP- > > > > > test packets to one such session instance, and enabling > adding a > > > > > sequence number in the test reply that is individually > > > incremented > > > > > on a per-session basis. > > > > > > > > > > How does it "accept a STAMP-test session"? > > > > > > > > > GIM>> Would s/accepted/configured/ work? > > > > > > That would be great. > > > > > > > > > > > > > Section 4.2.1 > > > > > > > > > > * in the stateful mode the Session-Reflector counts the > received > > > > > STAMP test packets in each test session and uses that > counter > > > > > to set the value of the Sequence Number field. > > > > > > > > > > Should we say anything about whether the initial sequence number > > > (having > > > > > received one packet from the Session-Sender) is zero or one? > > > > > > > > > GIM>> In the description of the format of the Session-Sender > > > > unauthenticated test packet stated: > > > > o Sequence Number is four octets long field. For each new > session > > > > its value starts at zero and is incremented with each > transmitted > > > > packet. > > > > Will add similar note for the Session-Reflector: > > > > OLD TEXT: > > > > * in the stateful mode the Session-Reflector counts the > received > > > > STAMP test packets in each test session and uses that > counter > > > > to set the value of the Sequence Number field. > > > > NEW TEXT: > > > > * in the stateful mode, the Session-Reflector counts the > > > > transmitted STAMP test packets. It starts with zero and is > > > > incremented by one for each subsequent packet for each test > > > > session. The Session-Reflector uses that counter to set the > > > > value of the Sequence Number field. > > > > > > Thanks! > > > > > > > > > > > > > Section 4.2.2 > > > > > > > > > > Also, > > > > > STAMP Session-Reflector test packet format in authenticated mode > > > > > includes a key (HMAC) ([RFC2104]) hash at the end of the PDU. > The > > > > > detailed use of the HMAC field is in Section 4.3. > > > > > > > > > > nit: "keyed" > > > > > > > > > GIM>> Done, thank you > > > > > > > > > > > > > > Section 4.3 > > > > > > > > > > I think we should have a statement about HMAC key (non-)reuse > across > > > > > separate measurement sessions. > > > > > > > > > > I agree with the secdir reviewer that the confidentiality > protection > > > > > seems like something that would be done at a "lower" level, not a > > > > > "higher" level. > > > > > > > > > GIM>> Resulting from our discussion with SecDir, the following text > is > > > now > > > > in the Integrity Protection in STAMP section: > > > > HMAC uses its own key; key management and the > > > > mechanisms to distribute the HMAC key is outside the scope of this > > > > specification. One example is to use an orchestrator to configure > > > > HMAC key based on STAMP YANG data model > [I-D.ietf-ippm-stamp-yang]. > > > > Would you suggest additional text or an update? > > > > > > This text is fine with respect to the "lower" vs. "higher" question; > as I > > > mentioned above I'd still like to see a bit more about whether the key > is > > > expected to be unique across sessions. > > > > > GIM2>> I've updated this text to state that the key may be unique per > test > > session (see above). > > > > > > > > > > > > > > > Section 4.4 > > > > > > > > > > In the former case, the Session-Sender MAY not be aware that its > > > > > > > > > > It's unclear that this "MAY" is normative as opposed to > descriptive. > > > > > > > > > GIM>> Yes, it should be in descriptive form s/MAY/might/ > > > > > > It looks like this didn't make it into the -08? Ah, because the > editor's > > > copy was attached and hasn't been pushed to the datatracker yet. > > > > > > > > > > > > > Session-Reflector does not support STAMP. For example, a TWAMP > > > Light > > > > > Session-Reflector may not support the use of UDP port 862 as > defined > > > > > in [RFC8545]. Thus STAMP Session-Sender MAY use port numbers as > > > > > defined in Section 4. If any of STAMP extensions are used, the > > > TWAMP > > > > > Light Session-Reflector will view them as Packet Padding > field. The > > > > > Session-Sender SHOULD use the default format for its timestamps > - > > > > > NTP. And it MAY use PTPv2 timestamp format. > > > > > > > > > > Given the above note about not knowing that the peer is TWAMP > Light vs. > > > > > STAMP, it seems that this SHOULD/MAY apply to all STAMP > > > implementations, > > > > > not just ones that are interacting with TWAMP Light. Which in turn > > > might > > > > > suggest that the normative statements are best made in a different > > > > > section. > > > > > (Also (nit), where do we say that NTP is the default format?) > > > > > > > > > GIM>> We've clarified the default format for timestamp when > addressing > > > > other review comments. Now the draft states in Section 4.2.1: > > > > The STAMP Session-Sender and Session-Reflector MUST use the > NTP 64 > > > > bit format of a timestamp (Z field value of 0). as the > default. > > > > And, as I've mentioned in response to the question above, the draft > > > > clarifies for PTPv2 format: > > > > A configuration/management function MAY configure STAMP > Session- > > > > Sender and Session-Reflector to using the PTPv2 truncated > format > > > > of a timestamp (Z field value of 1). > > > > I hope it is not seen as duplication and the message is consistent. > > > > > > Going from -07 to -08 reduced duplication and improved clarity, so I'm > not > > > too worried about this aspect. > > > > > > > > > > > > > > > > > In the latter scenario, if a TWAMP Light Session-Sender does not > > > > > support the use of UDP port 862, the test management system > MUST set > > > > > STAMP Session-Reflector to use UDP port number as defined in > > > > > Section 4. If the TWAMP Light Session-Sender includes Packet > > > Padding > > > > > field in its transmitted packet, the STAMP Session-Reflector > will > > > > > return the reflected packet of the symmetrical size if the size > of > > > > > the received test packet is larger than the size of the STAMP > base > > > > > packet. The Session-Reflector MUST be set to use the default > format > > > > > for its timestamps, NTP. > > > > > > > > > > On the other hand, if we take the same approach here, and assume > that > > > > > the Session-Reflector may not know that the Session-Sender is TWAMP > > > > > Light vs. STAMP, then this MUST would seem to always apply, and > thus > > > > > prevent the Session-Reflector from ever using the PTPv2 timestamp > > > > > format, in which case the text related to its doing so is "dead > code" > > > > > and should be removed to avoid confusion. > > > > > > > > > GIM>> When we say in the draft that a Session-Sender or > Session-Reflector > > > > "know" something, we imly that that is known to an operator, the one > who > > > > configures, manages the test session. If both entities support STAMP, > > > then > > > > the test session may be instantiated using Netconf/YANG and use PTPv2 > > > > format. If only one entity is STAMP-based, then operator may assume > that > > > > the remote node only supprots STAMP and set its system to use NTP > format. > > > > Do you see that reasonable? > > > > > > That's a perfectly reasonable approach to session > configuration/management; > > > my only concern is that the document's text gives a clear and accurate > > > description thereof. So perhaps it's better to reword the text(s) > about > > > Session-{Sender,Reflector} being aware of things with a view to the > > > operator's knowledge as manifested in configuration rather than purely > > > local knowledge. > > > > > GIM2>> Thank you for your clarification. Below is the update to Section > > 4.2.1: > > OLD TEXT: > > The STAMP Session-Sender and Session-Reflector MAY use, not use, > > or set value of the Z field in accordance with the timestamp > > format in use. This optional field is to enhance operations, but > > local configuration or defaults could be used in its place. > > NEW TEXT: > > The STAMP Session-Sender and Session-Reflector MUST use the NTP 64 > > bits format of a timestamp (Z field value of 0), as the default. > > An operator, using configuration/management function, MAY > > configure STAMP Session-Sender and Session-Reflector to using the > > PTPv2 truncated format of a timestamp (Z field value of 1). Note, > > that an implementation of a Session-Sender that supports this > > specification MAY be configured to use PTPv2 format of a timestamp > > even though the Session-Reflector is configured to use NTP format. > > That works for me, thanks. I think some of my IESG colleagues dislike > constructions of the form "MUST [...] except for $condition", though, so > perhaps "The default behavior of the STAMP Session-Sender and > Session-Reflector is to use the NTP 64-bit timestamp format (Z field value > of 0)" is safer. > > -Ben > > > > > > > > > > > > > > Section 8.2 > > > > > > > > > > RFC 2104 needs to be a normative reference. The truncation of the > HMAC > > > > > is simple enough that we probably don't need to consider RFC 4868 > > > > > normative just for it, though. > > > > > > > > > GIM>> Agreed and moved to the Normative list though it causes > Downref: > > > > ** Downref: Normative reference to an Informational RFC: RFC 2104 > > > > > > RFC 2104 is already listed at > https://datatracker.ietf.org/doc/downref/ so > > > there's no issue with the downref. > > > > > > Thanks, > > > > > > Ben > > > > >
- [ippm] Benjamin Kaduk's Discuss on draft-ietf-ipp… Benjamin Kaduk via Datatracker
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Mirja Kuehlewind