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

["Laganier, Julien" <[e-mail]>]

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

--julien