Re: [secdir] secdir review of draft-ietf-behave-v6v4-xlate-stateful-11

marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 09 July 2010 09:05 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5FD3A6BC9; Fri, 9 Jul 2010 02:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.229
X-Spam-Level:
X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 tJukjWwNqPbv; Fri, 9 Jul 2010 02:05:02 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A42123A6BCC; Fri, 9 Jul 2010 02:04:38 -0700 (PDT)
X-uc3m-safe: yes
Received: from marcelo-bagnulos-macbook-pro.local (53.30.18.95.dynamic.jazztel.es [95.18.30.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id AE69DBDFA16; Fri, 9 Jul 2010 11:04:37 +0200 (CEST)
Message-ID: <4C36E625.4060008@it.uc3m.es>
Date: Fri, 09 Jul 2010 11:04:37 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: "Laganier, Julien" <julienl@qualcomm.com>
References: <BF345F63074F8040B58C00A186FCA57F1F023C6F35@NALASEXMB04.na.qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F023C6F35@NALASEXMB04.na.qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17494.006
X-Mailman-Approved-At: Mon, 12 Jul 2010 09:21:32 -0700
Cc: "behave-chairs@tools.ietf.org" <behave-chairs@tools.ietf.org>, "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" <draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-behave-v6v4-xlate-stateful-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2010 09:05:16 -0000

Hi Julien,

Thanks for the review

Replies below.


El 28/06/10 23:09, Laganier, Julien escribió:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> Document abstract:
>
>     This document describes stateful NAT64 translation, which allows
>     IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
>     ICMP.  The public IPv4 address can be shared among several IPv6-only
>     clients.  When the stateful NAT64 is used in conjunction with DNS64
>     no changes are usually required in the IPv6 client or the IPv4
>     server.
>
> Comments:
>
> The document is a nice read and in a good shape. I have a few comments below:
>
> Section 1.2. "Overview": Repeated use of the term "transport address" but it is only defined later in the Terminology section 2.
mmm, a definition for transport address is provided in the overview 
section before the term is used. In particular, section 1,2 reads:

    In order to be able to
    perform IPv6-IPv4 translation, NAT64 requires state, binding an IPv6
    address and TCP/UDP port (hereafter called an IPv6 transport address)
    to an IPv4 address and TCP/UDP port (hereafter called an IPv4
    transport address).


wouldn't that suffice?

> Suggest moving "1.2 Overview" in its own standalone section numbered 3, just after terminology.
>    


> Section 2 describes Hairpinning and Section 3.8 specifies NAT64 support for Hairpinning. The document states that "Hairpinning support is important for peer-to-peer applications, as there are cases when two different hosts on the same side of a NAT can only communicate using sessions that hairpin through the NAT." I understand that it is important for NAT44 because only RFC1918 ambiguous address space is available for hosts behind NAT44 which can make it impossible for host to communicate. I however do not understand why it is needed with NAT64 where non-ambiguous IPv6 address space is available to hosts behind the NAT64. Why would the host be able to communicate only through a NAT64? It seems that putting an IPv6 router next to the NAT64 would avoid the need for hairpinning NAT64. Maybe I am missing something... If there's a easy explanation, suggest extending the terminology with it.
>    
mmm, probably some people that are more knowledgeable than me in the 
type of apps that make use of hairpinning could expand on this, but my 
understanding is that the problem is not related with the addresses 
being non unique, but wiht which address the host is able to discover.
I mean, suppose you have two IPv6 hosts sitting behind a NAT64.
Suppose that the rendez vous server (or whatever you call it) is in V4 land.
Then The rendez vous server will inform the V6 host about the v4 address 
of the other v6 host. So in this case, the v6 hosts will have to use the 
v4 address of the other host to initiate a communication. That is what 
hairpinning is needed for.
Does this makes sense?

This described in great detail in 
http://tools.ietf.org/html/rfc4787#page-16 which is refered in the nat64 
draft.


> Section 5.2.: "To avoid this type of abuse, a NAT64 MAY keep track of the sequence number of TCP packets in order to verify that proper sequencing of exchanged segments, in particular, the SYNs and the FINs." =>  I think you mean "in particular, those of the SYNs and the FINs."
right, fixed

>   Also, it seems to me that you want to keep track of is the whole TCP state rather than the only the sequence numbers, i.e., whether the connection is opened, half-closed, by watching at SYNs, RSTs and FINs.
>    

right, but we already do that, we keep track of the SYNs, the FINs and 
the RSTs. The only thing we do not mandate to keep track of is the seq 
number.

Regards, marcelo
> --julien
>
>
>
>
>