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

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Tue, 02 February 2016 15:49 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5571B2CBE; Tue, 2 Feb 2016 07:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2hrsWpqC0Nb; Tue, 2 Feb 2016 07:49:37 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172081B2CAE; Tue, 2 Feb 2016 07:49:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8560; q=dns/txt; s=iport; t=1454428177; x=1455637777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z2oHNG7xYQEnd4G8L+8xzR34ooAAodBTA/wMaYjXhIU=; b=m+zh7Ye3dkpa/mPitKDYz6JR1RZSFQV3qRZhg5A4d1ry0775XrnVJXgJ MyblXyuj6GiwbMerXYXT+m8un2TtSyiHtWeurT0+5EE7hxJn39EQSaQcW vj0Oiz5rJb1nwbrQp2Pa/XS8AWv5igmjiU977xEAjmiU80blSacuSea7s k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAgB1z7BW/4UNJK1egzpSbQaIU69ZghMBDYFkIYVsAhyBKjgUAQEBAQEBAYEKhEEBAQEDASMRRQULAgEIGAICJgICAjAVEAIEDgWIEwgOr2COdgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4UUgW0IgkKEAhEBBhaDAiuBDwWHU48eAYVGaYcbgVuEQohUim2DUQEeAQFCgjCBNGoBiDo0fAEBAQ
X-IronPort-AV: E=Sophos;i="5.22,385,1449532800"; d="scan'208";a="232264764"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 15:49:36 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u12FnYpk012063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 15:49:35 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 10:49:33 -0500
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 10:49:33 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: Alissa Cooper <alissa@cooperw.in>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-isis-te-metric-extensions-09: (with DISCUSS and COMMENT)
Thread-Index: AQHRXdFPD/4g4kHnsUCzuz8M+SYeVg==
Date: Tue, 02 Feb 2016 15:49:33 +0000
Message-ID: <0313B05C-9CAF-4629-A598-C97CFE33AF8F@cisco.com>
References: <20160202000623.2041.75747.idtracker@ietfa.amsl.com>
In-Reply-To: <20160202000623.2041.75747.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.72.183]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FFAE13B4D373FE4BB0FE88BE36234690@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/E61t74wKbFihYAiJIIur4IAhf1k>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-te-metric-extensions@ietf.org" <draft-ietf-isis-te-metric-extensions@ietf.org>, The IESG <iesg@ietf.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>
Subject: Re: [Isis-wg] Alissa Cooper's Discuss on draft-ietf-isis-te-metric-extensions-09: (with DISCUSS and COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2016 15:49:39 -0000

Hi Alissa,


thanks for the comments, see below.


> On Feb 2, 2016, at 1:06 AM, Alissa Cooper <alissa@cooperw.in> 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.


> 
>