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 clarifications and further detailing your comments,
questions. Please find my answers and notes below in-lined under the GIM2>>
tag.

Regards,
Greg

On Wed, Sep 11, 2019 at 12:53 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi Greg,
>
> Thanks for the reply. See inline for my comments and response.
>
>
> On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> > 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.
>
> So if I understand this (taking a discussion with Mirja about keeping
> things as simple as possible) the solution is to basically is when need
> arises define a new STAMP version, and then use YANG to coordinate
> which version is used for the measurement. If that is a correct re-
> interpretation of your response then I am fine with it.
>
GIM2>> The direction from the WG was to keep the base specification as
simple  as possible (and that was the reason to split TLV extensions into a
separate document).

>
> > >         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)?
>
> Okay, I don't really care where the discussion happens. But I don't
> find any real discussion and listing of the concerns with using user or
> dynamic ports for STAMP Sessions? With the formulation you use, I would
> expect at least some list of potential concerns that needs to be
> evaluated in the context of the particular usage of STAMP.
>
GIM2>> Per Berry's suggestion, I'm adding a new section, Operational
Considerations, to list possible scenarios and possible issues with using
destination ports from the User range and from the Dynamic range. I hope to
finish it in a couple days. Will share on this discussion thread promptly.

>
> > >
> > > -----------------------------------------------------------------
> > > -----
> > > 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.
>
> So if that is the only? concern then write it out. I would expect that
> the higher layer management protocol that creates a measurement session
> to actually ensure that the STAMP endpoint actually have the port
> numbers they attempt to use. Isn't that a reasonable requirement to put
> on the solution?
>
GIM2>> Agree with your suggestion. Will put in the new section. If STAMP is
managed by a centralized system, whether it is proprietary OSS/BSS or an
orchestrator that uses YANG data models, the system will be able to
coordinate selection of port numbers on the Session-Sender and
Session-Reflector. But some systems may use EMS or CLI and that is where
human coordination may be required.

>
> My thinking with the filtering out concern was that in cases where one
> runs STAMP measurement sessions, if the measurement interfer with
> critical traffic an action for an on-path node that can actually
> identify the STAMP traffic was to filer it out. And that may be
> considered trivial when the well known port is used, but if a user or
> dynamic port is used, then that requries a managment system to provide
> the on-path node with the necessary information, i.e. 3/5 tuple for the
> STAMP flows.
>
GIM2>> I think that a transit node can identify a flow as the STAMP flow
only if the destination port is the STAMP default UDP destination port
number, 862. In case a STAMP session has the destination port number as one
of port numbers from the User range, IP/UDP encapsulation of STAMP packets
would be indistinguishable from packets originated by the application that
is assigned that port number. Thus, filtering out on only destination port
number may negatively affect service, legitimate service. Because of that,
I think that filtering will have to use more information. On the other
hand, if the test flow does not exceed agreed rate, then any filtering test
packets out, in my opinion, is counter-productive, as it hides some issues
in the networks rather than letting the OAM tools to expose them, localize,
and characterize.

>
>
> > >         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.
>
> Yes, please include that definition. Question would it be clearer to
> replace ".. is the session betweeen .." with ".. is the bi-directional
> packet flows between .."?
>
GIM2>> I agree, defining a session as a session makes is somewhat
repetitive. Thank you.
Below is the updated text:
   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.

>
>
> > >         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.
>
> I think you missunderstood. When I talk about clock source, I am
> actually referring to identifying the particular clock that the node
> use to derive the included timestamp from.
>
> And likely this is a moot point in this document where the clock source
> information belongs in the management layer, e.g. in the YANG data
> model.
>
GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/?include_text=1>)
provides information about the clock synchronization protocol and the
method by wich the timestamp has been acquired at a Session-Reflector. We
may extend it to list the name/locatior of the master clock.

>
>
> > >         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. 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?
>
> From my perspective, the fact that optional TLV may occur following the
> base headers appears quite important. Here comes a question of
> intention form the WG. Is it intended that one can have STAMP endpoints
> that do not even support receiving packets larger than the base?
>

> In other words there will be two main versions already now, one that
> supports some TLV and can at least handle the TLV skip forward and
> ignore the content and one that will throw a fit over the TLVs? If that
> is not the intention I think the fact that TLV's may occur should be
> moved into this specification and have it as a normative reference.
>
GIM2>> Will move the reference to the Normative section. With TLV being
normative, I'd expect that the intelligent implementation of this draft, of
the base STAMP specification, will accept any valid STAMP packet though not
process extensions. But the base STAMP Session-Reflector will return the
base reflected packet.

>
> I guess the answer is that you have backwards comaptibility reasons for
> not allowing TLVs at all in some sessions, or?
>
GIM2>> Yes, that and the principle "keep it simple".

>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>