Re: [BEHAVE] Comments on nat64-02

[Reinaldo Penno <[e-mail]>]

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" <[e-mail]> wrote:

> 
> 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
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave