On Mon, Apr 16, 2018 at 03:43:33PM +0000, Jonathan Hardwick wrote: > Hi Benjamin > > Thanks for the comments - please see [Jon] below. > > Cheers > Jon > > > -----Original Message----- > From: Benjamin Kaduk [mailto:[email protected]] > Sent: 02 April 2018 19:20 > To: The IESG <[email protected]> > Cc: [email protected]; Julien Meuric > <[email protected]>; [email protected]; [email protected]; > [email protected] > Subject: Benjamin Kaduk's No Objection on draft-ietf-pce-lsp-setup-type-09: > (with COMMENT) > > <snip> > > I'm concerned about defining the space for optional sub-TLVs in > PATH-SETUP-TYPE-CAPABILITY but not giving much description of how future > sub-TLVs would work (since none are currently defined). Is there expected to > be a one-to-one mapping from PST to sub-TLV, or one-to-many, or something > else? If a given sub-TLV can be associated with more than one PST, some rules > would need to be specified for how that mapping works, what dependency there > is on the order in which sub-TLVs appear in the message, etc. I am not > balloting DISCUSS because I suspect the intent is for each sub-TLV to > correspond to exactly one PST, in which case the behavior is pretty easy. > But I would like to see more description of how this is expected to work. > > [Jon] The intent is for zero or one sub-TLV per path setup type, with each > sub-TLV applying to exactly one path setup type. How about this change: > > OLD > A list of sub-TLVs associated with the supported PSTs. > NEW > A list of sub-TLVs associated with the supported PSTs. Each PST has zero > or one sub-TLVs associated with it, and each sub-TLV is associated with > exactly one PST. > END
Sounds good. > > Both new TLVs have 'Reserved' fields that MUST be set to zero. Should they > be ignored on receipt (to allow for potential future use as an extension) or > can the receiver validate that they are zero? > > [Jon] Yes they should be ignored on receipt - fixed. > > > > The Security Considerations defer to RFCs 5440 and 8281, which (as the secdir > review notes) is mostly okay. RFC 5440 does have a long discussion of the > value of TCP authentication, but IIUC it does not mandate that TCP > authentication be used. That would leave open the possibility that an > attacker (e.g., TCP MITM) could generate error messages when a particular PST > is used, potentially forcing the use of a different PST, and this attacker > capability seems to be new in this document. As such, it would merit a > mention in the Security Considerations. (This attack only becomes relevant in > the face of some additional weakness or flaw in a PST that makes forcing its > use advantageous to the attacker for other reasons.) > > [Jon] How about we add the following to the security considerations? > > NEW > Note that, if the security mechanisms of [RFC5440] and [RFC8281] are not > used, then the protocol described by this draft could be attacked in the > following new way. An attacker, using a TCP man-in-the-middle attack, could > inject error messages into the PCEP session when a particular PST is (or is > not) used. By doing so, the attacker could potentially force the use of a > specific PST, which may allow them to subsequently attack a weakness in that > PST. > END That captures what I was describing; thanks again. -Benjamin _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
