Subject: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt

From: Ted Faber <[email-masked]>
Date: Thu, 22 Sep 2005 09:23:44 -0700

I'd sent this to Fernando off-list, but he was willing to have to
forwarded to tcpm to spur discussion of this draft.

Fernando, I've made some minor edits to this - primarily correcting my
tendency to type "teh" instead to "the."  I also added a paragraph near
the end adding to my argument that the behavior you're advocating might
not even violate 1122.  Everyone else, here are my *non-co-chair*
thoughts on this draft, though my estimate of consensus in the following
paragraph (and only in that paragraph) is made with co-chair hat on.

As far as consensus, I didn't see any strong consensus after the last
time Pekka presented the ideas in Minneapolis and I haven't seen any
change.  I do think there's an understanding in the group that there may
be ICMP issues, but I really don't see support to do something about it,
either in terms of your draft or another approach.  I do see some
support, but I don't see consensus that we should take this on yet.  I
think you need to make your case more persuasively.

Below here is just my feedback on your document - this is not WG chair
feedback.  If you think it would help to stir up discussion, I'm happy
to re-post these comments to the list.  Let me know.

The criticisms get more substantial as I go down.

When you mention an RFC, say the number of the RFC.  Something like "In
[7] the authors update [10]" is needlessly opaque.  The RFC editor
prefers symbolic references anyway, so "In [RFC10101] the authors update
[RFC10100]" is *much* clearer to the reader and much easier for the RFC
editor to deal with.  If you're using xml2rfc, this is an easy change,
if you're not consider making it anyway.

You're still calling these checks "security checks" rather than "sanity
checks" or "correctness checks."  Security is a loaded term to some
people and I think these checks are weak enough that some people will
object to the term.

In section 3, you don't mention that an ICMP error message, even a v4
ICMP, MAY contain as many bytes of the packet as the ICMP initiator
cares to include in the packet, subject to MTU constraints.  This means
that there may be enough information to erform more sophisticated checks
like MD5 or IPsec.  Furthermore, you seem to rule out the possibility of
a partial packet IPSec decryption/authentication; I'm not sure that's
accurate.  If partial decryption is possible, it seems that matching the
SPI for a valid IPSec decryption, and then having a partial decryption
of the IPSec packet match the port pair for an active IPSec/TCP connection
is already a much steeper hurdle than the sequence number check you
propose.  Make sure you're accurately representing the IPSec alternative
here.

In section 4, you leave out the most obvious choice.  Firewall all ICMP
messages (other than maybe ping).  ICMP is unreliable; protocols have to
work if they never get an ICMP message, so this seems like it must work.
Now, you may not want to encourage people to do that, but it's an
obvious choice, and I think you should make a case that seqno filtering
is better.

And importantly, you *never* point out that ICMP is unreliable.  In
fact, the only ICMP message that a router is required to generate (from
a quick look at 1122) is ECHO.  This is a really strong point in your
favor.  Even if you get the checks wrong; even if you discard ICMPs that
you shouldn't; even if you discard *all* the ICMP messages, TCP will not
fail.  The only possible interaction with dropping extra ICMP messages
is with PMTU, and that's something that does need to be addressed.  But
even PMTU should work in the face of extended bad luck (lots of dropped
ICMP messages).

Finally, there's no MUST in 1122 that says that TCP MUST abort
connections on which it receives hard errors.  1122 says TCP SHOULD
abort such connections.  Again, IMHO, failing a reasonable sanity check
could easily provide a reason to not follow the message.  But you need
to make that argument.

You can build a good argument from these principle that your proposed
checks are safe and reasonable - maybe even that implementing them
breaks no existing standard.  But since you never address the idea
that TCP already deals with unreliable ICMP messages, you leave yourself
open to every little nit pick about how individual checks work.

Consider using that to bolster your case.

-- 
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: Thu, 22 Sep 2005 10:46:28 -0700

To add my own perspective on the doc:

Previously, I was opposed to having TCP check any of the contents of an
ICMP message.

I have considered this in detail, and have come to the conclusion that
it is probably not only appropriate but necessary to have TCP check the
contents, e.g., the SEQNUM.

HOWEVER, I remain opposed to the application of consistency and/or
staleness checks (e.g., validation of port, validation of SEQNUM,
respectively) as being referred to as "security".

I would be in favor of a draft that focuses on the utility of using
these checks for consistency and staleness (old packets); this would
require substantial changes throughout the current doc, including to the
title (though the ID name could remain as-is, e.g., for continuity).

