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

[Gorry Fairhurst <[e-mail]>]

Maybe I was not clear:

At a first read, this I-D seems to ask an IETF WG to publish an 
informational document that  says actual implementations do not observe 
one Standards-track RFC  (RFC1122, saying TCP provides its own 
mechanisms), and has currently has an unknown relationship with a second 
  Standards-track RFC (RFC4821). The second was my main comment - we 
need to know more (see text below) about the level of 
conformance/deviation - so you suggestion of more text here would be 
most welcome.

Other comments in line.

Fernando Gont wrote:
> 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.
>
OK. That's useful to know.

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

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

[Section 6]

The generation of SQ by actual routers is already deprecated.

So, the new thing in this draft is that it observes that some 
implementations do not use SQ for TCP, since they have other ways to 
detect and react to congestion. That seems logical, if the IETF is 
publishing this document, we should make this change clear for other 
implementors to follow. My take is:
* It can be acceptable to ignore SQ, because CC provides an equivalent 
function.
* If hosts were to act upon SQ (in some future method) they should 
validate the response.

- Put this way, it sounds a lot like the PMTUD/PLPMTUD argument.

> 
>> * 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 believe that RFC 4821 does not necessarily obsolete traditional PMTUD.
>
Correct, as far as I know.

RFC4821 is a separate STD-track document, applicable to TCP.

> 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.
> 
The methods could be seen to parallel the concepts of RFC4821.

Do you think they seek to do similar things?

Can the methods be related to specific sections of RFC4821?

If this is to be published as an IETF document, I'd like to see if
this could be seen as a partial or full implementation, and if so does
it deviate from the specification?

>> * 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. 
>
So that just makes me wonder if the WG has agreed or not to this list.

> (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.
> 
Either way, as long as the WG is happy with this.

>> * 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.
> 
The SQ topic was discussed earlier.

Specifically, PLPMTUD is a recent standards track document though. I
think my comment comes from reading the title and abstract. If the
document talks about three methods, then this could perhaps be used to
update the abstract to say what is described. At the moment, the need 
for implementors to read this is not called out in the abstract. As a 
TCP-implementor, I should see something there that tells me this is 
something I should read.

> 
>> 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
> 
> 
Best wishes,

Gorry



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