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

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

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