Subject: RE: [Ietf-behave] updated

From: [email-masked]
Date: Mon, 26 Jun 2006 07:39:48 -0700 (PDT)

Just out of curiosity, can anyone provide me with a reference to a NAT that 
behaves in a way that requires this relay service?  A freely available NAT 
implementation that does this would be great if such a thing exists...

Thanks,
FM

------------------------------------------------
On Mon, 26 Jun 2006 02:38:30 -0700, "Rohan Mahy" <rohan.mahy@xxxxxxxxx> wrote:

> Hi Folks,
> 
> I just submitted a significant revision of TURN.  Until it appears in
> the archive, you can find it here:
> 
> http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.txt
> http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.html
> 
> While there are some major changes, the draft still has several open
> issues and will need another heavy editing pass. The highlights:
> 
> 1) Disallowed relaying UDP between the client and server to TCP
> between the server and the peer.
> 
> 2) Added lightweight TCP framing and simplified rules for wrapping UDP
> with a magic cookie in Data or Send indiciations.
> 
> 3) Removed the Connect Request.  This did not make sense.  If the peer
> could accept an inbound TCP connection, the client could probably just
> open its connection directly to the peer.
> 
> 4) Reintroduced the concept of a door.  The TURN server will accept a
> connection to the door once, establishes a binding, an then no further
> requests are allowed unless there is an explicit permission.
> 
> 5) Added Connection Status Indication, so you can tell if the TCP
> connection from the relay to the peer dies.
> 
> 6) Added ability to move/refresh your allocation to a new source address/port.
> 
> 7) Hopefully clearer Overview section.
> 
> 8) Added more motivation for odd/even port alignment
> 
> 9) Got rid of DESTINATION-ADDRESS.  REMOTE-ADDRESS is now used in its place.
> 
> 10) Use XOR-MAPPED-ADDRESS consistently instead of MAPPED-ADDRESS
> 
> 11) I added explicit Open Binding and Close Binding requests for completeness
> 
> Selected OPEN ISSUES:
> A) Can we get rid of the state machine for Set Active Destination?
> (See proposal in the draft)
> 
> B) Do we want Open/Close Binding?
> 
> C) Is it OK if clients have to use STUN messages to keep allocations
> alive?  (Data used to keep them alive).
> 
> 
> ok, enough for now.
> 
> thanks,
> -rohan
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Jun 2006 10:39:55 -0700 (PDT)

> Just out of curiosity, can anyone provide me with a reference 
> to a NAT that behaves in a way that requires this relay 
> service?  A freely available NAT implementation that does 
> this would be great if such a thing exists...

See the analysis at
http://www.watersprings.org/pub/id/draft-jennings-behave-test-results-01.txt
which includes test results showing NATs that are symmetric.  TURN, or some
other kind of media relay, would be necessary if two hosts behind symmetric
NATs want to communicate with each other.

-d

---

From: Saikat Guha <[email-masked]>
Date: Mon, 26 Jun 2006 13:58:33 -0700 (PDT)

> NATs want to communicate with each other.

The TCP list is at https://nutss.net/stunt-results.php ; the NATs with
non-Independent binding type would need TURN in many cases.

If you are looking for free implementations to toy with, OpenBSD's pf is
one such NAT.

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Jun 2006 14:03:01 -0700 (PDT)

> > other kind of media relay, would be necessary if two hosts 
> > behind symmetric NATs want to communicate with each other.
> 

With ICE-08, _both_ NATs would need to be non-Independent to need TURN,
correct?

-d

> If you are looking for free implementations to toy with, 
> OpenBSD's pf is one such NAT.
> 
> cheers,
> -- 
> Saikat
>

---

From: Saikat Guha <[email-masked]>
Date: Mon, 26 Jun 2006 15:09:21 -0700 (PDT)

On Mon, 2006-06-26 at 14:02 -0700, Dan Wing wrote:
> > the NATs with

I don't remember all of ICE-08, but I think that direct connections will
still succeed with one non-independent-mapping as long as the other has
address-dependent filtering or some such. If both are non-Independent,
then you almost certainly need TURN (unless you want to risk
port-prediction). For TCP, you may additionally require S-O support on
one of them. There are a whole bunch of these corner cases where certain
pairings will necessitate TURN, especially, as you mentioned, when both
are non-Independent.

-- 
Saikat
Attachment:
signature.asc

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Jun 2006 15:18:04 -0700 (PDT)

> > With ICE-08, _both_ NATs would need to be non-Independent 
> > to need TURN, correct?
> 
> I don't remember all of ICE-08,

Sorry, I should have been more precise.  I was referring to 
section 7.10 of ICE-08, "Learning New Candidates from Connectivity 
Checks".

-d

> But I think that direct connections will still succeed with one
> non-independent-mapping as long as the other has address-dependent
> filtering or some such.  If both are non-Independent, then you
> almost certainly need TURN (unless you want to risk
> port-prediction).  For TCP, you may additionally require S-O support
> on one of them.  There are a whole bunch of these corner cases where
> certain pairings will necessitate TURN, especially, as you
> mentioned, when both are non-Independent.
> 
> -- 
> Saikat
>

---

From: Philip Matthews <[email-masked]>
Date: Tue, 27 Jun 2006 14:39:40 -0700 (PDT)

On 26-Jun-06, at 18:18 , Dan Wing wrote:

the NATs with
It depends on the exact network configuration (of course).

If L and R are behind separate NATs which connect directly to the  
Internet,
both NATs have just one public address,
and both phones are configured to use a STUN server in the Internet,
then L's NAT can be endpoint-independent mapping, address-dependent  
filtering,
and R's can be address-and-port-dependent mapping and address-
and-port-dependent  filtering.

(L sends a binding-request to R's server-reflexive candidate, which  
get dropped,
but installs a filtering entry. R then sends a binding-request to L's  
server-reflexive  candidate,
which gets through because of the previously installed filtering entry.
This allows L to learn  R's peer-reflexive candidate, which is  
paired  with
L's server-reflexive candidate to form the working candidate pair).

If L's NAT has address-dependent mapping, or if R's NAT assigns a  
different IP
addresses to the server-reflexive candidate and the peer-reflexive  
candidate,
then this doesn't work and a TURN server is pretty much required.

- Philip