Subject: LL11 Add security consideration for the threat where an attacker forces address reconfiguration

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Feb 2003 19:32:18 -0800

Robert Elz suggested that a host send TCP resets before giving up its 
address. This sounds like a good idea, and I would not oppose this new 
text.

However, I do not agree with the entire analysis.

Robert Elz wrote:

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

I disagee that it is a new threat.

Unicast ARP poisoning can be used today to hijack a TCP connection 
without the victim even knowing it. (The intruder poisons the peer's ARP 
cache via a spoof unicast reply; the victim never even sees the spoof 
unicast reply so it never knows why it stopped receiving packets. The 
intruder can even forward modified packets to keep the connection 
apparently alive, so the victim in fact may not stop receiving packets.)

Stuart

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Feb 2003 11:59:24 -0500

I agree with kre that sending RSTs is a good idea, and I agree with
Stuart that spoofed ARPs are not an LL-specific threat.  The difference
with LL is that, *as a matter of protocol conformance*, ARPs can be used
to DoS a TCP connection at any time.  However I suspect this may also be
the case with most existing (non-LL) TCP implementations - especially
those that use ARP to perform DAD. In which case there would be little
practical difference to this threat between LL and non-LL.

Keith

On Tue, 11 Feb 2003 19:32:18 -0800
Stuart Cheshire <[email-masked]> wrote:

> without the victim even knowing it. (The intruder poisons the peer's
> ARP cache via a spoof unicast reply; the victim never even sees the
> spoof unicast reply so it never knows why it stopped receiving
> packets. The intruder can even forward modified packets to keep the
> connection apparently alive, so the victim in fact may not stop
> receiving packets.)
> 
> Stuart
>

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Feb 2003 17:18:22 +0700

Date:        Tue, 11 Feb 2003 19:32:18 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | Robert Elz suggested that a host send TCP resets before giving up its 
  | address. This sounds like a good idea, and I would not oppose this new 
  | text.

Thinking about this afterwards, there's actually another mechanism
that could be used (I suspect reset is likely best, but ...)

That is, a node on having its address "stolen" by another node, can
do what the draft currently says, and just go allocate itself a
new address (the new address allocation has never been the issue here)
but not release the old one - that is, continue to defend it to the
death, forever (or at least until there is no longer any reasonable
possibility that any old connections using the old address survive).

That would, essentially, remove the one real difference between the LL
spec, and what has always happened in the past when there are address
conflicts.

That is, the new problem that the LL spec introduces, is that it requires
nodes to abandon their address in the event of a conflict.  That's new,
and that's what leads to the problem.

  | However, I do not agree with the entire analysis.
  | I disagee that it is a new threat.

I agree, it is possible today to hijack connections.   Where the LL spec
makes a difference is that it (currently) requires the node being hijacked
to meekly go along with the hijack attempt - that is, it is required to
give up its address (and though the text doesn't say so, one presumes
also to cease sending packets claiming to originate from that address).

All of this makes hijack attempts much simpler than currently - that is,
not new (there's nothing new ...) but easier to perform with less effort.

All that is actually being asked for here is more text in the security
considerations.   I don't think it is too much, nor do I think it is
misleading anyone into believing that LL addresses are lots worse when
compared with others - it isn't even the addresses (or their allocation
here) that this note is about - but the practice of simply stopping using
them in the event of a conflict.

In the attack your described, nothing causes the victim to stop sending
packets to its peer - receiving those packets can often cause the peer
to reset the connection (depends upon what happens with sequence numbers
etc), with the current LL scheme, the peer will never see anything odd at all.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 14 Feb 2003 01:19:25 +0200

> spec, and what has always happened in the past when there are address

This is a bit OT, but a node can guard against ARP poisoning by doing
some additional checking on hardware addresses and cache state:
- discard all unsolicited ARP announcements
- never overwrite a cached hardware address
- keep reference counts for cache entries and keep entries with non-zero
reference counts alive by probing the peer before the entry has a chance
to expire

In the event of an address collision, given the above defensive
mechanisms, a node could configure a new address, but try to finish the
existing connections with the old one. This would work with a peer
employing similar counter-measures.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Feb 2003 13:16:16 +0700

Date:        14 Feb 2003 01:19:25 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1045178364.4848.1250.camel@devil>

  | This is a bit OT, but a node can ...

Yes, I agree with all of that.   But for present purposes, all that
is really required is that the security considerations make it clear
that there really is a potential problem here (that is, it isn't all
just as it used to be), and advise implementors to take care.

What is the best way to do that might vary depending upon the requirements
of the node in question - or it may eventually turn out that there's
one best way that works well (enough) for everyone.

Blindly just ceasing (abruptly) to use an address because some other node
says that you should is sometimes going to be dangerous though (not always,
there's no real problem if the node is just sitting there waiting for
someone to find it & communicate).

kre