Subject: [BEHAVE] NAT64 and TCP processing (was Re: Comments todraft-ietf-behave-v6v4-xlate-stateful-01.txt)

From: Reinaldo Penno <[email-masked]>
Date: Tue, 1 Sep 2009 14:47:55 -0400

Hello,

I read the paper reference by Dan below and the number of TCP connections
that end with TCP RST is significant.

> Martin Arlitt, Carey Williamson, "An Analysis of TCP Reset Behaviour on the
> Internet", October, 2004,
> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf

Also, there is this draft which is categorized as standards track and talks
about the many issues related to TCP window attacks and most of the
mitigations discussed require TCP sequence tracking.

http://www.ietf.org/id/draft-ietf-tcpm-tcpsecure-11.txt

The issues found here are not exclusive of NAT64, NAT44 would suffer the
same problems. But most NAT44 implementations today already track sequence
numbers whether due to security concerns or ALGs.

Thanks,

Reinaldo

On 7/15/09 12:34 PM, "Dan Wing" <[email-masked]> wrote:

> 
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
>> Sent: Wednesday, July 15, 2009 12:31 AM
>> To: Reinaldo Penno
>> Cc: Behave WG
>> Subject: Re: [BEHAVE] Comments
>> todraft-ietf-behave-v6v4-xlate-stateful-01.txt
>> 
>> Reinaldo Penno escribió:
>>> 
>>> On 7/14/09 9:30 AM, "marcelo bagnulo braun"
>> <[email-masked]> wrote:
>>> 
>>>  
>>>> Reinaldo Penno escribió:
>>>>    
>>>>> Hello,
>>>>> 
>>>>> we should include how to handle TCP RSTs as well. Host
>> implementations and
>>>>> NATs might remove the tcpb (or binding) as soon as a RST
>> is received (as
>>>>> long as seq number checking passes).
>>>>> 
>>>>>      
>>>> but that would imply to keep track of all the seq # for
>> all the data
>>>> packets for each of the flows....
>>>> I don't think i would like to go there.
>>>> 
>>>> In order to handle the RST packets, actually, i had
>> thought of that and
>>>> i included in the state machines, but it seems i forgot to
>> include in
>>>> the text...
>>>> 
>>>> I think a RST coming from the Internet part should be
>> ignored, cause as
>>>> you say may be an attack, but i think that if the rst
>> packet comes from
>>>> the network side (the network that runs the nat64) then it
>> should be
>>>> honnoured.
>>>>    
>>> 
>>> After the connection is established, and the v4 side sends
>> a RST to end the
>>> connection and we do not honor it we will have hanging TCP
>> bindings. This is
>>> exactly what we were trying to avoid by being diligent on following
>>> FINs/ACKs and having timeouts.
>> 
>> right, i guess the question is how often this happens.
> 
> Martin Arlitt, Carey Williamson, "An Analysis of TCP Reset Behaviour on the
> Internet", October, 2004,
> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf
> 
> -d
> 
>> I like Iljitshc suggestion of reducing the lifetime of the
>> binding when
>> a RST is seen, what do you think about that?
>> 
>>> A TCP connection ended by RST is reused pretty quickly and
>> the issue I see
>>> if we do not honor valid TCP RST it is that we can end up
>> reusing a old
>>> binding and all kinds of problems can exist.
>>>  
>> 
>> I fail to see any problem here. I mean, if the new connection
>> uses the
>> same 5 tuple, then the state can be reused wihtout problem and if it
>> doesn't, then a new binding will be created, what is the problem that
>> you see?
>>> On the other hand, spoofed TCP packets can end the
>> connection and there are
>>> specific seq checks needed (different from connecting state
>> from established
>>> state).
>>> 
>>>  
>> 
>> right, this is my concern
>> 
>>>> what do you think?
>>>>    
>>> 
>>>  
>>>>> Here, I think checking seq numbers is important for
>> security sake, specially
>>>>> in the case of TCP RSTs.
>>>>> 
>>>>> As far as ICMP response to unsolicited SYNs which we
>> discussed before I
>>>>> suggest the following amendment to your text
>>>>> 
>>>>> From
>>>>> 
>>>>> "      If the destination transport address contained in
>> the incoming V4
>>>>>       SYN 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"
>>>>> 
>>>>> To
>>>>> 
>>>>> "      If the destination transport address contained in
>> the incoming V4
>>>>>       SYN 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 unless REQ-4a of RFC5382
>> applies.  The state
>>>>>       remains unchanged in CLOSED"
>>>>> 
>>>>> 
>>>>>      
>>>> right
>>>> 
>>>> thanks, marcelo
>>>> 
>>>> 
>>>>    
>>>>> Thanks,
>>>>> 
>>>>> Reinaldo
>>>>> 
>>>>> 
>>>>> On 7/11/09 1:52 AM, "marcelo bagnulo braun"
>> <[email-masked]> wrote:
>>>>> 
>>>>> 
>>>>>      
>>>>>> Hi,
>>>>>> 
>>>>>> We have posted a new version of the NAT64 draft.
>>>>>> 
>>>>>> As discussed lately in the ml, we are using the FINs and
>> the SYNs to
>>>>>> close and establish the TCP session state in the NAT.
>>>>>> 
>>>>>> The document still needs quite some work, but if people
>> can take a quick
>>>>>> look and let us know if the overall direction is ok, it
>> would be great.
>>>>>> 
>>>>>> Thanks, marcelo
>>>>>> 
>>>>>> 
>>>>>> -------- Mensaje original --------
>>>>>> Asunto:         [BEHAVE] I-D
>>>>>> Action:draft-ietf-behave-v6v4-xlate-stateful-01.txt
>>>>>> Fecha:  Sat, 11 Jul 2009 01:45:01 -0700 (PDT)
>>>>>> De:     [email-masked]
>>>>>> Para:   [email-masked]
>>>>>> CC:     [email-masked]
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> A New Internet-Draft is available from the on-line
>> Internet-Drafts
>>>>>> directories.
>>>>>> This draft is a work item of the Behavior Engineering
>> for Hindrance
>>>>>> Avoidance
>>>>>> Working Group of the IETF.
>>>>>> 
>>>>>> 
>>>>>>         Title           : NAT64: Network Address and
>> Protocol Translation
>>>>>> from
>>>>>> IPv6 Clients to IPv4 Servers
>>>>>>         Author(s)       : M. Bagnulo, et al.
>>>>>>         Filename        :
>> draft-ietf-behave-v6v4-xlate-stateful-01.txt
>>>>>>         Pages           : 35
>>>>>>         Date            : 2009-07-11
>>>>>> 
>>>>>> NAT64 is a mechanism for translating IPv6 packets to
>> IPv4 packets and
>>>>>> vice-versa.  DNS64 is a mechanism for synthesizing AAAA
>> records from
>>>>>> A records.  These two mechanisms together enable client-server
>>>>>> communication between an IPv6-only client and an
>> IPv4-only server,
>>>>>> without requiring any changes to either the IPv6 or the
>> IPv4 node,
>>>>>> for the class of applications that work through NATs.  They also
>>>>>> enable peer-to-peer communication between an IPv4 and an
>> IPv6 node,
>>>>>> where the communication can be initiated by either end using
>>>>>> existing, NAT-traversing, peer-to-peer communication techniques.
>>>>>> This document specifies NAT64, and gives suggestions on how they
>>>>>> should be deployed.
>>>>>> 
>>>>>> A URL for this Internet-Draft is:
>>>>>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xla
>> te-stateful-01
>>>>>> .t
>>>>>> xt
>>>>>> 
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>> 
>>>>>> Below is the data which will enable a MIME compliant mail reader
>>>>>> implementation to automatically retrieve the ASCII version of the
>>>>>> Internet-Draft.
>>>>>> 
>>>>>> 
>>>>>>   
>>>>>>        
>>>>> 
>>>>>      
>>> 
>>> 
>>>  
>> 
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Zhen Cao <[email-masked]>
Date: Thu, 3 Sep 2009 22:01:02 +0800

