Re: [secdir] SECDIR review of draft-ietf-isis-auto-conf-04

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 29 March 2017 12:18 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5371296CE; Wed, 29 Mar 2017 05:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 zQhG5kMGM5iF; Wed, 29 Mar 2017 05:18:11 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111761296C8; Wed, 29 Mar 2017 05:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23058; q=dns/txt; s=iport; t=1490789889; x=1491999489; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fWsppe/+qtxTuNk4yxMGtZlQ+SXJuoK93UmSKMNiCIw=; b=YEZ/VRlDPLe+yh+yEmHp6hMGnsc3oUl8qbBkVP0R5POhSU5PtufKQyJf 9GIHAe0jL2SptoJzVHvyH/krDKc+WReb36w0s2b46LUQ/R37QyFXR4Idc UeM5XZrQQMwCQGqKL+mSGzWlUh2zBnmUsH1UO8Rqb6H3+GY4Fv/Ha59Z4 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBVpdtY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2GBCweDW4oRkVCIGIsngg+CDoYiAhqDGz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDIwpcAgEIEQQBASgDAgICHxEUCQgCBAESCIgPA4FYAxWtdIImh?= =?us-ascii?q?ysNgxEBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhk6Eb4JRgjmCUIJfBZYQhhY6AY4?= =?us-ascii?q?XhC+RPIpviHoBHziBBFkVhRkdgWN1AYgogQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.36,241,1486425600"; d="scan'208,217";a="401663662"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 12:18:07 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2TCI7wr025656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 12:18:07 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 07:18:07 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 07:18:07 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Radia Perlman <radiaperlman@gmail.com>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-isis-auto-conf.all@tools.ietf.org" <draft-ietf-isis-auto-conf.all@tools.ietf.org>
Thread-Topic: SECDIR review of draft-ietf-isis-auto-conf-04
Thread-Index: AQHSqEf+b5kJ8TGx5UCZKC9F5w0LG6GruBzg
Date: Wed, 29 Mar 2017 12:18:06 +0000
Message-ID: <12e61a2f6e194bc1822ce377172ddff2@XCH-ALN-001.cisco.com>
References: <CAFOuuo5FQHFBgiNnn6g3Qx1Cby6JUKS533LxWe=cKneeDBD9gQ@mail.gmail.com>
In-Reply-To: <CAFOuuo5FQHFBgiNnn6g3Qx1Cby6JUKS533LxWe=cKneeDBD9gQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.106.147]
Content-Type: multipart/alternative; boundary="_000_12e61a2f6e194bc1822ce377172ddff2XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_DxRs_eINTVE8E-N3S31Zr_10B8>
Subject: Re: [secdir] SECDIR review of draft-ietf-isis-auto-conf-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 29 Mar 2017 12:18:14 -0000

Radia –

Thanx for the review.
Responses inline.

From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Tuesday, March 28, 2017 9:50 PM
To: The IESG; secdir@ietf.org; draft-ietf-isis-auto-conf.all@tools.ietf.org
Subject: SECDIR review of draft-ietf-isis-auto-conf-04

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.

This document describes a touchless (autoconfiguring) implementation of IS-IS.  I don't have any security comments, but I have some other comments.

They use the term "Double-Duplication". I don't know what that is. I think they mean "both the system ID and router fingerprint are duplicated". To me "double duplicate" would be that there were 3 or more systems with the same information.

[Les:] You are correct  - the term “double-duplication” means duplicate system id AND fingerprint.
I would be happy to remove the term “double-duplication” and simply say “duplication of system-id and fingerprint”. I think this would be clarifying.
If this satisfies you and my co-authors agree we can make this change.

The terminology "NET" and "NSAP" have always been very confusing to most IETF'ers (including me!). Might it be possible to stop using those terms? Of course, it's not fair to pick on this document to start doing that. In the early days of IS-IS, some implementations decided that NET should be the NSAP minus the last byte. Others thought it should be a full size NSAP, but with the last byte 0. The formal ISO definition in CLNP did not clarify this sort of thing, at least to me. Anyway, is there an IETF IS-IS document that explains what NET and NSAPs are, as opposed to saying (as in this document) that "an NET is a type of NSAP", which I find very confusing.

[Les:] The terms are used in ISO 10589. I think the most precise reference is ISO 10589 Section 7.1.5:

“All of the IS’s manualAreaAddresses, when combined with the IS’s systemID, are valid network entity titles for the IS.”

I think the draft’s use of the term is consistent with ISO 10589 and I am not inclined to change it.

Of course there is no IETF document regarding NETs/NSAPs. Why would we want to delve into such dark waters? ☺

In section 3.4.2, it says " Routers operating in auto-configuration mode MUST NOT form adjacencies with routers which are NOT operating in auto-configuration mode. "

Why is that? I'd think it would be easier to deploy if you could gradually introduce autoconfiguring routers in with existing implementations that don't know about the A bit. Are you concerned about an actual area 0?

[Les:] The target for these extensions is defined in Section 2:

“IS-IS auto-configuration is primarily intended for use in small (i.e.
   10s of devices) and unmanaged deployments.  It allows IS-IS to be
   used without the need for any configuration by the user.  It is not
   recommended for larger deployments.”

I think there are many good reasons for that – the primary one being that when one starts deploying more than a minimum set of features there are many more options and it becomes problematical to select a default setting than will be satisfactory in all deployments. Determining level is one easy example – assuming L1 isn’t appropriate for larger deployments. Autoconfig of area address is another.

So this restriction is intentional.

   Les

Other than those (mostly) editorial comments, which are only suggestions anyway, this is ready for publication. I haven't been following IS-IS recently, and I'm actually surprised that there hasn't been totally autoconfiguring implementations up until now.

Radia