Additional rewrite

draft-joras-sconepro-quic-protocol-alt.md

@@ -1,27 +1,27 @@
 ---
-
 title: "SCONEPRO QUIC Protocol"
 abbrev: "SCONEPRO QUIC Protocol"
 category: info
 
-docname: draft-joras-sconepro-quic-protocol-latest
-submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF"
+docname: draft-joras-sconepro-quic-protocol-alt-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
 number:
 date:
 consensus: true
 v: 3
 keyword:
-
-- next generation
-- unicorn
-- sparkling distributed ledger
-  author:
-- fullname: Matt Joras
-  organization: Meta Platforms, Inc.
-  email: [email protected]
-- fullname: Marcus Ihlar
-  organization: Ericsson
-  email: [email protected]
+ - next generation
+ - unicorn
+ - sparkling distributed ledger
+author:
+ -
+    fullname: Matt Joras
+    organization: Meta Platforms, Inc.
+    email: [email protected]
+ -
+    fullname: Marcus Ihlar
+    organization: Ericsson
+    email: [email protected]
 
 normative:
 
@@ -41,6 +41,7 @@ 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
@@ -57,6 +58,7 @@ 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.
 
+
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
@@ -66,66 +68,146 @@ to a QUIC version that supports full TLS protection.
 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.
 
-# Version Field
-
-The version field of Long Headers in this QUIC version is 0x5509c337, which was
-a value chosen at random.
-
 # 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,
-Packet Type (2),
-Reserved (4),
-Version (32),
-Destination Connection ID Length (8),
-Destination Connection ID (0..160),
-Source Connection ID Length (8),
-Source Connection ID (0..160),
-Payload (..),
+  Header Form (1) = 1,
+  Fixed Bit (1) = 0,
+  Packet Type (2) = 0,
+  Reserved Bits (4),
+  Version (32),
+  Destination Connection ID Length (8),
+  Destination Connection ID (0..160),
+  Source Connection ID Length (8),
+  Source Connection ID (0..160),
+  Payload (..),
 }
+~~~~~
+
+Header Form:
 
-**Header Form:** The most significant bit (0x80) of byte 0 (the first byte) is
+: 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.
-**Packet Type** The next two bits contain a packet type. A single packet type
+
+Fixed Bit:
+
+: The next bit (0x40) of byte 0 is set to 1.
+
+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.
 
-# Initial Salt
+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.
+
+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:
 
-This version of QUIC uses an altered initial salt to derive the Initial Keys,
-specifically initial_salt=0x6784619005cadc9bb961ec4d31b76892eb1b567e
+: The Source Connection ID field follows the Source Connection ID Length field,
+  which indicates the length of this field.
 
-# HKDF Labels
+# Packet Protection
+This version of QUIC uses packet protection as defined for Initial packets in
+section 5 of [QUIC-TLS].
 
+This version of QUIC does not use packet numbers, therefore nonces are created
+by combining the intial destination connection ID with the source connection ID
+of the packet. Each SCONEPRO QUIC packet mus use a randomly generated source
+connection ID with a high probability of being unique.
+
+## Public Salt
+A publicly known salt is used to derive the secrets, specifically
+sconepro_salt=0x6784619005cadc9bb961ec4d31b76892eb1b567e.
+
+## 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.
 
 # Frames
+The payload of a SCONEPRO QUIC packet consists of a sequence of frames. Frames
+consist of a type field optionally followed by type specific payload.
+
+## Padding Frame
 
-This version of QUIC defines a set of frames that carry information related to
-network properties.
+Padding frames are defined in section 19.1 of [RFC9000] and are used to
+increase the size of a packet.
 
-## Padding
+~~~
+PADDING Frame {
+  Type (i) = 0x00,
+}
+~~~
 
-## Data
+## Data Frame
 
-## Upgrade
+~~~
+DATA Frame {
+  Type (i) = 0x01,
+  Length (i),
+  Payload (..),
+}
+~~~
 
-# Communication Overview
+Length:
+
+:  The length of the DATA Frame payload in bytes.
+
+Payload:
+
+:  SCONEPRO specific payload such as media bitrate information.
+
+## Alternative Hosts Frame
+
+Used to communicate alternative endpoints to which a client can connect to
+obtain confidentiality of the communication.
 
+~~~
+Alternative Hosts Frame {
+  Type (i) = 0x02,
+  Hosts (..),
+}
+~~~
+
+Hosts:
+
+:  A list of FQDNs (TODO Define Hosts format)
+
+# Communication Overview
 The goal of SCONEPRO 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.
@@ -136,7 +218,7 @@ 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
 MAY forward these packets in the normal fashion, such that all
-SCONEPRO-capable devices on the path can see its contents. All SCONEPRO-capable elements
+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.
@@ -147,24 +229,53 @@ pattern of the SCONEPRO packet, combined with trial decryption.
 
 # On Path Verification
 
-TODO: describe connection ID use
+SCONEPRO communication 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
+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
+separate UDP datagrams from the end to end QUIC flow, there is not an inherent
+guarantee that they were generated by a network element.
 
-# Extensibility To Provide Confidentiality and Authenticity
+A SCONEPRO 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.
 
-TODO describe QUIC V1 alternative.
+
+# 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
+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
+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.
 
 # Security Considerations
 
 TODO Security
 
+
 # IANA Considerations
 
 QUIC version.
 
+
 --- back
 
 # Acknowledgments
-
 {:numbered="false"}
 
 TODO acknowledge.