Subject: LL11: Is there an elephant in the room?

From: Stuart Cheshire <[email-masked]>
Date: Fri, 14 Feb 2003 23:26:58 -0800

Robert Elz suggested:

> Before abandoning an address ... hosts SHOULD actively
>	attempt to reset any existing connections using that address.

While I do think this is a good suggestion in isolation, I also want to 
point out that it is another example of how IPv4LL is being subjected to 
unprecedented nit-picking.

When changing a manually-assigned IP address, does any RFC say that hosts 
should actively	attempt to reset any existing connections? Changing a 
manually-assigned IP address also leaves TCP connections dangling which 
could be subject to later hijacking.

When a DHCP server declines to renew a lease (as more and more ISPs are 
doing these days), does the DHCP RFC say that hosts should 
actively	attempt to reset any existing connections before giving up the 
address?

The fact is that anyone wanting to hijack a TCP connection on the local 
link will do it in the usual way, by bi-lateral unicast ARP cache 
poisoning, and then continuing to pass data between the two poisoned 
hosts so that they don't notice. Tools Ettercap will even do this 
bi-lateral poisoning and pass-through for you. Compared to that, an 
attack that makes one of the hosts reconfigure is crude and clumsy and 
more likely to be detected.

Insisting that the document discuss the hazards of forced 
reconfiguration, when we know that tools like Ettercap already exist, is 
like insisting that airport security should X-ray everyone's shoelaces at 
an airport where we know that they're not checking anyone's carry-on bags.

Sure, the risk of forced reconfiguration exists, but by spending a lot of 
time talking about it, everyone is busy discussing the link-local ant 
while ignoring the IPv4 elephant in the room.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Mika Liljeberg <[email-masked]>
Date: 15 Feb 2003 17:43:20 +0200

> unprecedented nit-picking.

I'm trying to imagine a nit-picking elephant. :-)

In my view, when an address collision is detected the elephant is
already in the store. This discussion is merely about how to lay out the
store in such a way that the flying shards present the least hazard to
bystanders.

Resetting TCP connections might be an appropiate response to losing the
local IP address without warning. Forced TCB delection could easily send
an RST as a matter of course. However, I think section 2.5 is already
saying too much when it states "the host MUST immediately cease using
this address and configure a new link-local IP address". In our stack it
would make more sense to mark the old address as "deprecated" (see
definition in RFC2462) and pick a new one. 

	MikaL