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

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Sep 2005 07:58:58 -0300

Folks

I will separate the discussion into different issues, so that it is easier 
to get consensus on the different parts of the draft.

Issue 1 is: When a so-called ICMP "hard error" is received for a connection 
in any of the synchronized states (ESTABLISHED and so on), treat the error 
message as a soft error (i.e., do NOT abort the corresponding connection).

This improves TCP's robustness. In the event the error condition does not 
disappear in the near term, the connection will time out, anyway.

Note: ICMP is *unreliable*: you cannot depend on it, anyway.

All BSD-derived and Mentat-derived implementations have been doing this for 
at least fifteen years.

Comments?

Kindest regards,

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

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Sep 2005 07:32:02 -0700

Fernando Gont wrote:
> Folks
> 
> I will separate the discussion into different issues, so that it is
> easier to get consensus on the different parts of the draft.
> 
> Issue 1 is: When a so-called ICMP "hard error" is received for a
> connection in any of the synchronized states (ESTABLISHED and so on),
> treat the error message as a soft error (i.e., do NOT abort the
> corresponding connection).

WHY? Such an error could occur due to a reboot. It is legitimate operation.

> This improves TCP's robustness. In the event the error condition does
> not disappear in the near term, the connection will time out, anyway.

Now I'm confused. If a node were to have IPv4 and reboot with IPv6, you
want it to timeout. But your other draft wants to kill the TCP attempt
to connect *immediately* so you can retry.

So which is it? is restarting TCP connections important or not?

IMO, there is no reason to change TCP's behavior here, and it's
sufficient to leave it alone.

---

The whole tone of this doc is that there are attacks that need to be
dealt with; it ignores cases where such messages are sent legitimately.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Sep 2005 12:57:40 -0300

>WHY? Such an error could occur due to a reboot. It is legitimate operation.

In that case you should receive an RST, not an ICMP message.

>to connect *immediately* so you can retry.

In one case (soft errors draft), an ICMP error message is received during 
connection-establishment.
In this case, (ICMP attacks draft), I'm talking about ICMP error messages 
received during the life of a connection.

An ICMP error message is just a hint. As per D. Clark's paper, depending on 
the time you receive the message, the meaning may be different.

---

From: Ted Faber <[email-masked]>
Date: Fri, 23 Sep 2005 09:50:17 -0700

> In that case you should receive an RST, not an ICMP message.

Joe's not laying out his case completely.  Let me try to fill in the
blanks and he can tell me where I've misinterpreted what he's
suggesting.

Imagine a host that speaks IPv4 and TCP.  You connect to it.  The host
goes down and reboots (fairly quickly), but it's flag day, and the host
now no longer supports IPv4 at all, or no longer supports TCP at all.
You can work your imagination for other reasons that TCP might fail to
come up - a firewall (mis-?)configured to send the ICMP for application
protocols that have been outlawed, an embedded TCP stack with an
initialization/configuration error, TCP in an LKM with the wrong kernel
version...  There are a few whack-O cases out there that are unlikely
but well within the range of the possible.  None of those behaviors
(with the possible exception of the firewall) breaks a spec that I
can think of.

The point is that for whatever reason, all the host can do is send a
Protocol Not Supported ICMP, because the TCP stack will not be reached
(the postulate is that the host has stopped speaking either TCP or
IPv4).  Because the packet can't get to the TCP stack (which may not be
running at all), the host can't generate an RST.

Of course, if no ICMP is generated or gets through, the ESTABLISHED TCP
will eventually have a UTO and abort the connection.

Yes, this is a pretty bizarre case, but it is a valid hard error in an
ESTABLISHED state, and one where aborting the connection is the most
sensible thing to do.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Sep 2005 09:59:11 -0700

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

> In one case (soft errors draft), an ICMP error message is received
> during connection-establishment.
> In this case, (ICMP attacks draft), I'm talking about ICMP error
> messages received during the life of a connection.

But why should one be considered less hard, and one more hard? It's
basically reaction to the _inferred_ cause of such a message - in the
first case you assume it's benign and use it to fail-over, and in the
second you assume it's an attack and want to ignore it.

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.

