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

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund 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:
----------------------------------------------------------------------

Two very much discussing discusses. However, I would really like to hear the
answer to these concerns before clearing.

1. Section 4.3: Is the HMAC field size of 16 bytes hard coded? If there ever
would exist a need to deploy another integrity solution, even if the actual
algorithm used to construct the tag can be agreed by the management, there
appear to exist a hard look in to use 16-byte tags. Have this issue been
considered?

        2. Section 6:
        The possible impact of the
   STAMP test packets on the network MUST be thoroughly analyzed, and
   the use of STAMP for each case MUST be agreed by all users on the
   network before starting the STAMP test session.

        I assume some potential issues are know, shouldn't they really be
        listed here in the security consideration to further motivate why the
        analysis needs to happen.


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

        1. Section 4:
        Before using numbers from the User Ports range, the possible impact
   on the network MUST be carefully studied and agreed by all users of
   the network.

        Is the above sentence missing to list an important assumption? Is the
        assumption that by using the registred destination port an operator
        that sees to much STAMP traffic can simply filter it out and that way
        deal with the traffic, something which is not possible when using an
        locally decided port? If that is the case, this assumption should
        probably be noted.

        2. Section 3 and 4, and 4.1.1: What is a STAMP Session? Is that a
        measurment session between one specific and sender and a specific
        reflector for a time duration?  The defenition of the session do matter
        if one intended to enable a single sender to use multiple reflectors,
        and if that can be a single session or always multiple indepdendent
        ones. Would appreciate a definition what a session is. If it is
        possible to send STAMP traffic using a multicast or broadcast address
        should be made explicit.

        3.  Section 4.1.1.:
        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].

        Is the clock source here something that may be relevant or simply
        information the management functions should capture. I think there is a
        similar issue to that of RTP faced when it comes to understand what the
        timestamp actually represent and thus be used correctly. RTP clock
        source specification is RFC 7273
        (https://datatracker.ietf.org/doc/rfc7273/)

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

        The above text implies some potential for UDP payload size variability
        for the STAMP packets. However, the actual definition appear to have
        fixed sizes. Can you please clarify if I have missed something that
        enables the STAMP packet to have variable size?