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

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

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



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



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

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.


>We think we need clear definition of ICMPv6 reaction to ask developers
>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,

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