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
Precedence: list

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 co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y 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 belo=
w:

Section 1.2. "Overview": Repeated use of the term "transport address" but i=
t is only defined later in the Terminology section 2. Suggest moving "1.2 O=
verview" 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 fo=
r 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 th=
rough the NAT." I understand that it is important for NAT44 because only RF=
C1918 ambiguous address space is available for hosts behind NAT44 which can=
 make it impossible for host to communicate. I however do not understand wh=
y it is needed with NAT64 where non-ambiguous IPv6 address space is availab=
le to hosts behind the NAT64. Why would the host be able to communicate onl=
y through a NAT64? It seems that putting an IPv6 router next to the NAT64 w=
ould 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 s=
equence number of TCP packets in order to verify that proper sequencing of =
exchanged segments, in particular, the SYNs and the FINs." =3D> 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.

--julien