Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-07

From: Dave Thaler <[email-masked]>
Date: Tue, 5 Jan 2010 23:33:05 +0000

My comments and suggested wording changes on this document
are marked up in the PDF at
http://research.microsoft.com/~dthaler/draft-ietf-behave-v6v4-xlate-stateful-07.pdf

A summary of the main comments is:

1) The WG consensus on terminology was to use "stateful NAT64" not "NAT64"
   for this document.  The term "NAT64" is independent of stateful vs
   stateless, but specific to direction of initiation (6->4).

2) The doc implies that it can only support a single Pref64 prefix.  
   That would seem to preclude some topologies where it would otherwise 
   seem to work.  The other documents (including DNS64) have no such
   restriction.

3) The same question about handling nested ICMP error messages
   applies to this document, and I would hope the answers are the
   same between the two docs.

4) Section 3.1 currently states the fragment time interval MUST
   be configurable.  All the other configuration requirements are
   SHOULDs, and I believe this one should be too.

5) RFC 4787 REQ-4 recommends port preservation for UDP, but this 
   is missing from section 3.2.1.1 of this doc.

6) The doc says nothing about sequence number checking, only
   5-tuple checking, to effect state transitions.  There should
   be discussion of this, at least in security considerations
   if no sequence number checking is done.

7) Re Section 3.5 on hairpinning: there's also the 4->6->4
   hairpinning possibility when the 4->6 mapping is statically
   configured, right?

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 12:39:24 +0100

Hi Dave,

thanks for the review

I include next the replies to each of the comments you made in the review

DT1: I have used the stateful nat64 termoninology in the title, section 
titles, abstract and introduction and i have stated that in the rest of 
the document for brevity we may use nat64 alone. Please check the next 
version and let me know if more exhaustive use o fthe stateful nat64 
terminology is needed.

DT2: done

DT3: rephrased as:

     <t>DNS64 is a mechanism for synthesizing AAAA resource records (RR)
      from A RR. The IPv6 address contained in the synthetic AAAA RR is 
algorithmically generated from the IPv4
      address and the IPv6 prefix assigned to a NAT64 device by using 
the same algorithm defined in
      <xref target="I-D.ietf-behave-address-format"></xref>.</t>

DT4: rephrased as:

     <t>Together, these two mechanisms allow an IPv6-only client
    (i.e. either a host with only IPv6 stack, or a host with both IPv4 
and IPv6 stack,
    but only with IPv6 connectivity or a host running an IPv6 only 
application)
    to initiate
     communications to an IPv4-only server (analogous meaning to the 
IPv6-only host above).</t>

DT5: rephrased as:

 For basic functionality, the approach only requires
     the deployment of the stateful NAT64 function in the devices 
connecting an IPv6-only network to
     the IPv4-only network, along with the deployment of a few DNS64-enabled
     name servers accessible to the IPv6-only hosts

DT6: done

DT7 and DT8: I have removed the full paragraph as a result of Dan's review.

DT9: rephrased as

          <t>In the absence of any state in NAT64, only IPv6 nodes can 
initiate sessions to IPv4 nodes.
             This works for roughly the same class of applications that work
             through IPv4-to-IPv4 NATs.</t>

DT10 done

DT11: mmm, well these addresses are just addresses when they are 
assigned to the NAT64, i think. The prefix will be used to construct 
IPv4 converted addresses but i would find misleading to say that the 
IPv4 converented address have been assigned to the nat64.

DT12: agree. Rephrased to

       <t>The IPv6 address pool is one or more IPv6 prefixes assigned to 
the translator
       itself (hereafter we will call the IPv6 address pool as 
Pref64::/n, in the case there are more
       than one prefix assigned to the NAT64, the comments made about 
Pref64::/n apply to each of them). Due to the abundance of IPv6 address 
space,
       it is possible to assign one or more Pref64::/n, each of them 
being equal to or even bigger than the size of the whole IPv4 address 
space. This allows
       each IPv4 address to be mapped into a different IPv6 address by 
