Subject: WG action - 1 week to discuss [LL11] Add security consideration for the threat where an attacker forces address reconfiguration

From: Erik Guttman <[email-masked]>
Date: Sat, 8 Feb 2003 17:43:49 +0100 (CET)

Please see http://www.spybeam.org/ll11.html

This does not seem like it is a controversial issue.  It was suggested
some time ago and has gotten no further comment.  Please comment by 15
Feb 2003 when the issue will be decided.  If no comment is made, the
recommended text will be accepted.

Erik, since you raised this issue during the iesg review of
draft-ietf-zeroconf-ipv4-linklocal-07.txt could you please review the
recommended fix?

Thanks,

Erik

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 17:42:02 +0700

Date:        Sat, 8 Feb 2003 17:43:49 +0100 (CET)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <Pine.SOL.3.96.1030208174053.27529E-100000@field>

  | Please see http://www.spybeam.org/ll11.html

  | This does not seem like it is a controversial issue.  It was suggested
  | some time ago and has gotten no further comment.  Please comment by 15
  | Feb 2003 when the issue will be decided.  If no comment is made, the
  | recommended text will be accepted.

Everything that is there looks fine - but it doesn't really go far enough
in exposing the problem that the subject of this issue raises.

I'd ask that the following text also be included in the security
considerations section to address this point...

	Implementations and users should also note that a node that
	gives up an address and reconfigures, as required by section 2.5,
	allows the possibility that another node can easily successfully
	hijack existing TCP connections.  Before abandoning an address
	due to a conflict, hosts SHOULD actively attempt to reset any
	existing connections using that address.

The issue of course, is that on many net technologies where a node has the
ability to issue ARP packets, nodes also have the ability to snoop packets.

Such a node can, if it desires, watch a TCP connection be established,
go through the authentication phase, and then start sending (many) ARP
packets claiming to own the address of the system which just authenticated
itself.   That system (following section 2.5) reconfigures to a new address,
leaving the old one available for the node that usurped it.   That node
has all the information it needs (sequence numbers, port numbers, ...) to
successfully masquerade as the node that was previously authenticated.

This is a very serious (and new) security issue posed by using LL addresses
as demanded in section 2.5.  (new in the sense that it doesn't exist in
earlier IP stacks - not new to this e-mail of course).

At the very least this needs explicit mention in the security considerations.

It may be that this is actually serious enough that the algorithm of
section 2.5 should just be deleted, and hosts left to continue attempting
to use their usurped address (which will might mean, two nodes attempting
to communicate with the peer, or one node communicating, and the other
being confused, and sending TCP reset - but in any case, generally prevents
the worst possibilities of connection hijacking).   However, if nodes do
actively send RESET from the old address before abandoning it, that would
I think be good enough to avoid this.   (Sending RESET should also be
mentioned in section 2.5 itself).

This only deals with TCP, of course, UDP "connections" can still be
hijacked this way, there there is no real "reset" that can prevent it.
On the other hand, authenticated UDP services are few and far between.
Anyone dumb enough to attempt to use NFS (without kerberos or similar,
and excepting read only public access) using LL addresses deserves all
they receive.

kre

---

From: Erik Guttman <[email-masked]>
Date: Sun, 9 Feb 2003 15:21:51 +0100 (CET)

Robert suggests we add:
> 	existing connections using that address.

[WG chair hat off, WG participant hat on]
Looks good to me!

[WG chair hat on]
When suggesting text, please put it front and center and separate it
from argumentation. 

Erik
-----
Brevity is the soul of wit.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Feb 2003 09:59:35 +0100 (CET)

> draft-ietf-zeroconf-ipv4-linklocal-07.txt could you please review the

Looks like what I said.

  Erik