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

[Jana Iyengar <[e-mail]>]

This *may* be one of those things where keeping WebRTC in the back of our
minds might help QUIC not get stuck badly in the future.

So, as a thought exercise (not assuming that we need to solve this problem
here) I'd like to walk through what we *could* do if we actually supported
both WebRTC protocols and QUIC on the same port.

I think the simplest thing to do would be to pass everything through a QUIC
"dispatcher" that determines if this packet belongs to QUIC --- basically
confirms whether this packet should be consumed by QUIC or not --- and if
it isn't consumed by QUIC (including packets that QUIC decides MUST be
dropped because they are QUIC packets but violate some property) then it
can be consumed by non-QUIC applications on the same port.

The question of course is how bad is the likelihood of false
positives/negatives. With the encrypted packet types in QUIC, the QUIC
dispatcher will safely reject non-QUIC packets.

With the plaintext types, which are used during handshake, QUIC packets are
covered by a non-crypto FNV-1a hash. The cost that QUIC bears of a
mis-classification among plaintext packets as a QUIC packet is limited to
cases where the contents of the packet are not part of the final key
derivation. These packet types are limited to a few long-form packet types,
all of which have a number of version-independent fields upfront, including
version, which could be checked for sanity (since connection ID and packet
number can be arbitrary.) This still doesn't seem great, since 0x0001 is a
fine version number to have in QUIC and may be a completely reasonable
string in RTP.  So alternatively, we could renumber the long-form packet
types to start at 255 and count down, since 192 - 255 is left open by RFC
7983, and since we just need  6 cleartext packet types at the moment to be
distinct from the RTP packet types (it's smaller than that, since Stateless
Reject and Version Negotiation packets need to echo stuff from the client's
packets.)

TL;DR of this is that *if* we wanted to allow for a future coexistence of
WebRTC protocols with QUIC on the same port -- and this is a big "if",
since I wonder if they need to be on the same port --- we could renumber
just the long-form packets to start at 255 and grow downwards. We only need
<= 6 plaintext packet types to be out of the collision region with  RFC
7983.


On Wed, May 17, 2017 at 3:31 PM, Bernard Aboba <[e-mail]>
wrote:

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