Subject: [BEHAVE] Open issues with NAT64 v05

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

This is a complies list of open issues that have been brought up during 
the last discussions.

We can go through the list today in the interim.

Open issues with statefull nat64 v05

-- Address-dependent filtering of ICMP queries.
I have tried to reflect the concept of address dependent mapping for the 
ICMP queries. I am not sure if this makes to much sense or if it is 
worth the trouble. See section 3.2.3.  ICMP Query Session Handling
See 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.3

-- What to do with non expected TCP msgs in states other than ESTABLISHED.
The question is what to do with TCP segments of a given connection that 
is not what is expected by the state machine. In particular, what do we 
do with TCP data segments that the NAT64 has information to process i.e. 
a valid BIN entry) but do not correspond to any active connection. 
similar question applies to a duplicated SYN packet and so on. The 
current draft states that the NAT64 may forward of discard the packet, 
but certianly it must not create a session if the 3 way handshake is not 
performed properly. Would that make sense?
See the text in section 3.2.2.  TCP Session Handling in the CLOSED 
state, and others.
See 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.2

-- Address-Dependent filtering for TCP and simultaneous open
How to implement Address Dependent filtering and support simultaneous 
opens is tricky. I would appreciate if someone could take a look. In 
particular, there is the question of whether we drop the incoming V4 SYN 
or we store it. And if we store it, whether we use it only for the ICMP 
error, or we do forward it when the V6 SYN arrives.
Please take a look at page 23, how a V4 SYN is handled in CLOSED state 
of section 3.2.2.  TCP Session Handling
See 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.2

--Port allocation for TCP follows the same rules than for UDP?
We are using the rules for port allocation following the recommendation 
of RFC4787. TCP does not have the same rules (they are much more relaxed).
the current draft uses the same rules for both. Should we drop these 
rules for TCP?
See:3.2.4.  Rules for allocation of IPv4 transport addresses
See 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-05#section-3.2.4

-- 10 secs timer for waiting for fragments
In order to quantify this we need to understand how long may it take to 
receive a full packet over a slow link.
So, if we have 64KB of data, with 10 secs, the bandwidth we are assuming 
as minimum is 51 kbps
If we move to 2 secs as was suggested, the minimum bandwidth we are 
assuming is 256 kbps
The other issue related to this is whether it is possible to send 64KB 
long UDP packets. In a link with a 1500B MTU, this would result in 42 
packets and with a packet loss of 1%, half of the UDP segments will 
loose one segment, so maybe this is not feasible in any case.

-- Handling of RST packets.
Proposal to stsy in RST RCV unless we receive a data segment from the 
side that received the RST pkt.
Currently we move away from the RST RCV state upon the reception of any 
packet from any side.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Dec 2009 15:34:08 +0100

On 16 dec 2009, at 14:51, marcelo bagnulo braun wrote:

> similar question applies to a duplicated SYN packet and so on.

Duplicate SYNs can easily happen when a packet is lost in the path between the translator and the receiver. (Packets can also get duplicated easily on wifi when the actual packet was received correctly but the ACK was lost.) So duplicates must be allowed through.

> How to implement Address Dependent filtering and support simultaneous opens is tricky. I would appreciate if someone could take a look. In particular, there is the question of whether we drop the incoming V4 SYN or we store it.

I would hesitate to store packets coming in from the v4 side because that is where attackers will be as there is no relationship between the v4 users and the translator, but there is a relationship between the v6 users and the translator.

> In order to quantify this we need to understand how long may it take to receive a full packet over a slow link.
> So, if we have 64KB of data, with 10 secs, the bandwidth we are assuming as minimum is 51 kbps
> If we move to 2 secs as was suggested, the minimum bandwidth we are assuming is 256 kbps
> The other issue related to this is whether it is possible to send 64KB long UDP packets. In a link with a 1500B MTU, this would result in 42 packets and with a packet loss of 1%, half of the UDP segments will loose one segment, so maybe this is not feasible in any case.

Indeed. In theory 64k UDP packets are valid, in practice they don't happen. I think the largest real-world UDP packets are 4k EDNS0 DNS packets and even those are rare. Worst case 4k in 2 seconds is about 16 kbps, which seems fairly reasonable.

> Proposal to stsy in RST RCV unless we receive a data segment from the side that received the RST pkt.
> Currently we move away from the RST RCV state upon the reception of any packet from any side.

Both should work, I would go with what's simplest here.