It would be useful to consider how these checks would defeat some
attacks, _as an aside_ or in an appendix (and its utility depends on the
size of the window as well), but not as the focus of the document, IMO.

That said, there are a number of additional caveats that need to be put
in place to make the checks appropriate, that were not considered, and
are basically a detailed version of Ted's observation that there could
be errors along the way, e.g., as noted below for TCP checksum
validation. I.e., if you're going to validate the TCP header, start with
the checksum, as TCP requires.

I also agree with many of the other points Ted raised as an individual.

Joe

ADDITIONAL CHECKSUM ISSUES:

	- if the ICMP comes from the TCP endpoint (TCP dest matches
	ICMP source), then the TCP segment MAY?? (see below) be checked
	for consistency and staleness, including but
	not limited to the SEQNUM

	the ICMP checksum protects the payload on its return

	HOWEVER - this is what concerns me - it's NOT always clear
	whether the endpoint has validated the TCP checksum on
	receipt before this ICMP message is sent

	for errors for which the TCP checksum must have been validated
	at the receiver, then the above should be MAY

	for errors for which the TCP checksum may not have been
	or definitely was not validated, the above should, IMO,
	be MUST NOT

	e.g.:
	1)) If the ICMP error indicates host or protocol not found,
	then the TCP checksum is NOT validated on receipt, so a partial
	segment ***MUST NOT*** be validated/checked

	2)) if the ICMP error indicates port not found, then
	the TCP checksum ought to be validated before the port
	number is interpreted by the endpoint, so it was validated
	on receipt, and TCP ***MAY***

		- if the TCP packet includes the MD5 option, however,
		the signature MUST be verified before checking the
		segments contents. If the entire segment is not
		included - i.e., where the signature cannot be
		validated - then the TCP segment MUST NOT be validated,
		because the intended security may have been violated
		(IMO - this is a close call, though)

	- if the ICMP comes from an intermediate endpoint, where
	TCP dest != ICMP src, then the TCP segment MAY be checked
	for consistency and staleness as above, ONLY IF the entire
	segment is included and the TCP checksum is valid

		- if only a partial segment is included, TCP MUST NOT
		interpret the contents, since they could have been
		corrupated on the way to that endpoint (e.g., router)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Sep 2005 01:45:37 -0300

>if you're not consider making it anyway.

Yes, will do.

>people and I think these checks are weak enough that some people will

Yes, there's still one instance of that. Will change it in the next 
revision of the draft.

>like MD5 or IPsec.

I do mention this. However, the point is that including more bytes is not a 
requirement  (i.e., it's a MAY), and therefore an attacker will not include 
more bytes in the packet just to be catched.

>obvious choice, and I think you should make a case that seqno filtering

Will include this in the next revision.

>fail.

I did include this in the section about hard errors -> soft errors. But I 
agree there should be more stress on it.

>Consider using that to bolster your case.

Yes, I should put more stress on this.

Thanks for your feedback!

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Sep 2005 11:24:47 +0300 (EEST)

I agree with most comments you're making, but I have to react to this 
one..

> work if they never get an ICMP message, so this seems like it must work.

Isn't there sufficient evidence that "filter all ICMP" breaks most 
(all?) transport protocols in obvious and/or subtle ways?  (Just 
consider but there are probably other examples.) So, I fail to see how 
one could argue that "protocols have to work" -- but maybe this 
depends on the context and the definition of "work" (i.e., which kinds 
of functionality or performance degradations would be acceptable).

If we were to want to *really* get away from the point that ICMP is 
required for the protocol to operate to satisfy the users' 
expectations, there seems to be a LOT to do.

Hence, I think there is a strong practical argument that ICMP messages 
just can't be completely ignored -- and we've seen many stack 
developers react to that (by implementing verification mechanisms).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

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

>title (though the ID name could remain as-is, e.g., for continuity).

The TCP SEQ check does check for staleness, I agree.

>size of the window as well), but not as the focus of the document, IMO.

There are other checks/proposals in addition to the TCP SEQ check.

While validating ICMP messages is needed to keep TCP robust to "spurious" 
ICMP messages, the draft focuses on the use of ICMP to attack TCP.

>         receipt before this ICMP message is sent

That depends on the message type. For example, in the case of a "protocol 
unreachable", there's no TCP on the end-system, so there's nobody that 
"speaks TCP" and can check it on the destination host. The general answer 
to this question would be "No". And is another good point for being more 
cautious about honoring ICMP messages.

>         or definitely was not validated, the above should, IMO,

MUST NOT and *still* honor them???

>         segment ***MUST NOT*** be validated/checked

