Subject: [BEHAVE] Comments on nat64-02

From: Reinaldo Penno <[email-masked]>
Date: Thu, 26 Feb 2009 15:03:32 -0800

Hello,

I've been going through nat64 and have a few comments/questions:

1)

" 2.  H1 sends a packet to 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."

How can H2 (the destination) choose the source port of both the packets used
by the v6 host and the NAT64 on the IPv4 interface? Should it say H1?

There are also recommendations on RFC4787 about how ports should be mapped
from internal to external networks. I'm assuming those should apply also to
NAT64.

2)

"       *  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."

Maybe you mean (Y', y) as the destination and (Pref64:X, x) as the source?

3)
"   If a NAT64 filters on its IPv4 interface, then an incoming packet is
   dropped unless a packet has been recently sent out the interface with
   a destination IP address equal to the source IP address of the
   incoming packet."

Maybe substitute this wording by "address-dependent filtering according to
RFC4787".

Below you say " NAT64 filtering is consistent with the recommendations of
RFC 4787.", but RFC4787 REQ-8 allows filtering depending on what is
important for the NAT device: security vs. application transparency.

Is the reason for address-dependent filtering security?

4)

"     NOTE: The transport protocol is always one of TCP or UDP, even if
the IP packet contains an ICMP message."

I'm assuming per your TBD this will go away when the draft has ICMP Query
support? 

5)
"   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."

Can you cite the reference for using for the time of at least 10 seconds as
a "MUST"? 

6)

"   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
       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)."

In general I find this section and similar ones very implementation
specific, but regardless I have one comment.

I think you mean 

"... searches for a session table
       entry with a source IPv4 address equal to the destination IPv4
address in the incoming 5-tuple",

otherwise they will never match since the source IP address used by the
NAT64 device will always be different from the source v4 address used by
external hosts.

So, you try to match the destination IPv4 address of a possibly unsolicited
packet with a v4 session that already exists in the session table the
opposite direction, right? This seems consistent with step 2.

7)

"   3.  The NAT64 sets or resets the timer in the session table entry to
       maximum session lifetime.  By default, the maximum session
       lifetime is 5 minutes, but for specific destination ports in the
       Well-Known port range (0..1023), the NAT64 MAY use a smaller
       maximum lifetime."

This seems to be at odds with REQ-5, REQ-5c of RFC4787

You use the word "maximum", but those requirements use "     c) A default
value of five minutes or more for the NAT UDP mapping
         timer is RECOMMENDED."

In other words 5 minutes or more is rather different than a maximum of 5
minutes.

Maybe you can reference REQ-5c here.

Thanks,

Reinaldo

------ End of Forwarded Message

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 27 Feb 2009 11:28:52 -0800

A few more comments as I go through:

7)

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

I do not think one follows from the other as stated. Sending a packet from
ipv6 to ipv4 only creates the binding. It does not enable packets to flow
from ipv4 to ipv6. The mapping strategy might be different from the
filtering strategy.

I think (maybe I'm wrong) that the intent on RFC487 in separating mapping
from filtering was to make these orthogonal issues and allow security to
override things if needed.

8)

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

You mention endpoint independent but in section  "1.2.3.  Filtering" what
you seem to describe is address-dependent filtering.

9)

" It is possible to configure the NAT64 to implement more
   stringent security policy, if endpoint independent mapping is
   considered not secure enough"

I think you mean "endpoint independent filtering" as opposed to endpoint
independent mapping.

Thanks,

Reinaldo

On 2/26/09 3:03 PM, "Reinaldo Penno" <[email-masked]> wrote:

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