Subject: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 04 Sep 2019 18:45:16 -0700

Roman Danyliw 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:
----------------------------------------------------------------------

(1) Section 4.3.  The text does not explicitly state the data on which the HMAC
is computed (i.e., bytes 1 to the end of the last MBZ field of the message?)

(2) Section 6.  Per “In general, all the security considerations related to
TWAMP-Test, discussed in [RFC5357] apply to STAMP.”, what exact guidance is
relevant here:

-- Section 6 (Security Considerations) of RFC5357 says follow the guidance of
RFC4656 and guidance on the OWAMP Server-Greeting messages, only the former
seems relevant

-- Section 6 (Security Considerations) of RFC4656 has:

Section 6.1 which discusses authenticated and encrypted mode of OWAMP; but
STAMP has no encrypted mode.  The claims about authenticate mode seem to be
similar to OWAMP, but that’s not explicitly said

Section 6.2 discusses DoS, seems to have some related guidance but also
discusses TCP handshakes

Section 6.3 discusses covert channels, this seems relevant

Section 6.4 seems to discuss key management that section 4.3 of this draft
seems to suggest is out of scope

Section 6.5 seems to provide guidance on resource provisioning but uses the
KeyID primitive that doesn’t appear present in this draft

[please review the other sections too ...]

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Barry Leiba’s DISCUSS.

I also support Magnus Westerlund’s DISCUSS.  See #4.

(2) Section 4.1.1.  The sequence number is defined in terms of a “new session”.
 However, I couldn’t find the precise definition of a “session” – how is new
one initiated?  terminated?

(3) Section 4.2.1.  Per Session-Sender TTL, this field is defined, the guidance
on generating its value is clear, but its use is not explained.

(4) Section 4.3.  Related question to Magnus Westerlund’s DISCUSS, what is the
planned approach for crypto agility?

(5) Section 4.3.  Per, “HMAC uses its own key, and the definition of the
mechanism to distribute the HMAC key is outside the scope of this
specification.”

-- What is being suggested by “uses its own key”?

-- Is it expected that each Session-Sender/Reflector pair would have a unique
key?

-- Recommend being clearer on what’s out of scope, perhaps something on the
order of: s/… the definition of the mechanism to distribute the HMAC key is
outside the scope of this specification./

… key management and the mechanisms to distribute the HMAC key is outside the
scope of this specification.”

(5) Section 4.3.  Thanks for responded to Russ Housley’s SECDIR review and
proposing the new Section 4.3 and 4.4.  It provides helpful clarity.

(6) Editorial Nits
-- Section 3.  I didn’t understand the title of ‘Softwarization of Performance
Management’.  The text of the section seems to simply describe the elements of
Figure 1 and suggests a few ways to configure the these elements.

-- Section 4.  Typo.  s/MUST use received/MUST received/

-- Section 6.  Editorial.  s/Load of STAMP test packets/The load of the STAMP
test packets/

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Sep 2019 15:28:59 -0700

Hi Roman,
thank you for your review of the STAMP draft and my apologies for the
delayed response.
Through discussions with Barry and Magnus, we've updated -07 version and
just published the new one
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-08>. Please
find my answers to your questions, proposed updates in-line below and
tagged GIM>>.
Attached, please find the new working version and the diff between versions
-07 and -09 (the new working version).

Kind regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
GIM>> Yes, the intention is to cover the whole STAMP packet as presented in
the draft for Session-Sender and Session-Reflector. Would adding the
following sentence make it clear:
In the Authenticated mode, HMAC covers the first six blocks (96 octets).

> [please review the other sections too ...]
GIM>> Much appreciate your thorough analysis. Indeed, much of discussion in
RFC 4656 was centered on the security of the control plane, OWAMP-Control,
and is not relevant in case of STAMP. Thus the first sentence in the
Security Considerations section has been replaced with the new paragraph as
below:
OLD TEXT:
   In general, all the security considerations related to TWAMP-Test,
   discussed in [RFC5357] apply to STAMP.
NEW TEXT:
   [RFC5357] does not identify security considerations specific to
   TWAMP-Test but refers to security considerations identified for OWAMP
   in [RFC4656].  Since both OWAMP and TWAMP include control plane and
   data plane components, only security considerations related to OWAMP-
   Test, discussed in Sections 6.2, 6.3 [RFC4656] apply to STAMP.

GIM>> The new section, Operational Considerations, has been added in -08
version to address Barry's DISCUSS.

> one initiated?  terminated?
GIM>> Per discussion with Magnus, defined session as follows:
   In this document, a measurement session also referred to as
   STAMP session, is the bi-directional packet flow between one specific
   Session-Sender and one particular Session-Reflector for a time
   duration.

> on generating its value is clear, but its use is not explained.
GIM>> The operations on the Sender TTL in STAMP are the same as defined in
RFC 5357. There's no specific performance metric associated with the value
in the Sender TTL field. Some implementations may use it to monitor the
stability of the path from the Session-Sender to the Session-Reflector. I'd
imagine that there could be other ways to use it.

> -- What is being suggested by “uses its own key”?
GIM>> The intention was to differentiate from the procedure described in
Section 4.2 Integrity Protection (HMAC) in RFC 4656 how HMAC Session-key is
communicated using the control plane and then HMAC key can be derived based
on HMAC Session-key. Would you suggest changed wording?

> -- Is it expected that each Session-Sender/Reflector pair would have a
GIM>> Ultimately, yes. Each pair of Session-Sender and Session-Reflector
may be using a unique key.

> scope of this specification.”
GIM>> Thank you for the suggested text. Applied in the new working version:
   HMAC uses its own key; key management and
   the mechanisms to distribute the HMAC key is outside the scope of
   this specification.

> Figure 1 and suggests a few ways to configure the these elements.
GIM>> Re-named the section to "Operation and Management of Performance
Measurement Based on STAMP". Is the new title closer to the content of the
section?

> -- Section 4.  Typo.  s/MUST use received/MUST received/
GIM>> Thank you for catching it. Applied in the working version:
   An implementation
   of STAMP Session-Reflector by default MUST receive STAMP test packets
   on UDP port 862.
> -- Section 6.  Editorial.  s/Load of STAMP test packets/The load of the
GIM>> Thank you. Applied.