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

[Fernando Gont <[e-mail]>]

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

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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm