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

["Arifumi Matsumoto" <[e-mail]>]

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

2007/3/20, Fernando Gont <[e-mail]>:
> At 03:33 p.m. 19/03/2007, Tomohiro -INSTALLER- wrote:
>
> >We asked some vendors to implement as you suggested, however, they
> >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.

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

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

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

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

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.

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

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

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

-- 
[e-mail]

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