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 PROTECTED]> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
