Subject: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 09 Mar 2007 13:36:02 +0900

Hi all,

we've posted an I-D that defines TCP reactions(soft/hard) to ICMPv6 error messages.
This document translates ICMPv4 codes and into ICMPv6 codes in order to define
soft error / hard error classification for ICMPv6 codes.

I'd like to have a time slot for this item at Prague.

Best regards. 

	Title		: TCP Reaction to ICMPv6 Error Messages
	Author(s)	: T. Fujisaki, A. Matsumoto
	Filename	: draft-fujisaki-tcpm-icmpv6-reaction-00.txt
	Pages		: 7
	Date		: 2007-2-27
	
   RFC1122 defines nodes TCP stack behavior for ICMPv4 error messages,
   but does not for ICMPv6.  This document defines ICMPv6 message
   classification and node's TCP stack behavior for ICMPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fujisaki-tcpm-icmpv6-reaction-00.txt

Best regards.

-- 
Arifumi Matsumoto
    IP Technology Expert Team
    Secure Communication Project
    NTT Information Sharing Platform Laboratories
    E-mail: [email-masked]

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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 18 Mar 2007 05:00:37 -0300

>soft error / hard error classification for ICMPv6 codes.

We have been talking about ICMP errors on this list for about three 
years now. The direction the industry has taken is to get away from 
tying a specific reaction (basically "abort the connection" or "do 
nothing") to each error message type/code, regardless of e.g., 
connection state.

By translating ICMPv4 codes into ICMPv6 codes you'd basically be 
moving ICMPv6 a number of years back in time. The ICMPv6 spec already 
includes text that gives you freedom in how to respond to ICMPv6 
error messages (e.g., abort a connection in a non-synchronized state 
in response to an ICMP error message, or not abort the connection in 
response to an error message when the connection is in any of the 
synchronized states, or whatever). This freedom already lets you 
implement the soft errors behaviour if you want to address the 
problem of long delays between connection establishment attempts in 
v6 scenarios, as described in the soft errors draft of this WG.

If you translate the ICMPv4 codes into ICMPv6 codes, then:

* For those scenarios in which the lack of v6 connectivity is 
signaled by a so-called "soft error", you won't have solved anything 
(as RFC1122 tells you not to abort the connection attempt).

* For conenctions in the synchronized states, the hard errors would 
open the door to connection-reset attacks, as discussed in the icmp 
attacks draft of this WG.

Implementations have been moving away from the strict type/code -> 
{hard, soft} error classification since more than ten years ago. And 
I honestly think it would be quite a challenge to get the industry 
implement an ICMP error processing policy it has already decided not 
to implement for ICMPv4.

Thanks,

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

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Tue, 20 Mar 2007 03:33:45 +0900 (JST)

Hi Fernando,

Thank you very much for your detailed explanation.

 | By translating ICMPv4 codes into ICMPv6 codes you'd basically be 
 | moving ICMPv6 a number of years back in time. The ICMPv6 spec already 
 | includes text that gives you freedom in how to respond to ICMPv6 
 | error messages (e.g., abort a connection in a non-synchronized state 
 | in response to an ICMP error message, or not abort the connection in 
 | response to an error message when the connection is in any of the 
 | synchronized states, or whatever). This freedom already lets you 
 | implement the soft errors behaviour if you want to address the 
 | problem of long delays between connection establishment attempts in 
 | v6 scenarios, as described in the soft errors draft of this WG.

We know this text is in ICMPv6 spec, however, as you know, few IPv6
implementations respond to ICMP error messages currently. (The 9th
slide of below material include the ICMPv6 reaction of current nodes.)

http://www.nttv6.net/~fujisaki/fallback.pdf

We asked some vendors to implement as you suggested, however, they
said they did not because there were no clear definition for that.

 | If you translate the ICMPv4 codes into ICMPv6 codes, then:
 | 
 | * For those scenarios in which the lack of v6 connectivity is 
 | signaled by a so-called "soft error", you won't have solved anything 
 | (as RFC1122 tells you not to abort the connection attempt).

Yes, but in the case that administrators know that, it is possible to
signal some type of so-called "hard error" ICMP, such as admin
prohibit. This can be used in the case that a site uses ULA in their
network.

 | Implementations have been moving away from the strict type/code -> 
 | {hard, soft} error classification since more than ten years ago. And 
 | I honestly think it would be quite a challenge to get the industry 
 | implement an ICMP error processing policy it has already decided not 
 | to implement for ICMPv4.

It looks that some recent OSes still implement ICMPv4 reaction. 

We think we need clear definition of ICMPv6 reaction to ask developers
to implement ICMPv6 error processing.

--
Tomohiro Fujisaki

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2007 16:35:05 -0300

>said they did not because there were no clear definition for that.

Well, I think the soft errors draft provides a clear explanation of 
the problem, and describes very clearly how the alternative handling 
of ICMP soft errors can help in those scenarios. We have been talking 
on this list about this stuff for three years now.

IMO, if they decide not to implement the described change, it's 
because they think that the solution doesn't fit their needs, or 
because they simply don't want to.

(IIRC, from some talk at San Diego, one vendor that said they didn't 
implement this because "it is not a standard" was Microsoft. Yet they 
were just about (or actually did?) to include alternative congestion 
control algorithms for TCP in Vista that were not even documented by 
the IETF. So....)

>prohibit. This can be used in the case that a site uses ULA in their

So you are saying that we need a better definition of ICMPv6 codes, 
and yet the first thing you plan to do is to forget that definition, 
and use some other error code (that was meant for some other thing) 
to get the result you expect?

>It looks that some recent OSes still implement ICMPv4 reaction.

I don't know of any implementation out there that implements the ICMP 
"hard error" reaction specified in RFC1122. As a matter of fact, this 
has been the case for more than ten years. And in the last few years, 
those implementations that were aborting connections in response to 
the so-called ICMP hard errors changed their reaction to the one 
described in the ICMP attacks draft.

If you mean that some recent OSes still implement RFC1122's reaction 
to *soft* errors, that may be the case. But it's a completely 
different thing from translating ICMPv6 codes into ICMPv4 codes. 
Mapping ICMPv6 codes into ICMPv4 codes is moving ICMPv6 eighteen 
years backwards, and is certainly a bad idea. As I said in my other e-mail:

1) The scenarios you are trying to address usually lead to *soft* 
errors. As a result, the connection will not be aborted, and you will 
not have solved the problem you are trying to solve.
2) Defining ICMP messages that indicate hard errors (as in RFC 1122) 
would open the door to connection reset attacks against TCP. I can 
assure nobody is going to do this.

>to implement ICMPv6 error processing.

A standards-track document does not alleviate the need for a 
competent developer that is able to understand the problem he is 
facing, and analyze the possible solutions to it. I think the soft 
errors draft describes the problem very clearly, and describes an 
alternative handling for ICMP error messages that can help to 
overcome that problem. In practice, if the developer in question has 
any clue, he will implement the decribed handling (or not) based on 
the technical properties, rather on whether there is RFC2119 wording in it.

In the last couple of years, developers from NetBSD, FreeBSD, OpenBSD 
and Linux (at least) have worked on ICMP implementing some of the 
stuff in the ICMP attacks draft. I can guarantee that if you contact 
any of their developers, they will implement the soft errors behavior 
if they think it makes sense (that is, they will analyze what's in 
the document, and implement it if they think it makes sense and 
solves some problem they are having). Cisco has done it, too.

If there's any vendor that will simply not implement something only 
because he does not see the words "should" or "must" in caps, I think 
it's a problem at some layer higher than the 7th... which I really 
doubt the IETF could fix.

Kindest regards,

---

From: "Arifumi Matsumoto" <[email-masked]>
Date: Tue, 20 Mar 2007 22:03:59 +0900

Hi Fernando.
Let me comment as a co-auther.

> on this list about this stuff for three years now.

soft-error draft explains which ICMP error codes can map to which
ICMPv6 error code. However, it isn't for every existing ICMPv6 error codes.
So, I cannot determine any other existing ICMPv6 error code falls into
soft or hard.

   The "Requirements for Internet Hosts -- Communication Layers" RFC
   [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination
   Unreachable" messages that indicate soft errors are ICMP codes 0
   (network unreachable), 1 (host unreachable), and 5 (source route
   failed).  Even though ICMPv6 didn't exist when [RFC1122] was written,
   one could extrapolate the concept of soft errors to ICMPv6 Type 1
   Codes 0 (no route to destination) and 3 (address unreachable).

If you say you provides a clear explanation, please write like the following:

no route to destination : soft
address unreachable : soft
port unreachable : hard
...

> control algorithms for TCP in Vista that were not even documented by

Please let me know how they handle ICMP(v6) errors in such a congestion
control algorithm.

> to get the result you expect?

I cannot get how you lead to that understanding.
What he said was "if admin prohibit is defined as a hard error, TCP session
in *3-way handshake state* can be aborted if the host receives admin prohibit".

We don't care about TCP session in *establieshed state*. IMO, as there is
potential threat here, hard error should not abort established TCP session.

> described in the ICMP attacks draft.

About ICMPv4 hard error implementation, at least FreeBSD and MacOSX
implements RFC1122 reaction. i.e. For port unreachable message,
TCP connections in 3-way handshake state is dropped. For established
state connection, connection is not dropped by port unreachable. This is
owing to your soft-error draft. So, soft-error draft proposes two things, one
is for handshake state and the other is for established state. The first one
isn't implemented while the second one is implemented.
What we care is rather about the first one.

> assure nobody is going to do this.

What we want is to abort a connection when a host receives ICMPv6
hard error message if the connection is in 3-way handshake state.
IMO, the problem is that we don't have definition of ICMPv6 hard error
message, so no vendor can implement this behavior for ICMPv6 messages.

For established connection, we agree that there is potential security hole
when RFC1122 behavior is implemented. This problem should be covered
by your soft-error draft. Our proposal have no suggestion about this problem.

> solves some problem they are having). Cisco has done it, too.

