Subject: [tcpm] Next revision of the ICMP attacks draft

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 02:23:19 -0300

Folks,

I will be submitting a revision of the ICMP attacks draft next week.

These are the changes I have in mind:

* Update on the citation of the IPSec spec.

* Address all feedback sent by Fred Templin

* Add a paragraph on what the current state of affairs is, as suggested by Ted.

* Add some words on the effectiveness of ingress/egress filtering 
based on the ICMP payload, as suggested by Bora Akyol

* In the same section, replace the term "firewall" by "middle-boxes", 
as suggested by Pyda.

* Will hopefully include references to firewall implementations that 
already perform this filtering.

If there's any feedback I just missed, let me know.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2006 08:42:43 -0700

> * Add a paragraph on what the current state of affairs is, as suggested 

The doc has two different components; one involves deeper inspection of 
the ICMP message, the other describes changes to how TCP handles hard 
errors based on its state.

The latter should describe "what is implemented", and the extent to 
which it corresponds to existing spec. The doc should fall short of 
making recommendations that are intended to be interpreted as a change 
to spec, though.

In particular:

"or security reasons,
       it would be fair to treat ICMP port unreachable messages as soft
       errors (or completely ignore them) when they are meant for
       protocols that have their own mechanism for reporting this error
       condition."

directly opposes RFC1122, which states specifically that (sec 3.2.2.1):

	"A transport protocol
             that has its own mechanism for notifying the sender that a
             port is unreachable (e.g., TCP, which sends RST segments)
             MUST nevertheless accept an ICMP Port Unreachable for the
             same purpose."

IMO, the document needs a clear summary of where it diverges from 
RFC1122/792/etc. recommendations, and the conditions under which it 
would be appropriate to diverge (e.g., a threshold after which hard 
errors should be treated as soft, a switch for enabling that, etc.).

The document also suggests that unexpected responses should be treated 
as attacks:

	"However, it would be strange to
       get such an error during the life of a connection, ...
	...Thus, it would be fair to treat ICMP
       protocol unreachable error messages as soft errors (or completely
       ignore them"

Again, if there were a switch that were enabled by seeing a large number 
of such ICMPs, or a number of ICMPs which have invalid contents, then 
this would be a reasonable reaction. In the absence of such, this is 
overly hostile to potentially valid network feedback.

(I hope this is a way to move forward).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2006 09:50:08 -0700

...
>             MUST nevertheless accept an ICMP Port Unreachable for the

There is some ambiguity here; the paragraph RFC1122 states in total

3.2.2.1:

             A Destination Unreachable message that is received MUST be
             reported to the transport layer.  The transport layer SHOULD
             use the information appropriately; for example, see Sections
             4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
             that has its own mechanism for notifying the sender that a
             port is unreachable (e.g., TCP, which sends RST segments)
             MUST nevertheless accept an ICMP Port Unreachable for the
             same purpose.

	(FYI - port unreachable is type 3, code 3)

---

4.1.3.3 discusses UDP

4.2.3.9 states that:

             o    Destination Unreachable -- codes 2-4

                  These are hard error conditions, so TCP SHOULD abort
                  the connection.

4.2.4 is about passing ICMP messages to the application.

------

4.2.3.9 and 3.2.2.1 are somewhat contradictory. My interpretation of 
3.2.2.1 is that:

	TCP MUST accept ICMP 3/3 for the same purpose as a TCP RST

My interpretation of 4.2.3.9 is that, in being more general, it 
recommends a SHOULD for other ICMP error receipts, but that receiving a 
port unreachable is a hard error with a MUST.

I plan on talking with Bob Braden today to find out what the motivation 
behind this particular text is; right now, I have a guess that it may 
have something to do with firewalls, which ought not spoof RSTs to 
indicate port unreachable, but rather should send ICMPs for the same 
purpose. I'll send a follow-up when I find out more.

-------

Regardless, this document ought to be more specific about these sorts of 
interpretations, as well as the specific places in 1122/792/etc where 
such issues are divergent.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 16:23:27 -0300

At 13:50 23/05/2006, Joe Touch wrote:

[Great work citing RFC1122, btw]

>recommends a SHOULD for other ICMP error receipts, but that 
>receiving a port unreachable is a hard error with a MUST.
>
>I plan on talking with Bob Braden today to find out what the 
>motivation behind this particular text is; right now, I have a guess 
>that it may have something to do with firewalls, which ought not 
>spoof RSTs to indicate port unreachable, but rather should send 
>ICMPs for the same purpose. I'll send a follow-up when I find out more.

I recall at some point asking somebody (probably not Braden) on this 
issue. The answer I had got was that years and years ago there was 
some stack that rejected connections (say to a port on which there 
was no process listening) with a port unreachable rather than RST (as 
it should have). RFC1122 then tried to accommodate that/those stack/s.

As I mentioned in some other e-mail, there's other stuff in RFC1122 
which makes it clear that that RFC 1122 contains some text to 
accommodate what some (non-conformant, but yet popular) stacks were doing.

>Regardless, this document ought to be more specific about these 
>sorts of interpretations, as well as the specific places in 
>1122/792/etc where such issues are divergent.

I'd say that the only place in which the existing specs are violated 
is in the case of port unreachables.

Now,

The RFC attacks draft talk about treating the hard errors as soft 
errors for connections in the synchronized states. In the general 
case, the firewall will block a connection-establishment attempt, 
rather than accepting a connection and "resetting" it at some point 
later (yes, that *may* happen, though). But in the case of a 
connection request being rejected, the host that perform the active 
open will honor the ICMP unreachable, as the connection is in a 
non-synchronized state.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 16:31:13 -0300

At 12:42 23/05/2006, Joe Touch wrote:

>The doc has two different components; one involves deeper inspection 
>of the ICMP message, the other describes changes to how TCP handles 
>hard errors based on its state.
>
>making recommendations that are intended to be interpreted as a 
>change to spec, though.

Well, being that the document is meant for BCP/informational, the 
document explains what is supposed to be best currently. The document 
is not standards track, and has no words in caps.

>errors should be treated as soft, a switch for enabling that, etc.).