I think this is another point that shows why one should be cautious when 
processing ICMP messages.

Let's suppose the IMCP message was elicited by a corrupted TCP segment.

If it's a hard error, it must match an existing connection. It will then 
have to have a valid TCP SEQ. And even then, the message will be used only 
in case the connection times out.

For Source Quenches, you simply ignore the message.

As for "frag needed and DF bit set", the message must match an existing 
connection, the message must have a valid TCP SEQ, and a segment must 
timeout before the message is honored. (And, BTW, you need to process the 
ICMP payload even if you assume the TCP checksum has not been verified by 
the system that sent the ICMP error.... if not, how do you perform PMTUD?)

>                 (IMO - this is a close call, though)

?

>                 corrupated on the way to that endpoint (e.g., router)

What do you mean by "TCP MUST NOT interpret the contents"?

Kindest regards,

---

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

At 05:24 a.m. 23/09/2005, Pekka Savola wrote:

>Isn't there sufficient evidence that "filter all ICMP" breaks most (all?) 
>transport protocols in obvious and/or subtle ways?  (Just consider but 
>there are probably other examples.) So, I fail to see how one could argue 
>that "protocols have to work" -- but maybe this depends on the context and 
>the definition of "work" (i.e., which kinds of functionality or 
>performance degradations would be acceptable).
>
>required for the protocol to operate to satisfy the users' expectations, 
>there seems to be a LOT to do.
>
>just can't be completely ignored -- and we've seen many stack developers 
>react to that (by implementing verification mechanisms).

I think my draft is a good engineering solution for dealing with ICMP.

Filtering all ICMP breaks, for example, PMTUD.

ICMP can be useful both for solving problems (TCP soft errors thing) and 
for providing more specific information when you have problems.
That's basically what my draft tries to achieve: Mitigating the security 
implications of ICMP, while still using it when useful.

---

From: Ted Faber <[email-masked]>
Date: Fri, 23 Sep 2005 07:48:14 -0700

> more bytes in the packet just to be catched.

That's a valid point, in that an attacker will probably provide the bare
minimum data.    In fact, only getting the minimum data may be a hint
that this ICMP isn't so trustworthy.

Still, sanity checks covers the ground where there is no attacker just
corruption or misconfiguration.  In those cases, you can expect and use
more data.

---

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

Fernando Gont wrote:
> While validating ICMP messages is needed to keep TCP robust to
> "spurious" ICMP messages, the draft focuses on the use of ICMP to attack
> TCP.

TCP robustness is important; ICMP validity checks can help, but they are
NOT security checks unless there are security mechanisms at play (e.g.,
signatures).

> That depends on the message type. For example, in the case of a
> "protocol unreachable", there's no TCP on the end-system, so there's
> nobody that "speaks TCP" and can check it on the destination host. The
> general answer to this question would be "No". And is another good point
> for being more cautious about honoring ICMP messages.

So you don't seem to care about getting an ICMP message back with what
could have been a corrupted TCP partial segment back, but you DO care
about whether the SEQNUM is valid?

Yes - I would drop some ICMPs that are currently used. But my reasons
are based on existing TCP header semantics - not
incorrectly/inappropriately inferring security properties from them.

> MUST NOT and *still* honor them???

No - they MUST NOT honor them. I would silently drop these, for the
reason above.

> processing ICMP messages.

But I'm being MORE cautious than you in these cases, and this doc is
supposed to be about "security"?

> have to have a valid TCP SEQ. And even then, the message will be used
> only in case the connection times out.

Yes. And that rule should still apply - IF the segment is received in a
validated fashion. For hard errors received from the endpoint, the
connection would reset quickly. For hard errors NOT received from the
endpoint but received in total, this would reset after the timeout. For
hard errors NOT received from the endpoint and received in part, this
would never reset.

But that's OK - TCP never intends to cleanup state on old connections to
save space, but rather when it interferes with what would be a new
connection.

> For Source Quenches, you simply ignore the message.

Agreed, but that's just documenting long-recommended practice. I had
thought that was noted already in an RFC.

> timeout before the message is honored. (And, BTW, you need to process
> the ICMP payload even if you assume the TCP checksum has not been
> verified by the system that sent the ICMP error.... if not, how do you
> perform PMTUD?)

