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

[Eric Rescorla <[e-mail]>]

On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann <[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