Re: Neighbor Discovery from non-neighbors

[JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya at isc.org>]

At Fri, 3 Oct 2008 19:36:12 -0400,
"Hemant Singh (shemant)" <shemant at cisco.com> wrote:

> After, Erik Nordmark, Thomas Narten, myself, and Wes Beebee discussed
> the issue you brought to v6ops @ IETF and we summarized that your issue
> will not be able to touch the router forwarding tables, why did anyone
> post a security warning to FeeeBSD with totally erroneous data?
> 
> We never agreed during discussions in IETF that there was a security
> problem.  All that happens with the issue you raised is creation of a
> bogus entry in the router or node ND-cache. 
> 
> I don't consider the following data (shown in square brackets) in the
> BSD security posting as valid:

You seem to forget the fact that the FreeBSD security advisory
generally talks about that particular implementation.  Anything
written there is true, if you read it in the context of the FreeBSD
implementation (as an extreme example, a PC router that runs an
unmodified FreeBSD kernel).  I believe people normally interpret this
document in the correct context and won't be confused.

You also seem to be trapped in a specific router implementation model
where neighbor cache entries and forwarding tables are clearly
separated and the latter doesn't affect the former.  As far as I
understand it, such a model is not a protocol-level requirement, bFrom ipv6-bounces at ietf.org  Fri Oct  3 21:00:09 2008
Return-Path: <ipv6-bounces at ietf.org>
X-Original-To: ipv6-archive at megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 985813A6A08;
	Fri,  3 Oct 2008 21:00:09 -0700 (PDT)
X-Original-To: ipv6 at core3.amsl.com
Delivered-To: ipv6 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DE7FF3A6981
	for <ipv6 at core3.amsl.com>; Fri,  3 Oct 2008 21:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level: 
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=-0.300,
	BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_13=0.6,
	NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id c2fjBeZkiQKd for <ipv6 at core3.amsl.com>;
	Fri,  3 Oct 2008 21:00:07 -0700 (PDT)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162])
	by core3.amsl.com (Postfix) with ESMTP id 7EC1D3A67FB
	for <ipv6 at ietf.org>; Fri,  3 Oct 2008 21:00:06 -0700 (PDT)
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f])
	by mon.jinmei.org (Postfix) with ESMTP id 4BDB533C59;
	Fri,  3 Oct 2008 21:00:36 -0700 (PDT)
Date: Fri, 03 Oct 2008 21:00:36 -0700
Message-ID: <m2iqs9ypp7.wl%Jinmei_Tatuya at isc.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<Jinmei_Tatuya at isc.org>
To: "Hemant Singh (shemant)" <shemant at cisco.com>
Subject: Re: Neighbor Discovery from non-neighbors
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D04E423B0 at xmb-rtp-20e.amer.cisco.com>
References: <alpine.LRH.2.00.0810021001340.11598 at netcore.fi>
	<B00EDD615E3C5344B0FFCBA910CF7E1D04E423B0 at xmb-rtp-20e.amer.cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Cc: MILES DAVID <David.Miles at alcatel-lucent.com.au>, ipv6 at ietf.org,
	Pekka Savola <pekkas at netcore.fi>
X-BeenThere: ipv6 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces at ietf.org
Errors-To: ipv6-bounces at ietf.org

At Fri, 3 Oct 2008 19:36:12 -0400,
"Hemant Singh (shemant)" <shemant at cisco.com> wrote:

> After, Erik Nordmark, Thomas Narten, myself, and Wes Beebee discussed
> the issue you brought to v6ops @ IETF and we summarized that your issue
> will not be able to touch the router forwarding tables, why did anyone
> post a security warning to FeeeBSD with totally erroneous data?
> 
> We never agreed during discussions in IETF that there was a security
> problem.  All that happens with the issue you raised is creation of a
> bogus entry in the router or node ND-cache. 
> 
> I don't consider the following data (shown in square brackets) in the
> BSD security posting as valid:

You seem to forget the fact that the FreeBSD security advisory
generally talks about that particular implementation.  Anything
written there is true, if you read it in the context of the FreeBSD
implementation (as an extreme example, a PC router that runs an
unmodified FreeBSD kernel).  I believe people normally interpret this
document in the correct context and won't be confused.

You also seem to be trapped in a specific router implementation model
where neighbor cache entries and forwarding tables are clearly
separated and the latter doesn't affect the former.  As far as I
understand it, such a model is not a protocol-level requirement, but
just ut
just an implementation choice.  And, in fact, the FreeBSD kernel (or
BSD implementations in general) tightly couples the ARP/ND tables with
the forwarding table, so if a bogus entry is inserted in the former,
it will affect forwarding behavior.  As mentioned in the first
paragraph, a PC router using a vanilla FreeBSD kernel behaves that
way.  I won't surprised even other commercial routers that use a
customized BSD kernel have the same problem.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


an implementation choice.  And, in fact, the FreeBSD kernel (or
BSD implementations in general) tightly couples the ARP/ND tables with
the forwarding table, so if a bogus entry is inserted in the former,
it will affect forwarding behavior.  As mentioned in the first
paragraph, a PC router using a vanilla FreeBSD kernel behaves that
way.  I won't surprised even other commercial routers that use a
customized BSD kernel have the same problem.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------