Subject: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00: NAT

From: Magnus Westerlund <[email-masked]>
Date: Thu, 24 Jul 2008 17:22:03 +0200

Authors,
(As individual)

I read your document and I kind of reacted to that you call the 
translation process being like SIIT. To me it seems not to fulfill the 
one to one mapping that SIIT does and not touching ports. So I think you 
are much more in the region of doing things similar to a IPv4-IPv4 NAT 
with the IPv6 being the private side. You will have to deal with all the 
gory details of transport protocol translations and their affect on ICMP.

I am at least one that think when specifying these devices also should 
include support for our newer transport protocols. Especially as there 
is relatively little that blocks them in the IPv6 world compared to 
IPv4. And if initiating from IPv6 then you can expect most servers to 
have public IPv4 address that may actually be reachable over DCCP or 
SCTP. So not specifying how to handle these protocols will be simply one 
more roadblock against there usage and a better future.

I get the impression that your device will at least be performing 
address independent mapping allowing current STUN and ICE based or 
similar NAT traversal to work. However, when it comes to filtering, is 
really the NAT64 the place to perform any filtering. Isn't it much 
simpler and requiring less state to be non-filtering when it comes to 
mapping and let the receiving host deal with any unwanted traffic?

Then there is the mapping lifetime question. You specify the maximum 
lifetime to 5 minutes for UDP. What timer length where you considering 
for TCP?

Have you made any considerations on what traffic directions that will 
keep the timer alive?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 18:42:30 +0200

Hi Magnus,

thanks for the comments

comments below...

Magnus Westerlund escribió:
> one to one mapping that SIIT does and not touching ports. So I think 
> you are much more in the region of doing things similar to a IPv4-IPv4 
> NAT with the IPv6 being the private side. You will have to deal with 
> all the gory details of transport protocol translations and their 
> affect on ICMP.
right
what we meant is that the fields other than the address and the ports 
are translated using SIIT
Addresses and ports and a completely different story, as you say
> SCTP. So not specifying how to handle these protocols will be simply 
> one more roadblock against there usage and a better future.
no problem with that
the question is whether you think we need to specify this in the same 
document or in differnet ones
I mean, this idea for any connection oriented protocol is that need to 
deal with all the details of the protocol, so the spec is likely to be 
complex. I mean, for instance, for TCP, we want to create a binding only 
when the connection has been successfully estbalished, and that 
bascially means to re state the TCP state machine, but from the 
perspective of a middle box. The same would apply to DCCP and SCTP. 
there is no problme with doing that, just cumbersome

> similar NAT traversal to work. 
right
> However, when it comes to filtering, is really the NAT64 the place to 
> perform any filtering.
that is a question, i guess
> Isn't it much simpler and requiring less state to be non-filtering 
> when it comes to mapping and let the receiving host deal with any 
> unwanted traffic?
>
the UDP req defined by behave states that:

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

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

so, i understood that we needed to support filtering

i am ok with dropping the filtering, but i think we would be not 
complying with the requirements

> lifetime to 5 minutes for UDP. What timer length where you considering 
the reccomended value by the behave requirements, that i think to recall 
is 2 hours
that is why is so criticial to have the nat to fully understand the full 
tcp estalishment exchange, cause creating this is state is expensive

we are planning to include this in the next version

> Have you made any considerations on what traffic directions that will 
yes
i am not sure if the last version of the draft has it though...

But the idea is to comply with the behave requriment

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

      a) The NAT mapping Refresh Direction MAY have a "NAT Inbound

         refresh behavior" of "True".

regards, marcelo

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 26 Jul 2008 11:09:58 +0100

> Addresses and ports and a completely different story, as you say

Okay, I think that needs to be clarified. Becuase NAT64 clearly is not
stateless.

> there is no problme with doing that, just cumbersome
I am hoping that you will have a document that you can reference for the
translation of these protocols. For both DCCP and SCTP BEHAVE has
milestones and candidate WG documents. So I hope you will be able to use
references here.

> complying with the requirements

