Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)

[Matt Crawford]

 On Sat, 20 Jul 2002 10:41:02 +0900, Jun-ichiro itojun Hagino [EMAIL PROTECTED]  
said:
  therefore, it is unsafe to transmit ARP_REQUEST with spoofed IP
  source address - it will overwrite ARP entries of neighbors.
 (He meant sender address, of course)
Valdis Kletnieks said:
 This is, of course, a major security hole...

Gee, if only ARP's funcntion was performed above the IP layer somehow ...

Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)

[C. M. Heard]

On Sat, 20 Jul 2002, Lars Eggert wrote:

 Jun-ichiro itojun Hagino wrote:
  I looked through RFC826 and it seems that the operation performed by
  Lars was a Bad Thing.  RFC826 input processing explicitly suggests us
  to update ARP cache entry without checking arp operation type.
  
  therefore, it is unsafe to transmit ARP_REQUEST with spoofed IP
  source address - it will overwrite ARP entries of neighbors.
 
 I re-read it, too, and you are of course right.
 
 It's sad though how easy a DoS attack can be - as easy as mistyping the 
 IP address of your machine.
 
 It might be worthwhile to investigate if 826 should be updated. Someone 
 at IETF mentioned that Linux explicitly violates 826 and does not update 
 the local cache based on the contents of spoofed packets, and thus seems 
 more resilient than the BSDs (against this particular bug).

How does one tell, in principle, that the source IP address (ar$spa) in
an ARP packet is in fact spoofed?

//cmh

Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)

[Thomas Narten]

 It might be worthwhile to investigate if 826 should be updated.

Somewhat related, there was a SEND BOF last week on securing IPv6's
Neighbor Discovery. 

This AD has been asked to advance the individual submission
draft-cheshire-ipv4-acd-01.txt on the standards track. That document
proposes backwards-compatable updates to RFC 826.

Thomas