Re: [Isis-wg] Genart last call review of draft-ietf-isis-auto-conf-04

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 07 April 2017 22:44 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE3112714F; Fri, 7 Apr 2017 15:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, 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 D5bekc4kL0BF; Fri, 7 Apr 2017 15:44:32 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57780128B8E; Fri, 7 Apr 2017 15:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4000; q=dns/txt; s=iport; t=1491605067; x=1492814667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nHmSyAnRov0e8Q1BW7uMEdM0PAE08g0b0qFKipF0eik=; b=USNIDVuGyYmUm15unI9XvYbEK4IsdDjlFxVnSmTlszzkZ1ekapr9iO8x Cg6AIdoDeNCl0gu861bVSHIwLnlT9+gVxfJP9gsZCzG0L9W8gWOob/EYo zplLMMOHIPoyGq4XpLhujPqL/qsoa6LuxCKsZpxuZ4DIWgnce/r4l2aAW 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgACFehY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrgWwHg1+KE5FElVeCD4YiAhqDRD8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECASMRRQwEAgEIEQQBAQECAiYCAgIwFQgIAgQBDQUIiX8IqlyCJopqAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELhUOEcIdcgl8FnHgBkk6RSZN+AR84gQVbFYc?= =?us-ascii?q?cdYgsgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.37,168,1488844800"; d="scan'208";a="230307470"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 22:44:26 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v37MiQsA022101 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 22:44:26 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Apr 2017 17:44:25 -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; Fri, 7 Apr 2017 17:44:25 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, Robert Sparks <rjsparks@nostrum.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "draft-ietf-isis-auto-conf.all@ietf.org" <draft-ietf-isis-auto-conf.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-isis-auto-conf-04
Thread-Index: AQHSr90H4gcf2S4v0ECj7j9mrpM816G6YX4QgABbdoD//63TkIAAWZ6A//+58rA=
Date: Fri, 7 Apr 2017 22:44:25 +0000
Message-ID: <db59f122a2d84c28851944a50f1564a2@XCH-ALN-001.cisco.com>
References: <149159669211.11107.3275242226580240988@ietfa.amsl.com> <814d03ced1c64f18b20d23c65e7cdf04@XCH-ALN-001.cisco.com> <8469f915-7e13-dead-7a4e-ab36506948da@nostrum.com> <1fd1507c9d5442d0a944e35da9b38b1d@XCH-ALN-001.cisco.com> <EDD33B73-CDF2-42AB-AE8A-96073F449997@cisco.com>
In-Reply-To: <EDD33B73-CDF2-42AB-AE8A-96073F449997@cisco.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.94.189]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Tk_q2gXM4nNIjHD8D-Wu696RmGU>
Subject: Re: [Isis-wg] Genart last call review of draft-ietf-isis-auto-conf-04
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Apr 2017 22:44:39 -0000

Alvaro -

Not sure how long we should debate this as the text you are asking for is modest - but one more attempt on my part - not so much to debate whether to add text or not - but to come to a common understanding.

> -----Original Message-----
> From: Alvaro Retana (aretana)
> Sent: Friday, April 07, 2017 2:45 PM
> To: Les Ginsberg (ginsberg); Robert Sparks; gen-art@ietf.org
> Cc: draft-ietf-isis-auto-conf.all@ietf.org; ietf@ietf.org; isis-wg@ietf.org
> Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote:
> 
> Les:
> 
> Hi!
> 
> > System-id duplication is a problem for any deployment - not just
> > autoconfig deployments. And it will be disruptive in any network until it is
> resolved.
> >
> > The only thing autoconfig has added is a way to resolve this w/o
> > manual intervention. This in no way increases the vulnerability nor
> > the disruption the attacker can produce. (Yes - I state that quite
> intentionally).
> 
> I don’t know about Robert, but that is part of the discussion I would like to
> see.
> 
> Yes, duplicate system-ids have always been a potential problem, but this
> document introduces a new de-duplication mechanism that results not just
> in unsync’d databases, but in restarting adjacencies – so at least the
> manifestation of the problem is different.
> 
[Les:] The "problem" exists as long as the duplicate system-ids exist. The recovery mechanism does not introduce new problems - it actually acts to minimize the duration of the problem. One could argue (and I am NOT doing so) that automated resolution could be a benefit in all deployments. I think the issue in non-autoconfig deployments is that since systems have been manually provisioned we cannot assume that network operators want us to automatically change the config on one of their boxes. Though, who knows - maybe we will get asked to use this extension outside of autoconfig deployments. 

It is necessary to have such a mechanism in autoconfig deployments since there is - by default - no manual intervention. But to characterize this as adding risk is incorrect IMO.

  Les


> > So you are asking us to repeat a discussion which has already been
> > held in the context of RFC 5304 and RFC 5310.
> >
> > It would be more appropriate to add the normal reference to RFC
> > 5304/5310 in the Security section than what you propose.
> 
> I don’t think it hurts to add a reference to those RFCs, but they are both
> about adding authentication – the problem in this document is exacerbated
> by the fact that there’s no authentication by default.
> 
> The lower layer authentication mechanisms are quite weak, specially
> knowing that, if in a home environment, for example, it may be relatively
> easy to connect to the WiFi network.
> 
> Alvaro.
>