Subject: [BEHAVE] Stateful NAT64 compliance with RFC4787 requirements.

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

Hi,

I have tried to contrast RFC4787 requirements and the current NAT64 draft.
This is the result. I think we are in good shape.

There is only one requirement that we don't fully comply with i.e. 
REQ5-A. Not sure if we should change the draft to comply with it. comments?

Let me know if you think i am missing something.
We could include this text either in the appendix or as a separated 
document. I would expect this may be useful for IESG evaluation.

RFC 4787 Requirements

   REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

NAT64 complies with this by the usage of the UDP BIB and the fact that 
all UDP sessions are based on the corresponding BIB entry

   REQ-2:  It is RECOMMENDED that a NAT have an "IP address pooling"
      behavior of "Paired".  Note that this requirement is not
      applicable to NATs that do not support IP address pooling.

NAT64 complies with this in section 3.5.1.1.  Rules for Allocation of 
IPv4 Transport Addresses for UDP

   When a new UDP 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 the NAT64
      SHOULD use T as the IPv4 address.  Otherwise, use any IPv4 address
      of the IPv4 pool assigned to the NAT64 to be used for translation.

   REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
      overloading".

NAT64 complies with this since it never attempts to preserve the port in 
any case.

      a) If the host's source port was in the range 0-1023, it is
         RECOMMENDED the NAT's source port be in the same range.  If the
         host's source port was in the range 1024-65535, it is
         RECOMMENDED that the NAT's source port be in that range.

NAT64 complies with this with text:

3.5.1.1.  Rules for Allocation of IPv4 Transport Addresses for UDP

   When a new UDP 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 the port s is in the Well-Known port range 0-1023, and the
      NAT64 has an available port t in the same port range, then the
      NAT64 SHOULD allocate the port t.  If the NAT64 does not have a
      port available in the same range, the NAT64 MAY assign a port t
      from other range where it has an available port. (this behavior is
      recommended in REQ 3-a of [RFC4787])

      If the port s is in the range 1024-65535, and the NAT64 has an
      available port t in the same port range, then the NAT64 SHOULD
      allocate the port t.  If the NAT64 does not have a port available
      in the same range, the NAT64 MAY assign a port t from other range
      where it has an available port. (this behavior is recommended in
      REQ 3-a of [RFC4787])

   REQ-4:  It is RECOMMENDED that a NAT have a "Port parity
      preservation" behavior of "Yes".

NAT64 complies with this with text:

3.5.1.1.  Rules for Allocation of IPv4 Transport Addresses for UDP

   When a new UDP 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:

...

      The NAT64 SHOULD preserve the port parity (odd/even), as per
      Section 4.2.2 of [RFC4787]).

   REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
      minutes, unless REQ-5a applies.

NAT64 complies with this with text

      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.  The
      packet is translated and forwarded as described in the following
      sections.

      a) For specific destination ports in the well-known port range
         (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
         are specific to the IANA-registered application running over
         that specific destination port.

NAT64 DOES NOT complies with this requirements (it used to, but this was 
removed from the draft based on comments)

      b) The value of the NAT UDP mapping timer MAY be configurable.

NAT64 complies with this, see text above

      c) A default value of five minutes or more for the NAT UDP mapping
         timer is RECOMMENDED.

NAT64 complies with this, see text above

   REQ-6:  The NAT mapping Refresh Direction MUST have a "NAT Outbound
      refresh behavior" of "True".

NAT64 complies with this, see text above

      a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
         refresh behavior" of "True".

The difficulty to comply with this is that depending on the scenario, 
the internal and the external side of the NAT64 vary.
NAT64 complies with this, with the following text:

5.3.  Attacks on NAT64

...

   Another consideration related to NAT64 resource depletion refers to
   the preservation of binding state.  Attackers may try to keep a
   binding state alive forever by sending periodic packets that refresh
   the state.  In order to allow the NAT64 to defend against such
   attacks, the NAT64 MAY not extend the session entry lifetime for a
   specific entry upon the reception of packets for that entry through
   the external interface.  As described in the Framework document
   [I-D.ietf-behave-v6v4-framework], the NAT64 can be deployed in
   multiple scenarios, some of which the external side is the IPv6 one
   and some of which the external side is the IPv4 one.  It is then
   important to properly set which is the external side of the NAT64 in
   each specific configuration.

   REQ-7  A NAT device whose external IP interface can be configured
      dynamically MUST either (1) Automatically ensure that its internal
      network uses IP addresses that do not conflict with its external
      network, or (2) Be able to translate and forward traffic between
      all internal nodes and all external nodes whose IP addresses
      numerically conflict with the internal network.

