Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal

From: Erik Guttman <[email-masked]>
Date: Tue, 21 May 2002 06:44:55 -0700 (PDT)

Keith,

One more note on Keith's comments on 
draft-ietf-zeroconf-ipv4-linklocal-05.txt follows.

A host supporting link-local addresses is expected to enable them at all
times, and to support the address defense protocol at all times. So if an
ARP packet arrives at a host which conflicts with one of the host's existing
link-local addresses, the host is expected to either defend the existing
address, or configure a new link-local address and defend that address. 
Either way, the host MUST send out multiple ARP probes (4 probe packets at
2-second intervals to claim the address, followed by 2 announcements, also
at 2-second intervals), each using broadcast. 

This has a multiplier effect - one or two ARP packets sent by an attacker
results in six ARP packets being sent in response, causing every host on the
link to process each of those requests, and also breaking any connections
that might be using the link-local address. 

ERIK:  I do not see the difference in kind between this attack and the
       preexisting one which simply sends garbage ARP replies to stomp 
       on legitimate ones.  An attacker's ARP reply will break connections.  
       This forces higher layers to retry, which will imply additional ARP 
       requests being broadcast repeatedly, etc.  

       The difference is only one of magnitude.  With v4LL autoconf, an
       attacker's ARP will cause an address reconfiguration event, which
       requires (a) a new claim to be established, (b) discovery of the
       new IP address (using service discovery or multicast based name
       resolution) and (c) ARP to obtain the L2 address associated new 
       L3 address.  

       Whether there are 3 cycles of broadcast request / reply or
       1 cycle, an active ARP attack introduces traffic, distributed
       processing and cache poisoning, and delay.

Best regards,

Erik