Subject: [BEHAVE] Compliance of stateful NAT64 with RFC5382 requirements

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

Hi,

did the analysis for RFC5382 requriements.
The result is that NAT64 complies with all of them except for:
- there is no explicit mention to the admin being able to configure the 
type of filtering, it is asumed
- NAT64 does not complies with REQ4 as it doesn't send the ICMP error 
back after 6 secs. It never sends it.
- In REQ5, the NAT64 does not make any attempt to find out of the tcp 
connection is alive. there is a prposal to make the nat64 to send 
keepalives to find this out.

see the analysis below...

RFC5382 requirements

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

NAT64 complies with this requirement using the BIB to create any session 
entry.

   REQ-2:  A NAT MUST support all valid sequences of TCP packets
      (defined in [RFC0793]) for connections initiated both internally
      as well as externally when the connection is permitted by the NAT.
      In particular:
      a) In addition to handling the TCP 3-way handshake mode of
         connection initiation, A NAT MUST handle the TCP simultaneous-
         open mode of connection initiation.

NAT64 TCP state machine supports all sequences of valid TCP exhcnages 
and in particular supports TCP SO AFAICT.

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

NAT64 complies with this, as it defines and support both types of filtering

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

This is not explictly mentioned i.e. the draft states that both types of 
filtering are supported, but it simply assumes that a given type of 
filtering is used as configured by the admin... shoudl we make this more 
explicit?

      b) The filtering behavior for TCP MAY be independent of the
         filtering behavior for UDP.

NAT64 supports this as TCP and UDP are handled separated.

   REQ-4:  A NAT MUST NOT respond to an unsolicited inbound SYN packet
      for at least 6 seconds after the packet is received.  If during
      this interval the NAT receives and translates an outbound SYN for
      the connection the NAT MUST silently drop the original unsolicited
      inbound SYN packet.

NAT64 complies with this with text:

in section 3.5.2.2.  State machine for TCP processing in the NAT64

...
   *** CLOSED ***
...

   If a V4 SYN packet is received with an incoming tuple with source
   IPv4 transport address (Y,y) and destination IPv4 transport address
   (X,x) (this is the case of a TCP connection initiated from the IPv4
   side), the processing is as follows:

      If the security policy requires silently dropping externally
      initiated TCP connections, then the packet is silently discarded,
      else,

      If the destination transport address contained in the incoming V4
      SYN (i.e., X,x) is not in use in the TCP BIB, then the packet is
      discarded and an ICMP Port Unreachable error (Type 3, Code 3) is
      sent back to the source of the v4 SYN.  The state remains
      unchanged in CLOSED.

      If the destination transport address contained in the incoming V4
      SYN (i.e., X,x) is in use in the TCP BIB, then

         The NAT64 tries to create a new session table entry in the TCP
         session table (if resources and policy permit), containing the
         following information:

         +  The STE source IPv4 transport address is set to (X,x) (i.e.
            the destination transport address contained in the V4 SYN)

         +  The STE destination IPv4 transport address is set to (Y,y)
            (i.e. the source transport address contained in the V4 SYN)

         +  The STE transport IPv6 source address is set to the IPv6
            transport address contained in the corresponding TCP BIB
            entry.

         +  The STE destination IPv6 transport address contains the port
            y (i.e. the same port than the destination IPv4 transport
            address) and the IPv6 representation of Y (i.e. the IPv4
            address of the destination IPv4 transport address),
            generated using the algorithm described in Section 3.5.4.

         The state is moved to V4 SYN RCV.

         If the NAT64 is performing Address-Dependent Filtering, the
         lifetime of the STE entry is set to TCP_INCOMING_SYN as per
         [RFC5382] and the packet is discarded.  The motivation for
         creating the session table entry and discarding the packet
         (instead of simply dropping the packet based on the filtering)
         is to support simultaneous open of TCP connections.

         If the NAT64 is not performing Address-Dependent Filtering, the
         lifetime of the STE is set to at least to TCP_TRANS (the
         transitory connection idle timeout as defined in [RFC5382]) and
         it translates and forwards the packet as described in the
         following sections.

   For any other packet belonging to this connection:

      If there is a corresponding entry in the TCP BIB other packets
      SHOULD be translated and forwarded if the security policy allows
      to do so.  The state remains unchanged.

      If there is no corresponding entry in the TCP BIB the packet is
      silently discarded.

and then

   *** V4 SYN RCV ***

   If a V6 SYN is received with incoming tuple with source transport
   address (X',x) and destination transport address (Y',y).  The
   lifetime of the TCP session table entry is set to at least to the
   maximum session lifetime.  The value for the maximum session lifetime
   MAY be configurable but it MUST not be less than TCP_EST (the
   established connection idle timeout as defined in [RFC5382]).  The
   default value for the maximum session lifetime SHOULD be set to
   TCP_EST.  The packet is translated and forwarded.  The state is moved
   to ESTABLISHED.

   If the lifetime expires, the session table entry is deleted and the
   state is moved to CLOSED.

   For any other packet, other packets SHOULD be translated and
   forwarded if the security policy allows to do so.  The state remains
   unchanged.

  Otherwise, the NAT SHOULD send an ICMP Port
      Unreachable error (Type 3, Code 3) for the original SYN, unless
      REQ-4a applies.

There is an ongoing discussion if we should comply with this

      a) The NAT MUST silently drop the original SYN packet if sending a
         response violates the security policy of the NAT.

NAT64 complies with this, see text above, in particular

      If the security policy requires silently dropping externally
      initiated TCP connections, then the packet is silently discarded,
      else,

   REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
      connection are active,

NAT64 does not make any attempt to find this out. There is a proposal to 
send keepalives to do this,

      it MAY abandon the session if it has been
      idle for some time.  In such cases, the value of the "established
      connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
      The value of the "transitory connection idle-timeout" MUST NOT be
      less than 4 minutes.
      a) The value of the NAT idle-timeouts MAY be configurable.

NAT64 complies with this, using the TCP-EST timer and the TCP-TRANS timer

   REQ-6:  If a NAT includes ALGs that affect TCP, it is RECOMMENDED
      that all of those ALGs

NAT64 complies with this as NAT64 does not includes any ALG.

      (except for FTP [RFC0959]) be disabled by
      default.

I guess NAT64 complies with this, since it is not requires nor 
reccomended that the FTP is enabled by default.

   The following requirements reiterate requirements from [BEHAVE-UDP]
   or [BEHAVE-ICMP] that directly affect TCP.  This document does not
   relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].

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

NAT64 does complies with this, since it does not attempt to do port 
preservation in any case

   REQ-8:  A NAT MUST support "hairpinning" for TCP.

NAT64 compleis with this in section 3.8.  Handling Hairpinning

      a) A NAT's hairpinning behavior MUST be of type "External source
         IP address and port".

I don't think this applies to NAT64

   REQ-9:  If a NAT translates TCP, it SHOULD translate ICMP Destination
      Unreachable (Type 3) messages.

NAT64 complies with this.

   REQ-10:  Receipt of any sort of ICMP message MUST NOT terminate the
      NAT mapping or TCP connection for which the ICMP was generated.

NAT64 complies with this