diff --git a/draft-misell-quic-bdp-token.xml b/draft-misell-quic-bdp-token.xml deleted file mode 100644 index 24ddaf1..0000000 --- a/draft-misell-quic-bdp-token.xml +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - -]> - - - QUIC Bandwidth Delay Product Tokens - - - AS207960 Cyfyngedig -
- - 13 Pen-y-lan Terrace - Caerdydd - CF23 9EU - United Kingdom - - q@as207970.net - q@magicalcodewit.ch - https://magicalcodewit.ch -
- - tsv - QUIC - - This document describes a method to store previously calculated Congestion Control parameters on a QUIC - client to allow additional capacity on high Bandwidth Delay Product paths to be used with - Careful Resume. - - - - -
- Introduction - This document describes a method for a QUIC server to send calculated Congestion Control parameters - to a client for storage and later use on a future connection with Careful Resume - . It also allows the client to inspect CC parameters, - and allows the client not use them with new connections if its aware of a significant change in the - BDP of the path. - -
- Requirements Language - 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 when, and only when, they appear in all capitals, - as shown here. -
-
-
- BDP Tokens - The address validation token is overloaded to also store CC information. This has the advantage that a - QUIC client unaware of this document will still be able to make use of this specification without - modification. QUIC defines an address validation token as an opaque blob that - the client should not inspect. This document extends this by providing some structure token, whilst - still providing fields for server specific information. - The format of a token containing BDP information is defined as follows: -
- BDP Token - -BDP Token { - Address Validation Length (i), - Address Validation (..), - BDP Data Length (i), - BDP Data Value(..), - Saved Capacity (i), - Saved RTT (i) -} - -
- The fields are as follows: -
-
Address Validation Length
-
- A variable-length integer specifying the length of the Address Validation field, in bytes. - A value of 0 indicates that the server is not using address validation and is using the token purely - for CC information. -
-
Address Validation
-
- Opaque information specific to the server that it will use for address validation. - The construction of this field MUST comply with the requirements of - section 8.1. -
-
CC Data Length
-
- A variable-length integer specifying the length of the CC Data field, in bytes. - A value of 0 indicates that the server is not using CC Data, and that the Saved Capacity and - Saved RTT fields should also be ignored. -
-
CC Data
-
- Opaque information specific to the server that it will use to prime its congestion controller state. - This field SHOULD contain expiration/lifetime information, and any additional - information that the server may need to validate that the same path is being used, such as an - endpoint token defined in . - The data MUST be signed, or otherwise processed against modification by the client. -
-
Capacity
-
- The estimated capacity of the path in bytes, encoded as a variable-length integer. - The exact CC state value used is left to server preference. -
-
RTT
-
- The RTT of the path in microseconds, encoded as a variable-length integer. - The exact CC state value used is left to server preference. -
-
- The Capacity and RTT fields are merely hints to the client and the server - MUST not use these fields when priming its congestion controller state. If it wishes - to use these parameters it will have to also include them in its CC Data structure, as data in this - field is protected against modification by the client. -
-
- Extension signalling - The server can send the above extended BDP token to all clients without further negotiation. However - a client needs some way to know that there is meaningful structure to a token its received from the - server. To this end a new transport parameter is defined. -
-
bdp_token (0xTBD)
-
- The bdp_token transport parameter is a boolean value that indicates that the server is using - BDP tokens. It can have the following values:
- - 0, default value: BDP Tokens are not in use.
- - 1: BDP Tokens are in use. -
-
-
- -
- IANA Considerations -
- QUIC Transport Parameters - Per this document, one new entry has been added to the "QUIC Transport Parameters" registry defined in - section 22.3. This entry is defined below: - - New entries - - - - - - - - - - - - - - - - -
ValueStatusSpecificationParameter name
0xTBDProvisionalThis documentbdp_frame
-
-
- -
- Security Considerations - The CC Data field MUST be protected against manipulation by malicious clients. - A client that can modify CC calculations could otherwise cause overload of the network path. - The Capacity and RTT fields are hints to the client and not protected from modification by a client. The - server MUST ignore when processing a received BDP token. -
- - - - - References - - Normative References - - - - - - - - - Informative References - - - - - - diff --git a/draft-misell-quic-ex-token.xml b/draft-misell-quic-ex-token.xml new file mode 100644 index 0000000..469b631 --- /dev/null +++ b/draft-misell-quic-ex-token.xml @@ -0,0 +1,365 @@ + + + + + + +]> + + + Extensible Address Validation Tokens for QUIC + + + AS207960 Cyfyngedig +
+ + 13 Pen-y-lan Terrace + Caerdydd + CF23 9EU + United Kingdom + + q@as207970.net + q@magicalcodewit.ch + https://magicalcodewit.ch +
+ + tsv + QUIC + + This document describes a method to extend QUIC address validation tokens to include structured data that + a client can parse and make use of. The initial application envisioned in this document is signalling + congestion control parameters for use with Careful Resume. + + + + +
+ Introduction + This document defines a method to extend QUIC address validation tokens to have structure, so that a + client can parse them, and optionally make use of additional information within the token, depending + on the nature of the extensions in use. + The initial application for this is envisioned to be allowing a QUIC server to send calculated Congestion + Control parameters to a client for storage and later use on a future connection with Careful Resume + . + +
+ Requirements Language + 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 when, and only when, they appear in all capitals, + as shown here. +
+
+
+ Extensible Tokens + QUIC defines an address validation token as an opaque blob that + the client should not inspect. This document extends this by providing structure to the token, allowing + arbitrary fields to be defined on the token by this and future documents. + A QUIC client unaware of this document will still be able to make use of extensible tokens without + modification, although it will do nothing but pass the entire token back to the server unmodified. + The format of an extensible token is defined as follows: +
+ Extensible Token + +
+ The fields are as follows: +
+
Address Validation Length
+
+ A variable-length integer specifying the length of the Address Validation field, in bytes. + A value of 0 indicates that the server is not using address validation and is using the token purely + for extensible information. +
+
Address Validation
+
+ Opaque information specific to the server that it will use for address validation. + The construction of this field MUST comply with the requirements of + section 8.1. +
+
Extension ID
+
+ A variable-length integer specifying the ID of the extension. The registry for these IDs is defined + in the IANA Considerations section of this document. +
+
Extension Data Length
+
+ A variable-length integer specifying the length of the Extension Data field, in bytes. +
+
Extension Data
+
+ A byte field containing the data for the extension. +
+
+ Extension ID, Extension Data Length, and Extension Data can be repeated as many times as needed to + include desired extensions. Extension IDs MUST NOT appear multiple times in a token. +
+ Extensible token signalling + The server can send extended tokens to all clients without further negotiation. However a client needs + some way to know that there is meaningful structure to a token its received from the server. To this + end a new transport parameter is defined. +
+
ex_token (04143414213370002)
+
+ The ex_token transport parameter is a boolean value that indicates that the server is using + extensible tokens. It can have the following values:
+ - 0, default value: Extensible Tokens are not in use.
+ - 1: Extensible Tokens are in use. +
+
+
+
+ Invalid Extensible tokens + If the server is unable to decode the token received from the client, + or vise versa, this MUST be treated as the connection error + EX_TOKEN_ERROR (0x4143414213370002). +
+
+ Extension design + As an extensible token is designed to be presented to clients that may not be aware of what an + extensible token is, all extensions defined for extensible tokens MUST be designed + such that it can handle its data being echoed back to the server unmodified on a future connection. +
+
+
+ BDP Tokens + This document defines the BDP_TOKEN extension, designed to Congestion Control information for use + in Careful Resume . + The format of a token extension containing BDP information is defined as follows: +
+ BDP Token + +
+ The fields are as follows: +
+
Private Data Length
+
+ A variable-length integer specifying the length of the Private Data field, in bytes. A value of 0 + indicates that the server does not intend to store Congestion Control data on the client, and that + the Capacity and RTT fields are merely informative. +
+
Private Data
+
+ Opaque information specific to the server that it will use to prime its congestion controller state. + This field SHOULD contain expiration/lifetime information, and any additional + information that the server may need to validate that the same path is being used, such as an + endpoint token as defined in Careful Resume . + + The data MUST be signed, or otherwise protected against modification by the client. + If the data contains information that could potentially be used to fingerprint the client, it + MUST be encrypted, or otherwise protected against inspection by wire observers. + + An example method for protecting the Private Data field is provided in . +
+
Capacity
+
+ The estimated capacity of the path in bytes (congestion window), + encoded as a variable-length integer. +
+
RTT
+
+ The RTT of the path in microseconds, encoded as a variable-length integer. +
+
Requested capacity
+
+ In a token sent by the server, this field is set to the same value as the Capacity field. If the + client becomes aware of a change in the available bandwidth of the path, it can adjust this field to + request a lower capacity be used by the server when priming its congestion controller state. +
+
+
+ Client interaction + If the client becomes aware of a change in the available bandwidth of the path, it can use the + Requested Capacity field to signal to the server a change it its available bandwidth. The server + MUST not accept a value higher than that of the Capacity field, as this could cause + an overload of the network path. + + If the client sets the Requested Bandwidth field to 0 then it is signalling that the server should + not attempt to prime its congestion controller from previous state and should instead treat this + connection as an entirely new congestion control context. +
+
+ Invalid BDP tokens + If a server or client is unable to decode the token received as a valid BDP token then this + MUST be treated as a connection error BDP_TOKEN_ERROR (0x4143414213370003). + A token which is merely expired MUST NOT trigger a connection error, instead it + should be silently discarded. +
+
+ +
+ IANA Considerations +
+ QUIC Transport Parameters + Per this document, one new entry has been added to the "QUIC Transport Parameters" registry defined in + section 22.3. This entry is defined below: + + New Transport Parameter entries + + + + + + + + + + + + + + + + +
ValueStatusSpecificationParameter name
0x41434142 13370002ProvisionalThis documentex_token
+
+
+ QUIC Transport Error Codes + Per this document, two new entries have been added to the "QUIC Transport Error Codes" registry defined in + section 22.5. This entry is defined below: + + New Transport Error Code entries + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueStatusCodeDescriptionSpecification
0x41434142 13370002ProvisionalEX_TOKEN_ERRORThe extensible token received is invalid.This document
0x41434142 13370003ProvisionalBDP_TOKEN_ERRORThe BDP token received is invalid.This document
+
+
+ QUIC Extensible Token Extension IDs + Per this document, a new registry for "QUIC Extensible Token Extension IDs" is created under the + "QUIC" heading defined in section 22. + In addition to the fields listed in section 22.1.1, permanent registrations + in this registry MUST include the following field: +
+
Extension name
+
A short mnemonic for the extension type.
+
+ + Initial QUIC Extensible Token Extension IDs Entries + + + + + + + + + + + + + + +
ValueExtension nameSpecification
0x01BDP_TOKEN
+ Each value of the form 31 * N + 26 for integer values of N (that is, 26, 57, 88, ...) are reserved + for private use; these values are to be treated as opaque blobs meaningful only to the server + operator. + Each value of the form 31 * N + 27 for integer values of N (that is, 27, 58, 89, ...) are reserved; + these values MUST NOT be assigned by IANA and MUST NOT appear in the + listing of assigned values. +
+
+ +
+ Security Considerations + The Congestion Control data MUST be protected against manipulation by malicious or + mis-behaving clients. A client that can modify Congestion Control data could cause an overload of the + network path. +
+ + + + + References + + Normative References + + + + + + + + + Informative References + + + + + + +
+ Example method for protecting the BDP Token's Private Data Field + This section is non-normative. + Consider the following private data structure: +
+ BDP Private Data + +
+ This structure contains information that could be used to track a client (its previous IP address), and + therefore MUST be protected from inspection by wire observers. Additionally the Capacity + and RTT fields MUST be protected from modification by a client. + To this end this example uses the ChaCha20-Poly1305 cipher with additional data. + The ChaCha20-Poly1305 cipher encrypts data, and protects the encrypted data as well as additional + unencrypted data against modification. + The additional data has the following structure: +
+ BDP Additional Data + +
+ After encryption the 12 byte nonce is appended to the Private Data structure to allow the encryption + to be reversed when the token is later used. +
+ +