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

[marcelo bagnulo braun <[e-mail]>]

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