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

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 01 Dec 2008 13:33:51 +0000

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: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
Best wishes,

Gorry

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 01 Dec 2008 15:15:18 -0300

At 10:33 a.m. 01/12/2008, Gorry Fairhurst wrote:

>informational document that  says actual implementations do not 
>observe one Standards-track RFC  (RFC1122, saying TCP provides its 
>own mechanisms),

I'd say they do not observe neither RFC1122 (reaction to hard errors) 
nor RFC 792 (reaction to SQ).

>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 

I will read RFC 4821 in detail, and will come back to you on this 
one, with some proposed text.

>>>* 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]
>
>implementors to follow.

At some point, the draft actually recommended hosts to do that. 
However, the text was rephrased because as the doc was (and still is) 
aiming at Informational, it shouldn't make any recommendations. 
(Maybe I could split this particular "recommendation" into a 
stand-alone std track document that simply deprecates SQ? Given that 
it would be a std track document, it could actually deprecate SQ. 
FWIW, we had all agreed on deprecating SQ).

>My take is:
>* It can be acceptable to ignore SQ, because CC provides an 
>equivalent function.

Validate the response with the TCP SEQ, you mean?

>>implement PLPMTUD just for black-hole detection. I agree that 
>>additional discussion of PLPMTUD might be included, though.

IIRC, some things do parallel RFC4821. e.g., RFC 4821 interprets that 
if a probe segment is lost, it was lost due to the packet being "too 
big". My I-D interprets that, unless the the corresponding TCP 
segment was lost, the ICMP error message cannot be considered as 
"legitimate". RFC 4821 relies on timeouts to discover the Path-MTU. 
My I-D relies on timeouts to validate ICMP "frag needed" error messages.

>it deviate from the specification?

The PMTUD stuff is simply "stronger" validation of ICMP "frag needed" 
than that provided by simply checking the TCP SEQ. As a result, it 
suffers from ICMP black-holes as RFC 1191 does.

The PMTUD stuff in the ICMP attacks draft has been incorporated in 
some stacks (at least NetBSD and OpenBSD), to mitigate the attacks 
described in the document.

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

Not sure what to say. I guess that unless somebody yells, it means 
that they don't feel uncomfortable with what is in the document.

>>>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.
>Specifically, PLPMTUD is a recent standards track document though.

I'm not sure PLPMTUD really affects this document. This I-D is about 
the traditional PMTUD mechanism. While a pointer can be included 
stating "This particular attack can be avoided if PLPMTUD is 
implemented, as it does not rely on ICMP messages", the stuff in the 
document still applies to hosts that decide to implement RFC 1191 
(instead of PLPMTUD) or that decide to implement PLPMTUD only for 
black-hole detection.

>I
>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 come back to you with some alternative Abstract. If there's 
anything in particular you'd like to see there (other than an 
explicit comment stating that there are three attack.vectors), or you 
ahve some proposal for the abstract, please let me know...

Thanks!

Kind regards,