[secdir] Secdir review of draft-ietf-isis-te-metric-extensions-07

"Brian Weis (bew)" <bew@cisco.com> Tue, 22 December 2015 23:54 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0419E1AC412; Tue, 22 Dec 2015 15:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 xzJh4uk3oEL9; Tue, 22 Dec 2015 15:54:41 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F381AC40A; Tue, 22 Dec 2015 15:54:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2218; q=dns/txt; s=iport; t=1450828481; x=1452038081; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mZ4p0tkh3B4tTGkyfXfK5tX84FTFYOxq7M6zBjtqXcc=; b=f+drB8LMM0Q+sp2E9Q2hpEAFp85YJtYQ8smKOI5zlZJcbT+G1mP77nZC 8kt1RJSrZ0UUYgBOvcFoJXb/EL5kRmZXCePTCGSSBCepFQ5hAjZnNZfz1 uQezuHcnP2NiHjGEj7sC6niXo32S61ElvUbcbbrqI5wyAn8p6w+CeYFfP k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CnBQCz4XlW/4ENJK1egzqBRYxLsS6BY4YNgS46EgEBAQEBAQGBCoQ3BHkSAYEAJwQBDYg0v3UBAQEBAQEBAQEBAQEBAQEBAQEbiGWLEoEbBZcBAYELjD+OeI41ASkHNIQEhRKBCAEBAQ
X-IronPort-AV: E=Sophos;i="5.20,466,1444694400"; d="scan'208";a="60729338"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Dec 2015 23:54:40 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tBMNse2f019348 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Dec 2015 23:54:40 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Dec 2015 18:54:39 -0500
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 22 Dec 2015 18:54:39 -0500
From: "Brian Weis (bew)" <bew@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-isis-te-metric-extensions-07
Thread-Index: AQHRPRQeXsvgFRODtkmosRBxlZqCXA==
Date: Tue, 22 Dec 2015 23:54:39 +0000
Message-ID: <F56C08BC-776E-4D56-B505-77C9D9F0B479@cisco.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.154.48.120]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B87E975F70079F43AF53A71D80B50918@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/9u7ezw4gAj_rUCrkbGUsMdaAX8Y>
Cc: "draft-ietf-isis-te-metric-extensions.all@tools.ietf.org" <draft-ietf-isis-te-metric-extensions.all@tools.ietf.org>
Subject: [secdir] Secdir review of draft-ietf-isis-te-metric-extensions-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2015 23:54:43 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I consider this document Ready with nits.

This document adds some “sub-TLVs” to IS-IS Traffic Engineering Extensions (RFC5305), where the new sub-TLVs describe characteristics for a link (e.g., link delay, available bandwidth). It notes in the Abstract and Introduction that these will be used in real-time networks where performance data is critical to ensuring timely delivery of information (e.g., stock market data).

The Security Considerations accurately states that it does not introduce security issues, insomuch that it does not change the behavior of IS-IS or IS-IS Extensions for Traffic Engineering (RFC 5305). It points to the security considerations in RFC 5305, which really just points to security considerations in IS-IS Cryptographic Authentication  (RFC 5304). This is logical, if not so helpful. Pointing to RFC 5304 directly would be just as useful, in my opinion, but acceptable the way it is now.

Given that the stated motivation for this document is to pass performance data across networks where the performance data is considered critical (and the delay of which has an financial impact), it would be useful for the Security Considerations to be more specific about risks to the IS-IS TE extensions being tampered with on the link. For example, it could say that the effect of sending these IS-iS Traffic Engineering Sub-TLVs over insecure links could result in a man-in-the-middle attacker delaying real time data to the site, which could negatively affect the value of the data for that site.

Security Considerations also points to Traffic Engineering Extensions to OSPF Version 3  (RFC5329) which does not make a lot of sense to me, since OSPF is an entirely different protocol. I think a better alternate reference might be IS-IS Security Analysis (RFC7645).

Brian