Subject: Re: [Isis-wg] Alissa Cooper's Discuss on draft-ietf-isis-te-metric-extensions-09: (with DISCUSS and COMMENT)

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 2 Feb 2016 15:49:33 +0000

Hi Alissa,

thanks for the comments, see below.

> On Feb 2, 2016, at 1:06 AM, Alissa Cooper <[email-masked]> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-isis-te-metric-extensions-09: Discuss
> 
> 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-isis-te-metric-extensions/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (1) There seems to be some inconsistency in the way the A-bit is
> described as applied to the min/max delay sub-TLV. Section 4.2 says:
> 
> "A-bit.  The A-bit represents the Anomalous (A) bit.  The A-bit is set
>   when the measured value of this parameter exceeds its configured
>   maximum threshold.  The A bit is cleared when the measured value
>   falls below its configured reuse threshold.  If the A-bit is clear,
>   the sub-TLV represents steady state link performance."
> 
> Is the A-bit meant to apply only to the min delay? Or only to the max
> delay?

As stated, is the value of max-delay that triggers the setting of the a-bit and it is used to indicate that something is going wrong with that link.

> Then Section 5 says:
> 
> "For sub-TLVs which include an A-bit (except min/max
>      delay), an additional threshold SHOULD be included
>      corresponding to the threshold for which the performance
>      is considered anomalous (and sub-TLVs with the A-bit are
>      sent)."
> 
> Since min/max delay is excepted from this recommendation, I don't
> understand what the A-bit means in the min/max delay sub-TLV.

if delay is higher than a configured value the a-bit is set. Typically, the receiver of the subTLV will take the indication that something is happening on that list (i.e.: it is not steady state).

> (2) Section 11 says:
> 
> "This document does not introduce security issues beyond those
>   discussed in [RFC5305]."
> 
> This seems false. First, RFC 5305 doesn't seem to discuss any security
> issues. It points to RFC 5304. But even compared to RFC 5304, it seems
> this document does introduce new issues, because it exposes real-time
> performance information about the network which may be commercially
> sensitive, and which RFC 5305 does not expose.

well, RFC5305 already advertises allocated BW information which may also be considered sensitive.

> So, for example, the claim
> in RFC 5304 that "Because a routing protocol contains information that
> need not be kept secret, privacy is not a requirement," does not seem
> true. It may be that the same authentication mechanisms can be used, but
> that doesn't mean the threat model is the same.

Probably we could re-phrase the first paragraph of section 11:

   "The subTLVs introduced in this document allow an operator 
    to advertise state information of links (bandwidth, delay) 
    that could be sensitive and that an operator may not want 
    to disclose." 

then the existing text about authentication illustrates how security is addressed.

> Happy to defer to others with more routing security clue than I, but it
> seems like at a minimum the potential value of the information contained
> in the new sub-TLVs to an attacker needs to be acknowledged.

as the result of another DISCUSS we added following text:

   [RFC5304] describes an authentication method for IS-IS LSP that
   allows cryptographic authentication of IS-IS LSPs.

   It is anticipated that in most deployments, IS-IS protocol is used
   within an infrastructure entirely under control of the dame operator.
   However, it is worth to consider that the effect of sending IS-IS
   Traffic Engineering sub-TLVs over insecure links could result in a
   man-in-the-middle attacker delaying real time data to a given site
   (or destination), which could negatively affect the value of the data
   for that site/destination.  The use of LSP cryptographic
   authentication allows to mitigate the risk of man-in-the-middle
   attack.

this should address your comments. Let me know if it’s not the case.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (1) In Section 5:
> 
> OLD
> Min and max delay MAY be the lowest and/or highest measured value
>   over a measurement interval
> 
> NEW   
> Min and max delay MAY be the lowest and highest measured value
>   over a measurement interval, respectively,

ok.

