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

[Greg Mirsky <[e-mail]>]

Hi Magnus,
thank you for the review and thoughtful, pointed questions. Please find my
answers in-line under GIM>> tag.

Regards,
Greg

On Wed, Sep 4, 2019 at 3:54 PM Magnus Westerlund via Datatracker <
[e-mail]> wrote:

> 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?
>
GIM>> Indeed, this specification defines the use of only one algorithm and
only 16 bytes-long HMAC field. Your question prompted the discussion among
authors and we believe that in a future specification it would be feasible
to extend supporting a number of algorithms and different lengths of HMAC
field both being defined through extension to STAMP YANG data model.

>
>         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.
>
GIM>> This is in reference to using numbers from the User range as the
destination port number. Would adding the reference to the case of using
the port numbers from the User range address your concern? Or rather refer
to Section 4, as it includes more discussion (see below)?

>
>
> ----------------------------------------------------------------------
> 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.
>
GIM>> That is a very good point but our primary motivation for this
cautionary note (or strong warning) was that by allowing STAMP to use port
numbers from the User range, ports that may be already assigned to
protocols, creates a DDOS attack vector. As for the filtering STAMP traffic
out, I think that even if the destination port is one from the Dynamic
range, for a relatively long test session it can be filtered out.

>
>         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.
>
GIM>> Your interpretation is correct, STAMP session is implicitly defined
as p2p. And that is what reflected in the STAMP YANG model. Would the
following text make it clearer:
NEW TEXT:
   In this document, a measurement session also referred to as
   STAMP session, is the session between one specific Session-Sender and
   one particular Session-Reflector for a time duration.

>
>         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/)
>
GIM>> NTP and PTP encodings have a different interpretation of the Fraction
field of the Timestamp field. In my experience, PTP format is native for
the data plane, while NTP is more used at the control plane. Original
extension to TWAMP has been described in RFC 8186
<https://datatracker.ietf.org/doc/rfc8186/>.

>
>         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?
>
GIM>> I think that the text can be improved by characterizing the listed
sizes as "base". The variable length of a test packet in STAMP is supported
by using Extra Padding TLV defined in draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>. Below
is the proposed update:
OLD TEXT:
   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.
NEW TEXT:
   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].

With the new reference, should I-D.ietf-ippm-stamp-option-tlv be moved to
the Normative References list or may remain in the Informative list?