I examined source codes and confirmed that for established state,
they already implemented what you said. What I care is about
3-way handshake state connection.

-- 
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2007 15:26:41 -0300

>address unreachable : soft

Well, it only identifies soft errors, as it is assumed that the other 
errors are hard (if they aren't soft, they are hard), and thus they 
would lead to a connection abortion anyway. However, I would 
personally have no problem with including the other codes, if you 
think that would be of help.

>Please let me know how they handle ICMP(v6) errors in such a congestion

The point was that with congestion control they didn't mind that what 
they were implementing was not even documented by the IETF.

>in *3-way handshake state* can be aborted if the host receives admin 

Why would you define "admin prohibit" as a "hard error"?. Let's just 
say that a packet that belongs to my connection gets misdirected (due 
to a transient network problem) to some router which does not allow 
my traffic to pass. Why should I abort my connection?

Same thing if I am getting an ICMP admin prohibit simply because an 
IPS triggered some rule at a firewall *temporarily* (as is usually the case).

This would kill TCP's robustness.

>potential threat here, hard error should not abort established TCP session.

But if you map ICMPv6 codes into ICMPv4 codes, you map them for all 
states. That is exactly my point. That of "reacting to ICMP error 
messages based on type/code and connection state" is not considered 
in RFC1122 (the concept is introduced by the soft errors and the icmp 
attacks draft). If you want to map ICMPv6 codes into ICMPv4 codes, 
you map them for all states.

When I sent text on this matter for the ICMPv6 spec, the point was 
exactly this: give implementors the freedom to react to ICMPv6 error 
messages as it suits their needs. You can implement both the soft 
errors and the attacks draft without actually violating any v6 spec. 
And that is exactly why I say that doing the mapping from ICMPv6 
codes into ICMPv4 codes simply moves us backwards, because you'd tie 
ICMPv6 to RFC1122. Once you do that, get prepared for another three 
years of discussion on the subject. (check the archives of this list 
from 2004 and on)

>implements RFC1122 reaction.

No. RFC 1122 reaction is that hard errors abort connection in *any* 
state. Nobody does this.

>i.e. For port unreachable message,
>owing to your soft-error draft.

This is due to the *attacks* draft. Well, as a matter of fact, I 
talked with Kirk McKusick and others about this. And they didn't 
follow RFC1122 in that respect because they thought that would affect 
TCP's robustness negatively. Same thing with Mentat-derived 
implementations. Other (newer) implementations have switched to this 
behavior due to the icmp attacks draft, though.

>So, soft-error draft proposes two things, one
>is for handshake state and the other is for established state.

No. The soft errors drafts just described a modification of the 
handling of soft errors in the connection establishment phase. As for 
the established states, RFC1122 already tells you that you should not 
abort connections upon receiving one of them. Neither the soft errors 
draft nor the icmp attacks draft change anything in that respect.

>hard error message if the connection is in 3-way handshake state.

As I said, in the scenarios you are trying to address, you will get 
*soft* errors, rather than hard errors. (Unless you define as "hard" 
some error which should actually be defined as soft... ).

>message, so no vendor can implement this behavior for ICMPv6 messages.

The soft errors draft is even referenced in the v6fix site of the 
WIDE project. IMO, if a vendor does not implement it, then it's 
because they simply don't like the solution. Again, this looks like a 
problem at some layer higher than the 7th.

>by your soft-error draft. Our proposal have no suggestion about this problem.

Your proposal implicitly introduces this problem. RFC1122 "hard 
errors" abort connections irrespective of the connection state.

>3-way handshake state connection.

Send them the soft errors draft (probably together with the v6fix 
document). And if they think it makes sense, they will implement it.

I have had conversations on the subject (icmp attaks, in particular) 
with developers of all of the above open source OSes, and with Cisco 
and Sun. Nobody ever argued as to whether there was a "should" or 
"must" in caps, but rather analyzed the relevant draft, and 
implemented what they thought was convenient and made sense to them. 
If you send them the soft errors doc, most likely they will have the 
same attitude (which does not necessarily mean they will implement it).

I don't understand why Microsoft should be a special case here. 
Particularly, if they enabled IPv6 by default, and their customers 
are experiencing delays of dozens of seconds, they should have enough 
motivations to do something about it.

Kindest regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 21 Mar 2007 18:31:42 +0900

Hi,

Fernando Gont wrote:
> would lead to a connection abortion anyway. However, I would personally 
> have no problem with including the other codes, if you think that would 
> be of help.

At least you should not say or imply "others are hard errors" here.
Because the number of ICMP error codes can increase in the future.

> Why would you define "admin prohibit" as a "hard error"?. Let's just say 
> that a packet that belongs to my connection gets misdirected (due to a 
> transient network problem) to some router which does not allow my 
> traffic to pass. Why should I abort my connection?

You did mention that other ICMPv6 error codes can be treated as hard,
so admin prohibit is also hard, right ?
Anyway, it doesn't matter which specific ICMPv6 code falls into hard
or soft here.

> messages based on type/code and connection state" is not considered in 
> RFC1122 (the concept is introduced by the soft errors and the icmp 
> attacks draft). If you want to map ICMPv6 codes into ICMPv4 codes, you 
> map them for all states.

IMO soft-error draft doesn't obsolete RFC1122 but it supplements
RFC1122. It depends on a vendor whether he implements RFC1122 and
also soft-error RFC. Especially soft-error RFC will be informational,
so it is more vendor-dependent whether he implements it or not.

Just like this, RFC1122-revision(what we propose) doesn't obsolete
soft-error RFC or soft-error RFC doesn't obsolete RFC1122-revision.
soft-error RFC should supplement RFC1122-revision in the same way.

If a vendor implements and RFC1122 and not soft-error RFC for some
reason, he should think about implementing RFC1122-revision instead
of RFC1122 when RFC1122-revision is ready.
If another vendor implements RFC1122 and also soft-error RFC, he
should think about implementing RFC1122-revision and also soft-error
RFC.

This is my opinion about RFC1122-revision and soft-error RFC
relationship. As soft-error RFC will be informational in the immediate
future, IMO all the vendors that implements RFC1122 may not even
notice or take a look at it.

> messages as it suits their needs. You can implement both the soft errors 
> and the attacks draft without actually violating any v6 spec. And that 
> is exactly why I say that doing the mapping from ICMPv6 codes into 
> ICMPv4 codes simply moves us backwards, because you'd tie ICMPv6 to 
> RFC1122. Once you do that, get prepared for another three years of 
> discussion on the subject. (check the archives of this list from 2004 
> and on)

ICMPv6 gave freedom of its error message handling.
Then, every protocol has its own way of error message handling.
So TCP does.
TCP's error message handling should be standardized and should
not be vendor dependent.

The following is about implementation status.

> This is due to the *attacks* draft. Well, as a matter of fact, I talked 
> with Kirk McKusick and others about this. And they didn't follow RFC1122 
> in that respect because they thought that would affect TCP's robustness 
> negatively. Same thing with Mentat-derived implementations. Other 
> (newer) implementations have switched to this behavior due to the icmp 
> attacks draft, though.

I'm sorry for mis-understanding about two drafts.
So, for a summary, FreeBSD and MacOSX implements RFC1122 and for
established connection they implemented icmp-attacks draft.

Kindest regards.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2007 12:22:54 -0300

>Anyway, it doesn't matter which specific ICMPv6 code falls into hard

Exactly. That's why it doesn't make sense to do the mapping from 
ICMPv6 to ICMPv4. The point is that there's no clear definition of 
what is a hard error or a soft error. There's no such thing as soft 
or hard by itself. It depends *when* you receive the error message. 
Defining ICMP admin prohibited as soft or hard is IMHO pointless.

>notice or take a look at it.

We have had this discussion of Informational vs. Std track for one or 
two *years*, more than one year ago. And the WG agreed on Informational.

As for vendors not looking at Informational docs.... I don't buy that 
at all. Let's be clear: Any vendor with a clue will (or what's the 
purpose of Informational docs, after all?). As a matter of fact, many 
vendors already look at internet drafts.

