Subject: Re: [BEHAVE] Running TLS and plain STUN over the same TCP port

From: "Dan Wing" <[email-masked]>
Date: Mon, 5 Jan 2009 17:55:15 -0800

> I have a question related to the following excerpt from RFC5389:
> 
> >    Servers can run STUN over TLS on the same port as
> >    STUN over TCP if the server software supports 
> >    determining whether the
> >    initial message is a TLS or STUN message.
> 
> I can see two ways a server can determine that:
> 
> 1. Static configuration.
> 2. Evil heuristics.

TLS and STUN can be demultiplexed by examining the first byte of the stream.
Section 5.1.2 of draft-ietf-avt-dtls-srtp-06 shows how RTP, STUN, and DTLS can
be demultiplexed on a UDP stream; demultiplexing STUN or TLS on a TCP stream
would be similar.  

We should probably have provided a hint in RFC5389 that the first byte can be
used to demultiplex STUN or TLS; that might be a worthwhile errata.

-d

> Is there a third way I have overlooked (e.g. STARTTLS)?

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 6 Jan 2009 11:06:42 -0500

On Monday 05 January 2009 20:55:15 Dan Wing wrote:
> TLS and STUN can be demultiplexed by examining the first byte of the
> stream. Section 5.1.2 of draft-ietf-avt-dtls-srtp-06 shows how RTP, STUN,
> and DTLS can be demultiplexed on a UDP stream; demultiplexing STUN or TLS
> on a TCP stream would be similar.
>
> We should probably have provided a hint in RFC5389 that the first byte can
> be used to demultiplex STUN or TLS; that might be a worthwhile errata.

Thanks for your reply!

To summarize for the benefit of those reading the archives:

We're assuming that no STUN method ID greater than 0x63 exists. This ensures 
that the first byte is always <= 2 for STUN messages. In ChannelData messages, 
the first byte is always > 0x40 by definition. TLS 1.x always sends 3 as the 
first byte.

That's actually what "evil heuristics" was referring to because I didn't like 
making this assumption on my own. Now I know I'm in good company. :)

Thanks,
Simon

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Sun, 11 Jan 2009 05:10:14 -0500

> We're assuming that no STUN method ID greater than 0x63 exists. This  

I think you meant 127 (0x7F) and not 0x63.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Jan 2009 08:27:14 -0500

> I think you meant 127 (0x7F) and not 0x63.

Right. Why I wrote 0x63 is a complete mystery to me...

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Jan 2009 17:54:37 -0500

The good thing is that, so far, there hasn't been a lot of new STUN  
methods defined. So this trick seems likely to continue working for a  
while ...

- Philip