simply
       concatenating a Pref64::/n with the IPv4 address being mapped and 
a suffix.
       The provisioning of the Pref64::/n as well as the address format are
        defined in <xref target="I-D.ietf-behave-address-format" />. </t>

DT13: trimmed the paragraph to:

       <t>To allow an IPv6 initiator to do a DNS lookup to learn
       the address of the responder, DNS64 <xref 
target="I-D.ietf-behave-dns64"></xref>
        is used to synthesize AAAA RRs from the A
       RRs. The IPv6 address contained in the synthetic AAAA RRs contain
       the Pref64::/n assigned to the NAT64 and the real IPv4
       address of the responder. The
       synthetic AAAA RR is passed back to the IPv6 initiator, which will
       initiate an IPv6 communication with the IPv6 address associated 
to the
       IPv4 receiver. The packet will be routed to the NAT64 device, which
       will create the IPv6 to IPv4 address mapping as described before.</t>

DT14, correct, the walk-through description in this document has a 
detailed description of how the nat64 works, which is not in the dns64 
and the dns64 specific details are missing. I am not sure if you want 
any change in this...

DT15: I am hesitant to use actual ip addresses and names, since this is 
the same notation we will use in the normative part, so i think this 
helps the reader to get familair with the notation used later on... not 
sure how strongly you feel about using real IP addreses (or what other 
people think it is better...)

DT16: modified the ascii art to

+---------------------+         +---------------+
|IPv6 network         |         |    IPv4       |
|           |  +-------------+  |  Network      |
|           |--| Name server |--|               |
|           |  | with DNS64  |  |  +----+       |
|  +----+   |  +-------------+  |  | H2 |       |
|  | H1 |---|         |         |  +----+       |
|  +----+   |      +-------+    |  IP addr: X   |
| IP addr:Y'|------| NAT64 |----|               |
|           |      +-------+    |               |
|           |         |         |               |
+---------------------+         +---------------+

DT17: done

DT18:
I have changed all occurrence of box to device.
I think we need to keep 3 terms: NAT64, NAT64 function (to stress the 
functional part) and NAT64 device (to stress that we are talking about 
the box where the function is executed), would that be ok? I think that 
we need all 3 of them, cause we need nat64 function and nat64 de vice to 
empahsize that particular aspect we are talking about and using nat64 
function and nat64 device only would make reading longer

DT19 done, but i used the word binding rahter than mappings

DT20 done

DT21 done

DT22 done (changes in all the occurrences)

DT23 done

DT24: done (in all the occurrences)

DT25. I used the Filtering, Endpoint independent format to allow the 
definition of filtering to be first than the the definition of the types 
of filtering... do you think that is a problem?

DT26:rephrased to
         <t hangText="Hairpinning:">Having a packet do a "U-turn" inside 
a NAT
         and come back out the same side (IPv4 side or IPv6 side) as it 
arrived on.
         If the destination IPv6 address and its embedded IPv4 address
         are both assigned to the NAT64 itself, then the packet is
         being sent to another IPv6 host connected to the same
         NAT64.  Such a packet is called a 'hairpin packet'.
         A NAT64 that forwards hairpin packets, back to the IPv6 host 
are defined as
         supporting "hairpinning". 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. More 
detailed
         explanation of hairpinning and examples can be found in <xref
         target="RFC4787"></xref>.  </t>

DT27: rephrased as

         <t hangText="Mapping or Binding:">A mapping between an IPv6 
transport address and a
         IPv4 transport address or a mapping between an (IPv6 address, 
ICMPv6 Query Identifier)
          pair and an (IPv4 address, ICMPv4 query Identifier) pair. Used 
to translate the addresses and ports/Query Identifiers
         of packets flowing between the IPv6 host and the IPv4 host.
          In NAT64, the IPv4 address and port/ICMPv4 Query Identifier is 
