Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Benjamin Kaduk]

On Mon, Apr 16, 2018 at 11:35:19AM -0500, Spencer Dawkins at IETF wrote:
> Hi, Jonathan,
> 
> On Mon, Apr 16, 2018 at 10:54 AM, Jonathan Hardwick <
> jonathan.hardw...@metaswitch.com> wrote:
> 
> > Hi Spencer
> >
> > Thanks for your comments.  Please see [Jon] below.
> >
> > Cheers
> > Jon
> >
> > -Original Message-
> > From: Spencer Dawkins [mailto:spencerdawkins.i...@gmail.com]
> > Sent: 03 April 2018 03:23
> >
> > [Jon] I have proposed an update to Benjamin.  The draft does not need any
> > sub-TLVs, hence there are no examples, which has been a frequent pattern in
> > PCE RFCs since the working group got started!  Having said that, we could
> > immediately point to the first real example of a PST sub-TLV by providing
> > an informative reference to draft-ietf-pce-segment-routing.  I don't see
> > a problem doing this as the documents were always intended to be published
> > together.  How about
> >
> > OLD
> >   This document does not define any sub-TLVs.
> > NEW
> >   This document does not define any sub-TLVs; an example can be found in
> > [I-D.ietf-pce-segment-routing].
> > END
> >
> 
> Since I was echoing Benjamin's concern, I'll echo his relief - whatever you
> folks work out, will work for me.
> 
> But that sounds like a fine plan to me.

Having this additional informational reference also sounds good to
me.

-Benjamin

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Jonathan,

On Mon, Apr 16, 2018 at 10:54 AM, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> Hi Spencer
>
> Thanks for your comments.  Please see [Jon] below.
>
> Cheers
> Jon
>
> -Original Message-
> From: Spencer Dawkins [mailto:spencerdawkins.i...@gmail.com]
> Sent: 03 April 2018 03:23
> To: The IESG 
> 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: Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09:
> (with COMMENT)
>
>
> I'll let you folks work with Benjamin on this, but I echo his concern
> about the level of specification covering sub-TLVs (Spencer's summary: "not
> much specification").  As a related comment, I note that not defining any
> sub-TLVs in this document prevents the authors from giving any examples of
> what sub-TLVs might be appropriate, which would have been helpful for me in
> both the Abstract and Introduction.
>
> (I usually prefer clues about whether the reader should be reading a
> specification or not. It would be easier for me to know whether this
> document is relevant to me, if I knew what kinds of sub-TLVs were
> envisioned, even if only a couple of examples were provided. But do the
> right thing, of course)
>
> [Jon] I have proposed an update to Benjamin.  The draft does not need any
> sub-TLVs, hence there are no examples, which has been a frequent pattern in
> PCE RFCs since the working group got started!  Having said that, we could
> immediately point to the first real example of a PST sub-TLV by providing
> an informative reference to draft-ietf-pce-segment-routing.  I don't see
> a problem doing this as the documents were always intended to be published
> together.  How about
>
> OLD
>   This document does not define any sub-TLVs.
> NEW
>   This document does not define any sub-TLVs; an example can be found in
> [I-D.ietf-pce-segment-routing].
> END
>

Since I was echoing Benjamin's concern, I'll echo his relief - whatever you
folks work out, will work for me.

But that sounds like a fine plan to me.

Spencer
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Benjamin Kaduk]

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

Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Hi Spencer

Thanks for your comments.  Please see [Jon] below.

Cheers
Jon

-Original Message-
From: Spencer Dawkins [mailto:spencerdawkins.i...@gmail.com] 
Sent: 03 April 2018 03:23
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: Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)


I'll let you folks work with Benjamin on this, but I echo his concern about the 
level of specification covering sub-TLVs (Spencer's summary: "not much 
specification").  As a related comment, I note that not defining any sub-TLVs 
in this document prevents the authors from giving any examples of what sub-TLVs 
might be appropriate, which would have been helpful for me in both the Abstract 
and Introduction.

(I usually prefer clues about whether the reader should be reading a 
specification or not. It would be easier for me to know whether this document 
is relevant to me, if I knew what kinds of sub-TLVs were envisioned, even if 
only a couple of examples were provided. But do the right thing, of course)

[Jon] I have proposed an update to Benjamin.  The draft does not need any 
sub-TLVs, hence there are no examples, which has been a frequent pattern in PCE 
RFCs since the working group got started!  Having said that, we could 
immediately point to the first real example of a PST sub-TLV by providing an 
informative reference to draft-ietf-pce-segment-routing.  I don't see a problem 
doing this as the documents were always intended to be published together.  How 
about

OLD
  This document does not define any sub-TLVs.
NEW
  This document does not define any sub-TLVs; an example can be found in 
[I-D.ietf-pce-segment-routing].
END


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Jonathan Hardwick]

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


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

Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Thanks for the comments, Alvaro.  Please see [Jon] below.

