Re: Potential conflict between draft-ietf-quic-transport and RFC 7983

[Bernard Aboba <[e-mail]>]

Mike asked:

"Is it a goal for QUIC and DTLS-SRTP to coexist on the same port"?

[BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to co-exist on
the same port.  Within the scheme, DTLS is used for transport of WebRTC's
DTLS/SCTP/UDP data channel and DTLS-SRTP is used for key management of
SRTP/SRTCP.

While within WebRTC, DTLS currently provides both data channel transport as
well as SRTP key management, it is not clear that initial QUIC
implementations within WebRTC will attempt to provide alternatives for both
of these functions.

For example, experimental implementations of a QUIC data channel may wish
to focus solely on that objective without having to provide an alternative
to DTLS-SRTP.  In such an implementation, QUIC and DTLS-SRTP would need to
co-exist on the same port.



On Wed, May 17, 2017 at 2:52 PM, Mike Bishop <[e-mail]>
wrote:

> 7983 is a bugfix to 5764 section 5.1.2, per a quick perusal.  I didn’t
> read either of those RFCs as purporting to constrain the first byte of all
> future UDP-based protocols.  5764 says:
>
>
>
>    When DTLS-SRTP is used to protect an RTP session, the RTP receiver
>
>    needs to demultiplex packets that are arriving on the RTP port.
>
> ...
>
>    If other packet types are to be multiplexed as well, implementors
>
>    and/or designers SHOULD ensure that they can be demultiplexed from
>
>    these three *[or five, given 7983]* packet types.
>
>
>
> Is it a goal for QUIC and DTLS-SRTP to coexist on the same port?
>
>
>
> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Bernard Aboba
> *Sent:* Wednesday, May 17, 2017 2:37 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Potential conflict between draft-ietf-quic-transport and RFC
> 7983
>
>
>
> There appears to be a potential conflict between draft-ietf-quic-transport
> and RFC 7983. Looking at draft-ietf-quic-transport, both the short and the
> long headers appear to conflict with the de-multiplexing scheme defined in
> RFC 7983, which is based on the value of the first byte of multi-plexed
> protocols:
>
>
>
>    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
>
>    in between 0 and 3 (inclusive), then the packet is STUN.  If the
>
>    value is between 16 and 19 (inclusive), then the packet is ZRTP.  If
>
>    the value is between 20 and 63 (inclusive), then the packet is DTLS.
>
>    If the value is between 64 and 79 (inclusive), then the packet is
>
>    TURN Channel.  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 does not
>
>    match any known range, then the packet MUST be dropped and an alert
>
>    MAY be logged.  This process is summarized in Figure 3.
>
>
>
>                     +----------------+
>
>                     |        [0..3] -+--> forward to STUN
>
>                     |                |
>
>                     |      [16..19] -+--> forward to ZRTP
>
>                     |                |
>
>         packet -->  |      [20..63] -+--> forward to DTLS
>
>                     |                |
>
>                     |      [64..79] -+--> forward to TURN Channel
>
>                     |                |
>
>                     |    [128..191] -+--> forward to RTP/RTCP
>
>                     +----------------+
>
>
>
>      Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
>
>
>
>
>
>