Subject: [pcp] multiplexing DTLS and non-DTLS on same port

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 08:49:33 -0800

I had emailed IANA to get a port assigned for PCP.  A comment back from IANA
is that we allow PCP to use the same port for secure and unsecured versions
-- should we need to do so.  (I am not yet convinced we need DTLS for PCP,
but let's leave that discussion aside for a moment.  Let's assume we do want
DTLS for PCP for this email thread.)  Thus, I looked at how we might
multiplex both DTLS and non-DTLS PCP on the same port.

Another protocol, DTLS-SRTP, multiplexes DTLS and SRTP on the same port.
They did it this way (from RFC5764):

#
#   The process for demultiplexing a packet is as follows.  The receiver
#   looks at the first byte of the packet.  If the value of this byte is
#   0 or 1, then the packet is STUN.  If the value is in between 128 and
#   191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
#   RTP are being multiplexed over the same destination port).  If the
#   value is between 20 and 63 (inclusive), the packet is DTLS.  This
#   process is summarized in Figure 3.
#
#                   +----------------+
#                   | 127 < B < 192 -+--> forward to RTP
#                   |                |
#       packet -->  |  19 < B < 64  -+--> forward to DTLS
#                   |                |
#                   |       B < 2   -+--> forward to STUN
#                   +----------------+
#

PCP could do something similar.  An easy way to achieve it is to force a "1"
in the first bit of the common header, so it would change from

OLD:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver=0 |reserve|R|   OpCode    |       Reserved                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|Ver=0|reserve|R|   OpCode    |       Reserved                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......^

and anything with the first bit set is processed as plain PCP, and 
anything with the first bit clear is processed as DTLS.

This leaves us with 3 bits for version number, which seems plenty.

Thoughts?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 19:37:14 +0100

In your previous mail you wrote:

=> in fact I have a related question: do we need to support
DTLS and non-DTLS multiplexing? It seems if DTLS is required then
non-DTLS should be refused, and vice versa.
So IMHO we should wait. As you explained we even don't know if DTLS
could be used to protect PCP.

Regards

[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Jan 2011 14:14:00 -0500

> OLD:

This is simple and has been proven to work well in the context of RTP.
It will future-proof PCP without any disadvantage.

+1

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 11:15:42 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2011 10:37 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] multiplexing DTLS and non-DTLS on same port
> 
> 
> DTLS and non-DTLS multiplexing?

The question, from IANA, is (in a shortened form):  if you do add
channel security to your protocol, can you do it without consuming
an additional port?

> It seems if DTLS is required then

Yep.  But how would we refuse non-DTLS, if not with the ability to
multiplex DTLS and non-DTLS on the same port and return a PCP error
message?  

> So IMHO we should wait.

Wait on what?  Wait to ask IANA for a port?

-d

> As you explained we even don't know if DTLS

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jan 2011 00:04:07 +0100

>    Another protocol, DTLS-SRTP, multiplexes DTLS and SRTP on the same

=> BTW SRTP is the only standardized protocol doing this (others reuse
the TLS port as they can run over TCP too).

   
=> wait on a decision about DTLS use. I can't see a reason to rush
to support something we could use. Now the change has no other impact...
   
Regards

PS: If we change the first bytes we can take advantage of this
to enlarge the opcode field now too.