The ICMP attacks draft is aiming at Informational, too. Yet virtually 
all vendors have implemented most of it. Nobody ever bothered whether 
it was Std track or Informational.

If your specific problem arises from use of IPv6, then you can send 
the vendor (Microsoft?) the soft errors draft, and even direct them 
to the v6fix site. If that's not enough, I guess the only thing left 
is to have their clients tell them that it really sucks to have to 
wait dozens of seconds to browse a web page.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 22 Mar 2007 03:16:00 +0900

Fernando Gont wrote:
> Exactly. That's why it doesn't make sense to do the mapping from ICMPv6 
> to ICMPv4. The point is that there's no clear definition of what is a 
> hard error or a soft error. There's no such thing as soft or hard by 
> itself. It depends *when* you receive the error message. Defining ICMP 
> admin prohibited as soft or hard is IMHO pointless.

No. I mean it doesn't matter in this example admin prohibit is hard
or soft as far as there is hard error.

> As for vendors not looking at Informational docs.... I don't buy that at 
> all. Let's be clear: Any vendor with a clue will (or what's the purpose 
> of Informational docs, after all?). As a matter of fact, many vendors 
> already look at internet drafts.
> 
> all vendors have implemented most of it. Nobody ever bothered whether it 
> was Std track or Informational.

