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

[Fernando Gont <[e-mail]>]

At 12:46 p.m. 29/09/2005, Joe Touch wrote:

> > It's not useful to open the door to attack.
>
>We're not opening anything. It's already open, at least as spec'd.

Yes, and that's not good.


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

Because, if anything, I'd leave the apps the choice to make something 
stupid, intentionally, rather than keeping TCP vulnerable to trivial 
ICMP-based connection-reset attacks.


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

No. That means you are making an argument for a protocol which is already 
unreliable.


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

I don't think their are distinguishable, either.

I just mean that making as many checks as possible reduces the chance of 
being hit by spoofed.
And that being more conservative on the ones that would cause more harm is 
a good thing.



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

That's more of an administrative/procedural than a technical error. Was 
their technical rationale broken?


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






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