Re: source-quench I-D

[Gorry Fairhurst <[e-mail]>]

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