Subject: [Ietf-behave] UDP/TCP in STUN-relay

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 23 Mar 2006 16:58:57 -0800 (PST)

There is one case I do not really understand with STUN-relay.

Let say that the STUN client sends an AllocateRequest over UDP, with a
REQUESTED-TRANSPORT of TCP. How the STUN-relay server knows what framing
 to use to relay the data received on the allocated TCP transport to the
UDP linkage (see 12.1.1)?

Thanks.

---

From: [email-masked]
Date: Fri, 24 Mar 2006 00:29:45 -0800 (PST)

AFAIK, this is not handled by the draft, but do we need to support this
use case? One of the main motivations for cross-protol tuneling was to use
TCP/TLS to tunnels through a NAT, and present UDP to the outside world. 
Unless we can come up with a use case for UDP internally, TCP externally I
would recommend removing support for it. Has anyone seen a NAT that allows
UDP but blocks TCP?

OTOH we definetly need to nail down framing in the TCP->TURN->UDP
scenario.  I think we can use the TCP framing mechanism that Jonthan
proposed at the behave meeting; the server would emit every TCP 'chunk' as
a UDP packet.

--Derek

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Mar 2006 08:07:12 -0800 (PST)

> AFAIK, this is not handled by the draft, but do we need to support
> this use case?  One of the main motivations for cross-protol
> tuneling was to use TCP/TLS to tunnels through a NAT, and present
> UDP to the outside world.  Unless we can come up with a use case for
> UDP internally, TCP externally I would recommend removing support
> for it.  Has anyone seen a NAT that allows UDP but blocks TCP?

That isn't quite the scenario.  The scenario where the UDP/TCP
interworking is useful is this:

  Alice---[NAT/firewall]---[TURN]------------[NAT]---Bob
  <-------TCP---------------->|<-----------UDP-------->

Where Alice's NAT/firewall device blocks UDP.  Many company 
firewalls have that behavior, which cause applications such as
Skype and Yahoo Voice to send their traffic over TCP.  

Bob, on the other hand, has a 'normal' NAT, however Bob's
endpoint has no support for framing RTP over TCP.  This is
pretty common -- many endpoints have no ability to send their
RTP traffic over TCP.

