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
+44 1924 910888
+1 415 513 0064
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<cabo@tzi.org>  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
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

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

Attachment: smime.p7s