"Simultaneous open of TCP connections" is not supported. #58

Closed
ydahhrk opened this Issue May 27, 2013 · 5 comments

Projects

None yet

2 participants

@ydahhrk
Member
ydahhrk commented May 27, 2013

The NAT64 should store IPv4-TCP packets for which there's no state for a while.
This is explained in RFC 6146 page 28.

@ydahhrk ydahhrk was assigned May 27, 2013
@cetex
cetex commented May 18, 2014

What's are the implications of this being missing? / What's the reason for the need to fix this? :)
Can't you open multiple tcp sessions through jool simultaneously now?

@cetex
cetex commented May 18, 2014

Correcting myself here. :)
I read this: http://tools.ietf.org/html/rfc6146#page-28
and this: http://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html
TLDR: If an outside host connects to the gateway-ip(v4)
src port 1, dst port 2
At the same time as the inside-host connects to the same outside host from
src port 2, dst port 1
The connection should succeed and result in one less roundtrip needed for tcp.
(chances are very very slim of this occuring in real life)

Thanks for making me learn something new! ;)

@ydahhrk
Member
ydahhrk commented May 19, 2014

Lol. Still, I admit I could have been more wordy.

I case someone else wants a summary:

"Simultaneous open of TCP connections" is when all of the following conditions are met:

Two endpoints

  • Try to open a connection (send SYN packets),
  • a TCP connection,
  • the same connection (same addresses and ports, and at each other),
  • at the same time.

As cetex mentioned, this happens very rarely. I far as I know, there is no reason why anyone would actually actively want this to happen (even as an attack, AFAIK); it's simply a sporadic phenomenon TCP is supposed to handle gracefully. Also, it doesn't affect other connections at all.

Instead of doing what the RFC wants, Jool simply drops the IPv4 connection attempt. Jool will not crash, but what happens at the endpoints is somewhat implementation specific. In the worst case, they will simply have to reattempt the connection.

This is currently being worked at https://github.com/NICMx/NAT64/tree/tcp_store_packet, but it's on temporary hiatus and not part of the current planned milestones.

Update 2014-06-25: This is currently being worked at https://github.com/NICMx/NAT64/tree/issue58.

@ydahhrk ydahhrk added this to the 3.2.0 milestone Jun 24, 2014
@ydahhrk
Member
ydahhrk commented Jun 25, 2014

Another update:

My understanding of the consequences of the current implementation have changed.

This is what the RFC wants us to do:

If Jool receives a IPv4-TCP connection request, the packet should be stored.

  1. If no IPv6-TCP packet connection request is received after 6 seconds, the IPv4 node should receive a ICMP Destination Unreachable error (because there is no Simultaneous Open) containing the stored packet.
  2. If the IPv6 packet is received, there is a Simultaneous Open, so it should be forwarded normally and the stored packet discarded so the handshake can do its job.

This is what Jool currently does:

If Jool receives a IPv4-TCP connection request, the packet is discarded.

  1. If no IPv6-TCP packet connection request is received after 6 seconds, nothing happens, so the IPv4 node gives up after a while.
  2. If the IPv6 packet is received, it is forwarded normally and the handshake does its job.

Because the end result is the same in both second bullets, it just so happens that Jool has supported Simultaneous Open of TCP connections all along. What it does poorly is is let IPv4 nodes know that their TCP connections cannot be made when there is no Simultaneous Open...

@ydahhrk ydahhrk self-assigned this Jun 27, 2014
@ydahhrk ydahhrk modified the milestone: 3.2.0, 3.1.6 Aug 15, 2014
@ydahhrk ydahhrk modified the milestone: 3.1.6, 3.2.0 Sep 3, 2014
@ydahhrk
Member
ydahhrk commented Sep 4, 2014

This was fixed and the changes were merged into the master branch; Closing.

@ydahhrk ydahhrk closed this Sep 4, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment