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: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

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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to