Cheers
Jon

-Original Message-
From: Alvaro Retana [mailto:aretana.i...@gmail.com] 
Sent: 02 April 2018 19:19
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: Alvaro Retana's No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)



(1) The Length field in S3 has no units.  I'm sure people can guess it is in 
bytes, from the rest of the description, but it should be explicit.

[Jon] OK, fixed.



(2) The Reserved fields "MUST be set to zero".  What happens if they're not? 
Typically they are also ignored by the receiver...

[Jon] New text: "Its reserved field MUST be set to zero by the sender and MUST 
be ignored by the receiver."



(3) S3: "Each sub-TLV MUST obey the rules for TLV formatting defined in 
([RFC5440]).  That is, each sub-TLV MUST be padded to a four byte alignment, 
and the length field of each sub-TLV MUST NOT include the padding bytes."  The 
first sentence is ok.  The second one tries to paraphrase what rfc5440 says -- 
but rfc5440 doesn't say that, it doesn't even use Normative language!  This is 
the text from rfc5440:

   The Length field defines the length of the value portion in bytes.
   The TLV is padded to 4-bytes alignment; padding is not included in
   the Length field (so a 3-byte value would have a length of 3, but the
   total size of the TLV would be 8 bytes).

(3a) The text in this document shouldn't use Normative language to describe 
what rfc5440 says and specifies.

(3b) Note that the text from rfc5440 (specifically the part about "padding is 
not included in the Length field") is not aligned with the description of the 
Length field in this document: "The TLV Length field MUST be equal to the size 
of the appended sub-TLVs plus the size of the PST list (rounded up to the 
nearest multiple of four) plus four bytes."  Rounding up includes the padding.

[Jon] Yes, this area is a bit awkward, and you are correct to point out that 
this wording is flawed.  I agree that any trailing padding bytes ought not to 
be included in the length field, for consistency with the rules in RFC 5440.  
However, we do have to include any intermediate padding bytes in the length.  
For example, if the TLV looked like this:

[TLV] [padding1] [Sub-TLV A] [padding2] [Sub-TLV B] [padding3]

[padding1] pads the PST list to a multiple of 4 bytes.
[padding2] pads sub-TLV A to a multiple of 4 bytes.
[padding3] pads sub-TLV B to a multiple of 4 bytes.

The overall TLV length needs to include padding1 and padding2, but not padding 
3.  The reason: an implementation not recognising this TLV needs to be able to 
skip over it and ignore it.  If the overall length did not include padding1 or 
padding2 then that implementation would skip right into the middle of the 
sub-TLV list and get lost.

I propose the following text, which hopefully addresses your comment.

OLD
  That is, each sub-TLV MUST be padded to a four byte alignment, and the length 
field of each sub-TLV MUST NOT include the padding bytes.
  [...]
  The TLV Length field MUST be equal to the size of the appended sub-TLVs plus 
the size of the PST list (rounded up to the nearest multiple of four) plus four 
bytes.
NEW
  That is, each sub-TLV is padded to a four byte alignment, and the length 
field of each sub-TLV does not include the padding bytes.
  [...]
  If there are no sub-TLVs, then the TLV length field MUST be equal to four 
bytes plus the size of the PST list, excluding any padding bytes.  If there are 
sub-TLVs then the TLV Length field MUST be equal to four bytes plus the size of 
the PST list (rounded up to the nearest multiple of four) plus the size of the 
appended sub-TLVs excluding any padding bytes in the final sub-TLV.
END



(4) S6: "Each document that introduces a new path setup type to PCEP must 
include a manageability section."  Why is a Normative "MUST" not used?

[Jon] This is a requirement on document writers, not on implementations, so I 
thought a normative MUST would not be appropriate here.



(5) rfc6123 is a Historic document.  Maybe a reference to rfc5706 is more 
appropriate (even in addition to rfc6123).

[Jon] Yes, I agree. Fixed.



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce