Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck

[Thomas Herbst <[e-mail]>]

+1

From: Robert Cragie <[e-mail]<mailto:[e-mail]>>
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tue, 10 May 2011 06:55:52 -0700
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck

I have never seen what the issue is with using two ports like HTTPS:


 *   One port for CoAP over UDP
 *   One port for CoAP over DTLS over UDP

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
[phone]
[phone]
http://www.gridmerge.com<http://www.gridmerge.com/>

On 06/05/2011 8:49 AM, Eric Rescorla wrote:

On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann <[e-mail]><mailto:[e-mail]> wrote:


On May 6, 2011, at 02:51, Eric Rescorla wrote:



1. Use STUN as-is.


Yep, we are doing that.
(The escaping stuff is insurance for a case that is rather unlikely.  We could take it out.)

What is the status about STUN coexisting with DTLS?


As far as I know, there's no problem, since the leading bytes plus cookies make
collisions very unlikely.




2. Use a leading framing byte to distinguish DTLS and CoAP from STUN.
If you're really worried
about compactiness,


(Yes, we are.)



then pick only a single value to distinguish DTLS
(e.g., 0xffffffff)


(That would be a bit long.)


Sorry, brain failure. 0xff




and use all
the remaining values to give you a little more room in the rest of the packet.


Sure, we could do that.  It would mean spending another byte for all DTLS packets.


Right. My argument is that that's not that big a deal because it only
increases space
by ~5%.




More importantly, it also means DTLS packets no longer look like DTLS packets, which complicates debugging.


Yes, I agree that that's suboptimal. That's why I prefer separate ports...
The material you're quoting above is just some other thoughts for dealing with
the same port if people insist.




I would like to learn more about your plans to expand the DTLS ContentType space.
This hasn't changed since 1996.  Of course, it could, next month.
Again, the escaping stuff is insurance for this case.  We could take it out.


I don't think there are any immediate plans to do so--though note that
http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-01
does contemplate one addition. And I would assume that we intend to
assign the content-types towards the bottom of the range first. That said,
I don't think TLS-WG has by any means decided to commit to not
assigning a bunch more types.

Bes,t
-Ekr
_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/core