Subject: [MMUSIC] Does ICE-TCP work only with relayed candidates across a Linux NAT?

From: "Craig, Dave" <[email-masked]>
Date: Fri, 13 Jun 2008 15:57:29 -0700

I failed in a few tests to try to get a reflexive candidate to work
across a Linux NAT.  On closer inspection, I noticed that the latest
Linux NAT code tracks the full 5-tuple (IP source, destination,
protocol, TCP source & destination port), connection state, and sequence
numbers.  Is there any way that the reflexive candidates can work with
this kind of NAT?

Let's assume that the controlling host is behind one of these NATs.

1. The controlling host obtains the server reflexive candidate, say A:a
for IP address:port.  The NAT records that there is an active TCP
connection between the addresses and ports of the controlling host and
the STUN server (A:a -> S:s) as well as the sequence numbers in either
direction.

2. The controlling host forwards an INVITE with the server reflexive
candidate among its other candidates to the controlled host containing
the address and port the NAT allocated.

3. The controlled host repeats step 1 for itself and forwards an INVITE
with its candidates back to the controlling host.

4. The controlled host attempts to connect to the IP address and port
that the NAT in front of the controlling node allocated for its
connection to the TURN server (B:b -> A:a).
 
5. The NAT looks up the NAT state using B:b -> A:a which does not match
A:a -> S:s, so it drops the packet.

If in step 4, the controlled host predicted the address and port the NAT
would assign to a SYN sent by the controlling host, step 5 still fails.
The NAT expects to see SYNACK rather than SYN, so it drops the
controlled host's SYN packet.

Thanks,
	Dave
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic