From 509952994b914d27469cd19ef47503cf2a6ce7cb Mon Sep 17 00:00:00 2001 From: Q Date: Mon, 6 May 2024 20:17:01 +0100 Subject: [PATCH] Script updating gh-pages from 5945f91. [ci skip] --- draft-misell-quic-ex-token.html | 1633 +++++++++++++++++++++++++++++++ draft-misell-quic-ex-token.txt | 393 ++++++++ index.html | 48 + 3 files changed, 2074 insertions(+) create mode 100644 draft-misell-quic-ex-token.html create mode 100644 draft-misell-quic-ex-token.txt diff --git a/draft-misell-quic-ex-token.html b/draft-misell-quic-ex-token.html new file mode 100644 index 0000000..e064294 --- /dev/null +++ b/draft-misell-quic-ex-token.html @@ -0,0 +1,1633 @@ + + + + + + +Extensible Address Validation Tokens for QUIC + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftQUIC BDP TokensMarch 2024
MisellExpires 5 September 2024[Page]
+
+
+
+
Workgroup:
+
QUIC
+
Internet-Draft:
+
draft-misell-quic-ex-token-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Author:
+
+
+
Q. Misell
+
AS207960
+
+
+
+
+

Extensible Address Validation Tokens for QUIC

+
+

Abstract

+

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.

+
+
+
+

+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 5 September 2024.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+

+1. 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 + [I-D.ietf-tsvwg-careful-resume].

+
+

+1.1. 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 [BCP14] when, and only when, they appear in all capitals, + as shown here.

+
+
+
+

+2. Extensible Tokens +

+

QUIC [RFC9000] 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:

+
+
+
+BDP Token {
+    Address Validation Length (i),
+    Address Validation (..),
+    Extension ID (i),
+    Extension Data Length (i),
+    Extension Data (..),
+    ...
+}
+
+
+
Figure 1: +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 + [RFC9000] 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.

+
+

+2.1. 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. +
+
+
+
+
+

+2.2. 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).

+
+
+

+2.3. 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.

+
+
+
+
+

+3. BDP Tokens +

+

This document defines the BDP_TOKEN extension, designed to Congestion Control information for use + in Careful Resume [I-D.ietf-tsvwg-careful-resume].

+

The format of a token extension containing BDP information is defined as follows:

