Re: Mix of TCP and TLS in draft-rosenberg-midcom-turn-07.txt

Eric Hsu <[email protected]> Wed, 13 Jul 2005 17:22:58 +0800
Newsgroups gmane.ietf.midcom
Message-ID <[email protected]>
Hi Remi,

I've implemented a TURN server according to the draft with python and twist=
ed.

To "discriminate between TLS traffic and non-TLS traffic", I've
implemented it in the following way (TLS is a higher level protocol
built upon TCP):

. Turn server listens on a normal TCP port, say 12345
. Turn client connects to that port over normal TCP
. Turn client sends a 'STARTTLS' string to the server to begin tls negociat=
ion
. Turn server receives the 'STARTTLS', then it sends a 'READY' string
to the client and starts the TLS negociation with a server
certification to the client
. Once Turn client receives the 'READY' string, it should starts the
TLS negociation too
. Then everything is over TLS=20
. Once the  Turn client receives the one-time credential, it just
closes the TCP connection as the draft said.

By this mean, we can switch from a normal TCP connection to TLS :)

Regards

- Eric

2005/7/12, Remi Denis-Courmont <[email protected]>:
>         Hello,
>=20
>=20
> Section 8.3 of the latest TURN draft says that any Allocate Request
> should be sent to the same IP and port than the Shared Secret Request
> from which the one-time credentials where obtained. However, the latter
> is sent over TLS, presumably TLS over TCP. Maybe I got it wrong, but it
> is my understanding that Allocate Requests should be sent over TCP, ie.
> unencrypted TCP, without TLS.
>=20
> Yet, the draft doesn't how the server can discriminate between TLS
> traffic and non-TLS traffic. If the same port is to be used, I believe
> some kind of mechanism has to be used to differenciate both properly.
>=20
> Or maybe, all of the TCP traffic is to be sent over TLS between the TURN
> client and the TURN server, but it sounds like that would add some
> unneeded computational overhead.
>=20
> So how is that supposed to be handled ?
>=20
> Thanks in advance.
>=20
> Regards,
>=20
> --
> Remi Denis-Courmont <[email protected]>
> Nokia-NRC/Helsinki
>=20
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
>