Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-stamp-option-tlv-09: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Ben,
thank you for the discussion and thoughtful suggestions. Please find my
answers and notes in-line below tagged GIM>>.

Regards,
Greg

On Mon, Nov 9, 2020 at 9:22 PM Benjamin Kaduk <[e-mail]> wrote:

> A timely reminder; as it happens this was on my list to look at today as
> well :)
>
> I'm happy to report that the editor's copy looks to resolve my Discuss
> points on the -09; thank you!  Adding the Reverse Path field to indicate
> that the requested DSCP could not be used seems to be a fairly elegant
> approach (since we have bits to spare).
>
GIM>> Thank you for your kind words.

>
> The other changes look good, too, and pick up almost all my other comments.
> That said, I couldn't (quickly) find anything to indicate that we had
> already
> talked about my top-level comment point regarding the protection of the
> HMAC TLV and the potential for replayed packets.  While I recognize that
> there is a sequence number in the base STAMP packet format, STAMP itself
> does not seem to make many requirements on, e.g., processing packets in
> sequence number order or rejecting very old packets.  Since STAMP is a
> measurement protocol, I don't think we would need to change much of the
> STAMP behavior just because we can get some moderate level of
> action/information from the Session-Reflector (or just because the
> packet is authenticated by the HMAC, not that such reasoning would make
> much sense).  AFAICT, though, we should have some caveat in the security
> considerations that while the HMAC TLV protects the integrity of the
> extensions, it does not protect against replay.
>
GIM>> I propose to update the first paragraph in the Security
Considerations section:
OLD TEXT:
   This document defines extensions to STAMP [RFC8762] and inherits all
   the security considerations applicable to the base protocol.
   Additionally, the HMAC TLV is defined in this document to protect the
   integrity of optional STAMP extensions.  The use of HMAC TLV is
   discussed in detail in Section 4.8.
NEW TEXT:
   This document defines extensions to STAMP [RFC8762] and inherits all
   the security considerations applicable to the base protocol.
   Additionally, the HMAC TLV is defined in this document.  Though the
   HMAC TLV protects the integrity of STAMP extensions; it does not
   protect against a replay attack.  The use of HMAC TLV is discussed in
   detail in Section 4.8.
Does the update address your concern?

>
> I'm happy to approve posting of a -10 during the submissions blackout
> if that will help get things moving again.
>
GIM>> Thank you for your kind offer. If the update listed above is
acceptable, I'll post -10 once the submission opens.

