RE: Genart last call review of draft-ietf-isis-auto-conf-04

"Liubing (Leo)" <leo.liubing@huawei.com> Tue, 11 April 2017 01:44 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5C11293F2; Mon, 10 Apr 2017 18:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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, URIBL_BLOCKED=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 5rDaruX32T6A; Mon, 10 Apr 2017 18:44:50 -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 A749D128BB7; Mon, 10 Apr 2017 18:44:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEM15405; Tue, 11 Apr 2017 01:44:45 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Apr 2017 02:44:44 +0100
Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 11 Apr 2017 09:44:40 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Robert Sparks <rjsparks@nostrum.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.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>
Subject: RE: Genart last call review of draft-ietf-isis-auto-conf-04
Thread-Topic: Genart last call review of draft-ietf-isis-auto-conf-04
Thread-Index: AQHSr90I1Qr5MFU/1kyZBIn9T3xh16G53MgAgAAGPoCAAANtAIAABASAgAAQtoCABGROEP//ycMAgAAxw4CAAADlgIABDlAA
Date: Tue, 11 Apr 2017 01:44:40 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2ED881A@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> <8AE0F17B87264D4CAC7DE0AA6C406F45C2ED8506@nkgeml514-mbs.china.huawei.com> <c3a3a16110cb44c182413d993377de6d@XCH-ALN-001.cisco.com> <DC9299D1-F989-471C-A7AC-1A5E9C9288AB@cisco.com> <adbc350e-f516-75da-ae9c-458cae1b91da@nostrum.com>
In-Reply-To: <adbc350e-f516-75da-ae9c-458cae1b91da@nostrum.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.0A0B0205.58EC350E.0015, 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/ietf/8P8KO87KUlGLTAlOPhTlL7Se9jA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2017 01:44:53 -0000

Hi Les, Robert and Alvaro,

Thanks for Les' proposed text. I'll update it accordingly.

B.R.
Bing


> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Tuesday, April 11, 2017 1:36 AM
> To: Alvaro Retana (aretana); Les Ginsberg (ginsberg); Liubing (Leo);
> 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
> 
> +1
> 
> 
> On 4/10/17 1:32 PM, Alvaro Retana (aretana) wrote:
> > Works for me!
> >
> > Thanks!
> >
> > Alvaro.
> >
> >
> >
> >
> >
> > On 4/10/17, 10:34 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
> wrote:
> >
> > Bing/Robert/Alvaro -
> >
> > Here is the existing text of the Security Section:
> >
> >    "In general, the use of authentication is incompatible with auto-
> >     configuration as it requires some manual configuration.
> >
> >     For wired deployment, the wired connection itself could be
> considered
> >     as an implicit authentication in that unwanted routers are usually
> >     not able to connect (i.e. there is some kind of physical security in
> >     place preventing the connection of rogue devices); for wireless
> >     deployment, the authentication could be achieved at the lower
> >     wireless link layer."
> >
> >
> > Proposed revision:
> >
> > "In the absence of cryptographic authentication it is possible for an
> > attacker to inject  a PDU falsely indicating there is a duplicate
> > system-id. This may trigger automatic restart of the protocol using the
> duplicate-id resolution procedures defined in this document.
> >
> > Note that the use of authentication is incompatible with auto-
> > configuration as it requires some manual configuration.
> >
> >     For wired deployment, the wired connection itself could be
> considered
> >     as an implicit authentication in that unwanted routers are usually
> >     not able to connect (i.e. there is some kind of physical security in
> >     place preventing the connection of rogue devices); for wireless
> >     deployment, the authentication could be achieved at the lower
> >     wireless link layer."
> >
> > ???
> >
> >
> >
> >