That's an interesting question - it might be the case that you don't, or
it might be the case that you decided that since MTU adjustments are
very soft (don't kill a connection) you are willing to relax the need to
check the checksum in that case.

Again, foremost in the discussion is the issue that non-malicious
corruption is all you can check - including bit errors, stale packets,
etc. You cannot check _security_ unless things are signed. Nothing here
should be confused for a security check.

>>                 (IMO - this is a close call, though)

Thinking further, it's not so close. It MUST be checked just like the
checksum if it exists.

> What do you mean by "TCP MUST NOT interpret the contents"?

More specifically "the contents of the segment are meaningless" if the
checksum fails, so interpreting the contents "as a TCP segment" is
inappropriate in those cases.

Joe

---

From: Ted Faber <[email-masked]>
Date: Fri, 23 Sep 2005 07:52:10 -0700

?

ICMP's unreliably delivered, and optional (though strongly encouraged)
to generate.  If protocols rely on it, they're in some amount of
trouble.  I understand that some protocol may rely on it, but it's IMHO
misdesgigned.  I can't think of any way (outside maybe PMTU, which I
don't know much about) that TCP might be broken here.

Give me an example of breakage.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Sep 2005 13:19:50 -0300

>NOT security checks unless there are security mechanisms at play (e.g.,

I've already stated that I will change the only remaining instance of 
"security check" to "validation check", "sanity check", or whatever.

>about whether the SEQNUM is valid?

The specs do not require you to get a full TCP segment (in the ICMP 
payload), but want you to process them.

In most cases, you won't receive a full TCP segment (let's assume the 
segment was PMTU-sized, so the intermmediate router must now waste at least 
20+8 bytes in IP+ICMP headers).

If you don't want to process ICMP messages that do not contain full TCP 
segments, you are sort of asking to disable ICMP.

I'm saying, let's make some checks. Those checks will catch many (if any) 
corroputed messages. But let's also be conservative in what we do with the 
messages. For example, do not abort conections. Let's just record the 
message. If it times out, that recorded message will certainly provide 
someting better than a "timeout" error.

The same kind of rationale applies for "frag needed and DF bit set"....

>No - they MUST NOT honor them. I would silently drop these, for the

Your proposed behavior violates RFC1122.  The Host Requirements  states 
that a TCP MUST act on an ICMP error message passed up from the IP layer, 
directing it to the connection that elicited the error.

>thought that was noted already in an RFC.

No, it is not. TCP is still required to act on ICMP Source Quenches.

>inappropriate in those cases.

RFC1122 is already asking you to do this.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Sep 2005 10:10:27 -0700

> At 11:50 a.m. 23/09/2005, Joe Touch wrote:
...
> payload), but want you to process them.

*IF* you do validity checks, then the first part of validity to check is
the checksum. Jumping over that to check what you _want_ to check seems
inappropriate.

> segment was PMTU-sized, so the intermmediate router must now waste at
> least 20+8 bytes in IP+ICMP headers).

Agreed.

> segments, you are sort of asking to disable ICMP.

No - I'm suggesting that if you don't check the checksums, you have no
business deciding that other fields are "correct" or not. You can decide
to take the packet as a signal on faith - which is what is currently done.

But the instant you start 'checking' the packet, you have an obligation
to check what it _means_, not just what is convenient.

> I'm saying, let's make some checks. Those checks will catch many (if
> any) corroputed messages. But let's also be conservative in what we do
> with the messages. For example, do not abort conections. Let's just
> record the message. If it times out, that recorded message will
> certainly provide someting better than a "timeout" error.

If this is true, then why do you want to be aggresive in processing TCP
soft errors? Doesn't the same logic apply?

And why are erroneous messages more informative than a 'timeout' if it's
the timeout that ends up ultimately killing the connection?

> The same kind of rationale applies for "frag needed and DF bit set"....

What do I learn if I get these and they're erroneous?

> that a TCP MUST act on an ICMP error message passed up from the IP
> layer, directing it to the connection that elicited the error.

Doesn't that go for your check as well? I.e., either TCP must honor
them, or the process of honoring them involves validity checks and those
failing such checks must be silently dropped. That goes for checksum
checks, SEQNUM checks, etc.

> No, it is not. TCP is still required to act on ICMP Source Quenches.

It's not in an RFC - I checked my notes - but it was agreed upon a while
ago. It's long-recommended practice that just hasn't been documented in
an RFC yet.

> RFC1122 is already asking you to do this.

See above; you can't "eat your cake and have it too". Either TCP MUST
act on all ICMPs received, or it's OK to do validity checks that involve
parsing the header. If the latter, then TCP semantics demand that the
checksum be checked first - see RFC793.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Sep 2005 15:16:21 -0300

>the checksum. Jumping over that to check what you _want_ to check seems