IMO, ICMP attack draft addresses a security problem, so it may be easier
to make people move.

> If your specific problem arises from use of IPv6, then you can send the 
> vendor (Microsoft?) the soft errors draft, and even direct them to the 
> v6fix site. If that's not enough, I guess the only thing left is to have 
> their clients tell them that it really sucks to have to wait dozens of 
> seconds to browse a web page.

It may work for my specific problem. For the benefit of every
people using the Internet, which way should we take ?

I'd like to know everybody's opnion in this wg. I'm glad if you
could drop me a line on-list or off-list.

Kindest regards.

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Thu, 22 Mar 2007 03:41:43 +0900 (JST)

Hi,

 | >Anyway, it doesn't matter which specific ICMPv6 code falls into hard
 | >or soft here.
 | 
 | Exactly. That's why it doesn't make sense to do the mapping from 
 | ICMPv6 to ICMPv4. 

What he want to say is the classification of ICMPv6 is further
discussion. He did not say the mapping does not make sense.

RFC1122 is valid spec, and some systems implement RFC1122 TCP reaction
in SYN-SENT state. We want IPv6 nodes to react similarly.

 | The ICMP attacks draft is aiming at Informational, too. Yet virtually 
 | all vendors have implemented most of it. Nobody ever bothered whether 
 | it was Std track or Informational.

Is it in reverse order, isn't it?  Many vendors implement not to
disconnect established TCP session because it would have security
risks. And then ICMP attacks draft was written, as far as I read ML
archives.

 | If your specific problem arises from use of IPv6, then you can send 
 | the vendor (Microsoft?) the soft errors draft, and even direct them 
 | to the v6fix site. If that's not enough, I guess the only thing left 
 | is to have their clients tell them that it really sucks to have to 
 | wait dozens of seconds to browse a web page.

Sorry for repeatedly, but we think soft errors draft does not provide
enough information to implement the TCP reaction. We are afraid every
system react differently when it receives ICMP errors.

Yours Sincerely,
--
Tomohiro Fujisaki

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2007 15:40:36 -0300

>or soft as far as there is hard error.

You have RSTs.

>>We have had this discussion of Informational vs. Std track for one 
>>or two *years*, more than one year ago. And the WG agreed on Informational.
>>As for vendors not looking at Informational docs.... I don't buy 
>>that at all. Let's be clear: Any vendor with a clue will (or what's 
>>the purpose of Informational docs, after all?). As a matter of 
>>fact, many vendors already look at internet drafts.
>>The ICMP attacks draft is aiming at Informational, too. Yet 
>>virtually all vendors have implemented most of it. Nobody ever 
>>bothered whether it was Std track or Informational.
>

Then the issue you are raising is political, not technical.

>>to the v6fix site. If that's not enough, I guess the only thing 
>>left is to have their clients tell them that it really sucks to 
>>have to wait dozens of seconds to browse a web page.
>

I don't see the difference. You have a document that describes a 
problem, and a workaround. If an implementation suffers the described 
problem, send them the doc. After that, is up to them to do something, or not.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2007 16:12:17 -0300

>risks. And then ICMP attacks draft was written, as far as I read ML

BSD systems do not abort established connection in response to ICMP 
messages because the developers thought that that would negatively 
affect robustness. Those implementations that implemented this 
behavior in the last three years or so did that in response to the 
ICMP attacks draft.

>system react differently when it receives ICMP errors.

Perfect. Do you have any specific suggestion on how to improve the 
draft, so it addresses your concerns?

Kindest regards,