Subject: Re: [BEHAVE] nits on draft-bagnulo-behave-nat64-00.txt

From: Philip Matthews <[email-masked]>
Date: Tue, 17 Jun 2008 07:53:59 -0400

Copying the WG on the reply to this.

On Fri, 13-Jun-08, at 15:32 , Dan Wing wrote:
> Here are my nits.
>
> -d
>
> -----
>
>
>> 1.  Introduction
> ...
>>   The NAT64 and DNS64 mechanisms are related to the NAT-PT mechanism
>>   defined in [RFC2766], but significant differences exist.  First,
>>   NAT64 does not define the NATPT mechanisms used to support IPv6  
>> only
>>   servers to be contacted by IPv4 only clients, but only defines the
>>   mechanisms for IPv6 clients to contact IPv4 servers and its  
>> potential
>>   reuse to support peer to peer communications through standard NAT
>>   traversal techniques.  Second, NAT64 includes a set of features  
>> that
>>   overcomes many of the reasons the original NAT-PT specification was
>>   moved to historic status [RFC4966].
>
> It would be good to briefly enumerate those differences.  I admit  
> that I
> am not intimate with NAT-PT, so the only difference that I am aware of
> is EDNS0.  I think another difference is that the NAT64 and DNS64  
> functions
> do not talk to each other and share state, and I /think/ that NAT-PT  
> had
> them share state.  I don't know for sure, though.

I agree that a section enumerating the differences between this draft  
and RFC 2766 would be good.

>
>
>
>
>> 1.1.  Features of NAT64
> ...
>>   o  It enables IPv6-only nodes to initiate a client-server  
>> connection
>>      with an IPv4-only server, without needing any changes on either
>>      IPv4 or IPv6 nodes.  This works for the same class of  
>> applications
>>      that work through IPv4-to-IPv4 NATs.
>                                       ^^^^
>
> This should be "NAPTs" -- or you should indicate in your terminology  
> section
> that any reference to v4-to-v4 NAT is really to a v4-to-v4 NAPT.

Almost everyone today uses "NAT" to mean "NAPT". And the STUN and TURN  
documents do the same.
But we can add something about this.

>
>
>>
>>   o  It supports peer-to-peer communication between IPv4 and IPv6
>>      nodes, including the ability for IPv4 nodes to initiate
>>      communcation with IPv6 nodes using peer-to-peer techniques  
>> (i.e.,
>>      using a rendezvous server and ICE).  To this end, NAT64 is
>>      compliant with the recommendations for how NATs should handle  
>> UDP
>>      [RFC4787], TCP [I-D.ietf-behave-tcp], and ICMP
>>      [I-D.ietf-behave-nat-icmp].
>>
>>   o  Compatible with ICE.
>>
>>   o  Supports additional features with some changes on nodes.  These
>>      features include:
>>
>>      *  Support for DNSSec
>>
>>      *  Some forms of IPSec support
>>
>>      *  Increased ability to detect when there is a communication  
>> path
>>         that does not involve translating between IPv6 and IPv4.   
>> This
>>         is achieved by marking synthetic DNS AAAA resource records
>>         which usage would result in translated connectivity, so that
>>         the sender can prefer using non-synthetic records when it is
>               ^^^^^^
> the use of "sender" is a bit unclear, and could be referring to the  
> DNS64
> "sender" (replying to the DNS query).  How about "host initiating the
> connection" or something.

OK.

