Subject: [BEHAVE] Analysis of 64 Translation

From: Reinaldo Penno <[email-masked]>
Date: Wed, 16 Dec 2009 00:41:47 -0500

Hello,

We submitted a new draft with the purpose to analyze the 64 stateful
solution and foster a structured discussion around the benefits of the
solution.

Thanks,

Reinaldo

http://www.ietf.org/id/draft-penno-behave-64-analysis-00.txt

From: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Subject: I-D Action:draft-penno-behave-64-analysis-00.txt
X-RSN: 1/0/935/27926/31280
X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=31280
 
A New Internet-Draft is available from the on-line Internet-Drafts
directories. 
 
Title : Analysis of 64 Translation
Author(s) : R. Penno, et al.
Filename : draft-penno-behave-64-analysis-00.txt
Pages : 10 
Date : 2009-12-15 
 
Due to specific problems, NAT-PT was deprecated by the IETF as a
mechanism to perform IPv6/IPv4 translation. Since then, new work has
commenced which standardizes new mechanisms to perform IPv6/IPv4
translation. This document evaluates how the new translation
mechanisms avoid the problems that caused the IETF to deprecate
NAT-PT. 
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-penno-behave-64-analysis-00.txt
 
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.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 16 Dec 2009 04:49:23 -0500

Hello,

The current draft states that:

"   If a packet other than a RST packet is received, the lifetime is set
   to at least 2 hours and 4 min and the state is moved to ESTABLISHED.

   If the lifetime expires, the session table entry is deleted and the
   state is moved to CLOSED.
"

Let's suppose B in the IPv4 world sends a RST to A in IPv6 and we move into
a RST RCV state. 

If after that you only receive packets in the  B->A direction, should the
session be kept open? Wouldn't that be an indication that A accepted the RST
and/or in general is not in the picture anymore?

Finally it says ' If a packet other than a RST packet is received". If B
sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the
connection open? 

This is my understanding of TCP RST processing:

If host B sends a RST that is accepted by A, any other packets after that
would not get processed by A. All of TCP control state is removed as soon as
the TCP RST is accepted.

And if the RST is not accepted by A, this was B's original intention so it
will not be sending any more packets after that.

NAT behavior:

Therefore, for a NAT device without keep-alives that cannot make an
assessment whether the TCP RST was accepted or not, keeping the connection
open if any packet gets received does not seem to serve a purpose.

I would suggest the following:

"   
   If the lifetime expires, the session table entry is deleted and the
   state is moved to CLOSED.
"

In other words, we remove the session entry after 4 minutes.

Thanks,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 16 Dec 2009 14:21:01 +0100

> and/or in general is not in the picture anymore?

Yes, it would keep the session open.
Similarly, if a delayed packet hits the nat64 after the RST, it will 
move back to established.

We discuss this at large in stockholm. this is an optimization, to 
reduce the amount of state in the nat64, so we decided to keep it simple 
and be overly conservative about dropping useful state.

> sends a TCP RST and then sends, say, a SYN, FIN, ACK, should we keep the
yes, but we can limit it to data segments and we could limit it packet 
flying from the end the received the RST. I don't have a problem with 
that neither.

> will not be sending any more packets after that.
but the other scenario is that an attacker sent the RST to drop the 
connection
Morevoer, that the receiving node have made some validation of the seq 
number and decided not to accept the RST
But thsi is still not standarized (i.e. how the node should behave) so 
we wanted to not to try to guess what the node will do. So we keep the 
stare unless we have a very clear signal that the RST was accepted i.e. 
no more packets.
I mean, if a node send a RST and the other accepts it, there shoudln't 
be no more packets in either direction, right?

> assessment whether the TCP RST was accepted or not,
exactly

>  keeping the connection
but the consluion is exactly the opostive. Since the nat64 cannot guess, 
we need to keep the state in case the node still has the connection 
open, right?

>    state is moved to CLOSED.
This is the text that is already in the draft afaict, not sure what is 
your suggestion here.

Regards,marcelo

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

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 16 Dec 2009 12:21:43 -0500

My suggestion is to be conservative but also optimize for the common case
(RST are valid). In other words, we start the 4 minute timer and only move
back to establish if we see packets on _both_ directions.

Otherwise, if the premise is that the common case pertain to attacks and we
keep the connection open, then we are wasting resources and leaving
ourselves open to starvation since the attacker can send RST followed by
ACKs.

"   If packets other than a RST packet are received from both directions,
the lifetime is set to at least 2 hours and 4 min and the state is moved to
ESTABLISHED."

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 17 Dec 2009 08:59:06 -0500

That is fine. I checked version 07 and that is not captured in the spec yet.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Dec 2009 16:09:56 +0100

>> flying from the end the received the RST. I don't have a problem with
In the interim meeting yesterday, the feedback that the WG provided was 
against this and that they would rather to keep it as it is.
Hence, i have not changed that.

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 17 Dec 2009 10:13:37 -0500

Thanks,

What was the reason given?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Dec 2009 16:28:05 +0100

> What was the reason given?

What i understood was that the NAT64 should try to minimize as much as 
possible to second guess what is going on, so, being more conservative 
is better and in particular in this issue, that is not critical for 
interop, just an optimization for the nat behaviour

not sure if i missed some of other argument

Regards, marcelo