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

"Liubing (Leo)" <leo.liubing@huawei.com> Mon, 10 April 2017 10:07 UTC

Return-Path: <leo.liubing@huawei.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 94378129468; Mon, 10 Apr 2017 03:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 96M4Ogqjai1J; Mon, 10 Apr 2017 03:07:29 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E5E129477; Mon, 10 Apr 2017 03:07:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEL10452; Mon, 10 Apr 2017 10:07:22 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Apr 2017 11:07:21 +0100
Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 10 Apr 2017 18:07:11 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "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: AQHSr90I1Qr5MFU/1kyZBIn9T3xh16G53MgAgAAGPoCAAANtAIAABASAgAAQtoCABGROEA==
Date: Mon, 10 Apr 2017 10:07:10 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2ED8506@nkgeml514-mbs.china.huawei.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> <db59f122a2d84c28851944a50f1564a2@XCH-ALN-001.cisco.com>
In-Reply-To: <db59f122a2d84c28851944a50f1564a2@XCH-ALN-001.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.191.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58EB595B.0077, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.121, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9ea5c2356683d7cef74a5744d7b6aa9a
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/DbpDT-V4FjkfNt6MERBPlUyUPpU>
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: Mon, 10 Apr 2017 10:07:33 -0000

Hi Rober, Alvaro, and Les,

In general, the use of authentication is incompatible with auto-
   configuration as it requires some manual configuration.

> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
> Sent: Saturday, April 08, 2017 6:44 AM
> To: Alvaro Retana (aretana); 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
> 
> 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.

[Bing] I agree with Les that sys-id duplication attack is not an "adding" risk. 
But maybe we could add a bit more text to explain why this document RECOMMNED to implement Auth TLV.

Proposed added text in 3.5.1 (Authentication TLV) as below:
"The use of authentication is incompatible with auto-configuration as it requires some manual configuration. However, there might be some users would like to pay the effort of manual configuration to mitigate some security attack (e.g. a malicious node crafts packet to intentionally cause the Sys-ID duplication procedure continuously). 
Thus, it is RECOMMENED that IS-IS... (the same as existing text).

Do you think it's OK?

Best regards,
Bing


>   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.
> >