Re: [dhcwg] Review of draft-ietf-dhc-dna-ipv4-14.txt

On Tue, Aug 09, 2005 at 02:00:52PM +0200, Stig Venaas wrote:
> draft-ietf-dhc-dna-ipv4-14.txt is now available. Since it was submitted
> to the IESG (rev 09) there are a number of changes, in particular from
> rev 12 to rev 14. We (the wg) need to review this and check that we're
> still okay with the draft.

Issue #1, a nitpick.

The abstract and introductory words;

	This document synthesizes experience in the deployment	

I think Mr. Aboba meant;

	This document synthesizes from experience in the deployment
				  ^^^^
	of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses
	a set of steps known as Detecting Network Attachment for IPv4
	^

Note inclusion of 'from' and omission of 'to define'.

Issue #2, ICMP Echo ARP cache pollution wording changes.

Section 2.2.1, I liked the previous more vague description of the arp
cache pollution threat from ICMP better.  "It is bad, and you should
learn why before you go and send an ICMP packet."

There are at least two different kinds of ARP cache pollution that can
happen, and the new description seems to have marginalized one of them,
which annoyingly is the one I'm more worried about.

Suffice to say, sending an ICMP echo request can result in ARP cache
pollution on the default gateway in circumstances where you can
predict the exchange WILL NOT result in an ARP request, much less one
containing the host's IPv4 address in arp$spa, as the text now lists
as mandatory for the condition to ocurr.

Consider the point of view of the default gateway receiving an ICMP
Echo Request packet.

In the case where the source IP address of the ICMP Echo Request packet
is in the local subnet, you have everything you need in headers to respond
right away.  Why ARP request for the source MAC address of the ICMP Echo
Request?

So, the source MAC is shoved into the ARP cache to short circuit this.
When you send your response, you already know the requestor's ARP mapping
and can send the packet straight away without having to wait for a reply
back from ARP.

It's an ICMP optimization, but also has become a popular means for
"High Availability" clusters to change MACs associated with service
IP addresses without having to wait for the cache to time out.

I know from experience that at least Cisco models of the era I used
to network do this.  I presume this is still the case today (a
grandfather IOS feature), and that many other routers probably do
the same.

I'm more worried about pollution on the default gateway's arp cache
than any other node on the network, so even if we had to choose between
which two of these pitfalls to describe, I still think the draft has
chosen the wrong one.

I don't think we want to get into a big discussion in exactly what
circumstances arp cache pollution may ocurr.  I think the draft was
right the first time around in just saying "Sending an ICMP Echo
Request to the default gateway may result in ARP cache pollution."

If the IESG is pushing back on this, I think the only answer is an
appendix devoted to the problems with ICMP echo request.  There are
many ways it can be made to go wrong, and the statement in the draft
currently is misleading to suggest it requires those pre-requisites
to fail.

I don't like that idea.  It will take a lot of Mr. Aboba's time and I
don't think it will be really useful to the majority of implementors.

I'd rather it had stayed vague.

Issue #3, another wording nitpick.

Appendix A.1, "Then it only worth considering"...looks like an editing
error...you took out 'is' in -12 according to the diff.  I think that
'is' belongs there.

Issue #4, ICMP Router Discovery influencing DNA?

Appendix A.3, I realize this text just moved, but now on my third reading
of these words (I think), I wonder at part of the meaning.  Is this an
indication that default gateways learned via ICMP Router Discovery are
acceptable "Section 2" targets for DNA?

I hadn't thought about that dimension to these words.  I don't have an
opinion yet, I just wanted to bring it under the WG's lens.

Issues 1 and 3 are just nitpicks.  4 needs more WG exposure I think.

I'm fairly concerned about 2.  I think it can lead people into thinking
they can get away with a broken scenario ("You can do ICMP Echo if...").

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins