Subject: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 02 Apr 2018 11:19:35 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-lsp-setup-type-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

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

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?

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.)

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 16 Apr 2018 15:43:33 +0000

Hi Benjamin

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

Cheers
Jon

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: 02 April 2018 19:20
To: The IESG <[email-masked]>
Cc: [email-masked]; Julien Meuric <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Apr 2018 11:21:22 -0500

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

Sounds good.

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

That captures what I was describing; thanks again.

-Benjamin