A new QUIC version for network property communication
draft-joras-sconepro-quic-protocol-00

Network Working Group                                           M. Joras
Internet-Draft                                      Meta Platforms, Inc.
Intended status: Informational                                  M. Ihlar
Expires: 9 January 2025                                         Ericsson
                                                             8 July 2024

         A new QUIC version for network property communication
                 draft-joras-sconepro-quic-protocol-00

Abstract

   This document describes a new QUIC version.  The proposed wire format
   and a set of procedures can be used to communicate network properties
   between a content endpoint and an on-path device.  This is achieved
   by sending messages in this new QUIC version format adjacent to
   already established QUIC version 1 or version 2 connections on the
   same UDP 4-tuple.  The network properties are intended to enable
   self-adaptation of video media rates by content endpoints.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Secure Communication
   of Network Properties Working Group mailing list (sadcdn@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/
   sadcdn/.

   Source for this draft and an issue tracker can be found at
   https://github.com/mjoras/sconepro-quic-protocol.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 January 2025.

Joras & Ihlar            Expires 9 January 2025                 [Page 1]
Internet-Draft   QUIC for network property communication       July 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  New QUIC Version  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  QUIC Long Header Packet Format  . . . . . . . . . . . . . . .   3
   5.  Packet Protection . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Public Salt . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  HKDF Labels . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Frames  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Padding Frame . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Data Frame  . . . . . . . . . . . . . . . . . . . . . . .   5
     6.3.  Alternative Hosts Frame . . . . . . . . . . . . . . . . .   6
   7.  Communication Overview  . . . . . . . . . . . . . . . . . . .   6
     7.1.  Use of Connection IDs . . . . . . . . . . . . . . . . . .   7
   8.  On Path Verification  . . . . . . . . . . . . . . . . . . . .   7
   9.  Extensibility To Provide Confidentiality and Authenticity . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The basic idea of the QUIC version described in this document is to
   create an independent message flow between a client endpoint and
   devices in the network, in parallel to an end-to-end QUIC connection
   [RFC 9000], to exchange network properties.  This independent flow
   uses a separate version of QUIC.  This document will not describe
   what information is exchanged for these properties, but rather the
   overall way in which the communication functions.

Joras & Ihlar            Expires 9 January 2025                 [Page 2]
Internet-Draft   QUIC for network property communication       July 2024

   The new version of QUIC described in this document adheres to the
   version-independent properties of QUIC specified in RFC 8999.  This
   version of QUIC uses long headers for all its communication.  The
   version of QUIC defined in this document protects packets using
   publicly known keys, which means that confidentiality and integrity
   of protocol payload cannot be guaranteed.  The document describes how
   a connection can be upgraded to a QUIC version that supports full TLS
   protection.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  New QUIC Version

   RFC 8999 defines the version independent properties of QUIC to
   consist of long and short header packets and version negotiation
   packets.  This document defines a new version of QUIC which
   exclusively uses Long header packets.

   This version of QUIC has a single packet type, and a set of frame
   types used to communicate network properties.  Furthermore, packets
   are protected using publicly-know keys, similar to the way Initial
   packets are protected in QUIC version 1.

4.  QUIC Long Header Packet Format

   This version of QUIC only uses long header packets with the following
   format:

   Long Header Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 0,
     Forward Bit (1) = 0,
     Packet Type (2) = 0,
     Reserved Bits (3),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (8..160),
     Source Connection ID Length (8),
     Source Connection ID (8..160),
     Payload (..),
   }

Joras & Ihlar            Expires 9 January 2025                 [Page 3]
Internet-Draft   QUIC for network property communication       July 2024

   Header Form:  The most significant bit (0x80) of byte 0 (the first
      byte) is set to 1 for long headers.

   Fixed Bit:  The next bit (0x40) of byte 0 is set to 1.

   Forward Bit:  The next bit (0x20) of byte 0 indicates if a network
      device that replies to this packet should consume or forward it.
      By default it SHOULD be set to 0.

   Packet Type:  The next two bits contain a packet type.  A single
      packet type is defined for this protocol with the value 0b00.
      Future extensions MAY add new packet types.  A network device MUST
      ignore packets with unknown packet types and SHOULD forward such
      packets.

   Reserved Bits:  These bits are reserved for future use and SHOULD be
      set to 0.

   Version:  This QUIC version uses the value 0x5509c337, which was
      chosen at random.

   Destination Connection ID Length:  The byte following the version
      contains the length in bytes of the Destination Connection ID
      field that follows it.  This length is encoded as an 8-bit
      unsigned integer.

   Destination Connection ID:  The Destination Connection ID field
      follows the Destination Connection ID Length field, which
      indicates the length of this field.  A Destination Connection ID
      MUST be at least 8 bytes long.

   Source Connection ID Length:  The byte following the Destination
      Connection ID contains the length in bytes of the Source
      Connection ID field that follows it.  This length is encoded as an
      8-bit unsigned integer.

   Source Connection ID:  The Source Connection ID field follows the
      Source Connection ID Length field, which indicates the length of
      this field.  A Source Connection ID MUST be at least 8 bytes long.

5.  Packet Protection

   This version of QUIC uses packet protection as defined for Initial
   packets in section 5 of [QUIC-TLS].

Joras & Ihlar            Expires 9 January 2025                 [Page 4]
Internet-Draft   QUIC for network property communication       July 2024

   This version of QUIC does not use packet numbers, therefore nonces
   are created by combining the initial Destination Connection ID with
   the Source Connection ID of the packet.  A sender MUST generate a
   Source Connection ID with a high probability of being unique for each
   packet.

