Re: source-quench I-D

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 30 November 2010 08:42 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECFB3A6831 for <tsvwg@core3.amsl.com>; Tue, 30 Nov 2010 00:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 JhTYGwqJa5oh for <tsvwg@core3.amsl.com>; Tue, 30 Nov 2010 00:42:15 -0800 (PST)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id F02103A69C5 for <tsvwg@ietf.org>; Tue, 30 Nov 2010 00:42:14 -0800 (PST)
Received: from Gorry-Fairhursts-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id oAU8hDGh014979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Nov 2010 08:43:15 GMT
Message-ID: <4CF4B921.1040600@erg.abdn.ac.uk>
Date: Tue, 30 Nov 2010 08:43:13 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: source-quench I-D
References: <4CE39964.2070803@gont.com.ar> <201011171750.oAHHo1tQ028778@sj-core-5.cisco.com> <4CE43292.4010707@gont.com.ar> <4CE4DCB4.8010409@erg.abdn.ac.uk> <4CF43C3E.9080106@gont.com.ar>
In-Reply-To: <4CF43C3E.9080106@gont.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: tsvwg list <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2010 08:42:16 -0000

Here's a short off-list discussion, that I am copying to the list. The 
response below is not intended as a Chair contribution, it is just my 
own thoughts:

On 29/11/2010 23:50, Fernando Gont wrote:
> Hi, Gorry,
>
>> Another point, if you wanted to think is that we have routinely filtered
>> SQ in our firewall - is this important/unimportant?
>
> Do you mean that you have found Source Quench messages in your firewall,
> or that the draft should take a stance as to whether these messages
> should be filtered in firewalls?
>
I think the security consideration section, if we write an RFC on this 
topic, should note RFC 1812, saying it is not necessary for a firewall 
to forwrad this, since a host should not use it exclusively as an 
indicator of congestion, and it could be exploited in an off-path DoS 
attack if the host stack was not correctly implemented.

>
>> My own personal view would be that this is a TSVWG topic, in that it
>> impacts multiple transports and section 2 should say other IETF
>> transports also ignore SQ:-).
>
> Will do. -- FWIW, this might be good to comment (hat-off) on the tsvwg
> list. ;-)
>
> P.S.: Some have argued (off-list) that this document should also update
> RFC 1812 such that the "SHOULD NOT generate ICMP SQ" is changed to "MUST
> NOT generate ICMP SQ". Thoughts?
>
I think the recommendation in 4.3.3.3 of this RFC is correct:
"A router SHOULD NOT originate ICMP Source Quench messages."
- I'm not sure what further standards action is required in this respect.

IMHO, the following statement should with hindsight have been written as 
"SHOULD" rather than "MAY":
"A router MAY ignore any ICMP Source Quench messages it receives."

- I see 5.3.6 already concludes (which seems fair enough):
   "ICMP Source Quench is a very weak mechanism,
    so it is not necessary for a router to send it, and host software
    should not use it exclusively as an indicator of congestion."

> Thanks!
>


Gorry