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

[Greg Mirsky <[e-mail]>]

Hi Ben,
thank you for the clarifications and suggested text that improves the
document. Please find my answers and notes below tagged GIM2>>.
Attached is the new working version and its diff to -07 (including the
new Location TLV section).

Regards,
Greg

PS. I've clipped the COMMENTS as these now have the discussion thread
of their own.

On Thu, Jul 16, 2020 at 7:48 PM Benjamin Kaduk <[e-mail]> wrote:
>
> Hi Greg,
>
> On Thu, Jul 16, 2020 at 05:38:08PM -0700, Greg Mirsky wrote:
> > Hi Benjamin,
> > thank you for your thorough review and insightful comments (and DISCUSSes,
> > of course).
> > I hope it will be okay if I start with addressing DISCUSSes and split
> > comments resolution into a separate thread(s).
>
> Of course!
>
> > Hence, I've added my answers and notes in-line under tag GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Tue, Jul 14, 2020 at 7:30 PM Benjamin Kaduk via Datatracker <
> > [e-mail]> wrote:
> >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-ippm-stamp-option-tlv-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-option-tlv/
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > I support Roman's discusses and am happy to see the ongoing discussion
> > > thereof.
> > >
> > > (1) I think there's a conflict between this document and RFC 8762 with
> > > respect to the behavior of pure RFC 8762 implementations that receive
> > > packets longer than the base packet for the given operational mode.
> > >
> > > RFC 8762 says (Section 4.3):
> > >
> > > % The Session-Reflector receives the STAMP-Test packet and verifies it. If
> > > % the base STAMP-Test packet is validated, the Session-Reflector that
> > > % supports this specification prepares and transmits the reflected test
> > > % packet symmetric to the packet received from the Session-Sender copying
> > > % the content beyond the size of the base STAMP packet (see Section 4.2).
> > >
> > > But Section 4 of this document says:
> > >
> > >                                                    A Session-Reflector
> > >    that does not support STAMP extensions is not expected to compare the
> > >    value in the Length field of the UDP header and the length of the
> > >    STAMP base packet.  Hence the Session-Reflector will transmit the
> > >    base STAMP packet.  [...]
> > >
> > > Does "will transmit the base STAMP packet" mean something other than
> > > "with the exact length of the base packet [for the given operational
> > > mode]"?
> > >
> > GIM>> Thank you for pointing out the text in RFC 8672. I agree that text in
> > the draft requires re-work. Would the following update make it consistent
> > with RFC 8762 (I will accept your suggestion to change the use of the U
> > flag so that the Session-Sender sets it to 1 on the transmission. Thus if
> > the Session-Sender receives a TLV flag set to 1 in the reflected packet it
> > MUST skip the TLV):
> > OLD TEXT:
> >    A Session-Reflector
> >    that does not support STAMP extensions is not expected to compare the
> >    value in the Length field of the UDP header and the length of the
> >    STAMP base packet.  Hence the Session-Reflector will transmit the
> >    base STAMP packet.  It is the local policy on the Session-Sender
> >    (similar to the handling of SSID == 0 scenario described in
> >    Section 3) that will control the sender's behavior.
> > NEW TEXT:
> >    A Session-Reflector
> >    that does not support STAMP extensions will not process but copy them
> >    into the reflected packet, as defined in Section 4.3 [RFC8762].  The
> >    Session-Sender receives unprocessed TLV indicated by the U flag being
> >    set to 1.
>
> This should make us consistent with RFC 8762, yes.  I think it might be
> worth reminding the reader that the Session-Sender will know if it is
> talking to a Session-Reflector that does not support STAMP extensions,
> because such Session-Reflectors will send a zeroed SSID, though I guess
> that behavior is already mentioned a couple sentences later, so maybe it
> would be redundant here.
>
> I'd suggest rewording the last sentence (of the new text) to someething
> like "a Session-Sender that supports TLVs will indicate specific TLVs that
> it did not process by setting the U flag to 1 in those TLVs", to help
> reinforce that the U flag will only be set by a Session-Reflector that
> supports extensions/this document at all.

