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

[Henrik Nydell <[e-mail]>]

See below for PTP/NTP comment

On Wed, Sep 11, 2019 at 9: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.
>
> > >         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.
>
> > >
> > > -----------------------------------------------------------------
> > > -----
> > > 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?
>
> 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.
>
>
> > >         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 .."?
>
>
> > >         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.
>

In section 4.1.1 of draft-ietf-ippm-stamp there is a definition of the
Z-bit in the error correction field that denotes if the clock source is NTP
or PTP


>
>
> > >         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.
>
> I guess the answer is that you have backwards comaptibility reasons for
> not allowing TLVs at all in some sessions, or?
>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[e-mail]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 


Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.


Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.