Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> At 01:59 p.m. 23/09/2005, you wrote:
> 
>> >> > Issue 1 is: When a so-called ICMP "hard error" is received for a
>> >> > connection in any of the synchronized states (ESTABLISHED and so
>> on),
>> >> > treat the error message as a soft error (i.e., do NOT abort the
>> >> > corresponding connection).
>> >>
>> >> WHY? Such an error could occur due to a reboot. It is legitimate
>> >> operation.
>> >
>> >
>> > In that case you should receive an RST, not an ICMP message.
>>
>> Not if there is no TCP running, or none over IPv4 (i.e., convert to
>> IPv6).
> 
> Despite how likely or unlikely you consider this scenario to happen (if
> you are thinking about IDSes/firewalls, then there are other
> more-specific codes to use), why, if TCP was disabled during the life of
> a connection, couldn't it be re-enabled again?

It could. But if it doesn't, again you would receive only an ICMP.

>> > In one case (soft errors draft), an ICMP error message is received
>> > during connection-establishment.
>> > In this case, (ICMP attacks draft), I'm talking about ICMP error
>> > messages received during the life of a connection.
>>
>> But why should one be considered less hard, and one more hard? It's
>> basically reaction to the _inferred_ cause of such a message - in the
>> first case you assume it's benign and use it to fail-over, and in the
>> second you assume it's an attack and want to ignore it.
> 
> It's a matter of mechanism / policy separation.
> 
> The fact that the mechanism is the same does not mean the *policy* has
> to be the same.
> 
> There's a rationale on this very same issue in D. Clark's paper, which
> is cited in my draft. There are other works on mechanism/policy separation.
> 
> I have not invented anything.

You're application of the existing principle is based on your inference
that everything you don't expect MUST be an attack, or at least MUST be
treated as such.

IMO, 'be liberal in what you receive' (Postel's rationale) warrants that
IF there is a legitimate or benign reason that the same packet could
have arrived, then it MUST NOT be treated as an attack.

>> I don't agree with inferring things this way, esp. since such inferences
>> are based on a snapshot of typical use at the time the ID is published.
> 
> Do not infer things... i.e., do not infer attack. Just infer the message
> indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a
> *bit* on this)

I don't understand why the message indicates it's a soft error; it's
clear that some of these messages are hard errors and intended as such
(e.g., the case where TCPv4 disappears).

> BTW, I don't think this reflects "typical use at the time the ID is
> published", unless you are thinking of a time frame of at least fifteen
> years.
> 
> 
> 
>> > An ICMP error message is just a hint. As per D. Clark's paper,
>> depending
>> > on the time you receive the message, the meaning may be different.
>>
>> Agreed - but the meaning should always be considered benign before it is
>> considered an attack. If a benign cause _could_ have resulted in the
>> message, it seems inappropriate to react as if it's an attack.
> 
> I disagree. First, a spurious message is not benign. Unless you would
> also call "benign" a spurious message that resets your connections every
> other second, for example.
> 
> Other than that, the current environment is *not* benign.
> 
> There's a chance someone can break the door of my house, the window of
> my house or even the wall of my house to save me from a fire, or
> whatever (maybe it's just someone that just fell over them!). However,
> it seems to be fair to think that if someone does break my window, door,
> or wall, there are much more likely reasons for doing this, than
> "benign" ones.
> 
> Anyway, again: the draft describes possible attacks, and possible ways
> to address them. No need to "infer": Implement this if it's one of the
> described attacks that is taking place, it will protect you. If it's
> not, it won't hurt you.

It will protect you from the firemen too (e.g., ICMPs for TCPv4 that
disappears, as one example). Which DOES hurt you.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOasJE5f5cImnZrsRAmWfAKDNolzOILsIacjEbeGVuyQiZ6jZJwCfT4Eo
21aZUOPpjPEMiCDMLVQTjoA=
=oUJO
-----END PGP SIGNATURE-----

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