GIM2>> Thank you for the suggested text Accepted and it reads as:
NEW TEXT:
   A Session-Reflector
   that does not support STAMP extensions will not process but copy them
   into the reflected packet, as defined in Section 4.3 [RFC8762].  A
   Session-Reflector that supports TLVs will indicate specific TLVs
   that it did not process by setting the U flag to 1 in those TLVs.
>
> > >
> > > (2) As I remarked on (then-) draft-ietf-ippm-stamp, I think we need to
> > > require some level of cryptographic protection whenever control
> > > information is included in a Session-Sender's test packet.  That is,
> > > that a Session-Reflector MUST NOT act on control information received in
> > > unauthenticated packets, and specifically, that the HMAC TLV must be
> > > used, since the base authenticated STAMP packet's HMAC does not cover
> > > the options.
> > >
> > GIM>> The use of the HMAC TLV is required in the authenticated mode STAMP:
> >    The keyed Hashed
> >    Message Authentication Code (HMAC) TLV MUST be included in a STAMP
> >    test packet in the authenticated mode, excluding the case where the
> >    only TLV present is the Extra Padding TLV.
> > We can require that in unauthenticated STAMP mode some TLVs be accompanied
> > by the HMAC TLV. Would mitigate the exposure of the Session-Reflector?
> > Which TLVs, in your opinion, require such a requirement?
GIM2>> I have some reservations to say that a particular TLV MUST be
accompanied by the HMAC TLV. If a domain secured, an operator may use
a TLV, e.g., CoS TLV, without authentication. I think that the current
text:
   The HMAC TLV MAY be used to protect the integrity of STAMP extensions
   in STAMP unauthenticated mode.
can be expanded to require that an implementation can enable
authentication of extensions via the management plane. It might be as:
NEW TEXT:
   The HMAC TLV MAY be used to protect the integrity of STAMP extensions
   in STAMP unauthenticated mode.  An implementation of STAMP extensions
   MUST provide controls to enable the integrity protection of STAMP
   extensions in STAMP unauthenticated mode.
Would the updated text be acceptable?


>
> I think the idea was to require the HMAC TLV to accompany those TLVs that
> represent "control information", yes.  My initial read of the document
> (reflected in my longer comments) says that the Location and Timestamp
> Information TLVs would be considered to contain such "control information",
> though on reread perhaps the Timestamp Information is not always considered
> sensitive.  I'm on the fence about Location, and I think that Class of
> Service is pretty clearly on the "control information" side of things
> (since it affects the headers of the containing IP packet and consequently
> the behavior of the network).

GIM2>> I agree that CoS is very close to what we consider "control
information" as it includes information that affects how the reflected
test packet is transmitted. But as in RFC 8762 itself, HMAC TLV is
defined as optional in STAMP unauthenticated mode and, as I think of
it, that leaves the choice to an operator whether to protect the
integrity of the CoS TLV or not. Do you think that such arrangement is
acceptable?