Agreed. I just want to "jump over" if I simply cannot check the checksum 
(i.e., if there's no full TCP segment).

>soft errors? Doesn't the same logic apply?

Not necessarily. In the soft errors draft case, there's no previous 
knowledge of the TCP connection working OK. So my take is "take the error 
as a hint, and try the next possible IP address". As I have noted since 
this issue was first raised here, this is probably not the ideal solution 
(the ideal solution is, IMHO, applications using a Higher-Level API), but 
is an engineering approach to the problem.

D. Clark's paper contains a similar rationale.

>the timeout that ends up ultimately killing the connection?

You don't know for sure they are erroneous. And that's all the current 
specifications are providing.

>What do I learn if I get these and they're erroneous?

In the worst case (the IP addresses and port numbers were corrupted, along 
with the TCP SEQ), you reduce the MTU for the connection. Sometime later 
you will increase it again.

Anyway, the mechanism proposed in my draft won't likely suffer this during 
the life of a connection, and you still wait for at least one RTO before 
honoring the error message.

>checks, SEQNUM checks, etc.

You don't direct the messages to the corresponding conenction. I do do it.

>ago. It's long-recommended practice that just hasn't been documented in

Good we have come to an agreement. :-)

>checksum be checked first - see RFC793.

I agree that if you can check the checksum, you must do it. I'm just 
considering the case in which you can't

---

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

...
> considering the case in which you can't

IMO, if you can't interpret the checksum, you should not check the
SEQNUM - unless ICMPsrc=TCPdst, in which case you expect that the other
end already did the check.

There are cases where it's not feasible to check the checksum (PMTU,
among others), in which case I don't think it's appropriate to check the
SEQNUM either, though.

I.e., both or neither.

Joe

---

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

As a more high level comment regarding some of our points of agreement:

I do agree that a document addressing when and whether to check the
SEQNUM would be useful, as well as noting some of the other checks -
e.g., to drop source quench.

I don't agree that we can get there with incremental modification of the
current document, however.

The focus needs to be on why the checks are appropriate - even if there
are notes as to how this can incidentally help protect against some
types of attacks (e.g., in the security considerations section, or a
separate section).

Joe

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Sep 2005 09:34:11 +0300 (EEST)

> Give me an example of breakage.

PMTUD alone should be sufficient example :).  Note that in the case of 
PMTUD (and many other ICMP errors in general), if the ICMP error gets 
lost, the sending host will try to send again -- which will trigger 
another ICMP error, and another, and another..

While single ICMP errors are unreliable, in practice it seems they 
will be resent as many times as necessary (or until the original 
TCP/UDP/... sender gives up in any case).

(Sending ICMP errors is usually subject to some rate-limiting, but 
some are bound to be sent again sooner or later.)

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Sep 2005 08:10:10 -0700

> another ICMP error, and another, and another..

Until it times out. Which is what already happens for blackholes and
more than a few firewalls anyway, so this isn't a new situation.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Sep 2005 22:16:21 +0300 (EEST)

> more than a few firewalls anyway, so this isn't a new situation.

Sure.. but it's an unrecoverable condition: no matter how many 
times the application would try to retry the TCP transmission, it's 
going to fail the identically same manner.  I'd call that 'broken 
TCP'.

But that aside, the main point was not that this happens but whether 
the document could just recommend filtering out all ICMPs.  IMHO, TCP 
breaks too badly for us to recommend that.

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Sep 2005 12:48:07 -0700

Pekka Savola wrote:
> Sure.. but it's an unrecoverable condition: no matter how many times the
> application would try to retry the TCP transmission, it's going to fail
> the identically same manner.  I'd call that 'broken TCP'.
> 
> But that aside, the main point was not that this happens but whether the
> document could just recommend filtering out all ICMPs.  IMHO, TCP breaks
> too badly for us to recommend that.

In general, I agree - but there seems to be a spirit these days of
saying "but people do it". If that spirit exists elsewhere in the doc,
it's warranted here.

Joe

---

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

On Tue, Sep 27, 2005 at 09:34:11AM +0300, Pekka Savola wrote:
> PMTUD alone should be sufficient example :).

Well, I don't know that it breaks, I just don't know enough about that
spec and I'm being conservative based on Matt Mathis's statements.  I'll
rectify this anon.

> another ICMP error, and another, and another..

Yeah if the ICMP generator decides that's an appropriate implementation
of the 1122 SHOULD for ICMP messages.

But I need to read the PMTU stuff before I can have this discussion
rationally.

> some are bound to be sent again sooner or later.)

Optimist. :-) :-) :-)