Subject: Mechanism for negotiating extensions

From: Victor Vasiliev <[email-masked]>
Date: Thu, 25 Jan 2018 11:34:24 -0500

I've been thinking about extension negotiation, and I'm not entirely sure
that "just put a transport parameter per extension" is a sufficiently
complete answer.  There are at least two problems in extending QUIC that we
ought to address.

The first problem is that the frame type field is only one byte long.
While this is enough for any single QUIC connection, if we try to allocate
those globally in a non-conflicting manner, we might exhaust it sooner than
we think (also, this would require coordinating two extensions to be
compatible).  Thus, I believe we should to add a general mechanism where
every extension, when negotiated, would specify which frame type numbers
it's using on the wire for each frame, so that this number allocation can
be performed on per-connection basis.  I believe there are mechanisms
similar to that in other protocols (e.g. RTP does something like that in
RFC 8285).

The second problem is that the client list of offered extensions is not
protected by secure keys.  I am not sure how much of an issue this is in
terms of ossification -- I don't remember off the top of my head where it
caused problems in TLS *per se*, and inventing a completely new mechanism
for it will surely run into a set of issues.  Still, it's worth discussing.

If people believe that the mapping proposal is valuable, I can write up a
PR for this.

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 25 Jan 2018 20:09:26 +0000

Alternatively, could we say that "You MUST not use extension frames in IETF QUIC versions", i.e. if you want to use a extension frame, you should have your own version of QUIC.

This makes extension frames less useful for IETF QUIC versions, but private experimental QUIC versions do not have to rev that often, which is super valuable as well.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Victor Vasiliev <[email-masked]>
Sent: Thursday, January 25, 2018 8:34:24 AM
To: IETF QUIC WG
Subject: Mechanism for negotiating extensions

I've been thinking about extension negotiation, and I'm not entirely sure that "just put a transport parameter per extension" is a sufficiently complete answer.  There are at least two problems in extending QUIC that we ought to address.

The first problem is that the frame type field is only one byte long.  While this is enough for any single QUIC connection, if we try to allocate those globally in a non-conflicting manner, we might exhaust it sooner than we think (also, this would require coordinating two extensions to be compatible).  Thus, I believe we should to add a general mechanism where every extension, when negotiated, would specify which frame type numbers it's using on the wire for each frame, so that this number allocation can be performed on per-connection basis.  I believe there are mechanisms similar to that in other protocols (e.g. RTP does something like that in RFC 8285).

The second problem is that the client list of offered extensions is not protected by secure keys.  I am not sure how much of an issue this is in terms of ossification -- I don't remember off the top of my head where it caused problems in TLS per se, and inventing a completely new mechanism for it will surely run into a set of issues.  Still, it's worth discussing.

If people believe that the mapping proposal is valuable, I can write up a PR for this.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 25 Jan 2018 20:35:13 -1000

I personally agree that a mapping mechanism makes sense. RTP/SDP ended
up using a similar mechanism for the RTP media types, and that seems to
have worked well. In fact, I proposed something similar in a comment to
MT's extension proposal: Reserve a small number of extension frame types
in the "frame type" space. Create a transport parameter option in which
the client says "I want to use reserved frame type X to do XYZT". Server
acknowledges with corresponding option, "Let's use frame type X to do
XYZT". XYZT is a four letter acronym reserved in a Wiki.

Victor, why don't you submit a PR, so we can have a discussion on the
details?

-- Christian Huitema

On 1/25/2018 10:09 AM, Subodh Iyengar wrote:
>
> Alternatively, could we say that "You MUST not use extension frames in
> IETF QUIC versions", i.e. if you want to use a extension frame, you
> should have your own version of QUIC.
>
>
> This makes extension frames less useful for IETF QUIC versions, but
> private experimental QUIC versions do not have to rev that often,
> which is super valuable as well.
>
>
> Subodh
>
> ------------------------------------------------------------------------
> *From:* QUIC <[email-masked]> on behalf of Victor Vasiliev
> <[email-masked]>
> *Sent:* Thursday, January 25, 2018 8:34:24 AM
> *To:* IETF QUIC WG
> *Subject:* Mechanism for negotiating extensions
>  
> I've been thinking about extension negotiation, and I'm not entirely
> sure that "just put a transport parameter per extension" is a
> sufficiently complete answer.  There are at least two problems in
> extending QUIC that we ought to address.
>
> While this is enough for any single QUIC connection, if we try to
> allocate those globally in a non-conflicting manner, we might exhaust
> it sooner than we think (also, this would require coordinating two
> extensions to be compatible).  Thus, I believe we should to add a
> general mechanism where every extension, when negotiated, would
> specify which frame type numbers it's using on the wire for each
> frame, so that this number allocation can be performed on
> per-connection basis.  I believe there are mechanisms similar to that
> in other protocols (e.g. RTP does something like that in RFC 8285).
>
> The second problem is that the client list of offered extensions is
> not protected by secure keys.  I am not sure how much of an issue this
> is in terms of ossification -- I don't remember off the top of my head
> where it caused problems in TLS /per se/, and inventing a completely
> new mechanism for it will surely run into a set of issues.  Still,
> it's worth discussing.
>

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 26 Jan 2018 15:52:36 -0500

Sure.  Here's my idea of how this would work:
https://github.com/quicwg/base-drafts/pull/1072

On Fri, Jan 26, 2018 at 1:35 AM, Christian Huitema <[email-masked]>
wrote:

> I personally agree that a mapping mechanism makes sense. RTP/SDP ended up
> using a similar mechanism for the RTP media types, and that seems to have
> worked well. In fact, I proposed something similar in a comment to MT's
> extension proposal: Reserve a small number of extension frame types in the
> "frame type" space. Create a transport parameter option in which the client
> says "I want to use reserved frame type X to do XYZT". Server acknowledges
> with corresponding option, "Let's use frame type X to do XYZT". XYZT is a
> four letter acronym reserved in a Wiki.
>
>
> IETF QUIC versions", i.e. if you want to use a extension frame, you should
> have your own version of QUIC.
>
>
> private experimental QUIC versions do not have to rev that often, which is
> super valuable as well.
>
>
> Subodh
> ------------------------------
> *From:* QUIC <[email-masked]> <[email-masked]> on behalf of
> Victor Vasiliev <[email-masked]> <[email-masked]>