+
+
+
+BDP Token {
+    Private Data Length (i),
+    Private Data (..),
+    Capacity (i),
+    RTT (i),
+    Requested Capacity (i),
+}
+
+
+
Figure 2: +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 [I-D.ietf-tsvwg-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 Appendix A. +
+
+
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. +
+
+
+
+

+3.1. 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.

+
+
+

+3.2. 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.

+
+
+
+
+
+

+4. IANA Considerations +

+
+

+4.1. QUIC Transport Parameters +

+

Per this document, one new entry has been added to the "QUIC Transport Parameters" registry defined in + [RFC9000] section 22.3. This entry is defined below:

+ + + + + + + + + + + + + + + + + + +
+Table 1: +New Transport Parameter entries +
ValueStatusSpecificationParameter name
0x41434142 13370002ProvisionalThis documentex_token
+
+
+

+4.2. QUIC Transport Error Codes +

+

Per this document, two new entries have been added to the "QUIC Transport Error Codes" registry defined in + [RFC9000] section 22.5. This entry is defined below:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 2: +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
+
+
+

+4.3. 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 [RFC9000] section 22.

+

In addition to the fields listed in [RFC9000] section 22.1.1, permanent registrations + in this registry MUST include the following field:

+
+
Extension name
+
A short mnemonic for the extension type. +
+
+
+ + + + + + + + + + + + + + + + +
+Table 3: +Initial QUIC Extensible Token Extension IDs Entries +
ValueExtension nameSpecification
0x01BDP_TOKEN + Section 3 +
+

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.

+
+
+
+
+
+

+5. 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.

+
+
+
+

+6. References +

+
+

+6.1. Normative References +

+
+
[BCP14]
+
+
+ Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, .
+
+ Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, .
+<https://www.rfc-editor.org/info/bcp14> +
+
+
[RFC9000]
+
+Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/info/rfc9000>.
+
+
+
+
+

+6.2. Informative References +

+
+
[I-D.ietf-tsvwg-careful-resume]
+
+Kuhn, N., Emile, S., Fairhurst, G., Secchi, R., and C. Huitema, "Convergence of Congestion Control from Retained State", Work in Progress, Internet-Draft, draft-ietf-tsvwg-careful-resume-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-careful-resume-07>.
+
+
[RFC8439]
+
+Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, , <https://www.rfc-editor.org/info/rfc8439>.
+
+
+
+
+
+
+

+Appendix A. Example method for protecting the BDP Token's Private Data Field +

+

This section is non-normative.

+

Consider the following private data structure:

+
+
+
+Private Data {
+    IP Address (16 bytes),
+    Expiry Timestamp (8 bytes)
+}
+
+
+
Figure 3: +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 [RFC8439] 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:

+
+
+
+Additional Data {
+    Saved Capacity (8 bytes),
+    Saved RTT (16 bytes)
+}
+
+
+
Figure 4: +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.

+
+
+
+
+

+Author's Address +

+
+
Q Misell
+
AS207960 Cyfyngedig
+
13 Pen-y-lan Terrace
+
Caerdydd
+
CF23 9EU
+
United Kingdom
+ +
+URI: +https://magicalcodewit.ch +
+
+
+
+ + + diff --git a/draft-misell-quic-ex-token.txt b/draft-misell-quic-ex-token.txt new file mode 100644 index 0000000..ef3b31d --- /dev/null +++ b/draft-misell-quic-ex-token.txt @@ -0,0 +1,393 @@ + + + + +QUIC Q. Misell +Internet-Draft AS207960 +Intended status: Standards Track 4 March 2024 +Expires: 5 September 2024 + + + Extensible Address Validation Tokens for QUIC + draft-misell-quic-ex-token-latest + +Abstract + + 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. + +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 5 September 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 + 1.1. Requirements Language + 2. Extensible Tokens + 2.1. Extensible token signalling + 2.2. Invalid Extensible tokens + 2.3. Extension design + 3. BDP Tokens + 3.1. Client interaction + 3.2. Invalid BDP tokens + 4. IANA Considerations + 4.1. QUIC Transport Parameters + 4.2. QUIC Transport Error Codes + 4.3. QUIC Extensible Token Extension IDs + 5. Security Considerations + 6. References + 6.1. Normative References + 6.2. Informative References + Appendix A. Example method for protecting the BDP Token's Private + Data Field + Author's Address + +1. 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 + [I-D.ietf-tsvwg-careful-resume]. + +1.1. 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 [BCP14] when, and only + when, they appear in all capitals, as shown here. + +2. Extensible Tokens + + QUIC [RFC9000] 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: + + BDP Token { + Address Validation Length (i), + Address Validation (..), + Extension ID (i), + Extension Data Length (i), + Extension Data (..), + ... + } + + Figure 1: 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 [RFC9000] 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. + +2.1. 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. + +2.2. 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). + +2.3. 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. + +3. BDP Tokens + + This document defines the BDP_TOKEN extension, designed to Congestion + Control information for use in Careful Resume + [I-D.ietf-tsvwg-careful-resume]. + + The format of a token extension containing BDP information is defined + as follows: + + BDP Token { + Private Data Length (i), + Private Data (..), + Capacity (i), + RTT (i), + Requested Capacity (i), + } + + Figure 2: 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 [I-D.ietf-tsvwg-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 Appendix A. + + 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. + +3.1. 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. + +3.2. 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. + +4. IANA Considerations + +4.1. QUIC Transport Parameters + + Per this document, one new entry has been added to the "QUIC + Transport Parameters" registry defined in [RFC9000] section 22.3. + This entry is defined below: + + +============+=============+===============+================+ + | Value | Status | Specification | Parameter name | + +============+=============+===============+================+ + | 0x41434142 | Provisional | This document | ex_token | + | 13370002 | | | | + +------------+-------------+---------------+----------------+ + + Table 1: New Transport Parameter entries + +4.2. QUIC Transport Error Codes + + Per this document, two new entries have been added to the "QUIC + Transport Error Codes" registry defined in [RFC9000] section 22.5. + This entry is defined below: + + +==========+===========+=================+===========+=============+ + |Value |Status | Code |Description|Specification| + +==========+===========+=================+===========+=============+ + |0x41434142|Provisional| EX_TOKEN_ERROR |The |This document| + |13370002 | | |extensible | | + | | | |token | | + | | | |received is| | + | | | |invalid. | | + +----------+-----------+-----------------+-----------+-------------+ + |0x41434142|Provisional| BDP_TOKEN_ERROR |The BDP |This document| + |13370003 | | |token | | + | | | |received is| | + | | | |invalid. | | + +----------+-----------+-----------------+-----------+-------------+ + + Table 2: New Transport Error Code entries + +4.3. 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 + [RFC9000] section 22. + + In addition to the fields listed in [RFC9000] section 22.1.1, + permanent registrations in this registry MUST include the following + field: + + Extension name A short mnemonic for the extension type. + + +=======+================+===============+ + | Value | Extension name | Specification | + +=======+================+===============+ + | 0x01 | BDP_TOKEN | Section 3 | + +-------+----------------+---------------+ + + Table 3: Initial QUIC Extensible Token + Extension IDs Entries + + 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. + +5. 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. + +6. References + +6.1. Normative References + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, May 2017. + + + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + . + +6.2. Informative References + + [I-D.ietf-tsvwg-careful-resume] + Kuhn, N., Emile, S., Fairhurst, G., Secchi, R., and C. + Huitema, "Convergence of Congestion Control from Retained + State", Work in Progress, Internet-Draft, draft-ietf- + tsvwg-careful-resume-07, 16 February 2024, + . + + [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, + . + +Appendix A. Example method for protecting the BDP Token's Private Data + Field + + This section is non-normative. + + Consider the following private data structure: + + Private Data { + IP Address (16 bytes), + Expiry Timestamp (8 bytes) + } + + Figure 3: 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 [RFC8439] 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: + + Additional Data { + Saved Capacity (8 bytes), + Saved RTT (16 bytes) + } + + Figure 4: 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. + +Author's Address + + Q Misell + AS207960 Cyfyngedig + 13 Pen-y-lan Terrace + Caerdydd + CF23 9EU + United Kingdom + Email: q@as207970.net, q@magicalcodewit.ch + URI: https://magicalcodewit.ch diff --git a/index.html b/index.html index e69de29..6010950 100644 --- a/index.html +++ b/index.html @@ -0,0 +1,48 @@ + + + + TheEnbyperor/quic-bdp-token root preview + + + + +

Editor's drafts for root branch of TheEnbyperor/quic-bdp-token

+

View saved issues, or the latest GitHub issues and pull requests in the repo.

+ + + + + + + + +
QUIC BDP Tokensplain textdatatrackerdiff with last submission
+ + +