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

Robert Sparks <rjsparks@nostrum.com> Mon, 10 April 2017 17:35 UTC

Return-Path: <rjsparks@nostrum.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 DE319129A96; Mon, 10 Apr 2017 10:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 zk1vo9YZg61H; Mon, 10 Apr 2017 10:35:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A16E1294EC; Mon, 10 Apr 2017 10:35:52 -0700 (PDT)
Received: from unescapeable.local ([148.87.66.203]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3AHZgY8051381 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Apr 2017 12:35:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [148.87.66.203] claimed to be unescapeable.local
Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Liubing (Leo)" <leo.liubing@huawei.com>, "gen-art@ietf.org" <gen-art@ietf.org>
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>
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>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <adbc350e-f516-75da-ae9c-458cae1b91da@nostrum.com>
Date: Mon, 10 Apr 2017 13:35:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <DC9299D1-F989-471C-A7AC-1A5E9C9288AB@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fo1GMf0o5pRKG9JfjXibgSviQ6o>
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: Mon, 10 Apr 2017 17:35:58 -0000

+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."
>
> ???
>
>
>
>