> An ICMP error message is just a hint. As per D. Clark's paper, depending
> on the time you receive the message, the meaning may be different.

Agreed - but the meaning should always be considered benign before it is
considered an attack. If a benign cause _could_ have resulted in the
message, it seems inappropriate to react as if it's an attack.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Sep 2005 02:09:48 -0300

>ESTABLISHED state, and one where aborting the connection is the most

So we would keep connections vulnerable to reset attacks for that 1 in 
1000000th chance in which this scenario might take place?
(And, btw, in the event that happened, why would ignoring the ICMP message 
hurt you? For instance, the proposed policy does not prevent the 
application layer from being notified of the received ICMP error message! 
So this means you still let the application shoot itself, if it wants to! :-) )

Also, if there's consensus on the side of "not doing anything about this", 
then my next question/comment would be "Does it make sense to modify TCP's 
state transition diagram (as we currently are) to address TCP-based reset 
attacks, then? An attacker will use ICMP-based ones, because they are much 
easier to perform!"

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Sep 2005 01:54:24 -0300

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

>second you assume it's an attack and want to ignore it.

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.

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

BTW, I don't think this reflects "typical use at the time the ID is 
published", unless you are thinking of a time frame of at least fifteen years.

>message, it seems inappropriate to react as if it's an attack.

I disagree. First, a spurious message is not benign. Unless you would also 
call "benign" a spurious message that resets your connections every other 
second, for example.

Other than that, the current environment is *not* benign.

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.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Sep 2005 11:13:06 -0300

>now no longer supports IPv4 at all, or no longer supports TCP at all.
[....]
>running at all), the host can't generate an RST.

Imagine that your connection is operating over a long fat pipe (large 
bandwidth delay product), and assume you are implementing RFC1323 for PAWS.

The ICMP message may contain just the first 64 bits of the original IP 
datagram that elicited the error (i.e., no timestamps).

You might end-up aborting a connection in response to an error message 
caused by an old segment.

Just another scenario in which the same mechanism/feature protects you both 
from incidental (stale error message, in this case) and intentional (as in 
the ICMP-based reset attack).

So my take is that aborting the connection could probably be not the most 
sensible thing to do in this case, either.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Sep 2005 13:04:54 -0700

> caused by an old segment.

Yes, since you didn't know it was an old segment - which you would do
only if you heck the SEQNUM and not the PAWS. But this is a good reason
to parse the header properly - if there are TCP options which are not
included in the ICMP, it may not be appropriate to interpret parts of
the header that are affected by possible options - such as SEQNUM.

> Just another scenario in which the same mechanism/feature protects you
> both from incidental (stale error message, in this case) and intentional
> (as in the ICMP-based reset attack).

This is backwards; the mechanism doesn't protect you, notably because
yuo would abort the connection. Checking the SEQNUM in the absence of
the PAWS is just as bad as checking the SEQNUM in the absence of the
checksum.

> So my take is that aborting the connection could probably be not the
> most sensible thing to do in this case, either.

IF you're arguing that 'checks are useful for protection' - regardless
of the protection - then you have to do the checks. ALL the checks that
affect the semantics of what you're checking. Not just the ones that
protect from what you think are attacks, IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Sep 2005 13:26:49 -0700

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

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

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.

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.

> indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a

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

> I disagree. First, a spurious message is not benign. Unless you would
> also call "benign" a spurious message that resets your connections every
> other second, for example.
> 
> 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.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Sep 2005 04:35:33 -0300

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

>that everything you don't expect MUST be an attack, or at least MUST be

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.

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

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 05:36:08 -0700

Fernando Gont wrote:
> Exactly. But this means the so-called ICMP hard errors do not
> necessarily indicate "hard errors".

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

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

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

> I does not hurt. Remember: ICMP is unreliable. The ICMP error message
> may be corrupted, may be subject to rate limitation, etc.

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

> 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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Sep 2005 12:15:26 -0300

>assume the best, not the worst, of things you don't have other

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.

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

