Subject: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN

From: "core issue tracker" <[email-masked]>
Date: Sat, 06 Nov 2010 16:15:35 -0000

#56: Distinguishing DTLS, CoAP and STUN

 Section 10.2 need a discussion on how to tell the difference between DTLS
 and CoAP messages as the same port is used by default.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  trivial             |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/56>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sat, 06 Nov 2010 23:56:08 -0000

Comment(by cabo@…):

 DTLS UDP payloads begin with a byte out of

        enum {
            change_cipher_spec(20), alert(21), handshake(22),
            application_data(23), (255)
        } ContentType;

 i.e. 0x14 to 0x17.
 This would be decoded as a CoAP version 0.  We have to make sure we never
 use that version, and we have to ask DTLS to reserve contenttypes (that's
 what they call the initial byte) outside of the range 0..63.

 Similarly, STUN messages begin with 0 0 binary (MSBs).  Again, we have to
 avoid using CoAP version number 0.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/56#comment:1>
core <http://tools.ietf.org/core/>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 21:20:27 -0600

Section 5.1.2 of  RFC 5764 discusses the demux of RTP / DTLS / STUN. It seems to me that if COAP stepped on top of the same code points as RTP, it would be very unlikely to conflict with future exertions of STUN or DTLS because theses protocols will have big problems if they step on top of RTP. 

On Nov 6, 2010, at 5:56 PM, core issue tracker wrote:

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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Nov 2010 11:51:53 +0800

On Nov 7, 2010, at 11:20, Cullen Jennings wrote:

> if COAP stepped on top of the same code points as RTP

That would mean advancing CoAP to version 2.
Not something we want to do lightly with all the implementations out there.
(I'd also rather stay at 1 and be able to distinguish RTP and CoAP, too.)

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Sun, 7 Nov 2010 12:25:22 +0800

> avoid using CoAP version number 0.

Thanks for checking that ;-)  I will include this information into the security section of coap-04. And we need to mention that version 0 can not (and will not) be used for this reason.

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Peter Bigot <[email-masked]>
Date: Mon, 8 Nov 2010 11:59:06 -0600

I missed the working group discussion during which it was decided to carry
both secure and non-secure packets over the same protocol on the same port.

Following the general URI concept that the authority and hier-part define
the resource, while the scheme defines how you talk to the resource owner,
it is more natural (and consistent with http/https) that an alternative
scheme denote encrypted CoAP traffic.  Since the scheme would be encrypted,
use of a distinct port to disambiguate the content is also more clear.  This
would also decouple CoAP from being impacted by evolutionary decisions made
within DTLS.

On what basis was the decision made to diverge from the way it's done in
HTTP?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2010 06:44:21 +0800

Peter,

the current discussion is about documenting that you indeed *can* carry DTLS and unprotected CoAP on the same UDP port.
This is a useful property that HTTP/HTTPS did not have:  HTTP was long deployed when HTTPS was invented, and TLS (SSL) was not designed to use something like an upgrade mechanism.

Why do we want that property?

-- it enables us to get by with just one port reservation with IANA (good)
-- it enables implementations to mix raw CoAP with DTLS traffic on one port (maybe not that important)
-- it makes CoAP robust against STUN packets and enables the return of STUN information from the same port (not that important in a v6 network, but useful in v4).

Now the question you raise is about the URI scheme.
HTTPS had the unique situation that the mere scheme identifies both the protocol to be used and much of the security context (at least for "public" URIs).

CoAP-03 has three modes of operation: raw (NoSec), IPsec and DTLS.
It is not clear to me that you can encode the mode as well the security context (how do you set up the security association) in one scheme.

I think we need a separate ticket on this issue.

Gruesse, Carsten