Subject: [BEHAVE] should nat64 keep track of TCP seq numbers?

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 09 Jul 2009 16:29:47 +0200

Hi,

I am working on the TCP part of NAT64.

TCP binding are certainly expensive. The default lifetime recommended by 
RFC5382 are 2 hours and 4 min, so we want to be sure that a TCP 
connection exists in order to set up a binding. So, in order to do that, 
we need to track the TCP connection establishment and closure.

So, this begs the question of how much we need to track.

Let's consider the connection establishment.
One option would be for the NAT64 to track a SYN on one direction, a SYN 
in the other direction and once it has seen both of them it sets up the 
binding.
Another option is to track the full 3 way exchange with the seq number 
and check that the ACK for SYNs has been exchanged. In order to do that, 
the NAT64 needs to store the seq numbers of the SYN packets. (this 
doesn't imply that it needs to track the rest of the seq of data packets 
once that the binding has been set up.)

A similar discussion would apply to the FINs, only that it may have a 
bit more of details that we should look at.

So, a first question would be: do we keep track of seq numbers and acks 
in the tcp connection establishment of simply keeping track of the SYN 
flying in both directions is enough?

Thanks, marcelo

---

From: 郭大勇 <[email-masked]>
Date: Fri, 10 Jul 2009 10:01:14 +0800

Tracking TCP actions is heavy burden for NAT64 box. To lighten it,  the
aging-time of a flow may be used usually.
So it is enough to keep track of SYN flying.

Dayong Guo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
marcelo bagnulo braun
Sent: Thursday, July 09, 2009 10:30 PM
To: Behave WG
Subject: [BEHAVE] should nat64 keep track of TCP seq numbers?

Hi,

TCP binding are certainly expensive. The default lifetime recommended by
RFC5382 are 2 hours and 4 min, so we want to be sure that a TCP connection
exists in order to set up a binding. So, in order to do that, we need to
track the TCP connection establishment and closure.

Let's consider the connection establishment.
One option would be for the NAT64 to track a SYN on one direction, a SYN in
the other direction and once it has seen both of them it sets up the
binding.
Another option is to track the full 3 way exchange with the seq number and
check that the ACK for SYNs has been exchanged. In order to do that, the
NAT64 needs to store the seq numbers of the SYN packets. (this doesn't imply
that it needs to track the rest of the seq of data packets once that the
binding has been set up.)

A similar discussion would apply to the FINs, only that it may have a bit
more of details that we should look at.

So, a first question would be: do we keep track of seq numbers and acks in
the tcp connection establishment of simply keeping track of the SYN flying
in both directions is enough?

Thanks, marcelo

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 10 Jul 2009 10:15:10 +0300

> we need to track the TCP connection establishment and closure.

Tracking closure of a TCP connection is as easy as storing 2 bits: one for FIN 
packets in each direction.

> flying in both directions is enough?

You need just one bit for SYN-ACK, and it allows optimizing failed connections 
away. I do not see what sequence number tracking buys, unless the box also 
includes ALG functionality (changing size of packet payload requires sequence 
number tracking)?

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 10 Jul 2009 09:44:56 +0200

Rémi Denis-Courmont escribió:
> away. 

could you expand on this?

> I do not see what sequence number tracking buys, unless the box also

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 10 Jul 2009 11:06:50 +0300

On Friday 10 July 2009 10:44:56 ext marcelo bagnulo braun wrote:
> > Tracking closure of a TCP connection is as easy as storing 2 bits: one
> > for FIN packets in each direction.
> >
> > You need just one bit for SYN-ACK, and it allows optimizing failed
> > connections away.
>

The NAT can time out failed TCP connection requests (those without SYN/ACK) 
faster than established ones, so it _could_ be useful. To the contrary, 
tracking sequence number will not yield any option to time out TCP connection 
faster. Looking for FINs and RSTs packets is sufficient to detect dying 
connections, although it might cause some security problems (third party 
attacks against TCP sessions??).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 10 Jul 2009 10:30:34 +0200

On 10 jul 2009, at 10:06, Rémi Denis-Courmont wrote:

> Looking for FINs and RSTs packets is sufficient to detect dying
> connections

What can happen if you just remove state when both sends send a FIN is  
that if a packet before the FIN was lost the retransmission will not  
make it to the other side. That's not good.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 10 Jul 2009 04:46:15 -0400

Hello Marcelo,

I see two separate drivers for some of the things you mention: one is
resource consumption and the other is security.

My comments are based on a few NAT44 implementations I'm familiar. I'm not
suggesting any of these methods to be standardized but more to give you
feedback.

inline....

> bit more of details that we should look at.

Detecting the closing or reset of a connection is certainly very important
since NAT tables are expensive. A few methods I've seen (usually a 'grace'
timer is involved in all these methods before nuking):

* Only nuke the binding if you see a proper FINs or RST with proper seq
numbers. This is very security driven and common.

* Nuke binding if idle timeout has passed and no packets received. Also very
security driven. 

* Seeing FIN from just one side is enough. You run a timer and if no packets
are received you nuke the binding. This is resource driven and might not be
standard operating procedure.

* NAT box itself uses TCP keep alive packets to probe endpoints. If no
answer, nuke binding.

* There are others...

> flying in both directions is enough?

I guess the "enough" part put me off a bit.

My experience is that NATs actually perform basic seq/ack number checking
during connection establishment. This is usually due to security concerns
and the numbers can be discarded after connection/binding is established.
Now, whether NAT boxes will drop TCP packets if seq/acks do not match or
just log is another matter.

If security is not such a big concern and/or resource consumption is the
driver you can just keep track of SYN/SYN-ACK/ACK flying on both directions
as long as they are received forward and reverse 5-tuples that match.

As far as ALGs go, you might need to reorder (as in put in right order) TCP
segments and then full TCP tracking is needed. This is something discussed
in FTP64 which also applies to any other TCP ALGs.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 10 Jul 2009 11:41:17 +0200

> packets in each direction.
the problem is what if the FIN contained data and it is lost (after 
passing through the NAT64.
The option that i think may be reasonable would be to set a timer (4 min 
for instnace) after the second FIN, so that the NAT64 session state is 
removed after the timer expires.
this allows to have plenty of time for retransmitting the last FIN

(the other option would be to track the seq numbers of the FIN and make 
sure that the last FIN was properly ACKed. I think this may be an 
overkill and i think the previous proposal of the timer is a reasonable 
tradeoff)

> includes ALG functionality (changing size of packet payload requires sequence 

Sure, we can easily track SYN and SYN+ACK and aslo the SYN and SYN of 
simultaneous opening.
While this, the timeout would be short and once both SYNs have been seen 
by the NAT64 we would move to a longer timer.

I think this is a reasonable tradeoff

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 10 Jul 2009 11:45:07 +0200

> * NAT box itself uses TCP keep alive packets to probe endpoints. If no
I was thinking something in the lines Remy mentioned
If the NAT64 sees two FINs (one in each direction) it then starts a 
timer of let's say 4 min and then deletes the session.
It seems a middle ground option. Would that make sense to you?

> as long as they are received forward and reverse 5-tuples that match.

right, this is exaclty what i am asking... what do we do?

Regards, marcelo