Subject: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-04.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 26 Nov 2008 10:38:30 +0000

I volunteered to review this I-D in the TCPM meeting in MPLS.

I'd like to make the following observations, and explore whether these 
are issues:

* It was interesting to read the issues presented in the I-D. The I-D is 
mainly documentation of algorithms and current practice. If published, 
this seems like an informational document - I can not determine whether 
this is needed, and whether the material could already be covered by 
other documentation.

* One section of the document (6) describes issues with Source-Quench, 
however this is not a credible issue - it has long been known that 
Source-Quench is not of value. I think this section could safely be 
omitted, reduced or combined with earlier sections to provide more 
rationale for the main part of the I-D.

* The main part of the document is about PMTUD vulnerabilities to ICMP 
attacks and some deployed countermeasures. In my opinion, this 
discussion should be set against the framework defined by the IETF 
standards-track  "Packetization Layer Path MTU Discovery", RFC 4821, 
March 2007. This is not currently mentioned, which I find very 
confusing. I'd suggest that if the document is to be published as a 
useful output of the transport area it must compare the non-ICMP methods 
to those in RFC 4821.

* Appendix A concludes with an interpretation of the meaning of several 
RFCs. If this is the result of an IETF WG consensus call, this needs to 
be made clear and more effort needs to be made to determine the correct 
advice. If this is the editor's own view, then it should be omitted from 
a working group draft.

* Finally, I do not see a detailed discussion of ICMP issues in general 
as the title suggests, but more of a focus on PMTUD attacks. A change to 
the title and abstract would help attract the right people to read this 
and better reflect the actual content.

I will separately send some comments on the document itself to the list, 
but have decided to postpone the final stage of the review until I hear 
more about the relationship to PLPMTUD, since this may require some 
reworking of the document. It may be that there has been discussion on 
this topic before, if so please let me know.

Best wishes,

Gorry
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Nov 2008 02:19:07 -0300

Hello, Gorry,

Thanks so much for your thorough and timely review. You'll find my 
comments in-line....

>* It was interesting to read the issues presented in the I-D. The 
>I-D is mainly documentation of algorithms and current practice. If 
>published, this seems like an informational document - I can not 
>determine whether this is needed, and whether the material could 
>already be covered by other documentation.

It is not covered by other documentation. For instance, this 
Internet-Draft is the document that has been referenced in a number 
of vulnerability advisories published on these issues (e.g. by 
CERT/CC and UK NISCC), and has also been referenced by a number of 
vulnerability advisories published by vendors when they addressed these issues.

>* One section of the document (6) describes issues with 
>Source-Quench, however this is not a credible issue - it has long 
>been known that Source-Quench is not of value. I think this section 
>could safely be omitted, reduced or combined with earlier sections 
>to provide more rationale for the main part of the I-D.

I'm not sure what you mean. It may have been known that SQ was not of 
value... yet all implementations were responding to SQ as specified 
by the IETF. And it was in response to this I-D that many 
implementations removed support for SQ (e.g., I did the corresponding 
patch for OpenBSD).

>* The main part of the document is about PMTUD vulnerabilities to 
>ICMP attacks and some deployed countermeasures. In my opinion, this 
>useful output of the transport area it must compare the non-ICMP 
>methods to those in RFC 4821.

I belive that RFC 4821 does not necessarily obsolete traditional 
PMTUD. They may be orthogonal. That is, as stated in RFC 4821, you 
could implement PLPMTUD just for black-hole detection. I agree that 
additional discussion of PLPMTUD might be included, though.

>* Appendix A concludes with an interpretation of the meaning of 
>several RFCs. If this is the result of an IETF WG consensus call, 
>this needs to be made clear and more effort needs to be made to 
>determine the correct advice. If this is the editor's own view, then 
>it should be omitted from a working group draft.

This text was included in the document even before it was accepted as 
a wg document. (BTW, I do not recall when or why I moved that text 
out of the main body of the doc to an appendix). I don't seem to 
recall people arguing again this particular text. However, I'm open 
to remove this text if the wg feels this is a show-stopper.

>* Finally, I do not see a detailed discussion of ICMP issues in 
>general as the title suggests, but more of a focus on PMTUD attacks. 
>A change to the title and abstract would help attract the right 
>people to read this and better reflect the actual content.

The document discusses ICMP attacks against TCP. There are basically 
three of them: connection.reset (hard errors), throughput reduction 
(Source Quench), and the PMTUD ones. It's not that it focuses on the 
PMTUD ones, but rather that the full counter-measure for the PMTUD 
attack is more complex, so it requires more analysys, test-case 
scenarios, etc. That's it.

>I will separately send some comments on the document itself to the 
>list, but have decided to postpone the final stage of the review 
>until I hear more about the relationship to PLPMTUD, since this may 
>require some reworking of the document. It may be that there has 
>been discussion on this topic before, if so please let me know.

Please let me know if the above answer your questions....

Thanks so much for your review!

Kind regards,

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