Hi Benjamin

Thanks for the comments - please see [Jon] below.


-----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; 
Subject: Benjamin Kaduk's No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)


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:

  A list of sub-TLVs associated with the supported PSTs.
  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.

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?

  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 

Pce mailing list

Reply via email to