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

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

Not to recovery, but that's the issue with another draft. ;-)

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

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.

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

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? ;-)

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.

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

And this changes it to a MUST NOT. Which I disagree with.

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

	not all IDs *SHOULD* go to RFC

Sometimes the solution is to not write anything, and leave things as-is.

Joe

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

Attachment: signature.asc