RE: Liaison from BBF avec PDF

"Hemant Singh (shemant)" <shemant@cisco.com> Mon, 09 November 2009 07:13 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B443A6915 for <ipv6@core3.amsl.com>; Sun, 8 Nov 2009 23:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.028
X-Spam-Level:
X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 8H5h9EaYw8Vq for <ipv6@core3.amsl.com>; Sun, 8 Nov 2009 23:13:34 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 56FC63A69B0 for <ipv6@ietf.org>; Sun, 8 Nov 2009 23:13:34 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAMtP90qtJV2d/2dsb2JhbACCJC3AapY8hD4EgWg
X-IronPort-AV: E=Sophos; i="4.44,706,1249257600"; d="scan'208,217"; a="66974300"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2009 07:13:59 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id nA97DxmN029089; Mon, 9 Nov 2009 07:13:59 GMT
Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 01:13:59 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA610C.35099579"
Subject: RE: Liaison from BBF avec PDF
Date: Mon, 09 Nov 2009 01:13:56 -0600
Message-ID: <AF742F21C1FCEE4DAB7F4842ABDC511C11DE17@XMB-RCD-114.cisco.com>
In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4DEDE9BC12@EUSAACMS0703.eamcs.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Liaison from BBF avec PDF
Thread-Index: Acpg+vas8Ljm9WtrS7amLAiEU3PWIQAAiIcgAANAb+A=
References: <60C093A41B5E45409A19D42CF7786DFD4DEDE9BC12@EUSAACMS0703.eamcs.ericsson.se>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: David Allan I <david.i.allan@ericsson.com>, ipv6@ietf.org
X-OriginalArrivalTime: 09 Nov 2009 07:13:59.0211 (UTC) FILETIME=[351D87B0:01CA610C]
Cc: IPv6 Operations <v6ops@ops.ietf.org>
X-BeenThere: ipv6@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@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 07:13:40 -0000

Dave,

 

I have snipped some text (show between square brackets) from the slides
you sent us with my response below the text.  The summary from my
comments is that we need more data from you, and in a case or two, the
security problem does not exist.

 

[a malicious user may try to spoof a link-local address (e.g. by
connecting a PC to a bridged modem and configuring  a specific link-
local address on the PC)]

 

Before the spoofed link-local address (LLA) was spoofed, the address
existed with a PC behind a modem A with service ID, say, ID_A.  So even
if the LLA is spoofed by a PC behind modem B, the access concentrator
serving both modems still catches that the spoof is sending data now
from service ID ID_B.  There is a case that user with modem A can
shutdown the modem or the PC for the night and then if the PC behind
modem B spoofs, the PC may get into the access concentrator client db or
not - depends how long does the access concentrator keep entries for
shutdown PCs and modems   This bullet needs more data to be provided
upon before anyone can look into this issue.

 

[a malicious user may try to flood the network with a large number of
different link-local addresses, leading to a Denial of Service attack on
the BNG.]

 

Does the user change the hardware address with each new LLA? Did the
user initiate this hack using the modem or PC - there is degree of
difficulty involved if the hack is using the modem vs. a PC.  If the
user uses the same hardware address, then the hack is easily caught -
again unless the problem is described in more detail, folks cannot
comment on it.

 

[If two devices happen to have the same Ethernet MAC address as a
consequence of incompetent manufacture, the  link-local address derived
for that interface will also be non-unique, provided it is derived from
the EUI-64  identifier. This has been identified as an inconveniently
frequent scenario (impacting ~4% of access nodes at  any given time)]

 

Such a problem is already covered by the DAD procedure described in RFC
4862.  The same RFC also calls for  manual intervention is such a DUP
situation happens.  There is no automata specified for such an issue.
So one is now asking for new work related to RFC 4862.  M 2 cents on
adding automation to deal with such a DUP problem is difficult because
one will have to deal with false positives that are tough to resolve.
Such new work should not be taken up by 6man IETF WG who deals with v6
protocol work in the IETF.  

 

[As a result, link-local connectivity only exists between the host and
the BNG/edge router.   There is no way for the individual hosts to know
whether they are using duplicate link-local  addresses as direct
observation of neighbours traffic is precluded. - Editorial comment:
This is not unique to BBF TR101, numerous link layers exhibit this
behaviour (e.g. HFC or PON), and this can be virtualized at the
networking level (e.g. MEF ETREE  service definition, 802.1ad (2005)
Asymmetric VID, 802.1ah/.1aq also support this model)]

 

Cable has the same NBMA link and we have solved this issue by IPv6 ND
Proxy support on the access concentrator.   Lastly, nothing has been
shown in the DSL network that proves vND and DAD does not work in the
DSL NBMA link.   The hacker cases mentioned are just security issues
that should be taken in a DSL Forum security document. 

 

Hemant

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
David Allan I
Sent: Monday, November 09, 2009 2:27 PM
To: ipv6@ietf.org
Subject: RE: Liaison from BBF avec PDF

 

For those Microsoft challenged... my apologies in advance

 

D 

 

Attached are a series of charts that outlines a problem the Broadband
Forum is wrestling with in the IPv6 space, the charts are in effect a
companion to a liaison sent to INTAREA. I understand agendas are full so
there will not be time to discuss this in meeting time during the course
of this week, so it is posted such that there is a chance for reflection
on the problem (for those so inclined) on the list...and have
opportunity for face to face with any interested parties...

 

Please direct any questions for clairification to me...and I can arrange
to be found on breaks  

<< File: Background on SAVI liaison.ppt >> 

Cheers

Dave Allan

Co-chair BBF Arch & Transport Committee