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

Daniel Schaffrath wrote:
...
>> 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?

Basically. It's an indication that a packet hit a roadblock, but not
that the roadblock is essentially permanent. That happens only at the
destination (i.e., if the destination is gone, then game's over).

> Are there any other boundaries as RTT for ICMPs? 

None per se.

> Anyway, how come that
> there is the possibility of late ICMPs?

Routers respond with ICMPs only when they have cycles - otherwise, they
could go into overload giving feedback. That's in RFC1812.

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

Once the window wraps all windows look the same. At that point, there's
nothing useful to check.

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

Not true. IP addresses are checked two ways - with explicit
authentication (which we're not talking about; that involves IPsec,
e.g.) or by verifying which port they arrive on (and which router they
arrive from). Let's focus on that second part.

Let's say that IP address X must come in on port 3 from router Q. ICMPs
that report IP address X incorrect can come in on any port, from any
router. There's no rule that ICMPs must be routed the same way as the IP
packets they report on. The ICMP has a different source IP address, so
it could easily be routed via other paths.

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

I think there do, because of the above...

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

Attachment: signature.asc