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 extremely educational to me discussion, much appreciated.

Regards,
Greg

On Tue, Nov 10, 2020 at 7:49 PM Benjamin Kaduk <[e-mail]> wrote:

> Hi Greg,
>
> Your proposal for the security considerations sounds good to me.
> I look forward to the -10.
>
> -Ben
>
> On Tue, Nov 10, 2020 at 10:08:50AM -0800, Greg Mirsky wrote:
> > 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.
> > > > > > >
> > > > >
> > >
>