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

[Fernando Gont <[e-mail]>]

At 09:36 a.m. 29/09/2005, Joe Touch wrote:

> >> 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.
>
>That's true. The question is when/whether you can determine either. If
>you can't, then NOT honoring them is ill advice. The principle of 'be
>generous in what you receive' means it's more useful in general to
>assume the best, not the worst, of things you don't have other
>indications about.

It's not useful to open the door to attack. For instance, we are also 
working on spoofing attacks. If you want to be generous, then take all 
spoofed packets as legitimate.



> > 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".
>
>Yeah - and these could be unexpected, but legitimate. So you interpret
>them as attacks and ignore them?

I don't necessarily take them as attack. And I disagree with your 
interpretation of the robustness principle, in 2005 (and up) it's fair to 
assume the environmnent is hostile. That's why there's a mandatory 
"Security Considerations" section in today's documents.



> >> 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.
>
>Or break connections that are in the process of being established
>either. So which ID do you want to withdraw, this or the TCP soft-errors
>one? ;-)

The soft errors one is not for the Standards track, anymore.

And, as I said before, assuming that the same mechanism always implies the 
same policy is short-sighted.



>And conservative in this forum also includes "don't change the spec
>unless absolutely necessary". Near as I can tell, this is motivated
>solely by security, which it does not provide.

That's "rehashing the past", rather than "being conservative".



> >> > 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.
>
>And this changes it to a MUST NOT. Which I disagree with.

The app can still shoot itself, as my draft does not say the hard errors 
should not be signaled to the user application.



> > If you really think my proposal hurts, you should submit a proposal
> > entitled "Tunnelling ICMP over TCP", or the like.
>
>You've repeatedly suggested that if I don't like your drafts, I should
>write alternative drafts. Here's my perspective on this:

No, what I'm meaning is that if you think that treating hard errors as soft 
errors is ill-adviced, you should also arge that running ICMP over IP is 
ill-adviced.



>         not all IDs *SHOULD* go to RFC
>
>Sometimes the solution is to not write anything, and leave things as-is.

Me, a number of people here, the industry, and the IAB seem to have a 
different view on this draft. I respect yours, anyway.


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






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