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

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

Mika Liljeberg wrote:

>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

This change would violate the ARP specification in RFC 826, and any such 
change to RFC 826 would require a *lot* of discussion and debate. The 
list of problems in such a change would probably require a working group 
of their own.

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Feb 2003 16:49:20 +0700

Date:        Fri, 14 Feb 2003 23:27:22 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | This change would violate the ARP specification in RFC 826, and any such 
  | change to RFC 826 would require a *lot* of discussion and debate. The 
  | list of problems in such a change would probably require a working group 
  | of their own.

The change that was suggested would.   I know however that the last
implementation of ARP I did treated an unsolicited reply (and would
a broadcast request) as a suggestion that the IP<->MAC address mapping
might have changed.   That is, I invalidated the ARP cache entry.
(I doubt that I invented this technique, which suggests that others do
the same thing, and I learned it from someone else - this was all a
*long* time ago now).

When there was a need to send another packet to the destination, an ARP
request would result - that the true owner of the address would respond to.
A hacker might also respond, in which case odd things happen (the effect
is that the cache is invalidated again, as when the 2nd reply, whichever
it is, arrives, no reply is expected).

When the cache gets invalidated this way, the event is also logged, if it
is a genuine MAC address change, that's fine, one (comparatively rare)
log entry - if it is someone attempting to hijack addresses, it becomes
very obvious, very quickly.

There are still DoS possibilities here, but nothing like as bad as
just silently updating an ARP cache upon request, nor as bad as just
giving up an address upon request and handing it to someone else.

Stuart - all that anyone is asking here is that there be an adequate
security considerations section.   Giving up an address upon request
from any random node is new for the Internet architecture, and doing so
does have security implications - those need to be noted.

I agree with you (I think) that none of this is severe enough, compared
with what currently is possible, to warrant requiring any changes to
the protocol itself.   But there is enough here that noting the issue
in the security considerations is important.

wrt your reply to me ...  There is no RFC about manually changing assigned
IP addresses.   If we were to write one, this issue should be addressed
in it as well.   The same is true for DHCP - this is one of the reasons why
DHCP servers should not refuse to renew a lease - but if we were writing
about that now (what a client should do if a lease expires) then closing
all active connections should be on the list to at least attempt.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 15 Feb 2003 14:54:35 +0200

I support LL11.

On Sat, 2003-02-15 at 09:27, Stuart Cheshire wrote:
> change to RFC 826 would require a *lot* of discussion and debate.

Undoubtedly true, although RFC826 is none too clear on the mandatory
requirements. There's quite a bit of leeway in there.

I was not suggesting this as a solution (the description is too vague
anyway) and even indicated that it is slightly off-topic. I was only
pointing out that there are counter-measures that nodes can take and, as
Robert also pointed out, there are implementations which do.

Our implementation, for instance, follows the IPv6 Neighbor Discovery
state machine and takes an unsolicited ARP reply with a different
hardware address only as an indication that the address may have
changed. The cached entry is set to STALE state. From there it
progresses to PROBE state, in which the node to sends unicast probes to
the old hardware address to ascertain its reachability. The entry gets
deleted only if the old hardware address no longer responds, in which
case the next packet will cause the node to ARP for the address
normally.

The above may not be exactly as described in RFC826 but it works
reasonably well and it does address the issues that RFC826 cites as
reason for updating a cached hardware address. The implementation is
also a good deal more resistant to cache poisoning.

>  The 

That thought is not without merit, RFC826 is way past its time.
Certainly this is not a problem to address in this group, though.

I agree with Robert, however, that there should be a warning in the
security section about the new attack variants enabled by the address
collision resolution.

In the case of our stack, for instance, it clearly reopens attack
avenues that we had already dealt with.

	MikaL