This says it is recommended for an IPv4 to IPv4 NAT. That has a long
time been sold as a security device due to its filtering behavior. For a
IPv6 to IPv4 translator the need for such filtering is much less clear.
That is why I brought this up for discussion. One has to consider what
keeps the binding alive and in what directions. Which isn't clear at all.

> we are planning to include this in the next version

Okay, I think this is something we will have more discussion around when
we have cleared out the main questions on how the translator should
work. Just because if affects the amount of state and its DoS ability.

>         refresh behavior" of "True".

Okay, so the initiator will need to send traffic to keep the binding 
alive. One can ask one self how much does going to both direction affect 
the DoS ability of the translator, if at all. Otherwise by not using 
both direction you will affect some applications that needs to send 
traffic for keep-alive that they otherwise wouldn't have.

Cheers

Magnus Westerlund

---

From: Philip Matthews <[email-masked]>
Date: Sat, 26 Jul 2008 11:28:08 -0400

On Sat, 26-Jul-08, at 06:09 , Magnus Westerlund wrote:
>>> translation process being like SIIT. To me it seems not to fulfill  
>>> the one to one mapping that SIIT does and not touching ports. So I  
>>> think you are much more in the region of doing things similar to a  
>>> IPv4-IPv4 NAT with the IPv6 being the private side. You will have  
>>> to deal with all the gory details of transport protocol  
>>> translations and their affect on ICMP.
>> right
>> what we meant is that the fields other than the address and the  
>> ports are translated using SIIT

We choose to reference the SIIT RFC because that RFC specifies all the  
details for how the IP header and ICMP header translation is done. It  
seemed better to reference SIIT than repeat the information in the  
draft.

>
>
>>>
>>> I am at least one that think when specifying these devices also  
>>> should include support for our newer transport protocols.  
>>> Especially as there is relatively little that blocks them in the  
>>> IPv6 world compared to IPv4. And if initiating from IPv6 then you  
>>> can expect most servers to have public IPv4 address that may  
>>> actually be reachable over DCCP or SCTP. So not specifying how to  
>>> handle these protocols will be simply one more roadblock against  
>>> there usage and a better future.
>> no problem with that
>> the question is whether you think we need to specify this in the  
>> same document or in differnet ones
>> I mean, this idea for any connection oriented protocol is that need  
>> to deal with all the details of the protocol, so the spec is likely  
>> to be complex. I mean, for instance, for TCP, we want to create a  
>> binding only when the connection has been successfully estbalished,  
>> and that bascially means to re state the TCP state machine, but  
>> from the perspective of a middle box. The same would apply to DCCP  
>> and SCTP. there is no problme with doing that, just cumbersome

Indeed, there are a number of details which have not been specified  
and which should be added, either in our original document or in some  
follow-on document. As well as DCCP and SCTP, we have also not  
discussed multicast for example.

>>> However, when it comes to filtering, is really the NAT64 the place  
>>> to perform any filtering.

I think that some operators will want filtering, but I agree the issue  
is not well understood.

>
>
>>> Then there is the mapping lifetime question. You specify the  
>>> maximum lifetime to 5 minutes for UDP. What timer length where you  
>>> considering for TCP?
>>>
>> the reccomended value by the behave requirements, that i think to  
>> recall is 2 hours
>> that is why is so criticial to have the nat to fully understand the  
>> full tcp estalishment exchange, cause creating this is state is  
>> expensive
>>> Have you made any considerations on what traffic directions that  
>>> will keep the timer alive?
>>>
>> yes
> alive. One can ask one self how much does going to both direction  
> affect the DoS ability of the translator, if at all. Otherwise by  
> not using both direction you will affect some applications that  
> needs to send traffic for keep-alive that they otherwise wouldn't  
> have.

My view when contributing to the design of NAT64 was that each  
endpoint was running ICE not knowing what NATs existed between them.  
That is, there might be a NAT64 but there might also be one or more  
NAT44s. So I felt that a NAT64 should mimic a NAT44 as close a possible.

- Philip