[ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 September 2019 00:50 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 034CF1208E4; Wed, 4 Sep 2019 17:50:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-ippm-stamp@ietf.org, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, ippm-chairs@ietf.org, tal.mizrahi.phd@gmail.com, ippm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156764462100.22846.16937322291769285829.idtracker@ietfa.amsl.com>
Date: Wed, 04 Sep 2019 17:50:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/wdCSfg8jnaei9jQjJsnSiyn39yc>
Subject: [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
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: Thu, 05 Sep 2019 00:50:22 -0000

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:


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.

This document hardcodes the truncated HMAC-SHA-256 algorithm.  Per BCP
201, what is the procedure for cryptographic algorithm agility?

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).

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?

What error does the error estimate ... estimate?
Clock skew between sender and receiver?

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.

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.

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

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

(I also support Barry and Magnus' Discusses.)


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"

   (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined
   features such as Reflect Octets and Symmetrical Size for TWAMP

comma after TWAMP

   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?

   orchestration) and test functions.  One of such is Performance

"One such mechanism is"

   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".

   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").

   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.

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
(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.)

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.

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.)

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.)

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"?

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?

Section 4.2.2

   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"

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.

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.

   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
(Also (nit), where do we say that NTP is the default format?)

   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.

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.