Re: [secdir] Secdir review of draft-ietf-isis-pcr

János Farkas <> Mon, 11 January 2016 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8EBA1A8AF8; Mon, 11 Jan 2016 09:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.899
X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fH5YQYPYRl8g; Mon, 11 Jan 2016 09:28:08 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B3071A8BB0; Mon, 11 Jan 2016 09:28:07 -0800 (PST)
X-AuditID: c1b4fb3a-f79df6d0000013b1-9b-5693e625e8ee
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9B.89.05041.526E3965; Mon, 11 Jan 2016 18:28:05 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 11 Jan 2016 18:28:04 +0100
Message-ID: <>
Date: Mon, 11 Jan 2016 18:28:04 +0100
From: =?windows-1252?Q?J=E1nos_Farkas?= <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Salz, Rich" <>, "" <>, "" <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080906050301070800050205"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7q67qs8lhBou7ZCy+PX/NZjHjz0Rm i9k3VrFZXD/Szmjxf0sni8WHhQ9ZHNg8Jh9ZwOxx9uY/Fo8lS34yeXy5/JnN4+znhywBrFFc NimpOZllqUX6dglcGTcWcxYsNak43vecuYHxp2YXIweHhICJxIuG3C5GTiBTTOLCvfVsXYxc HEIChxklFj9awwzhrGWU2PV0HTNIFa+AtsSn1keMIDaLgKrEkycN7CA2m4CzxKOLvUwgtqhA lMTRJVfZIeoFJU7OfMICMkhE4ACjxP5P68GKhAUMJXa9u8sKcoWQQJDEww8FIGFOgWCJHZ9W sYHYzAJhEheeHwKbIySgJvHp7UP2CYz8s5CMnYWkbBbQJGYBe4kHW8sgwvIS29/OYYaw9SWu 37nPiiy+gJFtFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgJBzc8ttqB+PB546HGAU4GJV4 eAseTQoTYk0sK67MPcQowcGsJMKrtn1ymBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeJJnGMCGB 9MSS1OzU1ILUIpgsEwenVANj7GNHE/aNAeaG1j/j97jNPBaj2HVNSN2F6YzU4cz9z7je5KgU eqqzfF5/eruEzrvJMV0JQrHOLxPMhCXLF4aoN/y3nH+mPLHw4S9rwdbrN29f/sz7QpvLu6bt 5+PDV3adD62qqbR5yG/fsedZoUXO5+hXtiZJ+x4E/rmWuYz5+KNXziecOT8rsRRnJBpqMRcV JwIAyudlkYACAAA=
Archived-At: <>
X-Mailman-Approved-At: Mon, 11 Jan 2016 09:31:43 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-isis-pcr
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jan 2016 17:28:09 -0000

Hi Rich,

Thank you very much for your review!
Please find response to your questions in-line.

On 1/7/2016 3:31 PM, Salz, Rich wrote:
> 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.
> My view: Ready with issues, about the security considerations section.
> I know very little about IS-IS, or even the overall routing discipline.
> One nit is that this document cannot easily be read stand-alone.  That is probably okay, but a pointer to background RFC's are a definition of terms (e.g., sub-TLV) would be helpful.
This document largely relies on the following IS-IS specifications: 
RFC6329 (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path 
Bridging), RFC5305 (IS-IS Extensions for Traffic Engineering) and 
ietf-isis-te-metric-extensions, which are all normative references. 
Further pointers are given to the corresponding IEEE 802.1 
specifications, which explain the use of the IS-IS sub-TLVs.
We can give further references if there is anything in particular that 
is not clear.

> I do not understand how "reserving capacity" or "specifying capacity" cannot be used as a denial of service attack.  Perhaps that is related to the above paragraph?
Yes, this is pointed out in the penultimate paragraph of the security 
considerations. IS-IS PCR follows the PCE architecture specified by 
RFC4655. Therefore, the security considerations of RFC4655 are 
applicable here too, which I believe is stated in this paragraph.

> Is there authentication (perhaps out of band) between IS-IS systems?  Message integrity that prevents spoofing or modification?
Yes, security solutions are available for IS-IS.
The last paragraph of security considerations is intended to describe 
this. It first explains that IS-IS security considerations apply as 
IS-IS PCR is based on IS-IS. Furthermore, this paragraph also points out 
that the existing IS-IS security solutions are applicable for IS-IS PDUs 
between PCE and IS-IS System and among IS-IS Systems. This paragraph 
refers to RFC5310 (IS-IS Generic Cryptographic Authentication), which 
refers further to RFC 5304 (IS-IS Cryptographic Authentication); which 
can be used for IS-IS PCR.

We can make updates to the text if you find anything missing. Please let 
us know.