Would this TCP splicing technique work?

I think if you can get the level of cooperation between the two NATs and the broker, it would work, but I think there's a security hole in here:

In steps 9 and 10 (and requirement 3), you require that the Source machine allow the 'far' end of the tcp connection to change based on the arrival of a syn packet from another machine, without any apparent means for authenticating the two. Using the 'broker' machine to pass data back and forth transparently would work, but I'm not sure that's what you want.

All in and all, it's a neat idea, but I think that given the level of access/cooperation you' d have to have with your NAT arrangement in the first place that you might be better served setting up a port-forward from the NAT device's live ip to your internal ip for a specific, prearranged port (on both sides).

No, steps 9 and 10 and requirement 3 cause the NATs destination IP to change on the basis of a SYN packet coming from inside the NAT. Basically, the call sequence of the non-broker program looks like this:

s = socket(PF_INET, SOCK_STREAM, PF_UNSPEC);
bind(s, 0.0.0.0, port);
ret = connect(s, broker_ip, size);
assert(ret != 0);
other_ip = getOtherIPFromBroker(brokerfd);
ret = connect(s, other_ip, size);
assert(ret == 0);

The second connect causes a different SYN to be sent out to other_ip from the same IP and port as the SYN to broker_ip was originally sent from. The requirements require that the NAT hold open the same outgoing port for the same source IP and port, like they do now for UDP, and change the destination IP based on where the SYN packets are being sent to.

The intenet is to allow peer-to-peer services to connect even if they're behind NATs. A cooperating broker is not inconcievable in these cases.

Blech, it's morning and I somehow glossed over the contents of steps 7 and 8. Whoops. So, yes, you're fine authentication-wise there. :)

The pseudo-code for the call sequence helps, and it makes sense for what you're trying to accomplish. I'm trying to think of a better way to go about it, but it looks like my initial thoughts are that this is a fairly sensible way to do it.

The amount of to and fro traffic is going to make connections between distant nodes very expensive. It's better if you can mark the initial packet as NAT-preferred, and the reply to optionally contain the necessary information. This way latency is not much impinged by your changes.

Why is latency an issue? HTTP 1.0 connections from where I live (Australia) to the less well connected portions of Europe can cause grief. ping times of over 700 ms or more are typical. For future space- based IP sessions, any thought of 8 light minutes per AU for each one of these steps is not going to work. Think about how you can remove the steps to the barest minimum, whilst still achieving your goal.

The problem really needs sorting out in the IPv6 world with AH packet authentication.

There are security reasons for forcing the use of a single IP address or a pool of addresses to appear for any number of internal hosts. This doesn't change by going to IPv6, and in fact, due to AH, IPv6 is actually a retrograde step for sites relying on information hiding.

You also need to deal with load balancing devices that work by ever so slightly breaking IP to redistribute load. They are unfortunately with us now, for the largest sites in the world cannot cope without them.

> The problem really needs sorting out in the IPv6 world with AH packet > authentication.

NAT is in fact violating the RFCs, even in the current IPv4 world.

> There are security reasons for forcing the use of a single IP address > or a pool of addresses to appear for any number of internal hosts. > This doesn't change by going to IPv6, and in fact, due to AH, IPv6 is > actually a retrograde step for sites relying on information hiding.

There are better ways for this than using NAT. Remember, in an IPv6 world, you will have more IP adresses for one local net than the complete Internet has today. One possible way to hide your internal information would be to add and delete IP aliases for each connection. This way you could still use authenticated P2P connection with AH and still don't provide any valuable information to the outside (the IP adress won't work after the connection has been shut down).

--jochen