This does not applies to NAT64 since one side is IPv6 and the other one 
is IPv4

   REQ-8:  If application transparency is most important, it is
      RECOMMENDED that a NAT have "Endpoint-Independent Filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have "Address-Dependent
      Filtering" behavior.

      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

NAT64 complies with this, as it defines both Endpoint-Independent 
Filtering and Address-Dependent Filtering

   REQ-9:  A NAT MUST support "Hairpinning".

      a) A NAT Hairpinning behavior MUST be "External source IP address
         and port".

NAT64 complies with this in section 3.8.  Handling Hairpinning

Note that We concluded that hairpinning of incomig IPv4 packets does not 
make much sense.

   REQ-10:  To eliminate interference with UNSAF NAT traversal
      mechanisms and allow integrity protection of UDP communications,
      NAT ALGs for UDP-based protocols SHOULD be turned off.  Future
      standards track specifications that define an ALG can update this
      to recommend the ALGs on which they define default.

      a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
         the NAT administrator to enable or disable each ALG separately.

NAT64 complies with this since it does not defines any ALG.

   REQ-11:  A NAT MUST have deterministic behavior, i.e., it MUST NOT
      change the NAT translation (Section 4) or the Filtering
      (Section 5) Behavior at any point in time, or under any particular
      conditions.

NAT64 complies with this, as it defines a single mapping and the two 
require filtering which are configurable by the admin

   REQ-12:  Receipt of any sort of ICMP message MUST NOT terminate the
      NAT mapping.

NAT64 complies with this, as not ICMP message processing implies the 
termination of a binding

      a) The NAT's default configuration SHOULD NOT filter ICMP messages
         based on their source IP address.

NAT64 complies with this

      b) It is RECOMMENDED that a NAT support ICMP Destination
         Unreachable messages.

NAT64 complies with this, as it translates ICMP Dest Unreach

   REQ-13  If the packet received on an internal IP address has DF=1,
      the NAT MUST send back an ICMP message "Fragmentation needed and
      DF set" to the host, as described in [RFC0792].

      a) If the packet has DF=0, the NAT MUST fragment the packet and
         SHOULD send the fragments in order.

I understand that this is in the scope of the xlate draft and not in the 
scope of NAT64

   REQ-14:  A NAT MUST support receiving in-order and out-of-order
      fragments, so it MUST have "Received Fragment Out of Order"
      behavior.

      a) A NAT's out-of-order fragment processing mechanism MUST be
         designed so that fragmentation-based DoS attacks do not
         compromise the NAT's ability to process in-order and
         unfragmented IP packets.

NAT64 complies with this with the following text

3.4.  Determining the Incoming tuple
...
   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 the external behavior of the NAT64 is compliant
   with the following conditions:

      The NAT64 MUST handle fragments.  In particular, NAT64 MUST handle
      fragments arriving out-of-order , conditioned on the following:

      *  The NAT64 MUST limit the amount of resources devoted to the
         storage of fragmented packets in order to protect from DoS
         attacks.

      *  As long as the NAT64 has available resources, the NAT64 MUST
         allow the fragments to arrive over a time interval.  The time
         interval SHOULD be configurable and the default value MUST be
         of at least FRAGMENT_MIN.

      *  The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the fragment that contains OFFSET
         equal to zero.

      For incoming packets carrying TCP or UDP fragments with non-null
      checksum, 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, subsequent fragments
      may arrive before the first and the rules about how the NAT64
      handles (out-of-order) fragments described in the bulleted list
      above apply.

      For incoming IPv4 packets carrying UDP packets with null checksum,
      if the NAT64 has enough resources, the NAT64 MUST reassemble the
      packets and MUST calculate the checksum.  If the NAT64 does not
      have enough resources, then it MUST silently discard the packets.

      Implementers of NAT64 should be aware that there are a number of
      well-known attacks against IP fragmentation; see [RFC1858] and
      [RFC3128].  Implementers should also be aware of additional issues
      with reassembling packets at high rates, described in [RFC4963].

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Jan 2010 12:25:34 +0200

> removed from the draft based on comments)

I'm not sure I understand. REQ-5a allows for a MAY ("MAY have shorter timers"), it doesn't say "MUST have shorter timers". NAT64 doesn't allow for shorter timers, but that's OK - it still complies, no? (The original requirements says, "you still comply even if you use shorter timers" not "you need to allow for shorter timers to comply.")

Lars

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Jan 2010 14:15:28 +0100

> I'm not sure I understand. REQ-5a allows for a MAY ("MAY have shorter timers"), it doesn't say "MUST have shorter timers". NAT64 doesn't allow for shorter timers, but that's OK - it still complies,…
ok, so i will leave it as it is

regards, marcelo