James,
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.
For what it is worth, I would note that if you were using IPv6, this wouldn't have occurred (at least for the reasons of people trying to get around address scarcity by ARP spoofing...), because IPv6 doesn't impose any practical limit on the the number of hosts per link (due to 64 bit interface identifiers).
Bob
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 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------