Subject: [BEHAVE] [Fwd: Re: nat64-02 review]

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 07 Mar 2009 20:41:44 +0100

Hi Reinaldo,

thanks for your review

some replies below...

Reinaldo Penno escribió:
> 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?
>   
yes, fixed

> 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.
>
>   
Yes, this is considered in the normative part of the spec. this is a 
walkthrough  to allow the reader to get familiar with the overall 
behaviour, the specification itself is later on the doc.

>  
> 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?
>   

right, fixed
> 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".
>   
done
> 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?
>
>   
mmm, the text says that the NAT64 MAY do filtering, which is equivalent 
to what you say about the tradeoff between security and transparency, 
isn't it?

> 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? 
>   
right, ICMP packets will need to be supported as well

> 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"? 
>
>   
why do we need a reference? We are defining the behaviour in this 
document, right?
But, do you think 10 secs is not approapriate? would you use a different 
value? which one and why?

> 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.
>
>   
that's what would be needed to actually be able to forward the packet, 
i.e. if a mapping exists

but here we are talking about how to perform filtering.

So the text on the draft you mention above is wrong, but i think it 
should read:

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

would that make more sense to you?

> 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.
>
>
>   
right
this is one open question whether we will be able to afford endpoint 
independent mappings for all ports in the scenario of ipv4 depletion

we will need to solve this question, so for now we leave the possibility 
open in the draft

what is your opinion on this?

Thanks, marcelo

> Thanks,
> Reinaldo

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 7 Mar 2009 21:28:19 -0800

Hello, 

Thanks for addressing my comments. Further responses inline..

> why do we need a reference? We are defining the behaviour in this

Right.

> value? which one and why?

'Which one and why' is exactly what is missing from your statement in the
draft about the 10 seconds value.

So, is this 10 second value based on some empirical evidence, best practices
or what? 

> what is your opinion on this?

If we do not know yet why make a pre-emptive recommendation that is at odds
with RFC4787. I would say until we have good evidence we should default to
the current recommendation in RFC4787.

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 08 Mar 2009 09:59:57 +0100

> draft about the 10 seconds value.
i guess which one is not missing, it is 10 secs :-)
why, as far as i recall this was input provided by a reviewer
I mean, originally the draft didn't handle out of order fragments i.e. 
dropped the fragments out of order, but it was suggested that the nat64 
should support out of order fragments as long as they arrive in a given 
interval...
maybe Iljitsch of Phil have better recollection of why this specific 
value is in there...

> the current recommendation in RFC4787.

right, that was my take too
Now, with all the ipv4 depletion being so present, it seems that it may 
be worth reconsidering this, or at least open the discussion
I mean, even something as conservative as don't do endpoint independence 
with port 80 seem to provide benefits with not much loss functionality.
regards, marcelo