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

[Roman Danyliw via Datatracker <[e-mail]>]

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/