On Mon, Apr 16, 2018 at 03:43:33PM +, 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
> Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric
> ; 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)
>
>
>
> 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