Joe, I understand your point, but this would be something different 
from what we got consensus on.

>The document also suggests that unexpected responses should be 
>treated as attacks:
>

What I meant by this text is that is not common to receive those 
messages during synchronized states. They are the exception, rather 
than the rule.

>Again, if there were a switch that were enabled by seeing a large 
>number of such ICMPs, or a number of ICMPs which have invalid 
>contents, then this would be a reasonable reaction. In the absence 
>of such, this is overly hostile to potentially valid network feedback.

You need just a single packet to tear down a connection. Reacting 
after that, i.e., turning hard errors -> soft errors, wouldn't make 
much sense: the attack has already succeeded.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2006 13:13:07 -0700

Fernando Gont wrote:
>> recommends a SHOULD for other ICMP error receipts, but that receiving 
>> a port unreachable is a hard error with a MUST.
>>
>> that it may have something to do with firewalls, which ought not spoof 
>> RSTs to indicate port unreachable, but rather should send ICMPs for 
>> the same purpose. I'll send a follow-up when I find out more.
> 
> issue. The answer I had got was that years and years ago there was some 
> stack that rejected connections (say to a port on which there was no 
> process listening) with a port unreachable rather than RST (as it should 
> have). RFC1122 then tried to accommodate that/those stack/s.

I asked Bob. He hinted it had more to do with a non-TCP answer to TCP's 
not being there on a port was appropriate for layering reasons, and 
should have the same effect as RST.

> accommodate what some (non-conformant, but yet popular) stacks were doing.

Agreed. That's what "SHOULDs" would be there for, though - not MUSTs.

>> Regardless, this document ought to be more specific about these sorts 
>> of interpretations, as well as the specific places in 1122/792/etc 
>> where such issues are divergent.
> 
> I'd say that the only place in which the existing specs are violated is 
> in the case of port unreachables.

That depends on what "SHOULD" means. When I asked Bob, he said it means 
"REALLY SHOULD". It's short of MUST in terms of conformance, but not intent.

> Now,
> 
> The RFC attacks draft talk about treating the hard errors as soft errors 
> for connections in the synchronized states. In the general case, the 
> firewall will block a connection-establishment attempt, rather than 
> accepting a connection and "resetting" it at some point later (yes, that 
> *may* happen, though). But in the case of a connection request being 
> rejected, the host that perform the active open will honor the ICMP 
> unreachable, as the connection is in a non-synchronized state.

When you deploy a firewall or change its rules while it is deployed, 
these sorts of errors are legitimate and appropriate.

Not everything you don't expect is an attack.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2006 13:19:08 -0700

Fernando Gont wrote:
> document explains what is supposed to be best currently. The document is 
> not standards track, and has no words in caps.

There's a big difference between BCP and informational. BCP is intended 
as advice to designers on what they should do, not just what has been 
done. If this doc is just about 'what is', it ought to be informational.

> Joe, I understand your point, but this would be something different from 
> what we got consensus on.

I didn't see consensus to have an obfuscated doc ;-)

First, it'd be appropriate to describe what IS in terms of current 
implementations as well as noting clearly where it diverges from spec.

It is also appropriate to consider that one alternative to "everything I 
don't expect is an attack" is "when I see other clues that I'm under 
attack, then change behavior". This latter part goes to the extent to 
which this doc makes recommendations to new implementers. If that's not 
part of this doc, then it isn't needed. But if it is, the design 
tradeoff of assuming everything is an attack - and an alternative that 
doesn't do that - should, IMO, be noted.

> messages during synchronized states. They are the exception, rather than 
> the rule.

Exception != attack, though.

>> contents, then this would be a reasonable reaction. In the absence of 
>> such, this is overly hostile to potentially valid network feedback.
> 
> You need just a single packet to tear down a connection. Reacting after 
> that, i.e., turning hard errors -> soft errors, wouldn't make much 
> sense: the attack has already succeeded.