>
> > >
> > > (3) The secdir reviewer's question about dealing with 6-to-4 gateways
> > > seems to have not gotten a response.  Specifically, the requirement that
> > > "[t]he Session-Reflector MUST validate the Length value against the
> > > address family of the transport encapsulating the STAMP test packet"
> > > seems to require the protocol to fail when sender and reflector use
> > > different address families, or perhaps to require the sender to use
> > > trial and error to determine which address family is used by the
> > > reflector.  Some clarification on the intended operation in such
> > > scenarios seems appropriate.
> > >
> > GIM>> I've misunderstood the question and thank you for clarifying the
> > scenario. I now see that IP addresses in the Location TLV must allow
> > explicit signaling of the address family while providing space for IPv6.
> > So, we introduce sub-TLVs and a new sub-registry for IANA. Does that sound
> > reasonable? I'll work on details if you agree with the proposed approach.
>
> That sounds like it would work.
>
> > >
> > > (4) The ability for a Session-Sender to (MUST-level!) control the DSCP
> > > codepoint used by packets generated by a Session-Reflector feels like it
> > > opens up significant risk in site-local (security-relevant) policy.  That
> > > is, the interpretation of the DSCP codepoints is to large extent
> > > site-specific, and allowing a nominally external system to set any/all
> > > possible values, without a chance for site policy to be applied and
> > > block the use of potentially disruptive DSCP values.  So I think we need
> > > to modify the "MUST set", perhaps requiring that either the requested
> > > DSCP value is used or the entire TLV/packet/whatever is rejected.
> > >
> > GIM>> Perhaps we can add a note in the security section that an
> > implementation must control the support of each TLV. In other words, a
> > particular TLV can be disabled for the given test session. Alternatively,
> > the CoS TLV might require the use of the HMAC TLV. I think that the first
> > option is sufficient. What do you think? Or would you suggest an entirely
> > different approach?
>
> I think my previous replies here combine to say that use of the CoS TLV
> should require ues of the HMAC TLV, but I think it's also good to let an
> implementation control the support for each TLV as you propose.  My
> intuition is still saying that a separate local policy filter should be
> available, though -- just because the peer is authenticated does not
> inherently grant them privilege to set arbitrary DSCP values.  In some
> sense this is the classic distinction between authentication and
> authorization.  In some networks, setting some DSCP values might require
> more privilege than setting other such values, and the simple
> "authenticated or not" knob provided by the HMAC TLV doesn't allow us to
> express that distinction.  (I'm thinking about scenarios where setting a
> particular DSCP value privileges the enclosed packet to such a degree that
> other traffic on the network suffers significantly as a result -- a "drop
> everything and move this packet!" bit, if you will.)
GIM2>> Yes, I agree that the CoS TLV might become another loaded gun
ith which an operator shoots himself/herself in the foot. Well, one
more in a large arsenal we've provided them over the years. I envision
that the CoS TLV might be very useful during the service activation
testing and then exercising that "drop everything and move this
packet!" marking seems reasonable. On the other hand, using the same
marking as part of in-service testing requires analysis and
consideration. Do you think that additional text to explain the
possible impact of CoS TLV on the production network is needed?
>
> > >
> > > (5) If we're not going to remedy the severability of authenticated
> > > options from authenticated base packets (which would be my preferred
> > > resolution), we need to document that weakness in the security
> > > considerations.
> > >
> > GIM>> I think that the document does require HMAC TLV is used in the
> > authenticated mode.  Please see my comments to DISCUSS #2. Would you agree?
>
> I think my point didn't make it through properly, sorry.
>
> The issue is not that we need to authenticate both the "base part" and the
> "extensions part", but rather that we need a way to say that "base part of
> packet 1" and "extensions part of packet 1" go together.  Right now, with
> two separate HMACs, the Session-Reflector would happily process a packet
> that has "base part of packet 1" and "extensions part of packet 2" and not
> even notice that anything was wrong.  (A similar thing could be done to
> responses processed at the Session-Sender, of course.)  That is, I can
> freely "mix and match" authenticated base parts and authenticated
> extensions parts (as an on-path attacker).  Including as input to one of
> the HMAC calls a unique value from the other part of the packet will be
> enough to tie the two together, and let the recipient detect the
> modification.  The most promising candidates for such a "unique per-packet
> value" would be the HMAC output itself and the packet sequence number.
> Using the HMAC value itself is a more robust cryptographic construction (in
> that it authenticates the entire other part by reference), but I suspect
> that we'll have to use the sequence number due to implementation
> (performance) concerns -- needing to wait for the first HMAC before
> extensions can be finalized seems like it would introduce unwanted delay in
> the timestamping.  Assuming that implementations actually check the
> sequence number for repeats, that should still provide enough protection.
>
> Thanks,
>
> Ben
>
> > >
> > >