>
>
>
> ...
>> 1.2.2.  Walkthough
> ...
>>   5.  H1 receives the synthetic AAAA record and sends a packet  
>> towards
>>       H2.  The packet is sent from a source transport address of  
>> (Y',y)
>>       to a destination transport address of (Pref64:X,x), where y  
>> and x
>>       are ports chosen by H2.
>                             ^^
> should be "H1".

Yup.

>
>
>
>>   6.  The packet is routed to the IPv6 interface of the NAT64 (since
>>       Pref64::/96 has been associated to this interface).
>>
>>   7.  The NAT64 receives the packet and performs the following  
>> actions:
>>
>>       *  The NAT64 selects an unused port t on its IPv4 address T and
>>          creates the mapping entry (Y',y) <--> (T,t)
>>
>>       *  The NAT64 translates the IPv6 header into an IPv4 header  
>> using
>>          SIIT.
>>
>>       *  The NAT64 includes (T,t) as source transport address in the
>>          packet and (X,x) as destination transport address in the
>>          packet.  Note that X is extracted directly from the lower 32
>>          bits of the destination IPv6 address of the received IPv6
>>          packet that is being translated.
>
> Need to add text indicating where "x" (the port) is taken from.

It is mentioned in point 5, but we can make this clearer.

>
>
> Can this be made protocol-agnostic (UDP, TCP, DCCP)?  Or almost  
> protocol
> agnostic?

Well, the NAT64 needs to know where the port fields are, and also  
needs to know how to update the checksum. Did you have anything else  
in mind?

>
>
>
>>       The NAT64 sends the translated packet out its IPv4 interface  
>> and
>>       the packet arrives at H2.
>>
>>   8.  H2 node responds by sending a packet with destination transport
>>       address (T,t) and source transport address (X,x).
>>
>>   9.  The packet is routed to the NAT64 box, which will look for an
>>       existing mapping containing (T,t).  Since the mapping (Y',y)  
>> <-->
>>       (T,t) exists, the NAT64 performs the following operations:
>>
>>       *  The NAT64 translates the IPv4 header into an IPv6 header  
>> using
>>          SIIT.
>>
>>       *  The NAT64 includes (Y',y) as source transport address in the
>>          packet and (Pref64:X,x) as destination transport address in
>>          the packet.  Note that X is extracted directly from the  
>> source
>>          IPv4 address of the received IPv4 packet that is being
>>          translated.
>
> I believe the text in the bullet above is backwards -- the NAT64  
> would not
> send a packet with (Fref64:X,x) as the destination address.

Yup. The description of the source and destination transport addresses  
need to be swapped.
>
>
>
>>       The translated packet is sent out the IPv6 interface to H2.
>>
>>   The packet exchange between H1 and H2 continues and packets are
>>   translated in the different directions as previously described.
>>
>>   It is important to note that the translation still works if the  
>> IPv6
>>   initiator H1 learns the IPv4 address through some scheme other  
>> than a
>>   DNS look-up.  This is because the DNS64 processing does NOT  
>> result in
>>   any state installed in the NAT64 box and because the mapping of the
>>   IPv4 address into an IPv6 address is the result of concatenating  
>> the
>>   prefix defined within the site for this purpose (called Pref64::/96
>>   in this document) to the original IPv4 address.
>
> Does this mean that straight IPv4 addresses will work, like http://1.2.3.4 
>  ??
>
> I believe the answer is yes if the NAT64 function is part of the v6- 
> only host,
> but I believe the answer is no if the NAT64 function is in a  
> separate box.  It
> would be good to expand on this.

I believe you are right.

What we meant was that things would still work if Pref64:1.2.3.4 was  
learned through other means; for example, through a binding  
transaction with a STUN server, or though a rendezvous server like  
those used in HIP or being considered in P2PSIP. Clearly the v4  
address won't work without the prefix. And I agree we should explain  
this better.

>
>
> ...
>> 3.3.  DNS64
> ...
>>   To ensure endpoint-independent mapping behavior, a given IPv6 host
>>   must always use the same NAT64.  This, in turn, means that any
>>   synthetic AAAA records used by the host must always use the same
>>   prefix.  To ensure this, if a DNS64 has multiple Pref64::/96  
>> prefixes
>>   configured, it SHOULD ensure that the same prefix is used for all
>>   AAAA records returned to a given host across all queries.  A
>>   reasonable exception would be when the DNS64 knows, through some
>>   unspecified means, that the NAT64 associated with a Pref64::/96
>>   prefix is no longer functional.
>
> A v6 host can have multiple v6 addresses.  So, I think the above text
> needs to be adjusted to say "v6 address" rather than "host", because  
> it
> is difficult-to-impossible for the NAT64 to know if two v6 addresses  
> belong
> to the same host.  I don't see a problem with making the change -- the
> *host* doesn't need to see the same mapping, but a v6 application  
> using
> the same v6 address does, so I think the text can be safely adjusted  
> to
> refer to v6 address.  Please let me know if you disagree.

I think you are right. Good catch.

>
>
>
>
>>   Furthermore, it is highly desirable to synthesize the AAAA  
>> records as
>>   close as possible to the host that will use them.  This helps  
>> ensure
>>   that a given host always uses the same NAT64.
>
>
> This statement needs more justification text.  If I imagine that my  
> DNS64
> is on the other side of the globe, I do not see how a worse problem is
> created due to the location of my DNS64.

You want to synthesize as closely as possible to the host because you  
want to make sure to always use the same NAT64.

>
>
>> 3.4.  NAT64
>>
>>   A NAT64 is a device with one IPv6 interface and one IPv4 interface.
>>   The IPv6 interface MUST have a unicast /96 IPv6 prefix assigned to
>>   it, denoted Pref64::/96.  The IPv4 interface MUST have one or more
>>   unicast IPv4 addresses assigned to it.
>>
>>   A NAT64 uses the following dynamic data structures:
>>
>>   o  UDP BIB
>>
>>   o  UDP Session Table
>>
>>   o  TCP BIB
>>
>>   o  TCP Session Table
>
> draft-ietf-behave-nat-icmp discussses an ICMP session table that is  
> the
> same importance as UDP and TCP.  It might be best to just add ICMP to
> this list so that ICMP queries are handled appropriately.
>
> (I realize you have a "TBD:" later which mentions this, I am just
> suggesting how to add it to your document.)

OK. We haven't worked through the details of ICMP Query message  
support yet.

>
>
>
>> 3.4.1.  Determining the Incoming 5-tuple
>>
>>   This step associates a incoming 5-tuple (source IP address, source
>>   port, destination IP address, destination port, transport protocol)
>>   with every incoming IP packet for use in subsequent steps.
>>
>>   If the incoming IP packet contains a complete (un-fragmented) UDP  
>> or
>>   TCP protocol packet, then the 5-tuple is computed by extracting the
>>   appropriate fields from the packet.
>>
>>   If the incoming IP packet contains a complete (un-fragmented) ICMP
>>   message, then the 5-tuple is computed by extracting the appropriate
>>   fields from the IP packet embedded inside the ICMP message.   
>> However,
>>   the role of source and destination is swapped when doing this: the
>>   embedded source IP address becomes the destination IP address in  
>> the
>>   5-tuple, the embedded source port becomes the destination port in  
>> the
>>   5-tuple, etc.  If it is not possible to determine the 5-tuple
>>   (perhaps because not enough of the embedded packet is reproduced
>>   inside the ICMP message), then the incoming IP packet is silently
>>   discarded.
>>
>>      NOTE: The transport protocol is always one of TCP or UDP, even  
>> if
>>      the IP packet contains an ICMP message.
>
> I do not understand the significance of that Note.  Does it mean the
> transport protocol *inside* of the ICMP message needs to be TCP or UDP
> because you're only defining NAT64 for TCP and UDP?  Or does it mean
> something else?

It means that if the incoming IP packet contains an ICMP error message  
about a TCP packet, then the transport address in the incoming 5-tuple  
is considered to be TCP, even though "TCP over ICMP" would be more  
accurate. This is because the subsequent translation steps for such a  
packet are very similar to that for a TCP packet.  But I agree this  
needs to be made clearer.

>
>
>>   If the incoming IP packet contains a fragment, then more processing
>>   may be needed.  This specification leaves open the exact details of
>>   how a NAT64 handles incoming IP packets containing fragments, and
>>   simply requires that a NAT64 handle fragments arriving out-of- 
>> order.
>      
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> that phrase disagrees with the phrase below (search for FRAG-REQ):
See below.

>
>
>>   A NAT64 MAY elect to queue the fragments as they arrive and  
>> translate
>>   all fragments at the same time.  Alternatively, a NAT64 MAY  
>> translate
>>   the fragments as they arrive, by storing information that allows it
>>   to compute the 5-tuple for fragments other than the first.  In the
>>   latter case, the NAT64 will still need to handle the situation  
>> where
>>   subsequent fragments arrive before the first.
>>
>>   Implementors of NAT64 should be aware that there are a number of
>>   well-known attacks against IP fragmentation; see [RFC1858] and
>>   [RFC3128].
>
> You should also cite RFC4963, which describes problems of receiving
> fragments at high data rates -- which I expect a NAT64 would be doing.

Thanks for the reference.

>
>
>>   Assuming it otherwise has sufficient resources, a NAT64 MUST allow
>>   the fragments to arrive over a time interval of at least 10  
>> seconds.
>>   A NAT64 MAY require that the UDP, TCP, or ICMP header be completely
>      
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   contained within the first fragment.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> FRAG-REQ:  This highlighted sentence disagrees with the text above  
> (search
> for FRAG-REQ).

I guess  "initial fragment" would be better than "first fragment".
In other words, when fragments are sorted into their correct order,  
then the TCP, UDP, or ICMP header must be completely contains in the  
first fragment.
>
>
>
>
>> 3.4.2.1.  UDP Session Handling
>>
>>   The state information stored for a UDP session is a timer that  
>> tracks
>>   the remaining lifetime of the UDP session.  The NAT64 decrements  
>> this
>>   timer at regular intervals.  When the timer expires, the UDP  
>> session
>>   is deleted.
>>
>>   The incoming packet is processed as follows:
>>
>>   1.  If the packet arrived on the IPv4 interface and the NAT64  
>> filters
>>       on its IPv4 interface, then the NAT64 checks to see if the
>>       incoming packet is allowed according to the address-dependent
>>       filtering rule.  To do this, it searches for a session table
>>       entry with a source IPv4 address equal to the source IPv4  
>> address
>>       in the incoming 5-tuple.  If such an entry is found (there  
>> may be
>                                                               
> ^^^^^^^^^^^^
>>       more than one), packet processing continues.  Otherwise, the
>         ^^^^^^^^^^^^^
>
> I am not sure, but I believe the highlighted phrase disagrees with  
> text
> later in the document (search for MORE-ONE).

There is no conflict. This sentence talks about session table entries  
and the one below talks about BIB entries.

This exact same situation occurs with ordinary v4-to-v4 NATs. A host H  
on the private side of a v4-to-v4 NAT can be sending packets from  
(H,h) to two different ports y1 and y2 on server Y. This causes a  
single mapping entry to be installed in the NAT, but there are two  
different UDP sessions involved.

>
>
>>       packet is discarded.  If the packet is discarded, then an ICMP
>>       message SHOULD be sent to the original sender of the packet,
>>       unless the discarded packet is itself an ICMP message.  The  
>> ICMP
>>       message, if sent, has a type of 3 (Destination Unreachable)  
>> and a
>>       code of 13 (Communication Administratively Prohibited).
>>
>>   2.  The NAT64 searches for the session table entry corresponding to
>         ^^
> I believe you want to prefix this with "If the packet arrived on the  
> v6
> interface,"

No. It is possible to establish a session from the v4 side, if there  
is a BIB entry and if filtering allows.

This is a design decision that could change, but for now I see no  
reason to disallow this.

>
>
>>       the incoming 5-tuple.  If no such entry if found, a new entry  
>> is
>>       created
>
> ....
>> 3.4.3.  Computing the Outgoing 5-Tuple
> ...
>>   If the rules specify that a new BIB entry is created for a source
>>   transport address of (S',s), then the NAT64 allocates an IPv4
>>   transport address for this BIB entry as follows:
>>
>>      If there exists some other BIB entry containing S' as the IPv6
>>      address and mapping it to some IPv4 address T, then use T as the
>>      IPv4 address.  Otherwise, use any IPv4 address assigned to the
>>      IPv4 interface.
>>
>>      If the port s is in the Well-Known port range 0..1023, then
>>      allocate a port t from this same range.  Otherwise, if the  
>> port s
>>      is in the range 1024..65535, then allocate a port t from this
>>      range.  Furthermore, if port s is even, then t must be even, and
>>      if port s is odd, then t must be odd.
>>
>>      In all cases, the allocated IPv4 transport address (T,t) MUST  
>> NOT
>                                                                  
> ^^^^^^^^
>>      be in use in another entry in the same BIB, but MAY be in use in
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>      the other BIB.
>
> MORE-ONE: I believe this disagrees with the earlier text (search for
> MORE-ONE).

There is no conflict. See above.

>
>
>> 3.4.5.  Handling Hairpinning
>>
>>   This step handles hairpinning if necessary.
>>
>>   If the destination IP address is an address assigned to the NAT64
>>   itself (i.e., is one of the IPv4 addresses assigned to the IPv4
>>   interface, or is covered by the /96 prefix assigned to the IPv6
>>   interface), then the packet is a hairpin packet.  The outgoing
>>   5-tuple becomes the incoming 5-tuple, and the packet is treated  
>> as if
>>   it was received on the outgoing interface.  Processing of the  
>> packet
>>   continues at step 2.
>>
>>   TBD: Is there such a thing as a hairpin loop (likely not naturally,
>>   but perhaps through a special-crafted attack packet with a spoofed
>>   source address)?  If so, need to drop packets that hairpin more  
>> than
>>   once.
>
> Is the IP TTL insufficient?

Hmmm. I hadn't thought of that. Perhaps IP TTL will do. But first we  
need to investigate whether it is possible.

>
>
>> 3.5.  FTP ALG
>>
>>   TBD: Describe the FTP ALG, a mechanism for translating the embedded
>>   IP addresses inside FTP commands, that enables FTP sessions to pass
>>   through NAT64.
>
> I had a larger comment about FTP ALG in my email to the list.

OK.

>
>
>
>> 4.  Security Considerations
>>
>>   Implications on end-to-end security, IPSec and TLS.
>>
>>   Any protocol that protect IP header information are essentially
>>   incompatible with NAT64.  So, this implies that end to end IPSec
>>   verification will fail when AH is used (both transport and tunnel
>>   mode) and when ESP is used in transport mode.  This is inherent to
>>   any network layer translation mechanism.  End-to-end IPsec  
>> protection
>>   can be restored, using UDP encapsulation as described in [RFC2765].
>
> This paragraph should be re-written to more clearly remind readers  
> that NAT64
> works where v4-v4 NAPT works, and that v4-v4 NAPT does not work with  
> IPsec
> AH or with IPsec transport mode -- and thus neither does NAT64.  And  
> point
> out that with v4-v4 NAPT and with NAT64, IPsec-over-UDP works fine.   
> If you
> extend NAT64 s I suggest on the mailing list, IPsec transport mode  
> (without
> UDP encapsulation) would both work, too.
>
> (You might get additional inspiration from text at:
> http://tools.ietf.org/html/draft-kukec-ikev2-tutorial-additions-02#section-8
> which I ran into recently.)

OK.

>
>
>>   TBD: TLS implications
>
> I do not believe there are any TLS implications.

I tentatively agree.

>
>
>>
>>   Implications on DNS security and DNSSec.
>>
>>   NAT64 uses synthetic DNS RR to enable IPv6 clients to initiate
>>   communications with IPv4 servers using the DNS.  This essentially
>>   means that the DNS64 component generates synthetic AAAA RR that are
>>   not contained in the master zone file.  From a DNSSec perspective,
>>   this means that the straight DNSSec verification of such RR would
>>   fail.  However, it is possible to restore DNSSec functionality if  
>> the
>>   verification is performed right before the DNS64 processing  
>> directly
>>   using the original A RR of the IPv4 server.  So, in order to  
>> jointly
>>   use the NAT64 appraoch described in thei specification and DNSSec
>>   validation, the DNS64 functionality should be performed in the
>>   resolver of the IPv6 client.  In this case, the IPv6 client would
>>   receive the original A RR with DNSSec information and it would  
>> first
>>   perform the DNSSec validation.  If it is succcessful, it would then
>>   proceed the synthetize the AAAA RR according to the mechanism
>>   described in this document.  It should be noted that the synthetic
>>   AAAA RR would stay within the IPv6 client and it would not leak
>>   outside, making further DNSSec validations unnecesary.
>>
>>   Filtering.
>>
>>   NAT64 creates binding state using packets flowing from the IPv6  
>> side
>>   to the IPv4 side.  So, NAT64 implements by definition, at least,
>>   endpoint independent filtering, meaning that in order to enable any
>>   packet to flow from the IPv4 side to the IPv6 side, there must have
>>   been a packet flowing from the IPv6 side to the IPv4 side the  
>> created
>>   the binding information to be used for packets in the other
>>   direction.  Endpoint independent filtering allows that once a  
>> binding
>>   is created, it can be used by any node on the IPv4 side to send
>>   packets to the IPv6 transport address that created the binding.   
>> This
>>   basically means that as long a the IPv6 node does not open a hole  
>> in
>>   the NAT64, incoming communications are blocked and that once that  
>> the
>>   IPv6 node has sent the first packet, this packet opens the door for
>>   any node on the IPv4 side to send packets to that IPv6 transport
>>   address.  It is possible to configure the NAT64 to implement more
>>   stringent security policy, if endpoint independent mapping is
>>   considered not secure enough.  In particular, if the security  
>> policy
>>   of the NAT64 requires it, is it possible to configure the NAT64 to
>>   perform address dependent filtering.  This basically means that the
>>   binding state created can only be used by to send packets from the
>>   IPv4 address to which the original packet that created the binding
>>   was sent to.  This basically means that the door is open only for
>>   that IPv4 address to send packet to the IPv6 transport address.
>>
>>   Attacks to NAT64.
>>
>>   The NAT64 device itself is a potential victim of different type of
>>   attacks.  In particular, the NAT64 can be a victim of DoS attacks.
>>   The NAT64 box has a limited number of resources that can be  
>> consumed
>>   by attackers creating a DoS attack.  The NAT64 has a limited number
>>   of IPv4 address that is uses to create the bindings.  Even though  
>> the
>>   NAT64 performs address and port translation, it is possible for an
>>   attacker to consume all the IPv4 transport addresses by sending  
>> IPv6
>>   packets with different source IPv6 transport address
>
> It should also be pointed out that the he attack can also be performed
> by using a single v6 address, by making a huge number of connections  
> to
> v4 hosts.  Such as, for example, doing an FTP mirror of a v4 FTP  
> server.

With a single v6 address, an attacker can create many different  
session table entries, but only one BIB entry.

>
>
>>   It should be
>>   noted that this attack can only be launched from the IPv6 side,  
>> since
>>   IPv4 packets are not used to create binding state.  DoS attacks can
>>   also affect other limited resource available in the NAT64 such as
>>   memory or link capacity.  For instance, if the NAT64 implements
>>   reassembly of fragmented packets, it is possible for an attacker to
>>   launch a DoS attack to the memory of the NAT64 device by sending
>>   fragments that the NAT64 will store for a given period.  If the
>>   number of fragments if high enough, the memory of the NAT64 could  
>> be
>>   exhausted.  NAT64 devices should implement proper protection  
>> against
>>   such attacks, for instance allocating a limited amount of memory  
>> for
>>   fragmented packet storage.
>
> It would be valuable to cite the fragmentation attack RFCs again here.
> ([RFC1858], [RFC3128]).

OK.

- Philip

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