So, this functionality provides a way for Alice and Bob to
communicate where they couldn't communicate if they were both
forced to use UDP (because Alice's firewall blocks UDP).

> proposed at the behave meeting; the server would emit every 
> TCP 'chunk' as a UDP packet.

-d

---

From: [email-masked]
Date: Sat, 25 Mar 2006 15:33:13 -0800 (PST)

Dan & I talked about this and realized that one or both may have flipped
something in the question. Here's what we agree on, w/ ascii art for
clarification.

Case #1:

Alice---Tcp(or TLS)----[Nat/Firewall]----->Turn---Udp---->Public Network

This case will be supported by TURN.  The TURN server should turn the TCP
stream into UDP packets based on the framing mechanism Jonathan proposed
at IETF.  Briefly, there is an integer which intidates wheteher or not
this is a turn control message + the length of the data if it isn't STUN. 
UDP packets will be emitted based on this length.

Alice----Udp----[Nat/Firewall]----->Turn---Tcp(or TLS)---->Public Network

We think this case will not be supported by TURN.  It would require
implementing the TCP state machine over UDP between alice & the TURN
server.  Unless someone find a common case where a NAT/FW blocks TCP and
allows UDP this should remain out of scope as the implementation cost is
very high.

Hopefully this clears things up.

--Derek

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 26 Mar 2006 07:58:42 -0800 (PST)

> UDP packets will be emitted based on this length.

Yes, this was what Jonathan presented at the BEHAVE meeting, I
understand this solution, but my question was not about this.

> allows UDP this should remain out of scope as the implementation cost is

The text in the draft explicitly permits to do it:

"As a consequence of the REQUESTED-TRANSPORT attribute, it is possible
 for a client to connect to the server over UDP and request a TCP
 transport address, and for it to connect to the server over TCP (and
 TLS, which uses TCP) and request a UDP transport address.  In such a
 case, the server will relay data between them."

So from here there is two solutions: Remove the UDP-->TCP case from the
draft or explain what TCP framing is used on the relay. It is not
implementable as it is.

For the TCP framing, one solution would be to define a list of well
known TCP framing (contrans, Content-Length), and to pass it as an
attribute in the AllocateRequest.

But I agree that there is a very limited number of use cases that will
use this configuration, so that it can be removed from the draft.

-- 
Marc Petit-Huguenin
Home: marc@xxxxxxxxxxxxxxxxxx
Work: marc@xxxxxxx

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Mar 2006 14:20:47 -0800 (PST)

Marc Petit-Huguenin wrote:

>...

I also vote for removing this from the draft. Specifying it will be a
lot of work; implementing it will be even more; and no one has come up
with a situation in which it is useful.

/a

---

From: "Manjur" <[email-masked]>
Date: Tue, 28 Mar 2006 14:45:12 -0800 (PST)

Comment is inlined
----- Original Message -----
From: "Adam Roach" <adam@xxxxxxxxxxxx>
To: "Marc Petit-Huguenin" <petithug@xxxxxxx>
Cc: <ietf-behave@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 28, 2006 2:20 PM
Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay

> with a situation in which it is useful.

I would like to say that it should be fine to keep this flexibility of the
REQUESTED-TRANSPORT attribute.
STUN-relayed server comes to help the problem with NAT traversal and we
should not ignore the limited number of case as well.
Moreover, it gives more control to the client and the STUN-server to use not
only media but also file-transfer and other signaling communication.
It makes a bridge/tunnel to tcp and udp clinets/servers.
I found it very much useful when a tcp client(say udp is block) wants to
communicate to a udp server(server has only udp support) through the
STUN-relayed server.

>
> /a
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Mar 2006 14:56:43 -0800 (PST)

>communicate to a udp server(server has only udp support) through the

Derek tried to clear this up, but apparently confusion continues to
reign. No one is proposing that the use case you describe should be removed.

Currently, the TURN draft allows four combinations:

      TO CLIENT   TO NETWORK
      ---------   ----------
  1.     TCP         TCP
  2.     UDP         UDP
  3.     TCP         UDP
  4.     UDP         TCP

What you want to do is handled by #3. As far as I can tell, everyone
wants to keep #3. No one has proposed removing #3.

What is being proposed is that #4 be removed.

The problem is that #4 is currently underspecified, will be difficult to
specify, will be very difficult to implement, and will not actually be
useful.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Mar 2006 11:27:11 -0800 (PST)

I'm not opposed to removing #4, but I can at least say what I had in 
mind. Whether it works or is useful, is a different question.

The idea is that the TURN server would be receiving TCP segments from 
the public network. As it receives each segment, it places the content 
into a UDP packet and passes it on to the client. Thus, the TURN server 
is not assuming any framing at all; the UDP datagrams merely carry the 
TCP data without regard to any kind of framing.

now, the problem here is that this is going to break horribly in cases 
where there is UDP packet loss or reordering. Thats because the tcp 
framing mechanism most likely assumes reliable in order delivery, and if 
this is violated, the framing mechanism probably won't be useful to the 
client.

Now, there are potential TCP framing mechanisms which can work when 
translated to UDP; namely ones that rely on start codes for framing, 
along with embedded sequence numbers.  How common is that? probably not 
too much. Certainly not useful for RTP over TCP.

As such, I would agree with the current proposal to remove this 
capability from the draft, unless someone can provide a use case and 
solution that works (since mine doesnt).

To specify this, I wouldn't change any syntax, but have the turn server 
reject a request for TCP transport if the request arrived over UDP. 
Likely this requires a new error code.

Thanks,
Jonathan R.
Adam Roach wrote:

Manjur wrote:

      TO CLIENT   TO NETWORK
      ---------   ----------
  1.     TCP         TCP
  2.     UDP         UDP
  3.     TCP         UDP
  4.     UDP         TCP

The problem is that #4 is currently underspecified, will be difficult to
specify, will be very difficult to implement, and will not actually be
useful.
/a
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Manjur" <[email-masked]>
Date: Wed, 29 Mar 2006 11:56:06 -0800 (PST)

I want to keep #4. I am thinking of the flexibility issue of client and
STUN-relay server with #1 to #4.
I believe STUN-relay will not have limited usage with media traversal only.
It can use to make a tunneling/bridge with UDP and TCP protocol.
Why I support #4 is that a UDP client can connect to a TCP server through
the STUN-relay server.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Mar 2006 12:24:32 -0800 (PST)

So, I'll repeat the question - what is the specific use case (what kind 
of tcp server and why wouldn't the client have tcp), and how do you 
propose solving the framing problem.

-Jonathan R.

Manjur wrote:

----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@xxxxxxxxx>
To: "Adam Roach" <adam@xxxxxxxxxxxx>
Cc: "Manjur" <manjur@xxxxxxxxxxx>; <ietf-behave@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 29, 2006 11:27 AM
Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay

Manjur wrote:

I would like to say that it should be fine to keep this flexibility of
the

REQUESTED-TRANSPORT attribute.
STUN-relayed server comes to help the problem with NAT traversal and we
should not ignore the limited number of case as well.
Moreover, it gives more control to the client and the STUN-server to use
not

Derek tried to clear this up, but apparently confusion continues to
reign. No one is proposing that the use case you describe should be
removed.

     TO CLIENT   TO NETWORK
     ---------   ----------
 1.     TCP         TCP
 2.     UDP         UDP
 3.     TCP         UDP
 4.     UDP         TCP

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Mar 2006 13:08:50 -0800 (PST)

>STUN-relay server with #1 to #4.

In that case, you need to propose how to do it. Sending text would be
best, but a simple explanation of how such a usage can even work would
be a start.

/a