Re: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> At 08:08 a.m. 07/11/2005, Joe Touch wrote:
> 
>> >> and tone
>> >> of the argument changed as well. These are not - and cannot be put
>> forth
>> >> as - security issues.
>> >
>> > I disagree. The draft explains how an attacker can take advantage of
>> the
>> > described vulnerabilities. And, indeed, the ICMP-based connection-reset
>> > attack is much more trivial to perform than its TCP-based counterpart.
>>
>> It does NOT address the substantial vulnerabilities that remain, or the
> 
> You mean man in the middle attacks, or what?

Yes.

>> effect of interpreting all invalid exchanges as attacks (which I feel is
>> both overkill and inappropriate).
> 
> You implement the proposed mechanisms as counter-measures for ICMP-based
> attacks. In the event some packet is not part of an attack, the
> counter-measures will not hurt you, anyway, because ICMP is unreliable.

We've been over this one before; you make the system less functional by
dismissing correct ICMPs that end up reaching you.

>> >> We can talk about them being useful in how they mitigate the effect of
>> >> stale packets, and then - as a corellary - how some attacks emulate
>> >> stale packets.
>> >
>> > This could be true for the TCP sequence number check. But none of the
>> > attack-specific counter-measures have anything to do with stale
>> packets.
>> > If anything, they have to do with checking progress on the connection.
>>
>> Which is another kind of validity, but one that assumes that a
>> connection making progress should not also incur these kinds of signals.
>> I've described cases where non-malicious systems can behave this way.
> 
> Yes. And what is the problem if an ICMP message does not pass the
> proposed checks, not because it's part of an attack, but because it was
> caused by a stale TCP segment or whatever?

Stale is OK. The cases I'm talking about are TCP connections making
progress over multipath routing where one path is flakey and sends
ICMPs. That's not stale.

>> > If you just mitigate stale packets, you are still vulnerable to
>> > in-window attacks. The draft solves in-window attacks, which, as a
>> > corellary, solves the case of stale packets.
>>
>> It doesn't identify attacks; it (over)interprets certain behaviors as
>> attacks.
> 
> From the receiver's point of view, you cannot tell the difference.
> That's why, given the current hostile environments, it's fair to think
> bad guys may be behind these packets.

So why aren't ALL packets considered an attack in such an environment?

Yes, it's fair to think that bad guys MAY be behind the packets, but
only if you also think that good guys MAY as well. I consider it
dangerous to consider correct behavior as an attack.

>> I agree that making progress might be a reason to change the current
>> behavior of TCP/ICMP because TCP is making progress and the ICMPs can be
>> considered irrelevent - NOT AN ATTACK.
> 
> The draft does not mean that . It just means that we will implement a
> set of mechanisms that in the presence of blind ICMP-based attacks, it
> will protect us from them. It does not aim to guess whether the packet
> correspond to an attack, or not.

Yes it does; it guesses that any unexpected ICMP _is_ an attack that
should thus be ignored.

...
>> If you shut all in-window attacks, you've disabled a functioning
>> feature.
> 
> A feature you cannot depend on?

A feature that works for legitimate hosts. Short of doing
authentication, you can't "depend" on any packet.

Joe

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