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

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.

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

> Overall, it seems to me that there don't arise additional attack
> opportunities if there was congestion control on ICMP messages.

Basically the above; ICMPs don't need to have forged source addresses,
but in-band attacks do.

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