Subject: [Perc] Comments on: draft-ietf-perc-dtls-tunnel-00.txt

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 17:03:47 -0700

This looks mostly OK.  Comments below.

I'm not sure I'm excited about having the version # in every message.
That seems like a recipe for mess. Why not just have it in the first
message?

S 5.4.
   subsequently include this identifier in all messages it sends so that
   the media distributor can map messages received via a tunnel and
   forward those messages to the correct endpoint.  The association
   identifier SHOULD be randomly assigned and values not be re-used for
   a short period of time (e.g., five minutes) to ensure any residual
   state in the key distributor is clear and to ensure any packets
   already transmitted from the key distributor are not directed to the
   wrong endpoint.

Why don't you just generate a longer identifier and guarantee non-reuse?
It's not like you are short on bandwidth in this channel.

S 6.1.
   enum {
       unsupported_version(1),
       supported_profiles(2),
       media_keys(3),
       tunneled_dtls(4),
       endpoint_disconnect(5),
       (255)
   } MsgType;

   struct {
       uint8 version;
       MsgType msg_type;
       select (MsgType) {
           case unsupported_version: UnsupportedVersion;
           case supported_profiles:  SupportedProfiles;
           case media_keys:          MediaKeys;
           case tunneled_dtls:       TunneledDtls;
           case endpoint_disconnect: EndpointDisconnect;
     } body;
   } TunnelMessage;

Generally, it's a good idea to have TunnelMessages have a length in
a deterministic place as this allows one to make a generic message
parser before you look at the type.

Nit:
   This message contains this single element: * protection_profiles: The
   list of two-octet SRTP protection profile values as per [RFC5764]
   supported by the media distributor.

You have a formatting glitch here.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 24 Mar 2017 02:09:32 +0000

Ekr,

>That seems like a recipe for mess. Why not just have it in the first

Yeah, that could be done. We could move the version field to the 
"SupportedProfiles" message and require that the key distributor send 
the version error if that message contains an incompatible version.  
Then, we could put a version field into the "UnsupportedVersion" message 
  I think that would be sufficient.

>It's not like you are short on bandwidth in this channel.

Something like a 128-bit random value?  A UUID?  We could do that and 
avoid state maintenance.

>parser before you look at the type.

Good point. I think this was a left-over from when we assumed use of 
DTLS to tunnel DTLS, so length was the length of the packet.  We do need 
something for TLS, so I'll put in a length field before or after 
msg_type.

>You have a formatting glitch here.

Indeed.  Well, that sucks.  My markdown tool failed me.  I'll hack the 
text or fix the markdown tool. :)

Paul