A new QUIC version for network property communication
draft-joras-scone-quic-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Matt Joras , Marcus Ihlar | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-joras-scone-quic-protocol-00
Network Working Group M. Joras
Internet-Draft Meta Platforms, Inc.
Intended status: Informational M. Ihlar
Expires: 24 April 2025 Ericsson
21 October 2024
A new QUIC version for network property communication
draft-joras-scone-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 throughput advice
between an endpoint and an on-path network element. Throughput
advice are sent in QUIC packets of a new QUIC version. These QUIC
packets are sent adjecent to established QUIC version 1 and 2
connections, within the same UDP 4-tuple.
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 24 April 2025.
Joras & Ihlar Expires 24 April 2025 [Page 1]
Internet-Draft QUIC for network property communication October 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 . . . . . . . . . . . . . . . . . 2
3. SCONE Packet Format . . . . . . . . . . . . . . . . . . . . . 3
4. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Public Salt . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. HKDF Labels . . . . . . . . . . . . . . . . . . . . . . . 4
5. Communication Overview . . . . . . . . . . . . . . . . . . . 5
5.1. Use of Connection IDs . . . . . . . . . . . . . . . . . . 5
6. On Path Verification . . . . . . . . . . . . . . . . . . . . 6
7. Extensibility To Provide Confidentiality and Authenticity . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document describes SCONE, a protocol for the purpose of
communicating throughput advice from network elements to endpoints.
SCONE uses QUIC long header packets to send throughput advice in
parallel to established end-to-end QUIC connections.
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.
Joras & Ihlar Expires 24 April 2025 [Page 2]
Internet-Draft QUIC for network property communication October 2024
3. SCONE Packet Format
A SCONE packet consists of a QUIC long header optionally followed by
throughput advice fields:
SCONE Packet {
Header Form (1) = 1,
Fixed Bit (1) = 0,
Throughput Advice Bit (1),
Average Window Bit (1),
Forward Bit (1)
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),
[Throughput Advice (32)],
[Average Window (32)]
}
Header Form: The most significant bit (0x80) of byte 0 (the first
byte) is set to 1 to indicate a QUIC long header.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1.
Throughput Advice Bit: The next bit (0x20) indicates the precense of
a throughput advice field in this packet.
Average Window Bit: The next bit (0x10) indicates the precense of
average window field in this packet.
Forward Bit: The next bit (0x8) is set by clients and indicates
whether the SCONE packet should be forwarded or consumed by the
first network element that sees it.
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
Joras & Ihlar Expires 24 April 2025 [Page 3]
Internet-Draft QUIC for network property communication October 2024
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.
Throughput Advice: The throughput advice is a 32bit unsigned integer
representing maximum sustainable throughput through the network
element. Expressed in Kb/s.
Average Window: Indicates the duration over which the bitrate is
enforced. Expressed in milliseconds.
4. Packet Protection
SCONE uses packet protection as defined for Initial packets in
section 5 of [QUIC-TLS].
SCONE packets do not have 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.
4.1. Public Salt
A publicly known salt is used to derive the secrets, specifically
scone_salt=0x6784619005cadc9bb961ec4d31b76892eb1b567e.
4.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.
Joras & Ihlar Expires 24 April 2025 [Page 4]
Internet-Draft QUIC for network property communication October 2024
5. Communication Overview
The goal of SCONE is to provide a way to communicate throughput
advice 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 SCONE
packet destined to the same endpoint IP address and port. This
packet can be parsed by any capable network element on the path. All
capable elements are able to respond to the initial packet in a
similar fashion, by creating their own SCONE packets and sending them
to the QUIC client matching the IP/port tuple being utilized by the
end-to-end QUIC connection.
+--------+ +---------+ +--------+
| QUIC | | Network | | QUIC |
| Client | | Element | | Server |
+---+----+ +----+----+ +---+----+
| | |
+----------- QUICv1/v2 ---------->|
| | |
|---- SCONE ---->|---- SCONE ---->|
|<--- SCONE -----| |
| | |
A network element that receives a SCONE packet from a client with the
forward bit set to 1 MUST forward the packet. A network element that
receives a SCONE packet with the forward bit set to 0 MAY drop it.
The QUIC client must be able to distinguish the end-to-end QUIC
version 1 or 2 packets and SCONE packets. The QUIC server does not
need to be SCONE-aware as it will ignore the packet based on the
(unknown) version number.
5.1. Use of Connection IDs
SCONE packets contain both Source and Destination Connection IDs. A
client who initiates SCONE communication sets both Source and
Destination Connection IDs to randomly generated values. A network
device that 'responds' to a SCONE 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.
Joras & Ihlar Expires 24 April 2025 [Page 5]
Internet-Draft QUIC for network property communication October 2024
6. 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.
7. 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.
8. Security Considerations
TODO Security
9. IANA Considerations
TBD - QUIC version.
10. Normative References
Joras & Ihlar Expires 24 April 2025 [Page 6]
Internet-Draft QUIC for network property communication October 2024
[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 24 April 2025 [Page 7]