> 
> (2) Section 11 says:
> 
> "It is anticipated that in most deployments, IS-IS protocol is used
>   within an infrastructure entirely under control of the dame
> operator."
> 
> But Section 1 says:
> 
> "The data distributed by the IS-IS TE Metric Extensions proposed in
>   this document is meant to be used as part of the operation of the
>   routing protocol (e.g. by replacing cost with latency or considering
>   bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
>   for other uses such as supplementing the data used by an ALTO server
>   [RFC7285].”

well, the two statement above are consistent with each other.

> 
> In the ALTO case at least it would seem like the point of using this data
> would be to inform applications (outside the control of the operator)
> about the cost of routing traffic a certain way. I think this section
> could be more clear about the expectation that the performance data it
> exposes may be factored into such costs that get published outside the
> operator network.

ALTO defines an api through which an operator controls what is exposed or not so still the control is on the operator hands.

s.

---

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 01 Feb 2016 16:06:23 -0800

Then Section 5 says:

(2) Section 11 says:

sensitive, and which RFC 5305 does not expose. So, for example, the claim

(1) In Section 5:

OLD

NEW   
   
(2) Section 11 says:

But Section 1 says:

   [RFC7285]."

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Feb 2016 09:41:43 -0800

Hi Stefano,

> On Feb 2, 2016, at 7:49 AM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> 

What do you mean “as stated”? The text does not say whether the A-bit is triggered by min delay or max delay. It says it is triggered by “this parameter,” but there are two parameters in the sub-TLV.

> if delay is higher than a configured value the a-bit is set.

Min delay? Or max delay? And if the min/max delay sub-TLV includes the A-bit a specified in 4.2, why is it excepted from this recommendation?

> Typically, the receiver of the subTLV will take the indication that something is happening on that list (i.e.: it is not steady state).
> 
> 
>> (2) Section 11 says:
>> 

Agree, this is missing from RFC 5305, even more reason not to rely on it in total for its security considerations.

>    that could be sensitive and that an operator may not want 

WFM

Alissa

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 3 Feb 2016 07:44:32 +0000

Hi Alissa,

> On Feb 2, 2016, at 6:41 PM, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Stefano,
> 

sorry, my fault, I was looking at the wrong section.

Indeed, the A-bit is set when any of the two parameter exceeds the configured threshold.

The correct text should be:

   This field represents the Anomalous (A) bit.  The A bit is set when
   one or more measured values exceed a configured maximum threshold.
   The A bit is cleared when the measured value falls below its
   configured reuse threshold.  If the A bit is clear, the sub-TLV
   represents steady state link performance.

which is also in line with RFC7471.

s.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 3 Feb 2016 09:24:43 -0800

> On Feb 2, 2016, at 11:44 PM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
>>>> 

Ok, this makes sense. I still think clarification is also needed in Section 5.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 9 Feb 2016 20:33:48 +0000

>Ok, this makes sense. I still think clarification is also needed in

Alissa:

Hi!

When you get a minute, please take a look at the update that the authors
submitted today.

Thanks!

Alvaro.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 9 Feb 2016 13:39:48 -0800

Hi Alvaro,

The changes look good to me. I think this (unchanged) text in Section 5 is still unclear though:

For sub-TLVs which include an A-bit (except min/max
      delay), an additional threshold SHOULD be included
      corresponding to the threshold for which the performance
      is considered anomalous (and sub-TLVs with the A-bit are
      sent). The A-bit is cleared when the sub-TLV's performance
      has been below (or re-crosses) this threshold for an
      advertisement interval(s) to permit fail back.

Why is the min/max delay sub-TLV exempted from this recommendation?

Thanks,
Alissa

> On Feb 9, 2016, at 12:33 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 11 Feb 2016 09:37:02 +0000

Hi Alissa,

> On Feb 9, 2016, at 10:39 PM, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Alvaro,
> 

it looks we missed that one and the text "except min/max delay” should be removed.

thanks.
s.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 15 Feb 2016 20:33:58 +0000

On 2/11/16, 4:37 AM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

>it looks we missed that one and the text "except min/max delay² should be
>removed.

The latest (-11) addresses this last change!

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-metric-extensions-11

Thanks!

Alvaro.