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
- RE: Liaison from BBF avec PDF Hemant Singh (shemant)
- RE: Liaison from BBF avec PDF David Allan I
- RE: Liaison from BBF avec PDF Hemant Singh (shemant)