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

[Magnus Westerlund <[e-mail]>]

On Wed, 2019-09-11 at 11:33 -0700, Greg Mirsky wrote:
> 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). 

Yes, understood. 

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

Great!

Looking forward to review it when written. 

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


Good, then likely this is resolved when your text is ready. 

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

Ok. This was primarily to understand if this was in scope or not. But
it sounds like this is not really in scope for how to manage it. 

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

Looks good to me. 

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

Ok. sounds reasonable. 

> > 
> > > >         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 think that is very reasonable approach. Are you close to complete the
stamp-option-tlv document, or will the missref cause any issue? 

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

Thanks,

To me it looks like with some text changes all my issues are addressed.

Cheers

Magnus Westerlund 


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