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

Fernando Gont <fernando@gont.com.ar> Mon, 01 December 2008 18:24 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481D53A6B8A; Mon, 1 Dec 2008 10:24:20 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DF13A6B8A for <tcpm@core3.amsl.com>; Mon, 1 Dec 2008 10:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level:
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LtLBl81HCmK for <tcpm@core3.amsl.com>; Mon, 1 Dec 2008 10:24:18 -0800 (PST)
Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8D3D63A6B13 for <tcpm@ietf.org>; Mon, 1 Dec 2008 10:24:16 -0800 (PST)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 241346B6A47; Mon, 1 Dec 2008 15:24:14 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-50-77.speedy.com.ar [201.254.50.77] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id mB1INvlv021947; Mon, 1 Dec 2008 16:24:00 -0200
Message-Id: <200812011824.mB1INvlv021947@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 01 Dec 2008 15:15:18 -0300
To: gorry@erg.abdn.ac.uk
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <4933E7BF.2090200@erg.abdn.ac.uk>
References: <492D2726.3060505@erg.abdn.ac.uk> <200811270525.mAR5PWGK018547@venus.xmundo.net> <4933E7BF.2090200@erg.abdn.ac.uk>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 01 Dec 2008 15:24:13 -0300 (ART)
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-04.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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

>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),

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 
>conformance/deviation - so you suggestion of more text here would be 
>most welcome.

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

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.
>* If hosts were to act upon SQ (in some future method) they should 
>validate the response.

Validate the response with the TCP SEQ, you mean?



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

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.


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

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.



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

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.



>>>* 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'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
>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 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,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm