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

["Paul E. Jones" <[e-mail]>]

Ekr,

>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?

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.

>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.

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


>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.

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.


>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.

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

Paul