Hi Reinaldo,

The issue you raise here is interesting. As you said, the NAT44
implementation already track TCP seq number. Is it mandated in the
NAT44 standard documents?

Thanks,
Zhen

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 3 Sep 2009 13:43:47 -0400

No, in general the area where TCP, NAT44 and security intersect is very
light on standards.

There are comments in BEHAVE NAT TCP (NAT Session Refresh section) about how
a NAT can detect if a connection is still alive by sending TCP keep alive
packets (which require some seq/ack tracking).

I would venture to say TCP tracking is probably the de facto standard due to
ALGs, security and others, but it is something tricky to standardize. NAT64
current draft relies on a series of timers.

I wanted to bring this issue forth again after I read the references since
there was some doubt regarding attacks, percentage of connections that end
'nicely', other standards within IETF, etc.

Whatever method(s) we go with NAT64, the security and performance
implications need to be well-understood.

Thanks,

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Sep 2009 19:08:58 -0700

> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Thursday, September 03, 2009 10:44 AM
> To: Zhen Cao
> Cc: Dan Wing; marcelo bagnulo braun; Behave WG
> Subject: Re: [BEHAVE] NAT64 and TCP processing (was Re: 
> Comments todraft-ietf-behave-v6v4-xlate-stateful-01.txt)
> 
> ALGs, security and others, but it is something tricky to 
> standardize. 

BEHAVE's published RFCs related to NAT44 did not attempt to
define new behavior, as it was regarded as pointless to do
so:  NATs exist, they do what they do, and so on.

For new things, such as stateful IPv6/IPv4 translation, we
are ahead of the curve.  There are not millions of IPv6/IPv4
translators deployed on the Internet.

> NAT64

Agreed.  

I hope we can continue a discussion regarding the tradeoffs and
incorporate the discussion into the document so that implementors
receive useful guidance from the peer review of the IETF standards
process!  :-)

-d

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Sep 2009 13:41:56 -0300

> No, in general the area where TCP, NAT44 and security intersect is very

See the (currently expired) draft-gont-tcp-security I-D.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1