always
         one assigned to the NAT64 itself, while the IPv6
         address and port/ICMPv6 Query Identifier belongs to some IPv6 
host.</t>

DT28: rephrased as:

        A function that has per-flow state which translates IPv6 packets
          to IPv4 packets and vice-versa, for TCP, UDP, and ICMP.  The 
NAT64 uses binding state to
          perform the translation between IPv6 and IPv4 addresses.

DT29: see DT28

DT30: done

DT31: done

DT32: done rephrased as

       <t>A NAT64 is a device with at least one IPv6 interface and at 
least one IPv4 interface.
       Each NAT64 device MUST have at least one unicast /n IPv6 prefix 
assigned to it,

DT33: done

DT34: I am not convinced to change the terminology at this stage unless 
people feel very strongly about it, since it may be an error prone process

DT35: changed all query identifiers, query Id and so on to ICMP 
Identifier in all the document.

DT36: done

DT37: complete, corrected

DT38: done

DT39: I wait to see what is the outcome of the xlate doc discussion on 
this one

DT40: done

DT41: done

DT42: Changed the wording to
 the NAT64 tries to create a new entry (if resources and policy permit)

DT43: idem DT42

DT44: rephrased based on previous comments to:

               <t>The NAT64 sets (or resets) the timer in the Session Table
               Entry to maximum session lifetime. The maximum session 
lifetime MAY be configurable and
               the default SHOULD be at least UDP_DEFAULT.
               The maximum session lifetime MUST NOT be less than UDP_MIN.

DT45: done

DT46: same than DT42

DT47: same than DT44

DT48:
Req 4 of rfc4787 reads:

   REQ-4:  It is RECOMMENDED that a NAT have a "Port parity
      preservation" behavior of "Yes".
i.e. it is not port preservation, but port parity preservation. I 
understand that the current text complies with that.

DT49: done

DT50: we discussed about sequence numbers and my understanding was that 
the consensus was that we are not going to keep track of the sequence 
numbers in the nat64. I even displayed both state machines, one with seq 
numbers and one without seq numbers and we decided that we will not keep 
track of them. That being said, i understnad that some nat64 will keep 
track of the seq numbers for security reasons as you say, but i 
understand that will not be specified in the spec.

DT51 done

DT52 done

DT53: done

DT54: done

DT55: done

DT56: done

DT57: done

DT58: done

DT59: I don't think there could be a hairpinning for an incoming IPv4 
packet. see my previous email exchanged with Dan about this.

DT60: removed that paragraph after Dan's review

DT61: removed paragpraph after Dan's review

DT62: turned into sub sections

DT63: removed the address and port dependent

DT64: done

DT65: done rephrased as:
Then any packet sent to the binding's IPv4
    address could loop in the NAT64. This is prevented in the current 
specification
    by filtering incoming packets containing Pref64::/n in the source 
address as described next.

DT66: done

DT67: done

DT68 through DT72: I have removed the whole section based on previous 
reviews.

So, coming back to the main comments:

>    stateless, but specific to direction of initiation (6->4).
I have modified the document to reflect that.

>    seem to work.  The other documents (including DNS64) have no such
I agree that the nat64 shoudl support multiple prefixes. I have modified 
the text to reflect that

>    same between the two docs.
I haven't done anything about this, waiting for the outcome of the 
disucssion of both documents

>    SHOULDs, and I believe this one should be too.
done

>    is missing from section 3.2.1.1 of this doc.
as discussed above, req 4 requires port parity preservation and this is 
already covered in the doc afaiu

>    if no sequence number checking is done.
I agree with including something about this in the security 
consideration section. I will work more on the security considerations 
with Reinaldo's review and i will add some text about this. I am not 
sure what points you think they should be relfected, though... i mean, 
do you have a clear idea of what are the security properties of tracking 
the seq number?

>    hairpinning possibility when the 4->6 mapping is statically

see my email exchange with dan about this. My understnading is that 
hairpining of IPv4 packet don't make much sense.

