Subject: [Pce] RtgDir review: draft-ietf-pce-association-diversity-08.txt

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 12 Aug 2019 15:18:39 +0200

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-pce-association-diversity-08.txt
Reviewer: Emmanuel Baccelli
Review Date: 12/08/2019
Intended Status: Standards Track

Summary of comments:

    The procotol extension is simple, and its operation is documented
pretty well.
    The document is concise, and clear from my point of view.
    See below a couple of remarks that could be considered prior to
publication.

Major Issues:

    No major issues found.

Minor Issues:

    In Section 5 (Security): If I understand correctly, dynamically adding
a new LSP to an existing disjoint association affects the (re)computation
and the (re)characterization of all LSPs in this association. In this case,
is it entirely obvious to me that there is no specific threat using the
attack vector of adding an LSP to an existing association, when flag T is
set?
What is the state of other LSPs in an existing association after another
LSP was added, which resulted in the required disjointness now fails?

Nits:

    In Section 3 (Motivation): In my opinion, this section might benefit
from being split in two: a pure motivation section, and an applicability
section.

    In Section 4.1: it is stated that "a PCE may be limited in the number
of LSPs it can take into account when computing disjointness" [...] "the
PCE may provide no path, a shortest path, or a constrained path based on
relaxing disjointness, etc.  The disjoint status is informed to the PCC."
Here, it would be useful to forward reference to section 4.6.

    In section 4.6: the spec seems to suppose that there exists an absolute
order ranking different levels of disjointness,
such that a PCE can simply take the decision to "reduce disjointness" to
the next best level.
I suspect that this is not always easy to rank in complex cases, if at all
possible.

Are some more flags foreseen (tbd in section 6.2 ?) for more fine-grained
characterization of "relaxed disjointness" in complex cases e.g. when
adding an LSP to an already-large disjoint association ?
I assume the answer is "not really".

Assuming the above, without becoming too ugly, specification could be more
explicit about ranking levels of disjointness which relaxing decisions
should be made, when flag T is unset.
Else, the spec could add a clarifying sentence on the difficulty of
ordering absolutely many different levels of disjointness for many LSPs, in
the same association.

---

From: Mahend Negi <[email-masked]>
Date: Tue, 13 Aug 2019 20:28:38 +0530

Hi Emmanuel,

Thanks for your comments. Please see inline, do find attached reworked
draft and version-diff for reference.

> attack vector of adding an LSP to an existing association, when flag T is

When T flag is set, we would have a case of no-path for the new LSP. It
would be good to also indicate that the new LSP could not be added into the
association group. I have added text for this.

> LSP was added, which resulted in the required disjointness now fails?

The other LSPs would not be impacted. So as such there is no specific
security threat with T flag. But, it would be good to add some generic
text. Updated section -

6. Security Considerations

This document defines one new type for association, which on itself does
not add any new security concerns beyond those discussed in

[RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, adding of a
spurious LSP into the disjointness association group

could lead to re-computation and set-up of all LSPs in the group, that
could be used to overwhelm the PCE and the network.

Also, as stated in [I-D.ietf-pce-association-group], much of the
information carried in the Disjointness Association object, as per

this document is not extra sensitive. It often reflects information that
can also be derived from the LSP Database, but association

provides a much easier grouping of related LSPs and messages. The
disjointness association could provide an adversary with the

opportunity to eavesdrop on the relationship between the LSPs. Thus
securing the PCEP session using Transport Layer Security (TLS)

[RFC8253], as per the recommendations and best current practices in
[RFC7525], is RECOMMENDED.

> from being split in two: a pure motivation section, and an applicability

OK

> Here, it would be useful to forward reference to section 4.6.

OK

>
>     In section 4.6: the spec seems to suppose that there exists an
> absolute order ranking different levels of disjointness,

Added (as it deems fit).

> I assume the answer is "not really".
Your assumption is right.

> should be made, when flag T is unset.
I think, adding "as it deems fit" is better and let implementations decide
with protocol signalling the result.

> ordering absolutely many different levels of disjointness for many LSPs, in
Do you still feel this to be necessary? I am not too sure.

Thanks!

_______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 26 Aug 2019 12:39:21 +0200

Dear Mahend

thanks for you answers. Your changes look fine to me.

Two last nits:

- in the sentence you added in section 5.6 when the T flag is set, "In case
of other PCEP message, the PCE MUST return a PCErr message with Error-Type
26".
=> PCEP message other than what? This is not crystal clear. I suggest you
clarify explicitly.

- in the sentence you added in section 5.6 when the T flag is unset, "the
PCE is allowed to relax disjointness by either applying a requested
objective function (Section 5.4) if specified.  Otherwise the PCE is
allowed to reduce the required level   of disjointness (as it deems fit)"
=> as-is, there seems to be a typo: a spurious "either". How about:

"the PCE is allowed to relax disjointness by applying a requested objective
function (Section 5.4) if specified. Otherwise, if no objective function is
specified, the PCE is allowed to reduce the required level of disjointness
as it deems fit"

Cheers

Emmanuel

On Tue, Aug 13, 2019 at 4:58 PM Mahend Negi <[email-masked]> wrote:

>>     In Section 5 (Security): If I understand correctly, dynamically
>> adding a new LSP to an existing disjoint association affects the
>> (re)computation and the (re)characterization of all LSPs in this
>> association. In this case, is it entirely obvious to me that there is no
>> specific threat using the attack vector of adding an LSP to an existing
>> association, when flag T is set?
>>
>
> [RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, adding of
> a spurious LSP into the disjointness association group
>
>> I suspect that this is not always easy to rank in complex cases, if at
>> all possible.
>>
>
> Added (as it deems fit).
>
>
>> Assuming the above, without becoming too ugly, specification could be
>> more explicit about ranking levels of disjointness which relaxing decisions

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 27 Aug 2019 16:26:34 +0530

Hi Emmanuel,

Thanks for you review, the last two nits seems reasonable to me.

Regards,
Dhruv

On Mon, Aug 26, 2019 at 4:09 PM Emmanuel Baccelli
<[email-masked]> wrote:
> - in the sentence you added in section 5.6 when the T flag is set, "In case of other PCEP message, the PCE MUST return a PCErr message with Error-Type 26".
> => PCEP message other than what? This is not crystal clear. I suggest you clarify explicitly.
>
> - in the sentence you added in section 5.6 when the T flag is unset, "the PCE is allowed to relax disjointness by either applying a requested objective function (Section 5.4) if specified.  Otherwise the PCE is allowed to reduce the required level   of disjointness (as it deems fit)"
> "the PCE is allowed to relax disjointness by applying a requested objective function (Section 5.4) if specified. Otherwise, if no objective function is specified, the PCE is allowed to reduce the required level of disjointness as it deems fit"
>
> Cheers
>
> Emmanuel
>
>> Thanks for your comments. Please see inline, do find attached reworked draft and version-diff for reference.
>>
>>
>> On Tue, Aug 13, 2019 at 3:21 AM Emmanuel Baccelli <[email-masked]> wrote:
>>>
>>> Hello,
>>>
>>> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>>
>>> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
>>>
>>>     The procotol extension is simple, and its operation is documented pretty well.
>>>     See below a couple of remarks that could be considered prior to publication.
>>>
>>> Major Issues:
>>>
>>>     No major issues found.
>>>
>>> Minor Issues:
>>>
>>>     In Section 5 (Security): If I understand correctly, dynamically adding a new LSP to an existing disjoint association affects the (re)computation and the (re)characterization of all LSPs in this association. In this case, is it entirely obvious to me that there is no specific threat using the attack vector of adding an LSP to an existing association, when flag T is set?
>>
>>
>> When T flag is set, we would have a case of no-path for the new LSP. It would be good to also indicate that the new LSP could not be added into the association group. I have added text for this.
>>
>>> What is the state of other LSPs in an existing association after another LSP was added, which resulted in the required disjointness now fails?
>>
>>
>> The other LSPs would not be impacted. So as such there is no specific security threat with T flag. But, it would be good to add some generic text. Updated section -
>>
>> This document defines one new type for association, which on itself does not add any new security concerns beyond those discussed in
>>
>> [RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, adding of a spurious LSP into the disjointness association group
>>
>> could lead to re-computation and set-up of all LSPs in the group, that could be used to overwhelm the PCE and the network.
>>
>>
>> Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object, as per
>>
>> this document is not extra sensitive. It often reflects information that can also be derived from the LSP Database, but association
>>
>> provides a much easier grouping of related LSPs and messages. The disjointness association could provide an adversary with the
>>
>> opportunity to eavesdrop on the relationship between the LSPs. Thus securing the PCEP session using Transport Layer Security (TLS)
>>
>> [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED.
>>
>>
>>
>>>
>>> Nits:
>>>
>>>     In Section 3 (Motivation): In my opinion, this section might benefit from being split in two: a pure motivation section, and an applicability section.
>>
>>
>> OK
>>>
>>>
>>>     In Section 4.1: it is stated that "a PCE may be limited in the number of LSPs it can take into account when computing disjointness" [...] "the PCE may provide no path, a shortest path, or a constrained path based on relaxing disjointness, etc.  The disjoint status is informed to the PCC."
>>>     In section 4.6: the spec seems to suppose that there exists an absolute order ranking different levels of disjointness,
>>> such that a PCE can simply take the decision to "reduce disjointness" to the next best level.
>>> I suspect that this is not always easy to rank in complex cases, if at all possible.
>>
>>
>> Added (as it deems fit).
>>
>>
>>>
>>> Are some more flags foreseen (tbd in section 6.2 ?) for more fine-grained characterization of "relaxed disjointness" in complex cases e.g. when adding an LSP to an already-large disjoint association ?
>>> Assuming the above, without becoming too ugly, specification could be more explicit about ranking levels of disjointness which relaxing decisions should be made, when flag T is unset.
>>
>> I think, adding "as it deems fit" is better and let implementations decide with protocol signalling the result.
>>
>>
>>>
>>> Else, the spec could add a clarifying sentence on the difficulty of ordering absolutely many different levels of disjointness for many LSPs, in the same association.
>>

---

From: Mahend Negi <[email-masked]>
Date: Sat, 31 Aug 2019 15:23:20 +0530

Hi Emmanuel,

Thanks for your review, updated in the new version.

FYI:
New Version:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-10
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-10

Regards,
Mahendra

On Mon, Aug 26, 2019 at 4:09 PM Emmanuel Baccelli <
[email-masked]> wrote:

> - in the sentence you added in section 5.6 when the T flag is set, "In
> case of other PCEP message, the PCE MUST return a PCErr message with
> Error-Type 26".
> "the PCE is allowed to relax disjointness by applying a requested
> objective function (Section 5.4) if specified. Otherwise, if no objective
> function is specified, the PCE is allowed to reduce the required level of
> disjointness as it deems fit"
>
> Cheers
>
> Emmanuel
>
>>>     In Section 4.1: it is stated that "a PCE may be limited in the
>>> number of LSPs it can take into account when computing disjointness" [...]
>>> "the PCE may provide no path, a shortest path, or a constrained path based
>>> on relaxing disjointness, etc.  The disjoint status is informed to the
>>> PCC."
>>> Are some more flags foreseen (tbd in section 6.2 ?) for more
>>> fine-grained characterization of "relaxed disjointness" in complex cases
>>> e.g. when adding an LSP to an already-large disjoint association ?
>> I think, adding "as it deems fit" is better and let implementations
>> decide with protocol signalling the result.
>>
>>