Subject: [P2PSIP] rfc5389 + DTLS

From: jc <[email-masked]>
Date: Sun, 27 Sep 2009 02:58:54 -0700

Hi,
Because every node is a STUN client/server and DTLS is required this  
breaks rfc5389 compliance. I assume this is an oversight in rfc5389  
considering rfc4347 came first.

Julian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Sep 2009 07:44:07 -0700

How does it break RFC 5389 compliance?

-Ekr

On Sun, Sep 27, 2009 at 2:58 AM, jc <[email-masked]> wrote:
> Hi,
> Because every node is a STUN client/server and DTLS is required this breaks
> rfc5389 compliance. I assume this is an oversight in rfc5389 considering
> rfc4347 came first.
>
> Julian
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: jc <[email-masked]>
Date: Sun, 27 Sep 2009 11:41:51 -0700

> How does it break RFC 5389 compliance?

There is no section describing TLS over UDP(DTLS).

"7.2.1. Sending over UDP ...................................13"
"7.2.2. Sending over TCP or TLS-over-TCP ...................14"

and rfc5389 clearly states:

"Note that only "tcp" is defined with "stuns" at this time."

and:

"In addition, IANA has assigned port number 5349 for the "stuns"  
service, defined over TCP and UDP. The UDP port is not currently  
defined; however, it is reserved for future use."

How is RELOAD compliant with rfc5389?

Julian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Sep 2009 11:48:20 -0700

On Sun, Sep 27, 2009 at 11:41 AM, jc <[email-masked]> wrote:
> "In addition, IANA has assigned port number 5349 for the "stuns" service,
> defined over TCP and UDP. The UDP port is not currently defined; however, it
> is reserved for future use."
>

STUN isn't being used over TLS (or DTLS) in RELOAD. Rather, it's being
used in the context of ICE for the purposes of connectivity checks. As
far as I know, there's no issue here.

-Ekr

---

From: jc <[email-masked]>
Date: Sun, 27 Sep 2009 12:15:06 -0700

On Sep 27, 2009, at 11:48 AM, Eric Rescorla wrote:

>> service,

Every time you perform an Attach in RELOAD it uses either DTLS or TLS   
with STUN to perform ICE connectivity checks(done by TLS/DTLS hand- 
hake in ice-lite) towards the remote candidates. Is this fact or  
fiction?

Julian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Sep 2009 12:26:40 -0700

On Sep 27, 2009, at 12:15 PM, jc <[email-masked]> wrote:

> Every time you perform an Attach in RELOAD it uses either DTLS or  
> TLS  with STUN to perform ICE connectivity checks(done by TLS/DTLS  
> hand-hake in ice-lite) towards the remote candidates. Is this fact  
> or fiction?

It's fact but you're confusing two meanings of the word "with". In  
this case tls/dtls is multiplexed with stun over tcp/udp, therefore  
there is no need to define stun over dtls. The stun over tls you are  
pointing to is not used with ice, but rather for other stun-using  
applications such as turn

Ekr

---

From: jc <[email-masked]>
Date: Sun, 27 Sep 2009 13:13:01 -0700

> applications such as turn

I've built out my transports so that the lowest layer is UDP/TCP the  
next is DTLS/TLS and the next demultiplexes STUN, RELOAD and APP. In  
other words DTLS and TLS are completely transparent to the ICE  
transport. I don't demultiplex any TLS or DTLS packets because when  
the SSL state is acquired everything else can only be upper layer  
messages. What you've stated indicates to me that you may receive a  
STUN message on the UDP/TCP layer because you've mentioned having to  
"multiplex tls/dtls" with stun over tcp/udp". Does my implementation  
sound correct to you?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Sep 2009 14:10:02 -0700

On Sun, Sep 27, 2009 at 1:13 PM, jc <[email-masked]> wrote:
> Every time you perform an Attach in RELOAD it uses either DTLS or TLS  with
> STUN to perform ICE connectivity checks(done by TLS/DTLS hand-hake in
> ice-lite) towards the remote candidates. Is this fact or fiction?
>
> It's fact but you're confusing two meanings of the word "with". In this case
> tls/dtls is multiplexed with stun over tcp/udp, therefore there is no need
> to define stun over dtls. The stun over tls you are pointing to is not used
> with ice, but rather for other stun-using applications such as turn
>
>
> I've built out my transports so that the lowest layer is UDP/TCP the next is
> DTLS/TLS and the next demultiplexes STUN, RELOAD and APP. In other words
> DTLS and TLS are completely transparent to the ICE transport. I don't
> demultiplex any TLS or DTLS packets because when the SSL state is acquired
> everything else can only be upper layer messages. What you've stated
> indicates to me that you may receive a STUN message on the UDP/TCP layer
> because you've mentioned having to "multiplex tls/dtls" with stun over
> tcp/udp". Does my implementation sound correct to you?

No, this doesn't sound right.

The idea here is that ICE provides a fast connectivity check and then
you only establish TLS/DTLS connections over the single channel
that ICE successfully establishes. If you do things the other way
(TLS first, then ICE), then you end up trying to establish a zillion
independent (D)TLS connections (which would be really slow even
if it worked, which it won't) and then running ICE, which is pointless
since you can't establish a (D)TLS connection unless you have two-way
connectivity.

-Ekr

---

From: jc <[email-masked]>
Date: Sun, 27 Sep 2009 14:26:03 -0700

> since you can't establish a (D)TLS connection unless you have two-way

This is literarily a few lines of code I have to change to run non- 
encrypted ICE. This isn't very clear in the draft because the MUST's  
pertaining to DTLS and TLS seem to overlap the ICE implementation.  
This resolves the topic since rfc5389 and DTLS aren't used in  
conjunction in the draft.

Thanks for the clarification on that,
Julian