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

From: "Craig, Dave" <[email-masked]>
Date: Mon, 23 Jun 2008 11:07:47 -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

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

---

From: "Saikat Guha" <[email-masked]>
Date: Mon, 23 Jun 2008 22:24:41 +0200

On Mon, Jun 23, 2008 at 8:07 PM, Craig, Dave <[email-masked]> wrote:
> Is there any way
> that the reflexive candidates can work with this kind of NAT?
[...]
> 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).

If I understand your setup correctly, both ends need to attempt to
connect to the other at the same time. What should happen is that
there is a SYN from B:b->A:a, and a SYN from A:a->B:b, one of which
would get dropped by the opposing NAT while the other SYN gets across.

> 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.

In this scenario are both ends sending the SYNs?

-- 
Saikat

---

From: "Craig, Dave" <[email-masked]>
Date: Mon, 23 Jun 2008 13:47:24 -0700

If the Linux NATs in the middle only allow a SYNACK response to the SYN they translated, how would the mapping setup by one SYN let another in?

Private Net 1 <-> NAT 1 <-> Internet <-> NAT 2 <-> Private Net 2

A SYN originating from Private Net 1 leaves a mapping only for a SYNACK.  Likewise, a SYN originating from Private Net 2 leaves only a mapping for a SYNACK.  Both of these SYN packets get dropped when they reach the other Private Net's NAT because they have the wrong flags.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Saikat Guha
Sent: Monday, June 23, 2008 1:25 PM
To: Craig, Dave
Cc: [email-masked]
Subject: Re: [BEHAVE] Does ICE-TCP work only with relayed candidates across a Linux NAT?

...

...

---

From: "Saikat Guha" <[email-masked]>
Date: Mon, 23 Jun 2008 23:10:49 +0200

> A SYN originating from Private Net 1 leaves a mapping only for a SYNACK.  Likewise, a SYN originating from Private Net 2 leaves only a mapping for a SYNACK.  Both of these SYN packets get dropped w…

If that is indeed the case, that sounds broken ... the iptables
masquerade target from a few years ago used to support TCP sim. open.
I assume you checked there aren't any bad firewalls rules active.
Would you mind running the NAT Testing Software on
http://nutss.gforge.cis.cornell.edu/stunt.php and comparing your
result to http://www.guha.cc/saikat/stunt-results.php? result #258.

cheers,

---

From: Philip Matthews <[email-masked]>
Date: Tue, 24 Jun 2008 12:12:37 -0400

Just a quick comment  that ICE-TCP is in an uncertain state right now,  
as its success rate is rather low (around 40%) and the MMUSIC WG has  
not decided what it wants to do about this.

- Philip

On Mon, 23-Jun-08, at 14:07 , Craig, Dave wrote:

> 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?
>
> 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.
>
> 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  
> 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
>