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

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 May 2017 14:36:46 -0700

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.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 17 May 2017 21:52:13 +0000

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:[email-masked]] On Behalf Of Bernard Aboba
Sent: Wednesday, May 17, 2017 2:37 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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:

                    +----------------+

                    |                |

                    |                |

                    |                |

                    |                |

                    +----------------+

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 May 2017 15:31:21 -0700

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 <[email-masked]>
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:
>
>
>
>    these three *[or five, given 7983]* packet types.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Bernard Aboba
> *Sent:* Wednesday, May 17, 2017 2:37 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Potential conflict between draft-ietf-quic-transport and RFC
> 7983
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 17 May 2017 18:02:43 -0700

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 <[email-masked]>
wrote:

> While within WebRTC, DTLS currently provides both data channel transport
> as well as SRTP key management, it is not clear that initial QUIC
> On Wed, May 17, 2017 at 2:52 PM, Mike Bishop <[email-masked]
> > wrote:
>
>> 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:
>>
>>
>>

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 18 May 2017 06:45:27 +0000

FYI, Colin raised this issue in the past and we have ticket #426 on it open: https://github.com/quicwg/base-drafts/issues/426

Lars

> On 2017-5-17, at 23:36, Bernard Aboba <[email-masked]> wrote:
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 18 May 2017 12:12:43 +0100

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Mike asked: 
> 
> [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 <[email-masked] <mailto:[email-masked]>> wrote:
> From: QUIC [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bernard Aboba
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 18 May 2017 12:15:08 +0100

> On 17 May 2017, at 23:31, Bernard Aboba <[email-masked]> wrote:
> 
> Mike asked: 
> 

Being able to co-exist with STUN and TURN on the same port is likely important if we ever want QUIC to work peer-to-peer through NATs, too.

Colin

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