>either. So which ID do you want to withdraw, this or the TCP soft-errors

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.

>solely by security, which it does not provide.

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

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

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 08:46:15 -0700

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

> For instance, we are also

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.

> 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 doesn't assume everything is an attack, but
rather whether things we do introduce new vunerabilities - which isn't
an issue here.

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

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

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

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

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

> 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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Sep 2005 13:02:28 -0300

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

Yes, and that's not good.

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

>don't so far.

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

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 09:12:31 -0700

> At 12:46 p.m. 29/09/2005, Joe Touch wrote:
...
> No. That means you are making an argument for a protocol which is
> already unreliable.

Yes, I am. Or have you disabled all non-IPsec'd connections to your site?

...
> their technical rationale broken?

No technical rational for overriding spec or process was given in either
case. They appear to have just slipped through - i.e., an error.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 29 Sep 2005 17:20:19 +0100 (BST)

> Yes, I am. Or have you disabled all non-IPsec'd connections to your site?

How, exactly, does one go and equate unreliable with insecure?
Entirely different things.

> case. They appear to have just slipped through - i.e., an error.

I would argue that the formation of the ROHC workgroup was the error.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 29 Sep 2005 10:33:39 -0700

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

...but it's useful.
IP and UDP are unreliable too, but they're useful.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Sep 2005 15:01:41 -0300

>IP and UDP are unreliable too, but they're useful.

Of course. That's why I don't propose to "drop all ICMP", or simply drop 
the so-called "ICMP hard errors:.

Perform checks, and if you are to fail, fail for the sake of 
robustness/security.

---

From: Ted Faber <[email-masked]>
Date: Fri, 30 Sep 2005 10:40:12 -0700

> 1000000th chance in which this scenario might take place?

That's a decision for the community, of course.  But my opinion is that
you need to address the issue in the draft, not implicitly assume that
tradeoff is obvious.  Even if the community adopts it, it's wise to
indicate that we thought about it. 

> So this means you still let the application shoot itself, if it wants to! 

Hey, I generally believe that ignoring ICMP doesn't hurt you.  What's at
issue is whether responding to this ICMP can help you.  I believe that
the document asserts that once the connection is ESTABLISHED, this ICMP
is never a valid reason to terminate the connection.  Joe's described a
situation (that consists of many different possible causes) where
listening to that ICMP is perfectly reasonable.  An application's always
welcome to shoot itself from TCP's perspective.

> attacks, then? An attacker will use ICMP-based ones, because they are much 

If you've got questions about the motivations for and support of
tcpsecure, there's no need to be coy - no need to make such comments
conditionally.  :-) 

Right now, it sounds like the answer to your question is "yes, the WG
supports the tcp secure changes, independently of the changes proposed
here."

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Sep 2005 15:18:30 -0300

>indicate that we thought about it.

Good point. Will do.

>Hey, I generally believe that ignoring ICMP doesn't hurt you.

Yep, sorry.

>What's at
>is never a valid reason to terminate the connection.

You will always find something that does not fit. The point is that the 
benefits of treating hard errors as soft errors outweighs those of aborting 
the corresponding connection upon receipt of one of them.

>Joe's described a
>listening to that ICMP is perfectly reasonable.
>An application's always welcome to shoot itself from TCP's perspective.

I mean that even when you treat the hard error as soft error, you still 
notify it to the application. The application can, upon this notification, 
cause the connection to be aborted.

>supports the tcp secure changes, independently of the changes proposed

My argument is: Why would an attacker bother to guess a TCP sequence 
number, when it can reset a conenction much more trivially by means of ICMP?

"The strength of  a chain is that of the weakest link", I mean.

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Sep 2005 11:36:45 -0700

Fernando Gont wrote:
...
> notify it to the application. The application can, upon this
> notification, cause the connection to be aborted.

FWIW, the application can't do much with ICMPs it didn't expect to be
notified about. So this change requires not only a change to TCP, but a
change to every application that might be affected. That's worth noting
(if not reconsidering the implications of).

> "The strength of  a chain is that of the weakest link", I mean.

