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

[Colin Perkins <[e-mail]>]

I sketched out one way of doing the demuxing of QUIC and the WebRTC protocols on the same port in https://github.com/quicwg/base-drafts/issues/426 <https://github.com/quicwg/base-drafts/issues/426> – if we’re willing to lose a couple of bits from the QUIC type field, then separating the protocols seems straight-forward.

Colin




> On 18 May 2017, at 02:02, Jana Iyengar <[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>] On Behalf Of Bernard Aboba
> Sent: Wednesday, May 17, 2017 2:37 PM
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[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.
>  
>  
> 
> 



-- 
Colin Perkins
https://csperkins.org/