>
> Thanks, and sorry again for the slowness of my responses on this one.
>
> -Ben
>
> On Mon, Nov 09, 2020 at 02:08:37PM -0800, Martin Duke wrote:
> > Ping?
> >
> > On Tue, Oct 6, 2020 at 12:06 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > > Hmm, my notes have this one as waiting on me to look at the latest
> updates,
> > > though there are a few other documents currently in front of it in my
> > > priority queue.
> > >
> > > -Ben
> > >
> > > On Tue, Oct 06, 2020 at 12:04:28PM -0700, Martin Duke wrote:
> > > > I believe the current status of this is that Ben is awaiting another
> > > > version of this draft to resolve his DISCUSS. If anyone has a
> different
> > > > understanding, please say so.
> > > >
> > > > On Thu, Sep 3, 2020 at 12:44 PM Greg Mirsky <[e-mail]>
> > > wrote:
> > > >
> > > > > Hi Ben,
> > > > > thank you for your comments and suggestions, all are much
> appreciated.
> > > > > Please find my notes in-lined below tagged by GIM>>. Attached are
> the
> > > diff
> > > > > and the new working version of the draft.
> > > > >
> > > > > Regards,
> > > > > Greg
> > > > >
> > > > > On Tue, Sep 1, 2020 at 8:55 PM Benjamin Kaduk via Datatracker <
> > > > > [e-mail]> wrote:
> > > > >
> > > > >> Benjamin Kaduk has entered the following ballot position for
> > > > >> draft-ietf-ippm-stamp-option-tlv-09: 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-option-tlv/
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> ----------------------------------------------------------------------
> > > > >> DISCUSS:
> > > > >>
> ----------------------------------------------------------------------
> > > > >>
> > > > >> Thanks for all the updates; we've made good progress.
> > > > >>
> > > > >> I think we're still not converged on the DSCP handling, though.  I
> > > have
> > > > >> a bit more exposition in the COMMENT section, but in short, my
> > > > >> understanding is that we're setting up a session-reflector to
> incur
> > > > >> unbounded levels of risk with hard protocol requirements.  I
> think we
> > > > >> need to provide a way to bound that risk, for example by allowing
> the
> > > > >> Session-Reflector to selectively choose to treat the CoS TLV as
> > > > >> unimplemented (set the U flag in its reflected packet) or some
> other
> > > > >> mechanism for local policy to filter what DSCP codepoints are set
> in
> > > > >> reflected packets (ideally, indicating that the policy made a
> change).
> > > > >>
> > > > > GIM>> Thank you for pointing to the inter-QoS domain scenario.
> > > Clearly, it
> > > > > must be handled with more caution. Using the U flag is a very
> > > interesting
> > > > > approach. But wouldn't the Session-Sender skip the CoS TLV in the
> > > reflected
> > > > > packet? As a result, we may not retrieve information about the CoS
> > > mapping
> > > > > in the forward direction, i.e., towards the Session-Reflector. And
> it
> > > might
> > > > > be difficult for an operator to recognize whether the
> Session-Reflector
> > > > > doesn't support the particular CoS or STAMP extensions altogether.
> I
> > > would
> > > > > propose a new field being added in the CoS TLV:
> > > > >
> > > > >    -    RP (Reverse Path) - is a two-bit-long field.  A
> Session-Sender
> > > > >       MUST set the value of the RP field to 0 on transmission.
> > > > >
> > > > > And further in the section another update:
> > > > >    A STAMP Session-Reflector that receives a test packet with the
> CoS
> > > > >    TLV MUST include the CoS TLV in the reflected test packet.
> Also,
> > > the
> > > > >    Session-Reflector MUST copy the value of the DSCP and ECN
> fields of
> > > > >    the IP header of the received STAMP test packet into the DSCP2
> field
> > > > >    in the reflected test packet.  Finally, the Session-Reflector
> MUST
> > > > >    use the local policy to verify whether the CoS corresponding to
> the
> > > > >    value of the DSCP1 field is permitted in the domain.  If it is,
> the
> > > > >    Session-Reflectorset MUST set the DSCP field's value in the IP
> > > header
> > > > >    of the reflected test packet equal to the value of the DSCP1
> field
> > > of
> > > > >    the received test packet.  Otherwise, the Session-Reflector
> MUST use
> > > > >    the DSCP value of the received STAMP packet and set the value
> of the
> > > > >    RP field to 1.  Upon receiving the reflected packet, if the
> value of
> > > > >    the RP field is 0, the Session-Sender will save the DSCP and ECN
> > > > >    values for analysis of the CoS in the reverse direction.  If the
> > > > >    value of the RP field in the received reflected packet is 1,
> only
> > > CoS
> > > > >    in the forward direction can be analyzed.
> > > > >
> > > > > Would these updates address your concern?
> > > > >
> > > > >>
> > > > >> Also, there's a bit of fallout from the flags reworking that's
> left to
> > > > >> cleanup in Section 4: we now have the Session-Sender set the U
> flag to
> > > > >> 1, so this text no longer makes sense:
> > > > >>
> > > > >> % A STAMP system, i.e., either a Session-Sender or a
> > > Session-Reflector,
> > > > >> % that has received a STAMP test packet with extension TLVs MUST
> > > > >> % validate each TLV:
> > > > >> %
> > > > >> %    If the U flag is set, the STAMP system MUST skip the
> processing
> > > of
> > > > >> %    the TLV.
> > > > >>
> > > > >> I think it should just apply to the Session-Sender for this case
> --
> > > the
> > > > >> Session-Reflector doesn't need to check the received U flag,
> since the
> > > > >> Session-Sender will not be generating TLVs it does not understand.
> > > > >> (Whether or not to keep the behavior for the M and I flags as
> applying
> > > > >> to both Session-Sender and Session-Reflector vs. just
> Session-Sender
> > > > >> does not immediately seem to be of much consequence.
> > > > >>
> > > > > GIM>> Thank you for catching this. Indeed, that brakes STAMP with
> > > > > extensions. I think that though checking M and I flags of a
> > > > > Session-Reflector should not do any harm, it doesn't seem to have
> any
> > > > > benefits. Hence we may remove the Session-Reflector from the
> sentence
> > > and
> > > > > the updated introduction to the flag processing reads like below:
> > > > >    A STAMP Session-Sender that has received a reflected STAMP test
> > > > >    packet with extension TLVs MUST validate each TLV:
> > > > >
> > > > >>
> > > > >>
> > > > >>
> ----------------------------------------------------------------------
> > > > >> COMMENT:
> > > > >>
> ----------------------------------------------------------------------
> > > > >>
> > > > >> My most significant remaining comments are on the Security
> > > > >> Considerations (Section 6):
> > > > >>
> > > > >> The security of the HMAC mechanism is not complete, since it is
> > > > >> susceptible to replay attack.  As such, when HMAC is in use, it is
> > > > >> important to check that the received sequence numbers are (at
> least
> > > > >> mostly) monotonic and to detect replays.  While replayed packets
> do
> > > not
> > > > >> always indicate an attack (depending on the network technology)
> they
> > > are
> > > > >> still a noteworthy condition, and we should say something about
> > > whether
> > > > >> we expect to produce a response to each received instance or to
> > > suppress
> > > > >> replies to replayed input.
> > > > >>
> > > > > GIM>> Is there a reliable mechanism to distinguish between an
> > > out-of-order
> > > > > duplicated packet and a replayed packet? I've checked RFC 5357
> TWAMP
> > > for
> > > > > any suggestion and believe that there is no special consideration
> by a
> > > > > Session-Reflector for an out-of-order duplicated packet. The TWAMP
> > > > > Session-Reflector does not monitor whether the sequence numbers of
> the
> > > > > received test packets are in the monotonically increasing sequence.
> > > STAMP
> > > > > is designed to be comparable with TWAMP and have some level of
> > > > > interoperability. Hence, discarding what appears as a replayed
> packet
> > > at a
> > > > > STAMP Session-Reflector might be less desirable behavior. If we
> follow
> > > > > TWAMP's behavior, what else can be done at the Session-Reflector to
> > > > > strengthen the security?
> > > > >
> > > > >>
> > > > >>    Monitoring and optional control of DSCP do not appear to
> introduce
> > > > >>    any additional security threat to hosts that communicate with
> STAMP
> > > > >>    as defined in [RFC8762].  As this specification defined the
> > > mechanism
> > > > >>    to test DSCP mapping, this document inherits all the security
> > > > >>
> > > > >> I'm afraid I still don't understand the reasoning here.  In my
> > > > >> understanding, the risk stems from the semantics of the DCSP field
> > > being
> > > > >> (for at least some codepoints) site-local, there not being a
> guarantee
> > > > >> that the session-sender and session-reflector are on the same
> network
> > > > >> (and thus, using the same DSCP semantics), and the hard
> requirement
> > > for
> > > > >> the Session-Reflector to set the DCSP value indicated by the
> > > > >> Session-Sender.  A mechanism for a remote entity to induce
> generation
> > > of
> > > > >> local packets with unspecified semantics is a risk that cannot be
> > > > >> qualified at protocol-design time, since the possible outcomes are
> > > > >> inherently unspecified.  This is analogous to the situation with
> > > > >> undefined behavior in programming languages like C -- the
> programmer
> > > is
> > > > >> flat-out required to avoid it, because literally anything could go
> > > wrong
> > > > >> if undefined behavior is triggered.
> > > > >>
> > > > > GIM>> I agree that the inter-QoS domain case requires more
> > > consideration
> > > > > in the Security section. I propose the updated text below:
> > > > >
> > > > >    As this specification defined the mechanism to test DSCP
> mapping,
> > > > >    this document inherits all the security considerations
> discussed in
> > > > >    [RFC2474].  Monitoring and optional control of DSCP using the
> CoS
> > > TLV
> > > > >    may be used across the Internet so that the Session-Sender and
> the
> > > > >    Session-Reflector are located in domains that use different CoS
> > > > >    profiles.  Thus, it is essential that an operator verifies the
> set
> > > of
> > > > >    CoS values that are used in the Session-Reflector's domain.
> Also,
> > > an
> > > > >    implementation of a Session-Reflector SHOULD support a local
> policy
> > > > >    to confirm whether the value sent by the Session-Sender can be
> used
> > > > >    as the value of the DSCP field.  Section 4.4 defines the use of
> that
> > > > >    local policy.
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> This is especially risky when there is the possibility for the
> > > > >> Session-Reflector to act on packets that do not have any form of
> > > > >> authentication (i.e., could be spoofed from off-path).  But we do
> not
> > > > >> mention this risk at all, let alone give guidance on its
> mitigation.
> > > > >> (Discussion of the security considerations of unauthenticated
> > > operation
> > > > >> would ideally be generalized to all actions/TLVs that have side
> > > effects,
> > > > >> not just the specific case of setting the DSCP codepoint.)
> > > > >>
> > > > > GIM>> It seems very challenging for a STAMP system to differentiate
> > > > > between a duplicate and/or out-of-order test packet and a replayed
> > > packet
> > > > > because one of the metrics STAMP test measures is the network
> > > re-ordering
> > > > > metric per RFC 4737 <https://tools.ietf.org/html/rfc4737>. We may
> > > > > recommend that the rate-limiting of test packets be selected
> > > > > conservatively.
> > > > >
> > > > >>
> > > > >> Section 4.2
> > > > >>
> > > > >> I'd suggest saying that all fields that are not filled are
> transmitted
> > > > >> with all bits set to zero.
> > > > >>
> > > > > GIM>> Thank you for the helpful suggestion. Appended Section 4.2:
> > > > >    Note that all fields not filled by either a Session-Sender or
> > > > >    Session-Reflector are transmitted with all bits set to zero.
> > > > >
> > > > >>
> > > > >> Section 4.2.1
> > > > >>
> > > > >>    o  Source MAC Address sub-TLV - is a 12-octet-long sub-TLV.
> The
> > > Type
> > > > >>       value is TBA9.  The value of the Length field MUST equal to
> 8.
> > > > >>       The Value field is a 12-octet-long MBZ field that MUST be
> zeroed
> > > > >>       on transmission and ignored on receipt.
> > > > >>
> > > > >> Value should be 8-octets-long, no?
> > > > >>
> > > > > GIM>> Thank you for catching it! You are absolutely correct. Fixed
> this
> > > > > and a similar in:
> > > > >    o  Source EUI-64 Address sub-TLV - is a 12-octet-long sub-TLV
> that
> > > > >       includes the EUI-64 source MAC address.  The Type value is
> TBA11.
> > > > >       The value of the Length field MUST equal to 8.  The Value
> field
> > > > >       consists of an eight-octet-long EUI-64 field.
> > > > >
> > > > >
> > > > >
> > > > >> Section 4.2.2
> > > > >>
> > > > >>    A Session-Sender MAY include the Source MAC Address sub-TLV is
> the
> > > > >>    Location TLV.  If the Session-Reflector receives the Location
> TLV
> > > > >>
> > > > >> nit: s/is/in/
> > > > >>
> > > > > GIM>> Thank you. Fixed (and three more places in the same
> sub-section).
> > > > >
> > > > >>
> > > > >> Section 4.3
> > > > >>
> > > > >>    MUST NOT fill any information fields except for STAMP TLV
> Flags,
> > > > >>    Type, and Length.  All other fields MUST be filled with zeroes
> The
> > > > >>
> > > > >> nit: missing full stop.
> > > > >>
> > > > > GIM>> Done.
> > > > >
> > >
>