Subject: [Gen-art] Re: Last Call: draft-cheshire-ipv4-acd (IPv4 Address Conflict Detection) to Proposed Standard

From: Stuart Cheshire <[email-masked]>
Date: Sun, 13 Jan 2008 16:05:04 -0800

Thank you all for your comments.

An updated draft is available at:

<http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-05bis.txt>

In cases where I did not make the requested changes, I'll try to explain 
here why not.

>The security considerations say that this specification "makes
>this existing ARP vulnerability no worse, and in some ways
>makes it better" (which I don't doubt), but gives no reference
>for the "existing ARP vulnerability." Such a reference would
>be useful.

Can you suggest a suitable reference?

A Google search for "arp is insecure" finds lots of hits, but none I'd 
call appropriate as a stable reference in an RFC.

>I wondered if some mention of pseduowires might be useful,
>but don't know enough to make a sensible suggestion.

If you can suggest some text I'd be willing to consider it.

>I also wondered whether there should be some mention of IPsec,
>but can't think of anything pressing.

Unlike IPv6 ND, ARP does not run over IP, so IPsec doesn't help.

>  The 'target hardware address'
>  field is ignored and SHOULD be set to all zeroes.
>
>Spencer: why is this SHOULD, and not MUST? I'm not asking for a
>change, I'm asking for a clue.

>This shouldn't even be a SHOULD because it is not required for 
>interoperability.  It certainly can't be a MUST, as it conflicts 
>with a suggestion in the original ARP specificaion (RFC 826).
>
>Here is what RFC 826 has to say about how an ARP implementation sets 
>the target hardware address in an ARP request that it is about to 
>broadcast:
>
>| It does not set ar$tha to anything in particular,
>| because it is this value that it is trying to determine.  It
>| could set ar$tha to the broadcast address for the hardware (all
>| ones in the case of the 10Mbit Ethernet) if that makes it
>| convenient for some aspect of the implementation.  

I see no problem at all with this standard tightening up this particular 
part of RFC 826.

Protocol design has matured since 1982. In those days, it may have been 
reasonable to say that it's okay to put six bytes of whatever you feel 
like into a network packet, and the receiver ignores it. In modern 
specifications, it's not. Such fields are typically labelled MBZ (Must Be 
Zero). The benefit of this is that if compliant implementations can be 
trusted to put zeroes in those fields, it keeps the door open for future 
standards to extend the protocol, by specifying meanings for the non-zero 
values.

No one is saying that old code has to be changed. But... if you want to 
claim that your code complies with this RFC, then you may need to clean 
it up in some places, and "not putting random garbage into the packet" is 
one of the things that it should do if you want to comply with a new, 
modern, more tightly-written RFC.

The reason it's a "SHOULD" not a "MUST" is alluded to above -- there may 
be cases we haven't thought of yet where there's a benefit to be had by 
putting a non-zero value in this field. Some creative implementer may 
think of such a benefit we had not anticipated. Since that would not 
break interoperability, the MBZ recommendation is a "SHOULD" not a 
"MUST". Should some future standard define meanings for the non-zero 
values in a way that's not compatible with what some implementer did, 
then the "SHOULD" lets the writers of that standard go to the 
non-compliant implementers and say, "Hey, you were warned that you'd be 
on your own if you did that."

In practice we know it's highly unlikely for the ARP specification to be 
updated every again, but that's no reason to lower our standards.

>   Sending ARP Replies using broadcast does increase broadcast traffic,
>   but in the worst case by no more than a factor of two.  In the
>   traditional usage of ARP, a unicast ARP Reply only occurs in response
>   to a broadcast ARP Request, so sending these via broadcast instead
>   means that we generate at most one broadcast Reply in response to
>   each existing broadcast Request.  On many networks, ARP traffic is
>   such an insignificant proportion of the total traffic that doubling
>   it makes no practical difference.  However, this may not be true of
>   all networks, so broadcast ARP Replies SHOULD NOT be used
>
>Spencer: slightly confused about why SHOULD NOT, if this is not a
>problem in most cases. Is this stronger (or broader) than it needs to be?

The "SHOULD NOT" term is used in the "harm to the network" sense, i.e. 
"Some people argued that broadcast replies will cause harm to the 
network, so don't do it unless you really know what you're doing, and 
have a very good reason to go against what the RFC recommends, and are 
willing to defend your decision to all those people who will scream that 
you're causing harm to their networks."

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

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Jan 2008 13:50:48 +1300

...
> you're causing harm to their networks."

Back in the days of large bridged networks, redundant broadcasts
of any kind were regarded as highly undesirable. Every
bridge and every host stack had to process the packet, and
this definitely seemed like a Bad Thing. I don't recall that
broadcast ARP replies were ever proved to start ARP storms,
but I was certainly paranoid about that sort of thing. I think
a SHOULD NOT is quite defensible.

   Brian