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

"Laganier, Julien" <julienl@qualcomm.com> Fri, 09 July 2010 17:24 UTC

Return-Path: <julienl@qualcomm.com>
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 AFEC83A6AA3; Fri, 9 Jul 2010 10:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 iQyL+zsYudu5; Fri, 9 Jul 2010 10:24:40 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0AD963A65A6; Fri, 9 Jul 2010 10:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1278696283; x=1310232283; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20marcelo=20bagnulo=20braun=20<marcelo@it.uc3m.es> |CC:=20"secdir@ietf.org"=20<secdir@ietf.org>,=20"iesg@iet f.org"=20<iesg@ietf.org>,=0D=0A=09"draft-ietf-behave-v6v4 -xlate-stateful@tools.ietf.org"=0D=0A=09<draft-ietf-behav e-v6v4-xlate-stateful@tools.ietf.org>,=0D=0A=09"behave-ch airs@tools.ietf.org"=20<behave-chairs@tools.ietf.org> |Date:=20Fri,=209=20Jul=202010=2010:24:14=20-0700 |Subject:=20RE:=20secdir=20review=20of=20draft-ietf-behav e-v6v4-xlate-stateful-11|Thread-Topic:=20secdir=20review =20of=20draft-ietf-behave-v6v4-xlate-stateful-11 |Thread-Index:=20AcsfRcdm6p0M3B7jSGKnFLJPdC1nLwARaEkA |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F023C75D E@NALASEXMB04.na.qualcomm.com>|References:=20<BF345F63074 F8040B58C00A186FCA57F1F023C6F35@NALASEXMB04.na.qualcomm.c om>=0D=0A=20<4C36E625.4060008@it.uc3m.es>|In-Reply-To:=20 <4C36E625.4060008@it.uc3m.es>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=PGtNSxkPFEOcLc5uZDhAuZGLglrlP9Th0XI5KyfLd50=; b=TzW6YIadno79yQ3JODtAMiON5HBa/19Q1x3nT1jTEZ7MORtfGBBOrjWF Tz5llDgbD8I9xKlDeqHSA3VhuoYdAjDVPfURqGt9/UkrmmfKKPeX4terq TVoqW160V//0HAwN12YPpnje4rE7ycpSyAZMCjj2MhPru5A62dcXRgLHb U=;
X-IronPort-AV: E=McAfee;i="5400,1158,6038"; a="46847065"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 09 Jul 2010 10:24:40 -0700
X-IronPort-AV: E=Sophos;i="4.53,563,1272870000"; d="scan'208";a="81935745"
Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Jul 2010 10:24:39 -0700
Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Jul 2010 10:24:16 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 9 Jul 2010 10:24:16 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Date: Fri, 9 Jul 2010 10:24:14 -0700
Thread-Topic: secdir review of draft-ietf-behave-v6v4-xlate-stateful-11
Thread-Index: AcsfRcdm6p0M3B7jSGKnFLJPdC1nLwARaEkA
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F023C75DE@NALASEXMB04.na.qualcomm.com>
References: <BF345F63074F8040B58C00A186FCA57F1F023C6F35@NALASEXMB04.na.qualcomm.com> <4C36E625.4060008@it.uc3m.es>
In-Reply-To: <4C36E625.4060008@it.uc3m.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 17:24:43 -0000

Hi Marcelo,

Thank you for clarifying. I do not have further questions/comments.

--julien

marcelo bagnulo braun wrote:
> 
> 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
> >
> >
> >
> >
> >