>SEND secures the mapping between an IPv6 address and a MAC address, but
>it does nothing to guarantee that the L2 topology actually delivers the
>packets to the intended destination. When we expand all that energy
>signing neighbor discovery packets, have we really improved security?
Here's a concrete example of how the address mapping part of SEND would
improve security*
In 2002, I was sitting in the conference room at Mobicom browsing one of the
papers when my 802.11/IPv4 network connection started to act up. It would go
away, then come back, then hang for a long period of time. When I looked
into the matter more deeply, I discovered that the DHCP lease on my address
had been revoked, and my machine was attempting, unsuccessfully, to get
another one. I spoke to the NOC about it, and found out that they had only
allocated enough address space for 256 hosts, and there were well over 300
people in the room, many of whom were knowledgable networking researchers.
Somebody was ARP spoofing, stealing addresses because not enough had been
allocated. ARP spoofing is one of the threats SEND is designed to counter,
so if IPv6/SEND had been deployed, this attack would not have been possible.
Now, you can argue that SEND doesn't protect the MAC address itself (and in
fact, specifically doesn't claim to), it just protects the mapping, so
someone could still just send out frames with your MAC address. So it is
still possible for an attacker to spoof a MAC address, for those shared
media where a host specific MAC address appears on the air, like 802.11, and
the address is not protected (and this is a particular problem for 802.11
because the management frames are completely unprotected). The spoofer
cannot, however, claim frames holding packets having your IP address if SEND
is used, because the mapping is protected. In the end, there is really only
so much IETF can do, and now it is up to IEEE to fix their MAC protocol so
that people can't steal addresses or spoof management frames (I'm told they
are working on it).
In this particular case, the service was free so the fact that I was
inconvenienced by not being able to use the connection was of little
economic consequence. But if I had been using a connection to a wireless
service provider who charges for the service, the consequence may not have
been as minor. In my view (speaking from a wireless service provider
perspective), SEND is an excellent reason why a wireless service provider
whose media has characteristics similar to 802.11 might want to deploy IPv6,
provided of course that host support is available.
The full list of threats SEND is designed to counter is outlined in the
Security Considerations section of the SEND RFC and detailed in RFC 3756;
note that these are the only threats SEND is designed to counter. In
particular, as discussed in somewhat excruciating detail on this thread and
explcitly mentioned in the SEND RFC, the address mapping part of SEND does
not claim to protect proxy ND of any sort. I spoke to Dave Thaler about this
a few IETFs ago, and I believed we agreed that it was OK for this draft, but
I've not looked at the draft since.
However, it seems pretty clear to me that there is considerable interest in
security for proxy ND. The Mobopts IRTF research group is interested for
securing fast handover, and it would also be useful for MIP6 though the MIP6
group is busy with other tasks at the moment so it has not hit their radar
screen yet. We had a BAR BOF for Mobopts on proxy SEND in San Diego, but
there hasn't really been much discussion about it on the Mobopts list.
Considering the more leisurely pace work takes in IRTF, something might not
pop out of Mobopts on proxy SEND for some time. So my suggestion is, if
people think proxy SEND is a burning issue, instead of continuing to argue
about this particular draft, maybe it would be more productive to have a BOF
(if the WG chairs of the IPv6 group would rather not sponsor proxy ND
security work in the IPv6 WG) or schedule a session at the IPv6 WG meeting
(if the chairs would want to sponsor the work). I'd be happy to help
organize the BOF if one is necessary.
jak
*Note that there is another part of SEND which people seem to forget,
involving router security. That should work with NDProxy, learning bridges,
and any other local subnet topology where a first hop router is involved and
the host routes all off subnet traffic through the router.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
