From 0621fa26d9875ed14f13006064e5a6b747f7487f Mon Sep 17 00:00:00 2001 From: mirjak Date: Mon, 8 Jul 2024 15:08:31 +0200 Subject: [PATCH 1/3] Don't use the name SCONEPRO I think it's better to just talk about a new QUIC version and to not make people believe this is the one and only proposal for a new protocol. --- draft-joras-sconepro-quic-protocol-alt.md | 28 +++++++++++------------ 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/draft-joras-sconepro-quic-protocol-alt.md b/draft-joras-sconepro-quic-protocol-alt.md index 74150ee..c69d8a6 100644 --- a/draft-joras-sconepro-quic-protocol-alt.md +++ b/draft-joras-sconepro-quic-protocol-alt.md @@ -1,6 +1,6 @@ --- -title: "SCONEPRO QUIC Protocol" -abbrev: "SCONEPRO QUIC Protocol" +title: "A new QUIC version for network Exposure" +abbrev: "QUIC for network exposure" category: info docname: draft-joras-sconepro-quic-protocol-alt-latest @@ -29,30 +29,30 @@ informative: --- abstract -This document describes a wire format and a set of procedures used to +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. The network properties are intended to enable self-adaptation of video +device. This is achived 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. -The wire format in this document is defined as a new version of QUIC that -adheres to the version-independent properties of QUIC specified in RFC 8999. -Messages are sent adjacent to already established QUIC version 1 or version 2 -connections on the same UDP 4-tuple. This version of QUIC uses long headers for -all its communication, and packet protection is achieved using publicly known -keys. - --- middle # Introduction -The basic idea of SCONEPRO is to use an independent flow between a client +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. +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 @@ -74,7 +74,7 @@ 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. -# SCONEPRO QUIC Packets +# QUIC Long Header Packet Format This version of QUIC only uses long header packets with the following format: @@ -161,7 +161,7 @@ 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. # Frames -The payload of a SCONEPRO QUIC packet consists of a sequence of frames. 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. ## Padding Frame From bb917dee0cf6176a0019abc5a0824ae03b8ddc65 Mon Sep 17 00:00:00 2001 From: mirjak Date: Mon, 8 Jul 2024 17:02:17 +0200 Subject: [PATCH 2/3] Update draft-joras-sconepro-quic-protocol-alt.md --- draft-joras-sconepro-quic-protocol-alt.md | 44 +++++++++++------------ 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/draft-joras-sconepro-quic-protocol-alt.md b/draft-joras-sconepro-quic-protocol-alt.md index c69d8a6..e1833ce 100644 --- a/draft-joras-sconepro-quic-protocol-alt.md +++ b/draft-joras-sconepro-quic-protocol-alt.md @@ -211,24 +211,24 @@ Host: define format) # Communication Overview -The goal of SCONEPRO is to provide a way to communicate properties between an +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 SCONEPRO communication, a QUIC client establishes its -normal end to end connection as per usual from RFC 9000. Once this is done, the -client opportunistically sends a SCONEPRO QUIC packet destined to the same -endpoint IP address and port. This packet can be be parsed by any -SCONEPRO-capable network element on the path. A SCONEPRO-capable elements +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 be parsed by any +capable network element on the path that support this new QUIC version. These elements MAY forward these packets in the normal fashion, such that all -SCONEPRO-capable devices can see its contents. All SCONEPRO-capable elements -are able to respond in a similar fashion, by creating their own SCONEPRO QUIC -packets and sending it to the SCONEPRO QUIC client matching the IP/port tuple -being utilized by the end to end QUIC connection. +capable devices on path can see its contents. All capable elements +are able to respond in a similar fashion, by creating their own long header +packets for this QUIC version and sending it to the QUIC client matching the IP/port tuple +being utilized by the end-to-end QUIC connection. -The SCONEPRO QUIC client MUST be able to distinguish the end to end QUIC -packets and the SCONEPRO QUIC packets. This can be done by looking for the -pattern of the SCONEPRO packet, combined with trial decryption. +The QUIC client MUST be able to distinguish the end-to-end QUIC +packets version 1 or 2 and the new QUIC version packets. This can be done by looking for the +pattern of packets, combined with trial decryption. ## Use of Connection IDs SCONEPRO QUIC packets contain both Source and Destination Connection IDs. A @@ -240,29 +240,29 @@ the Source Connection ID to a randomly generated value. # On Path Verification -SCONEPRO communication MUST only be done with network elements that can be +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 SCONEPRO communication is only meant to be done with network elements +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 SCONEPRO QUIC packets are themselves carried in +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 SCONEPRO network device MUST set the Destination Connection ID Length and +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 SCONEPRO QUIC packet sent by a client. +observed new version QUIC packet sent by a client. # 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 SCONEPRO to be extended to allow for +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 SCONEPRO QUIC -client and a SCONEPRO-capable network element. Authenticity could similarly +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 @@ -281,7 +281,7 @@ TODO Security # IANA Considerations -QUIC version. +TBD - QUIC version. --- back From 1d06bda4746821892fa9ebbc97ac919861ca2692 Mon Sep 17 00:00:00 2001 From: mirjak Date: Mon, 8 Jul 2024 17:23:05 +0200 Subject: [PATCH 3/3] whitespace --- draft-joras-sconepro-quic-protocol-alt.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-joras-sconepro-quic-protocol-alt.md b/draft-joras-sconepro-quic-protocol-alt.md index e1833ce..e4868f7 100644 --- a/draft-joras-sconepro-quic-protocol-alt.md +++ b/draft-joras-sconepro-quic-protocol-alt.md @@ -222,7 +222,7 @@ endpoint IP address and port using this new version. This packet can be be parse capable network element on the path that support this new QUIC version. These elements MAY forward these packets in the normal fashion, such that all capable devices on path can see its contents. All capable elements -are able to respond in a similar fashion, by creating their own long header +are able to respond in a similar fashion, by creating their own long header packets for this QUIC version and sending it to the QUIC client matching the IP/port tuple being utilized by the end-to-end QUIC connection.