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

[Arifumi Matsumoto <[e-mail]>]

Hi,

Fernando Gont wrote:
> 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.

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.

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

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.

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

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.

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

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.

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