But TCP-antispoof explains that the chain is already sufficiently weak
in many cases even if you try to fix ICMP.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Sep 2005 16:01:31 -0300

>(if not reconsidering the implications of).

Strictly speaking, here should be a way to notify applications of the 
received ICMP messages (as per RFC1122). Yes, in practice this would mean 
that applications should be modified. What I mean is that, in the event you 
still want to abort a connection upon receipt of an ICMP message, you can 
do so at the application layer, when you are notified (if you have decided 
to) of the received ICMP messages.

>in many cases even if you try to fix ICMP.

It's weak. But we are making it weaker unnecessarily.

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Sep 2005 12:48:21 -0700

...
> It's weak. But we are making it weaker unnecessarily.

What's weaker than weak enough? (and why would we need to modify a core
Internet protocol if it's still weak enough)?

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 30 Sep 2005 21:25:17 +0100 (BST)

> Internet protocol if it's still weak enough)?

Using bad rhetoric and word games against someone with English as a
second language is bad form.

Strengthening ICMP and TCP where reasonable and possible seem entirely
sensible to me and in line with the mandate of this workgroup.

Joe - you don't have to kill -everything- you hadn't thought of first,
and some of us would respect you more if you didn't.

L.

---

From: Ted Faber <[email-masked]>
Date: Fri, 30 Sep 2005 15:46:12 -0700

> and some of us would respect you more if you didn't.

Let's try to stay civil, please.

---

From: Ted Faber <[email-masked]>
Date: Fri, 30 Sep 2005 16:08:01 -0700

> cause the connection to be aborted.

That's actually a pretty reasonable course of action, IMHO.  Again, I
think that the clearer you can be about this in the doc, the better.
1122 says that all ICMPs must trigger an asynchronous notification to
the application and your argument that the application can reasonably
distinguish between ICMP messages is a pretty good one.  One could even
imagine arguing for a "compatibility mode" response set that existing
applications can use by default to react as previously.  ("Compatibility
mode" is clearly very speculative, and I wouldn't expect to see it.)

I didn't really see this set out clearly in your document, but that may
be reader error.

> "The strength of  a chain is that of the weakest link", I mean.

I understand what you're saying.  Again without my chair hat on:

I'm not sure that either off-path spoofed RSTs or off-path spoofed ICMP
messages are really attractive DoS vectors, and on-path spoofers can
generate packets that will defeat either tcpsecure or these ICMP checks.

One of the attractions of tcpsecure - for me with my chair hat off - is
the relative simplicity of the mechanism:  ACK suspect RSTs with the
strong assurance that a real RST will be validated.

The ICMP error draft has more complicated checks - one muct potentially
parse much of a TCP header and its options - and the attack is somewhat
less promising - ICMP messages are commonly filtered and unreliable. 

That said, I do see some merit in addressing the ICMP weakness.  The
sanity checks are somewhat perilous to get right, but it's reasonable to
say that any attack packet you intercept is one connection saved and any
valid error message you discard could have been lost anyway.  While it's
still good to get these right, I think that equation makes the cost of
getting a check wrong less apocalyptic than some may think.

I think you've made me at least a lukewarm believer here.

I'm going to try to be quiet for a while and see what others think.

(That's my idea of a subtle hint that others' opinions would be very
welcome.)

---

From: Ted Faber <[email-masked]>
Date: Fri, 30 Sep 2005 17:03:00 -0700

> Let's try to stay civil, please.

Let me be clear here, since it may sound like I'm singling Lloyd out
unfairly or that I'm endorsing Joe's line of argumentation.  I'm doing
neither.

I'm (perhaps vainly) hoping to prevent a flame up.

This discussion, while heated technically, has remained personally
civil.  I understand that both participants and readers may be getting a
little frustrated at this point.  But, I think that the above comment
isn't technically helpful.

I'm not trying to squelch good discussion.  Despite the heat in some of
this thread, I think I've come away with a better understanding of
Fernando's thinking here, though I've mostly been paying attention to
his replies to me.

In any case this is all coming from only my jet-lagged brain.  Mark will
tell me if he disagrees.

Thanks.