If you got a bunch of invalid ICMPs, you would not have let them tear 
anything down, but at that point you might want to change hard errors to 
soft during connections.

If you get a bunch of attacks during connections, changing hard to soft 
makes it easier to keep new connections up, and is also a reasonable 
response to attack, even if some of the effects of that attack have 
already succeeded.

The goal - IMO - isn't protection from every packet that might have been 
an attack, but a reasonable response to attacks that recovers. Innocent 
until proven guilty, so to speak.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 19:59:37 -0300

At 17:19 23/05/2006, Joe Touch wrote:

>>>The doc has two different components; one involves deeper 
>>>inspection of the ICMP message, the other describes changes to how 
>>>TCP handles hard errors based on its state.
>>>
>>>The latter should describe "what is implemented", and the extent 
>>>to which it corresponds to existing spec. The doc should fall 
>>>short of making recommendations that are intended to be 
>>>interpreted as a change to spec, though.
>>document explains what is supposed to be best currently. The 
>>document is not standards track, and has no words in caps.
>
>There's a big difference between BCP and informational. BCP is 
>intended as advice to designers on what they should do, not just 
>what has been done. If this doc is just about 'what is', it ought to 
>be informational.

This document is about what is the best current practice to deal with 
ICMP-based attacks.

>I didn't see consensus to have an obfuscated doc ;-)

Joe, let me make my point clear.

If you make a comment that is meant to improve the draft the WG has 
agreed to work on, I will try to address it.
No there's something you don't like about the draft, or you don't 
like the draft at all, I will probably not be able to address it at all.

In the last couple of days you re-raised the discussion on soft/hard 
errors, almost hinted to introduce a switch (which would probably 
lead to a discussion on "what it should default to", and now we are 
"making science" around which the WG already had consensus on.

>If you get a bunch of attacks during connections, changing hard to 
>soft makes it easier to keep new connections up, and is also a 
>reasonable response to attack, even if some of the effects of that 
>attack have already succeeded.
>
>The goal - IMO - isn't protection from every packet that might have 
>been an attack, but a reasonable response to attacks that recovers. 
>Innocent until proven guilty, so to speak.

Yeah, use telnet, until you realize somebody is sniffing your 
connections. Then switch to ssh.

That saves you from all the performance drawbacks of ssh, but keeps 
secure new connections that recover.

(There is a long list of analogies that could be made... many of them 
even more funny, but...)

The point is that I don't agree with that point of view at all.

"It is best to assume that the network is filled with malevolent 
entities that will send packets
designed to have the worst possible effect. This assumption will lead 
to suitably protective design."

We won't be taken seriously if we ask implementors to implement a 
rather complex machinery that, until they get hacked once or a few 
times, will protect them from being hacked again for some period of 
time. Particularly when the solution to protect TCP from ICMP-based 
attacks is completely straightforward, and that's what most 
implementations have been doing for fifteen years or so.

As a matter of fact, I'm spending more cycles in having people 
participate in the discussions, and provide feedback for "submitting 
new reviews". For some reason, you tend to take the discussion to the 
point we were in more than half an year ago. Most likely, if I were 
not the author of the draft, I wouldn't participate myself.

The draft has been in a steady state for quite a long time. Probably 
since version -03 of draft-gont. Most of the stuff that was added in 
the revisions was stuff that I really thought is was needed. But it 
didn't hurt, so I granted it. The feedback I got even from people 
that had never provided feedback before have been mostly (if not 
completely) editorial. Minor tweaks.

I am going to address the comments listed in the e-mail I sent to the 
list. Those are the comments that try to move forward the current 
draft, by improving it.

I thank you for the effort you have put in making each version of the 
draft a better one, and even your last comments on the update of the 
reference to the IPSec standard. But adding switches to select the 
behaviour, heuristics to decide when to change the reaction to hard 
errors, etc., is, IMO, not what the WG agreed on, and, IMHO, 
something that adds unnecessary complexity, unnecessary pages and 
unnecessary discussion.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2006 20:56:31 -0700

Fernando Gont wrote:
....
> designed to have the worst possible effect. This assumption will lead to 
> suitably protective design."

                 "Be liberal in what you accept, and
                  conservative in what you send"

There is a large difference between documenting what is - and weighing 
the implications of that - with accepting what is implemented and 
recommending it for the future without substantial detail. I heard the 
WG agree to the former, not the latter; the chairs can clarify.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 May 2006 10:18:25 -0300

At 00:56 24/05/2006, Joe Touch wrote:

>>designed to have the worst possible effect. This assumption will 
>>lead to suitably protective design."
>
>There is a large difference between documenting what is - and 
>weighing the implications of that - with accepting what is 
>implemented and recommending it for the future without substantial 
>detail. I heard the WG agree to the former, not the latter; the 
>chairs can clarify.

What changes are you proposing, specifically?

Kindest regards,