|
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 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 |