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

[Alissa Cooper <[e-mail]>]

Hi Stefano,

> On Feb 2, 2016, at 7:49 AM, Stefano Previdi (sprevidi) <[e-mail]> wrote:
> 
> Hi Alissa,
> 
> 
> thanks for the comments, see below.
> 
> 
>> On Feb 2, 2016, at 1:06 AM, Alissa Cooper <[e-mail]> 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.

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.

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

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

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

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

WFM

Alissa

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