Re: [tcpm] Congestion control in face of ICMP unreachable messages

[Daniel Schaffrath <[e-mail]>]

Thanks, Joe, for all the patience.

On 2007/09/13  , at 05:01, Joe Touch wrote:

> Hi, Daniel,
>
> Daniel Schaffrath wrote:
>> On 2007/09/07  , at 16:13, Joe Touch wrote:
>>> Daniel Schaffrath wrote:
>>>> On 2007/08/17  , at 18:41, Joe Touch wrote:
>>>>> AFAIK, congestion control response to in-band messages (ACKs) and
>>>>> timeouts (implied loss, as TCP interprets it), as well as to  
>>>>> some new
>>>>> fields (ECN, etc.) which are carried in the same packets.
>>>>>
>>>>> Reactions to external congestion signals - ICMP source quench  
>>>>> (which
>>>>> has
>>>>> been informally deprecated a while ago, but has not been  
>>>>> documented as
>>>>> such yet) or otherwise - would constitute another opportunity  
>>>>> for a DOS
>>>>> attack, and seem like a bad idea to encourage.
>>>>
>>>> I am note sure your security concerns really apply :) If the bad  
>>>> user
>>>> controls the forwarding node, there is no need to rely on ICMP  
>>>> message
>>>> to cause harm. Instead, just dropping random segments would do  
>>>> the job.
>>>> If the bad user is off the forwarding node, she would need (as  
>>>> usual)
>>>> guess port and sequence numbers.
>>>
>>> Only port numbers. Sequence numbers strictly don't matter for ICMPs.
>> But that is under way, if I am not mistaken
>> (draft-ietf-tcpm-icmp-attacks-02). And Linux for instance already
>> implements it...
>
> I've already spoken about this at previous IETFs and on this list.
Sorry. I am actually new to the matter...

> The basic summary:
> - the network is under no obligation to respond with ICMPs within  
> one RTT
That's a very valuable hint! And gives motivation why RFC 1122 after  
the receipt of an ICMP (host/net) unreachable message only requests  
to flag a "soft error" to the application allows continuing sending  
(simply because the issue about the unreachability might have changed  
in the meantime...) Correct?

Are there any other boundaries as RTT for ICMPs? Anyway, how come  
that there is the possibility of late ICMPs?


> - as a result, checking to ensure that ICMPs are in-window is  
> incorrect
> as it will drop legitimate responses - or worse, interpret them as  
> attacks
>
> The fact that an I-D remains on this point and that Linux  
> implements it
> does not change the above.
And how come that there is an I-D on dropping legitimate responses  
from the network?

Maybe one mitigation might be to relax the window check to accept a  
few older windows and not just the current one, thereby allowing  
proper handling of "late" ICMPs, but still filtering some malicious  
ICMPs . But as this is so obvious is has probably some (hidden)  
shortcoming (which I can't think of at the moment).


>>>> If she is able to guess right, she
>>>> might as well opt to send forged ACK dupacks to cause harm, or  
>>>> for an
>>>> ECN capable transport just one ECE marked ACK.
>>>
>>> ICMPs don't need to come from the endpoint IP address, i.e., address
>>> verification will prevent spoofed ACKs, but cannot prevent ICMPs,  
>>> since
>>> the latter need not have spoofed source addresses.
>>
>> Ok, but if a router is (potentially) able to check for spoofed IP  
>> source
>> addresses it could as well check for spoofed/illegal ICMP payloads
>> (which contain both IP addresses) . Isn't that true?
>
> Routers can check for spoofed addresses as they enter protected  
> regions
> of the Internet; if there's a hole in that 'fence' however, packets  
> can
> leak in. Once in, they can't necessarily be checked for spoofed
> addresses unless they're authenticated, and most are not.
But, again: isn't it true that if and only if for a given datagram a  
router is able to decide whether the source address of that datagram  
is spoofed, then that router could also decide (if that datagram  
contained an ICMP unreachable message) whether the source IP in the  
ICMP payload is spoofed or not (and act accordingly, i.e., drop it or  
not). So, overall there don't arise additional attack opportunities  
when there was some (to be defined) congestion control in face of  
ICMP (host/net) unreachable messages (which was my original claim).  
Sorry, maybe I am bit theoretical here, but I'd love to check if my  
understanding is correct.

[...]

Thanks again and thanks a lot!!
Daniel Schaffrath


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