Regards, marcelo

> -Dave
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Jan 2010 18:19:03 +0000

> IPv6-only host above).</t>

The above text omits the IPv6-only app case mentioned in my feedback.
Is that intentional?  If so, why?

> IPv4 converented address have been assigned to the nat64.

Ok then say the prefix will be used to construct IPv4-converted addresses.

>        RRs. The IPv6 address contained in the synthetic AAAA RRs

s/address/addresses/
(since RRs is plural)

> contain
>        synthetic AAAA RR is passed back to the IPv6 initiator, which

s/RR is/RRs are/
(this was the point of my comment)

> will

s/the/an/
(again my main point)

> people think it is better...)

I think it's more important for the reader to understand what's going on
than to become familiar with a confusing notation here.  So I would really
like this to be changed.

I think I saw another review saying the same thing, so I don't
think it's just me.

> function and nat64 device only would make reading longer

NAT64 is ambiguous... does it mean NAT64 function or NAT64 device?
I think we should get down to 2 terms only. I see you updated the
definition of Stateful NAT64 to say "function" instead of "device".
This means you can delete the term "NAT64 function" throughout the 
remainder of the doc and just use "NAT64" since that is defined as 
function.  However, I'd suggest adding a definition of "Stateful 
NAT64 device" right after the definition of "Stateful NAT64" to
make this distinction explicit.

> of filtering... do you think that is a problem?

Given that you didn't do the same for Mapping, yes I think it's
inconsistent between mapping and filtering.

>          target="RFC4787"></xref>.  </t>

See comments below on IPv4 hairpinning.
 
>          <t hangText="Mapping or Binding:">A mapping between an IPv6

Why have two terms (mapping, binding) rather than one?

> people feel very strongly about it, since it may be an error prone

I would like to hear others' comments on this.

> DT39: I wait to see what is the outcome of the xlate doc discussion on

Ok, let's not forget this

> understand that the current text complies with that.

Yes you're right.  I read it wrong.

> understand that will not be specified in the spec.

Then the security considerations section should point out this issue.

> packet. see my previous email exchanged with Dan about this.

I see the email but I don't agree with it.  You seemed to imply
it "wouldn't make sense" and you assumed that an IPv6 node was
talking to an IPv4 node.  In contrast my comment was:

"There's also the 4->6->4 hairpinning possibility 
 when the 4->6 mapping is statically configured, right?"
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And I saw no response to this in the other thread.

So if an admin tries to configure a static mapping

   (1.1.1.1, 1234) <-> (WKP::2.2.2.2, 5678)

Is the implementation supposed to fail the configuration attempt?
Certainly nothing in the present draft says so, so I assume it 
succeeds.  Now when an IPv4 packet arrives destined to 1.1.1.1:1234,
it will be hairpinned to 2.2.2.2:5678.

Hence I believe the resolution to [DT26] and [DT59] are 
insufficient.

> do you have a clear idea of what are the security properties of

It should be stated that as currently specified, the NAT64 only requires
filtering traffic based on the 5-tuple.  In some cases (e.g., statically
configured mappings), this may make it easy for an attacker to guess.  
An attacker need not be able to guess other fields, e.g. the TCP sequence
number, to get a packet through the NAT64.  While such traffic might be
dropped by the final destination, it does not provide additional
mitigations against bandwidth/CPU attacks targeting the internal network.

> hairpining of IPv4 packet don't make much sense.

Hopefully it makes sense to you now based on my response to [DT59].
Note I'm not saying it has to be supported.  I'm saying that if you 
don't want it to be supported, the document should explicitly disallow it.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Jan 2010 18:25:02 +0000

Minor clarification below.

>  when the 4->6 mapping is statically configured, right?"

Clarification: it will be translated to [WKP::2.2.2.2]:5678
which will then go through the NAT64, and be translated to
2.2.2.2:<something>

Where <something> would be 5678 if it's port preserving but could
be something else.

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 20:13:44 +0100

