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

[Fernando Gont <[e-mail]>]

At 05:26 p.m. 27/09/2005, Joe Touch wrote:

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

Exactly. But this means the so-called ICMP hard errors do not necessarily 
indicate "hard errors".
Treating had errors as soft errors (in the synchronized states) improves 
TCP's robustness.



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

No. I'm just saying that one needs to be more cautious when processing ICMP 
messages.
The ICMP messages could be part of an attack, or could be stale. In any of 
these two cases, honoring them would be ill advice.

The same policies that protect you from attack also protect you from stale 
error messages.



>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 disagree. That's just an interpretation. I take it as "even something you 
don't expect should not break your system" i.e. "you should be albe to deal 
with unexpected packets nicely".



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

Yes, *some*, and in *certain* circumstances/scenarios. The more 
conservative way to go is to not break connections.



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

I does not hurt. Remember: ICMP is unreliable. The ICMP error message may 
be corrupted, may be subject to rate limitation, etc.
And again, processing of protocol unreachables is a SHOULD, not a MUST.

If you really think my proposal hurts, you should submit a proposal 
entitled "Tunnelling ICMP over TCP", or the like.


--
Fernando Gont
e-mail: [e-mail] || [e-mail]






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