[tcpm] comments on draft-ietf-tcpm-icmp-attacks-05

["Eddy, Wesley M. (GRC-MS00)[Verizon]" <[e-mail]>]

As a WG participant (not co-chair), here are some
comments I have after reading the latest version
of the ICMP attacks draft:

1) (editorial) In Section 2.1, don't capitalize
"Architecture", as it makes "Internet Architecture"
look like some kind of specific proper noun, which
it definitely isn't.

2) (question) In Section 2.1, we have:
"When an intermediate router detects a network
problem while trying to forward an IP packet,
it will usually send an ICMP ..."  Do we
want "will usually" or "has the option to", or
something similar?  I'm not aware of the actual
statistics on this.

3) (editorial) In Section 3, first sentence,
"internet header" -> "IP header" ?

4) (technical) For the last paragraph in section
3, we focus on the lack of IKE usage as a reason
why IPsec can't generally be used to authenticate
ICMP messages, but I think the bigger problem is
that even if we all ran IPsec, we'd need to have
routers using certificates with paths compatible
for all other hosts on the network ... not too
feasible from what I can tell.  I think this is
more difficult than either the deployment or the
embedded devices issue that the draft mentions.

5) (general) Section 5.1, last paragraph, it
seems like we should be mentioning TCP-AO as
well here, though I don't think it changes any
part of the claim.

6) (editorial) Section 5.2, typo "preferebable"

7) (editorial) Section 6.2, "On the other hand,
TCP implements its own congestion control
mechanisms ..." ... I don't think this is
really an "on the other hand", I think it's
more of a "Furthermore".

8) (general) In Section 6.2, I think we can be
stronger and say that the 1122 requirement to
react to source quench is no longer pertinent,
as the Internet has moved well beyond needing
this.

9) (general) Wow, section 7 takes a much closer
look at PMTUD than I ever expected to find here;
roughly half the document sits in this topic
alone.  Is this *really* an attack that we're
that worried about in a general case?  

The modifications in this part of the document
seem too complex for what they buy, to me.  It
seems like in places where there's concern about
it, we can just say to ignore these ICMPs and use
the PLPMTUD (4821) instead.  I can understand
that what's in the draft has been implemented,
but how valuable is it really when we already
have a Proposed Standard in PLPMTUD that can
totally answer to this concern by just ignoring
the ICMPs in question?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------