below...

> The above text omits the IPv6-only app case mentioned in my feedback.
mmm, no, the text above says "a host running an IPv6 only 
application"... what am i missing?
> Ok then say the prefix will be used to construct IPv4-converted addresses.
Ok
added
       Pref64::/n will be used by the NAT64 to construct IPv4-Converted 
IPv6 addresses as defined in <xref 
target="I-D.ietf-behave-address-format"></xref>.

>>        RRs. The IPv6 address contained in the synthetic AAAA RRs
ok

> (this was the point of my comment)
ok

>>        initiate an IPv6 communication with the IPv6 address associated

ok
> make this distinction explicit.
ok

> inconsistent between mapping and filtering.

but we don't define endpoint independent nor address dependent mapping 
in the document, so i fail to see what the inconsistency is.
> Why have two terms (mapping, binding) rather than one?
don't know, i guess people use both. I have no problem to replace all 
the mappings by bindings... to me are the same

> Then the security considerations section should point out this issue.
ok, see below, where the security aspects of seq number tracking is 
discussed.
> it "wouldn't make sense" 

well hairpinning as defined in rfc4787 means that

   If two hosts (called X1 and X2) are behind the same NAT and
   exchanging traffic, the NAT may allocate an address on the outside of
   the NAT for X2, called X2':x2'.  If X1 sends traffic to X2':x2', it
   goes to the NAT, which must relay the traffic from X1 to X2.  This is
   referred to as hairpinning and is illustrated below.

     NAT
   +----+ from X1:x1 to X2':x2'   +-----+ X1':x1'
   | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
   +----+                         |  v  |
                                  |  v  |
                                  |  v  |
                                  |  v  |
   +----+ from X1':x1' to X2:x2   |  v  | X2':x2'
   | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
   +----+                         +-----+

                           Hairpinning Behavior

   Hairpinning allows two endpoints on the internal side of the NAT to
   communicate even if they only use each other's external IP addresses
   and ports.

Following that definition, i understnad that hairpinning can only happen 
between the two nodes that can initiate communication i.e. between two 
IPv6 nodes in our case. It is not obvious to me how to extend the 
concept of hairpinning for nodes that cannot initiate communications

> and you assumed that an IPv6 node was
this is precluded by the text in the draft that drops any packet 
contianing pref64 in the source address in order to prevent hairpinning 
loops.

        <t>Irrespective of the transport protocol used, the NAT64 MUST 
silently discard
            all incoming IPv6 packets containing a source address that 
contains the Pref64::/n.
            This is required in order to prevent hairpinning loops as 
described in <xref target="sec"></xref>.
            In addition, the NAT64   MUST only process incoming
            IPv6 packets that contain a destination address that 
contains Pref64::/n.
            Likewise, the NAT64   MUST only process incoming
            IPv4 packets that contain a destination address that belong 
to the IPv4 pool assigned to the NAT64.</t>

> mitigations against bandwidth/CPU attacks targeting the internal network.

added the following text

<t>    As currently specified, the NAT64 only requires
    filtering traffic based on the 5-tuple.  In some cases (e.g., statically
    configured mappings), this may make it easy for an attacker to guess. 
    An attacker need not be able to guess other fields, e.g. the TCP 
sequence
    number, to get a packet through the NAT64.  While such traffic might be
    dropped by the final destination, it does not provide additional
    mitigations against bandwidth/CPU attacks targeting the internal 
network.
    To avoid these type of abuse, some NAT64 MAY keep track the sequence 
number
    of TCP packets in order to verify that proper sequencing of 
exchanged segments,
    in particular, the SYNs and the FINs.</t>
> don't want it to be supported, the document should explicitly disallow it.
mmm, what about if we define hairpinning for the nat64 case only as the 
IPv6-NAT64-IPv6?
I mean, after all, it is not obvious to extend rfc4787 definition to the 
nat64 case and this seems the reasnable way to extend it... what do you 
think?