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

["Stefano Previdi (sprevidi)" <[e-mail]>]

Hi Alissa,


> On Feb 2, 2016, at 6:41 PM, Alissa Cooper <[e-mail]> wrote:
> 
> 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.


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.


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