5.1.  Public Salt

   A publicly known salt is used to derive the secrets, specifically
   sconepro_salt=0x6784619005cadc9bb961ec4d31b76892eb1b567e.

5.2.  HKDF Labels

   The labels used in [QUIC-TLS] to derive packet protection keys
   (Section 5.1), header protection keys (Section 5.4) change from "quic
   key" to "quicscone key", from "quic iv" to "quicscone iv", from "quic
   hp" to "quicscone hp", to meet the guidance for new versions in
   Section 9.6 of that document.

6.  Frames

   The payload of a packet using this QUIC version consists of a
   sequence of frames.  Frames consist of a type field optionally
   followed by type-specific payload.

6.1.  Padding Frame

   Padding frames are defined in section 19.1 of [RFC9000] and are used
   to increase the size of a packet.

   PADDING Frame {
     Type (i) = 0x00,
   }

6.2.  Data Frame

   DATA Frame {
     Type (i) = 0x01,
     Length (i),
     Payload (..),
   }

   Length:  The length of the DATA Frame payload in bytes.

   Payload:  SCONEPRO specific payload such as media bitrate
      information.

Joras & Ihlar            Expires 9 January 2025                 [Page 5]
Internet-Draft   QUIC for network property communication       July 2024

6.3.  Alternative Hosts Frame

   Used to communicate alternative endpoints.  This can be used to send
   a new request of QUIC version but to the network device's IP address
   and port instead of using the same 4-tuple than the corresponsing
   end-to-end QUIC connection.  Alternatively, it can also be used to
   setup a full QUIC version 1 connection from the client to the
   nextwork device to obtain confidentiality and authentication of the
   communication.

   Alternative Hosts Frame {
     Type (i) = 0x02,
     Host (..)..,
   }

   Host:  A tuple consisting of a host name, port and a QUIC protocol
      version.  (TODO define format)

7.  Communication Overview

   The goal of this QUIC version is to provide a way to communicate
   properties between an on-path network device and a QUIC client
   endpoint, with the QUIC client responsible for the initiation of that
   communication.

   Before establishing the communication, a QUIC client usually
   establishes a QUIC version 1 or 2 end-to-end connection as per RFC
   9000.  Once this is done, the client opportunistically sends a QUIC
   long header packet destined to the same endpoint IP address and port
   using this new version.  This packet can be parsed by any capable
   network element on the path that supports this new QUIC version.  If
   the Forward Bit is set, a capable element MUST forward these packets
   and send an Alternative Hosts Frame with its own IP address and port
   number to be used for further communication.  This option can be used
   if more than one capable device might be on the path and needs to see
   the contents.  All capable elements are able to respond to the
   initial packet in a similar fashion, by creating their own QUIC
   packets for this QUIC version and sending them to the QUIC client
   matching the IP/port tuple being utilized by the end-to-end QUIC
   connection.

   The QUIC client must be able to distinguish the end-to-end QUIC
   version 1 or 2 packets and the new QUIC version packets.  This can be
   done by looking for the pattern of packets, combined with trial
   decryption.

Joras & Ihlar            Expires 9 January 2025                 [Page 6]
Internet-Draft   QUIC for network property communication       July 2024

7.1.  Use of Connection IDs

   SCONEPRO QUIC packets contain both Source and Destination Connection
   IDs.  A client who initiates SCONEPRO communication sets both Source
   and Destination Connection IDs to randomly generated values.  A
   network device that 'responds' to a SCONEPRO QUIC packet sets the
   Destination Connection ID to the value of the Source Connection ID of
   the packet it responds to.  The network device sets the Source
   Connection ID to a randomly generated value.

8.  On Path Verification

   Communication using this new QUIC version MUST only be done with
   network elements that can be verified to be on the same network path
   as an end to end QUIC flow.  This is because this communication is
   only meant to be done with network elements that have the ability to,
   for example, modify and drop packets relevant to an end-to-end QUIC
   flow.  As QUIC packets for this new version are themselves carried in
   separate UDP datagrams from the end to end QUIC flow, there is not an
   inherent guarantee that they were generated by a network element.

   A capable network device MUST set the Destination Connection ID
   Length and Destination Connection ID fields to the values received in
   the most recently observed new version QUIC packet sent by a client.

9.  Extensibility To Provide Confidentiality and Authenticity

   The use of keys derived from a publicly known salt does not allow for
   confidentiality or authenticity of the communication.  The only
   manner of authenticity defined in this document is verification of
   the on-path nature of a network element.  It may be desirable for
   this version of QUIC to be extended to allow for confidentiality and
   authenticity.

   Confidentiality with this protocol could be achieved by further
   leveraging the provisions of QUIC version 1 to do a TLS handshake
   between the QUIC client and a capable network element.  Authenticity
   could similarly leverage the provisions of TLS.  However, this comes
   with significant complications.  TLS achieves authenticity by using
   Public Key Infrastructure (PKI), where each participant can choose to
   trust the certificate offered by their peer.  While this PKI exists
   today for Internet endpoints, there is no such existing PKI for
   network elements.  It is important to note that conducting a TLS
   handshake would restrict the communication between the QUIC client
   and exactly one on-path network element.

   Alternatively, a network element could advertise a set of hosts to
   which the client can connect using QUIC version 1.

Joras & Ihlar            Expires 9 January 2025                 [Page 7]
Internet-Draft   QUIC for network property communication       July 2024

10.  Security Considerations

   TODO Security

11.  IANA Considerations

   TBD - QUIC version.

12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Matt Joras
   Meta Platforms, Inc.
   Email: matt.joras@gmail.com

   Marcus Ihlar
   Ericsson
   Email: marcus.ihlar@ericsson.com

Joras & Ihlar            Expires 9 January 2025                 [Page 8]