Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcp-soft-errors

Fernando Gont <fernando@gont.com.ar> Wed, 13 August 2008 08:49 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853A33A6AD0; Wed, 13 Aug 2008 01:49:53 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E233A6A53; Wed, 13 Aug 2008 01:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level:
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDdosFjE6q9q; Wed, 13 Aug 2008 01:49:51 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 23AAD3A6A73; Wed, 13 Aug 2008 01:49:49 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 179DB6B6805; Wed, 13 Aug 2008 05:49:48 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-43-199.speedy.com.ar [201.254.43.199] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7D8ngss006153; Wed, 13 Aug 2008 05:49:43 -0300
Message-Id: <200808130849.m7D8ngss006153@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 13 Aug 2008 05:44:10 -0300
To: Jari Arkko <jari.arkko@piuha.net>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <48A2958C.8020009@piuha.net>
References: <20080717102200.0757D3A69C6@core3.amsl.com> <200807181736.m6IHaWB3006186@venus.xmundo.net> <48A2958C.8020009@piuha.net>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 13 Aug 2008 05:49:47 -0300 (ART)
Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, david.borman@windriver.com, iesg@ietf.org, weddy@grc.nasa.gov, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org
Subject: Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcp-soft-errors
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At 05:04 a.m. 13/08/2008, Jari Arkko wrote:

>>I'm the author of the TCPM WG's "ICMP attacks against TCP draft". 
>>While that draft was initially meant for the informational track, 
>>it is now aims at "Informational". So, even when virtually all 
>>current implementations behave as you describe, the IETF 
>>specifications remain unchanged.
>
>Ok. Perhaps it would be useful to state something about reality as 
>well -- even if you do not recommend something else, I think you 
>should acknowledge the fact that virtually all implementations 
>behave differently.

I'd be more than pleased to do it. The only reason for which I didn't 
is that we had very heated debates on the ICMP attacks stuff on the 
TCPM WG mailing-list, and thus I didn't want to start the debate over 
again in the context of this draft. I will prepare some text, and ask 
for comments. Does it sound reasonable?


>>>Section 3.2 says:
>>>
>>>In scenarios where a node has no default routers and Neighbor
>>>Unreachability Detection (NUD) [RFC4861] fails for destinations
>>>assumed to be on-link, or where firewalls or other systems that
>>>enforce scope boundaries send ICMPv6 errors, the sending node will be
>>>signaled of the unreachability problem. However, as discussed in
>>>Section 2.2, standard TCP implementations will not abort connections
>>>when receiving ICMP error messages that indicate soft errors.
>>>
>>>Clarity. This is somewhat misleading. When the node has no default
>>>routers it also has no prefixes, no global addresses and it will not
>>>even try to use IPv6 towards other global addresses.
>>
>>Why not? What if a Router Advertisement has a "Router Lifetime" of 
>>0? Am I missing something?
>
>Ah, I didn't think of this case. I'll leave it up to you if you want 
>to edit the text to clarify what you mean. (I don't require you to 
>and I'm not certain that it is needed.)

Same here. Will come back to you asap with some proposed text.

Thanks!

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm