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, 09 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 > > > > > > > > > >
- [secdir] secdir review of draft-ietf-behave-v6v4-… Laganier, Julien
- Re: [secdir] secdir review of draft-ietf-behave-v… Laganier, Julien
- Re: [secdir] secdir review of draft-ietf-behave-v… marcelo bagnulo braun