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

Fernando Gont wrote:
> 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.

We're not opening anything. It's already open, at least as spec'd.

> For instance, we are also
> working on spoofing attacks. If you want to be generous, then take all
> spoofed packets as legitimate.

Which is what I have proposed - except where we can assert they are
spoofed with some level of confidence, rather than just a wild guess,
i.e., with TCP/MD5 or IPsec.

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

Security considerations doesn't assume everything is an attack, but
rather whether things we do introduce new vunerabilities - which isn't
an issue here.

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

While I agree with that, assuming that we can infer different policies
just based on whether a connection has been established is equally
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".

I'm not rehashing it; I think the reasons for the past spec still apply.

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

What would THAT do? You want to NOT act on them at the TCP level, but
pass them to the app anyway? Why?

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

That presumes I think that there is a viable way to secure ICMP, which I
don't so far. If you don't think it's secure, discard all ICMPs.

Otherwise, act on what you get, because there's no way to distinguish
one ICMP from another just based on the content of the ICMP per se. This
goes back to your policy issue - I do agree that we should act on
different ones differently, just not that these cases (legitimate ICMPs
vs spoofed) are distinguishable.

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

Well, FWIW, the IAB/IESG also approved a number of drafts to go to RFC
standards-track that violate RFC791 on the use of IP ID (ROHC), and a
recent one we discussed in this group that depended normatively on a
mechanism that was an ID. I.e., they make mistakes too (as do we all).

Joe

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

Attachment: signature.asc