Hi Benjamin Thanks for the comments - please see [Jon] below.
Cheers Jon -----Original Message----- From: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: 02 April 2018 19:20 To: The IESG <i...@ietf.org> Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric <julien.meu...@orange.com>; pce-cha...@ietf.org; julien.meu...@orange.com; pce@ietf.org 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 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 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
