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

"Laganier, Julien" <julienl@qualcomm.com> Mon, 28 June 2010 21:09 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id CA9C328C121; Mon, 28 Jun 2010 14:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.489
X-Spam-Status: No, score=-104.489 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Rk4pc6LLFZJB; Mon, 28 Jun 2010 14:09:34 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com []) by core3.amsl.com (Postfix) with ESMTP id A634C28C115; Mon, 28 Jun 2010 14:09:34 -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=1277759383; x=1309295383; h=from:to:cc:date:subject:thread-topic:thread-index: message-id: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:=20"secdir@ietf.org"=20<secdir@ietf.org>,=20"iesg@iet f.org"=20<iesg@ietf.org>|CC:=20"draft-ietf-behave-v6v4-xl ate-stateful@tools.ietf.org"=0D=0A=09<draft-ietf-behave-v 6v4-xlate-stateful@tools.ietf.org>,=0D=0A=09"behave-chair s@tools.ietf.org"=20<behave-chairs@tools.ietf.org>|Date: =20Mon,=2028=20Jun=202010=2014:09:41=20-0700|Subject:=20s ecdir=20review=20of=20draft-ietf-behave-v6v4-xlate-statef ul-11|Thread-Topic:=20secdir=20review=20of=20draft-ietf-b ehave-v6v4-xlate-stateful-11|Thread-Index:=20AcsXBjnihORq h1ckQ3SEf8aol2I7fQ=3D=3D|Message-ID:=20<BF345F63074F8040B 58C00A186FCA57F1F023C6F35@NALASEXMB04.na.qualcomm.com> |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"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=g+ufuVUltCoBtgB0sgR1fDlfAwN0ZMsk5M0PQEO1Oio=; b=J8OQniaFwlFHw78FgQ/yd+IqR+7Ulhw3aEbBc4rlpaNAJhFtpF/YSyT6 r0e4glYA0wWZSzM5WGEiyA8HCNX961TzXP4alknqluc8yu6ht0BCNiwkD RmEpC+C0cv/UiZrZantF7FQQfX6JhtmU46M0NnCSM0L/uBkSovliVzAxN s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6027"; a="45683672"
Received: from ironmsg02-r.qualcomm.com ([]) by wolverine02.qualcomm.com with ESMTP; 28 Jun 2010 14:09:42 -0700
X-IronPort-AV: E=Sophos;i="4.53,497,1272870000"; d="scan'208";a="80423705"
Received: from nasanexhub05.na.qualcomm.com ([]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Jun 2010 14:09:42 -0700
Received: from nasanexhc09.na.qualcomm.com ( by nasanexhub05.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id; Mon, 28 Jun 2010 14:09:44 -0700
Received: from nalasexhc03.na.qualcomm.com ( by nasanexhc09.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id 14.0.694.0; Mon, 28 Jun 2010 14:09:44 -0700
Received: from NALASEXMB04.na.qualcomm.com ([]) by nalasexhc03.na.qualcomm.com ([]) with mapi; Mon, 28 Jun 2010 14:09:44 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Mon, 28 Jun 2010 14:09:41 -0700
Thread-Topic: secdir review of draft-ietf-behave-v6v4-xlate-stateful-11
Thread-Index: AcsXBjnihORqh1ckQ3SEf8aol2I7fQ==
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F023C6F35@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" <draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org>, "behave-chairs@tools.ietf.org" <behave-chairs@tools.ietf.org>
Subject: [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: Mon, 28 Jun 2010 21:09:35 -0000

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


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

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