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

[Fernando Gont <[e-mail]>]

At 10:03 a.m. 20/03/2007, Arifumi Matsumoto wrote:

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

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.



>>(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....)
>
>Please let me know how they handle ICMP(v6) errors in such a congestion
>control algorithm.

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



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

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.



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

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)



>> >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.
>
>About ICMPv4 hard error implementation, at least FreeBSD and MacOSX
>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,
>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.

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.



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

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



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

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.



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

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



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

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,

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





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