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

Fernando Gont <fernando@gont.com.ar> Fri, 18 July 2008 17:36 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 332E228C1FD; Fri, 18 Jul 2008 10:36:13 -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 D7AB828C1FD; Fri, 18 Jul 2008 10:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, 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 qQQeCK4yxaeI; Fri, 18 Jul 2008 10:36:11 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0B6F028C1B2; Fri, 18 Jul 2008 10:36:09 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DA27D6B6764; Fri, 18 Jul 2008 14:36:43 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-34-122.speedy.com.ar [201.254.34.122] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m6IHaWB3006186; Fri, 18 Jul 2008 14:36:32 -0300
Message-Id: <200807181736.m6IHaWB3006186@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 18 Jul 2008 14:33:07 -0300
To: Jari Arkko <jari.arkko@piuha.net>, iesg@ietf.org, tcpm@ietf.org
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <20080717102200.0757D3A69C6@core3.amsl.com>
References: <20080717102200.0757D3A69C6@core3.amsl.com>
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]); Fri, 18 Jul 2008 14:36:43 -0300 (ART)
Cc: tcpm-chairs@tools.ietf.org, david.borman@windriver.com, 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 07:22 a.m. 17/07/2008, Jari Arkko wrote:

>First, I was unable to find any evidence of review from the 6MAN or V6OPS
>communities. No request for review has been posted to the lists, at least.
>Has there been such review, and if not, can we ensure it happens now?
>Normally, in general and in particularly for Informational documents IETF
>Last Call suffices, but as I outlined above, this specification is
>important enough to warrant that we get it right.

Actually, the document took off from an initial ID from v6ops. e.g., 
the "Contributors" section in the draft acknowledges this (also it 
does not explicitly reference the v6ops wg).



>Section 2.1 says:
>
>    When receiving an ICMP error message that indicates a hard error
>    condition, TCP will simply abort the corresponding connection,
>    regardless of the connection state.
>
>Question. I was under the impression that recent specifications have
>started to say to not blindly believe ICMP errors due to denial-
>of-service concerns? If this is not the case, then no problem.

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.



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

Thanks!

Kind regards,

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