Subject: RE: Request to Advance: <draft-ietf-ipv6-ndproxy-00.txt> [RESEND]

From: "Christian Huitema" <[email-masked]>
Date: Mon, 31 Jan 2005 22:39:38 -0800

So, thinking some more about it, I have this nasty feeling about the
usefulness of SEND. Compare the two topologies:

	Host-A <---> learning bridge <---> Host-B
	Host-A <---> ND-Proxy        <---> Host-B

SEND will work just fine with the learning bridge topology, but will not
work with the ND-Proxy topology. Yet, do you really believe that one is
inherently more secure than the other? Learning bridges can do all kinds
of interesting tricks, in fact more so than proxies. 

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?

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Feb 2005 23:10:06 +0200

> signing neighbor discovery packets, have we really improved security?

SEND is just one part of the overall puzzle, not the sole answer
to all problems. And solutions usually are unable to prevent all
problems. In particular, whatever you do, its hard for endpoints
to ensure that their packets are not stopped, redirected, modified,
or looked at en route. One thing you can do is to ensure that the
packets are protected so that these attacks, if performed, would
not have an impact beyond denial-of-service. That's why we have
protocols such as TLS or IPsec*.

Another thing you can do is to ensure that such attacks are
harder to launch or at least that they can not be launched
from anywhere. This is where SEND helps. Basically, SEND
prevents the use of L3 control protocols to hijack sessions.
Of course, a router or learning bridge that legitimately
gets the traffic could still send it to someone else or
to the trashcan. But it would be great if we could at least
prevent outsiders, such as people that plug into an Ethernet
port at an office, from doing this.

But an attack below layer 3 will still get you into trouble.
This includes things like wireless attacks, e.g., an open
wireless LAN or spoofing your L2 address to a switch that
looks at source MACs. Various methods exist to deal with
these issues, starting from a switch locking into to a MAC
address upon first usage on a port ("Learn and Lock" on
some equipment).

See also Section 9.1 in the SEND protocol document.

--Jari

*) Earlier, we even considered doing per-packet cryptographic
protection based on SEND. This would be your zero-config
.1X variant.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Feb 2005 14:01:06 -0800

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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 01 Feb 2005 23:37:42 -0800

James,

>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