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

[Fernando Gont <[e-mail]>]

Hello, Wesley,

Thanks so much for your feedback. Comments-inline...


> 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.

I think this was capitalized in Dave's Clark paper. But have no problem
with the proposed change.



> 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.

The router will send an ICMP error message, unless rate-limiting
prevents it. That's my understanding. And this is what RFC 1812 states.



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

Will do. (Although the ICMP spec uses the term "internet header" rather
than "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 ... 

Sorry. You meant that all the routers in the path should be using
certificates?


> 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.

Agreed.



> 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.

Agreed. Maybe this is also an indication that TCP-AO *should* change
something in this respect!



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

Will do.



> 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".

Will do. ("english as a second language" here. :-( )



> 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.

I fully agree with you. However, at some point in the past there was all
these discussions that the document was "going against the standards",
and that it was "too strong", being an "Informational" document. Hence
it's not as strong as I would have liked it to be.

That said, the internet has moved beyond reseting established
connections in response to hard errors, too. :-)



> 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.  

Yes. And it could have been worse. Because for the other two
vulnerabilities, it all boils down to "ignore source quenches" and
"process hard errors as soft errors if they are received for connections
in any of the synchronized states". But you cannot ignore "frag needed"
messages.


> Is this *really* an attack that we're
> that worried about in a general case?  

Yes. See the "Acknowledgement" section of the I-D -- it was reviewed by
people from Free', Net', and OpenBSD, Solaris and opensolaris, Cisco,
Extremenetworks, and others. Yes, that's not the world... but I'd argue
that a good sample.

Without the TCP seq check, is trivial (and with an advertised MTU of 0
it even crashed some implementations). With the TCP SEQ check, things
are not so bad... but the windows keep increasing.

That said, the document is informational, and documents what has been
done in the industry. And the stuff in Section 7 is implemented in a
number of systems and deployed already in the Internet.



> The modifications in this part of the document
> seem too complex for what they buy, to me.  

I did the patch myself for OpenBSD in a few hours (and it was probably
my first commit to the tree). Conceptually speaking, it's even simpler:
Before you know data has successfully been transferred to the remote
endpoint, just validate the ICMP error messages by checking the TCP SEQ.
Once you have successfully transferred data, check for progress on the
connection before honoring the ICMP error messages).



> 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?

I have already been told by a number of developers that they would not
implement the ICMP-free version of PLPMTUD, because of its convergence
time. They are more willing to implement it for icmp blackhole detection.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1