From a8df254a1601ea7fff9c316951c1a05cb7cc5e11 Mon Sep 17 00:00:00 2001 From: Cameron Bytheway Date: Fri, 10 Jan 2025 18:14:07 -0700 Subject: [PATCH] ci: create .duvet/config.toml --- .duvet/.gitignore | 1 + .duvet/config.toml | 24 ++ .../exceptions/recovery/6.2.2.toml | 0 .../exceptions/recovery/6.2.4.toml | 0 .../exceptions/recovery/6.3.toml | 0 .../exceptions/recovery/7.3.2.toml | 0 .../exceptions/recovery/7.3.3.toml | 0 .../exceptions/recovery/7.6.2.toml | 0 {specs => .duvet}/exceptions/recovery/7.toml | 0 {specs => .duvet}/exceptions/rfc8312/4.6.toml | 0 {specs => .duvet}/exceptions/rfc8899/1.3.toml | 0 {specs => .duvet}/exceptions/rfc8899/2.toml | 0 {specs => .duvet}/exceptions/rfc8899/3.toml | 0 {specs => .duvet}/exceptions/rfc8899/4.1.toml | 0 {specs => .duvet}/exceptions/rfc8899/4.4.toml | 0 .../exceptions/rfc8899/5.1.1.toml | 0 .../exceptions/rfc8899/5.3.1.toml | 0 .../exceptions/rfc8899/6.1.1.toml | 0 .../exceptions/rfc8899/6.1.4.toml | 0 .../exceptions/rfc8899/6.1.5.toml | 0 .../exceptions/rfc8899/6.1.6.toml | 0 {specs => .duvet}/exceptions/rfc8899/6.1.toml | 0 .../exceptions/rfc8899/6.2.1.3.toml | 0 .../exceptions/rfc8899/6.2.1.4.toml | 0 .../exceptions/rfc8899/6.2.2.4.toml | 0 .../exceptions/rfc8899/6.2.2.toml | 0 .../exceptions/rfc8899/6.2.3.3.toml | 0 {specs => .duvet}/exceptions/rfc8899/6.2.toml | 0 {specs => .duvet}/exceptions/tls/4.1.2.toml | 0 {specs => .duvet}/exceptions/tls/4.4.toml | 0 {specs => .duvet}/exceptions/tls/4.5.toml | 0 {specs => .duvet}/exceptions/tls/4.7.toml | 0 {specs => .duvet}/exceptions/tls/5.1.toml | 0 {specs => .duvet}/exceptions/tls/5.2.toml | 0 {specs => .duvet}/exceptions/tls/5.3.toml | 0 {specs => .duvet}/exceptions/tls/5.4.1.toml | 0 {specs => .duvet}/exceptions/tls/6.2.toml | 0 {specs => .duvet}/exceptions/tls/6.3.toml | 0 {specs => .duvet}/exceptions/tls/6.4.toml | 0 {specs => .duvet}/exceptions/tls/6.6.toml | 0 {specs => .duvet}/exceptions/tls/8.1.toml | 0 {specs => .duvet}/exceptions/tls/8.2.toml | 0 {specs => .duvet}/exceptions/tls/8.3.toml | 0 {specs => .duvet}/exceptions/tls/8.4.toml | 0 {specs => .duvet}/exceptions/tls/9.2.toml | 0 {specs => .duvet}/exceptions/tls/9.4.toml | 0 {specs => .duvet}/exceptions/tls/9.6.toml | 0 .../exceptions/transport/10.3.1.toml | 0 .../exceptions/transport/10.3.2.toml | 0 .../exceptions/transport/10.3.toml | 0 .../exceptions/transport/19.15.toml | 0 .../exceptions/transport/19.16.toml | 0 .../exceptions/transport/2.2.toml | 0 .../exceptions/transport/5.1.1.toml | 0 .../exceptions/transport/5.1.2.toml | 0 .../exceptions/transport/5.1.toml | 0 .../exceptions/transport/5.2.3.toml | 0 .../exceptions/transport/7.4.1.toml | 0 {specs => .duvet}/exceptions/transport/7.toml | 0 .../exceptions/transport/8.2.3.toml | 0 .../exceptions/transport/8.2.4.toml | 0 .../exceptions/transport/9.4.toml | 0 .../rfc/rfc8312/section-4.2.toml | 43 ++ .../rfc/rfc8312/section-4.3.toml | 18 + .../rfc/rfc8312/section-4.4.toml | 28 ++ .../rfc/rfc8312/section-4.5.toml | 27 ++ .../rfc/rfc8312/section-4.6.toml | 54 +++ .../rfc/rfc8312/section-4.8.toml | 34 ++ .../rfc/rfc8312/section-5.1.toml | 90 ++++ .../rfc/rfc8312/section-5.8.toml | 19 + .../rfc/rfc8899/section-1.3.toml | 68 +++ .../rfc/rfc8899/section-2.toml | 157 +++++++ .../rfc/rfc8899/section-3.toml | 389 ++++++++++++++++++ .../rfc/rfc8899/section-4.1.toml | 87 ++++ .../rfc/rfc8899/section-4.2.toml | 29 ++ .../rfc/rfc8899/section-4.3.toml | 69 ++++ .../rfc/rfc8899/section-4.4.toml | 72 ++++ .../rfc/rfc8899/section-4.5.toml | 20 + .../rfc/rfc8899/section-4.6.1.toml | 81 ++++ .../rfc/rfc8899/section-4.6.2.toml | 111 +++++ .../rfc/rfc8899/section-5.1.1.toml | 71 ++++ .../rfc/rfc8899/section-5.1.2.toml | 61 +++ .../rfc/rfc8899/section-5.2.toml | 139 +++++++ .../rfc/rfc8899/section-5.3.1.toml | 45 ++ .../rfc/rfc8899/section-5.3.2.toml | 24 ++ .../rfc/rfc8899/section-5.toml | 59 +++ .../rfc/rfc8899/section-6.1.1.toml | 20 + .../rfc/rfc8899/section-6.1.4.toml | 10 +- .../rfc/rfc8899/section-6.1.5.toml | 10 +- .../rfc/rfc8899/section-6.1.6.toml | 28 ++ .../rfc/rfc8899/section-6.1.toml | 32 ++ .../rfc/rfc8899/section-6.2.1.3.toml | 6 +- .../rfc/rfc8899/section-6.2.1.4.toml | 30 ++ .../rfc/rfc8899/section-6.2.2.4.toml | 29 ++ .../rfc/rfc8899/section-6.2.2.toml | 21 + .../rfc/rfc8899/section-6.2.3.3.toml | 6 +- .../rfc/rfc8899/section-6.2.toml | 42 ++ .../rfc/rfc8899/section-8.toml | 110 +++++ .../rfc/rfc9000/section-10.1.2.toml | 39 ++ .../rfc/rfc9000/section-10.1.toml | 38 ++ .../rfc/rfc9000/section-10.2.1.toml | 114 +++++ .../rfc/rfc9000/section-10.2.2.toml | 55 +++ .../rfc/rfc9000/section-10.2.3.toml | 131 ++++++ .../rfc/rfc9000/section-10.2.toml | 85 ++++ .../rfc/rfc9000/section-10.3.1.toml | 82 ++++ .../rfc/rfc9000/section-10.3.2.toml | 98 +++++ .../rfc/rfc9000/section-10.3.3.toml | 37 ++ .../rfc/rfc9000/section-10.3.toml | 214 ++++++++++ .../rfc/rfc9000/section-10.toml | 23 ++ .../rfc/rfc9000/section-11.1.toml | 62 +++ .../rfc/rfc9000/section-11.2.toml | 38 ++ .../rfc/rfc9000/section-11.toml | 55 +++ .../rfc/rfc9000/section-12.2.toml | 104 +++++ .../rfc/rfc9000/section-12.3.toml | 113 +++++ .../rfc/rfc9000/section-12.4.toml | 195 +++++++++ .../rfc/rfc9000/section-12.5.toml | 75 ++++ .../rfc/rfc9000/section-13.1.toml | 35 ++ .../rfc/rfc9000/section-13.2.1.toml | 145 +++++++ .../rfc/rfc9000/section-13.2.2.toml | 45 ++ .../rfc/rfc9000/section-13.2.3.toml | 103 +++++ .../rfc/rfc9000/section-13.2.5.toml | 46 +++ .../rfc/rfc9000/section-13.2.6.toml | 38 ++ .../rfc/rfc9000/section-13.2.7.toml | 21 + .../rfc/rfc9000/section-13.2.toml | 26 ++ .../rfc/rfc9000/section-13.3.toml | 186 +++++++++ .../rfc/rfc9000/section-13.4.1.toml | 44 ++ .../rfc/rfc9000/section-13.4.2.1.toml | 54 +++ .../rfc/rfc9000/section-13.4.2.2.toml | 47 +++ .../rfc/rfc9000/section-13.4.2.toml | 45 ++ .../rfc/rfc9000/section-13.toml | 48 +++ .../rfc/rfc9000/section-14.1.toml | 80 ++++ .../rfc/rfc9000/section-14.2.1.toml | 92 +++++ .../rfc/rfc9000/section-14.2.toml | 97 +++++ .../rfc/rfc9000/section-14.3.toml | 26 ++ .../rfc/rfc9000/section-14.4.toml | 24 ++ .../rfc/rfc9000/section-14.toml | 82 ++++ .../rfc/rfc9000/section-15.toml | 61 +++ .../rfc/rfc9000/section-17.1.toml | 74 ++++ .../rfc/rfc9000/section-17.2.1.toml | 121 ++++++ .../rfc/rfc9000/section-17.2.2.toml | 105 +++++ .../rfc/rfc9000/section-17.2.3.toml | 94 +++++ .../rfc/rfc9000/section-17.2.4.toml | 66 +++ .../rfc/rfc9000/section-17.2.5.1.toml | 61 +++ .../rfc/rfc9000/section-17.2.5.2.toml | 69 ++++ .../rfc/rfc9000/section-17.2.5.3.toml | 77 ++++ .../rfc/rfc9000/section-17.2.5.toml | 44 ++ .../rfc/rfc9000/section-17.2.toml | 204 +++++++++ .../rfc/rfc9000/section-17.3.1.toml | 101 +++++ .../rfc/rfc9000/section-17.4.toml | 110 +++++ .../rfc/rfc9000/section-18.2.toml | 291 +++++++++++++ .../rfc/rfc9000/section-19.10.toml | 79 ++++ .../rfc/rfc9000/section-19.11.toml | 76 ++++ .../rfc/rfc9000/section-19.12.toml | 31 ++ .../rfc/rfc9000/section-19.13.toml | 44 ++ .../rfc/rfc9000/section-19.14.toml | 49 +++ .../rfc/rfc9000/section-19.15.toml | 157 +++++++ .../rfc/rfc9000/section-19.16.toml | 74 ++++ .../rfc/rfc9000/section-19.17.toml | 35 ++ .../rfc/rfc9000/section-19.18.toml | 30 ++ .../rfc/rfc9000/section-19.19.toml | 67 +++ .../rfc/rfc9000/section-19.20.toml | 36 ++ .../rfc/rfc9000/section-19.21.toml | 60 +++ .../rfc/rfc9000/section-19.3.1.toml | 70 ++++ .../rfc/rfc9000/section-19.3.toml | 85 ++++ .../rfc/rfc9000/section-19.4.toml | 46 +++ .../rfc/rfc9000/section-19.5.toml | 50 +++ .../rfc/rfc9000/section-19.6.toml | 56 +++ .../rfc/rfc9000/section-19.7.toml | 66 +++ .../rfc/rfc9000/section-19.8.toml | 86 ++++ .../rfc/rfc9000/section-19.9.toml | 48 +++ .../rfc/rfc9000/section-2.1.toml | 54 +++ .../rfc/rfc9000/section-2.2.toml | 63 +++ .../rfc/rfc9000/section-2.3.toml | 24 ++ .../rfc/rfc9000/section-21.11.toml | 53 +++ .../rfc/rfc9000/section-21.12.toml | 21 + .../rfc/rfc9000/section-21.3.toml | 22 + .../rfc/rfc9000/section-21.4.toml | 18 + .../rfc/rfc9000/section-21.5.3.toml | 26 ++ .../rfc/rfc9000/section-21.5.6.toml | 102 +++++ .../rfc/rfc9000/section-21.5.toml | 70 ++++ .../rfc/rfc9000/section-21.6.toml | 31 ++ .../rfc/rfc9000/section-21.7.toml | 34 ++ .../rfc/rfc9000/section-21.9.toml | 39 ++ .../rfc/rfc9000/section-22.1.1.toml | 48 +++ .../rfc/rfc9000/section-22.1.2.toml | 65 +++ .../rfc/rfc9000/section-22.1.3.toml | 81 ++++ .../rfc/rfc9000/section-22.1.4.toml | 50 +++ .../rfc/rfc9000/section-22.2.toml | 37 ++ .../rfc/rfc9000/section-22.3.toml | 89 ++++ .../rfc/rfc9000/section-22.4.toml | 48 +++ .../rfc/rfc9000/section-22.5.toml | 105 +++++ .../rfc/rfc9000/section-3.1.toml | 101 +++++ .../rfc/rfc9000/section-3.2.toml | 134 ++++++ .../rfc/rfc9000/section-3.3.toml | 51 +++ .../rfc/rfc9000/section-3.5.toml | 104 +++++ .../rfc/rfc9000/section-4.1.toml | 99 +++++ .../rfc/rfc9000/section-4.2.toml | 58 +++ .../rfc/rfc9000/section-4.4.toml | 26 ++ .../rfc/rfc9000/section-4.5.toml | 71 ++++ .../rfc/rfc9000/section-4.6.toml | 93 +++++ .../rfc/rfc9000/section-4.toml | 32 ++ .../rfc/rfc9000/section-5.1.1.toml | 160 +++++++ .../rfc/rfc9000/section-5.1.2.toml | 121 ++++++ .../rfc/rfc9000/section-5.1.toml | 85 ++++ .../rfc/rfc9000/section-5.2.1.toml | 40 ++ .../rfc/rfc9000/section-5.2.2.toml | 100 +++++ .../rfc/rfc9000/section-5.2.3.toml | 47 +++ .../rfc/rfc9000/section-5.2.toml | 55 +++ .../rfc/rfc9000/section-6.1.toml | 36 ++ .../rfc/rfc9000/section-6.2.toml | 48 +++ .../rfc/rfc9000/section-6.3.toml | 31 ++ .../rfc/rfc9000/section-6.toml | 29 ++ .../rfc/rfc9000/section-7.2.toml | 115 ++++++ .../rfc/rfc9000/section-7.3.toml | 130 ++++++ .../rfc/rfc9000/section-7.4.1.toml | 192 +++++++++ .../rfc/rfc9000/section-7.4.2.toml | 30 ++ .../rfc/rfc9000/section-7.4.toml | 68 +++ .../rfc/rfc9000/section-7.5.toml | 78 ++++ .../rfc/rfc9000/section-7.toml | 85 ++++ .../rfc/rfc9000/section-8.1.1.toml | 17 + .../rfc/rfc9000/section-8.1.2.toml | 71 ++++ .../rfc/rfc9000/section-8.1.3.toml | 241 +++++++++++ .../rfc/rfc9000/section-8.1.4.toml | 114 +++++ .../rfc/rfc9000/section-8.1.toml | 113 +++++ .../rfc/rfc9000/section-8.2.1.toml | 96 +++++ .../rfc/rfc9000/section-8.2.2.toml | 83 ++++ .../rfc/rfc9000/section-8.2.3.toml | 29 ++ .../rfc/rfc9000/section-8.2.4.toml | 60 +++ .../rfc/rfc9000/section-8.2.toml | 61 +++ .../rfc/rfc9000/section-8.toml | 31 ++ .../rfc/rfc9000/section-9.1.toml | 24 ++ .../rfc/rfc9000/section-9.2.toml | 33 ++ .../rfc/rfc9000/section-9.3.2.toml | 52 +++ .../rfc/rfc9000/section-9.3.3.toml | 63 +++ .../rfc/rfc9000/section-9.3.toml | 77 ++++ .../rfc/rfc9000/section-9.4.toml | 78 ++++ .../rfc/rfc9000/section-9.5.toml | 133 ++++++ .../rfc/rfc9000/section-9.6.1.toml | 55 +++ .../rfc/rfc9000/section-9.6.2.toml | 77 ++++ .../rfc/rfc9000/section-9.6.3.toml | 95 +++++ .../rfc/rfc9000/section-9.6.toml | 27 ++ .../rfc/rfc9000/section-9.7.toml | 36 ++ .../rfc/rfc9000/section-9.toml | 104 +++++ .../rfc/rfc9001/section-4.1.2.toml | 31 ++ .../rfc/rfc9001/section-4.1.3.toml | 123 ++++++ .../rfc/rfc9001/section-4.1.4.toml | 84 ++++ .../rfc/rfc9001/section-4.2.toml | 30 ++ .../rfc/rfc9001/section-4.3.toml | 53 +++ .../rfc/rfc9001/section-4.4.toml | 86 ++++ .../rfc/rfc9001/section-4.5.toml | 37 ++ .../rfc/rfc9001/section-4.6.1.toml | 47 +++ .../rfc/rfc9001/section-4.6.2.toml | 55 +++ .../rfc/rfc9001/section-4.7.toml | 21 + .../rfc/rfc9001/section-4.8.toml | 42 ++ .../rfc/rfc9001/section-4.9.1.toml | 44 ++ .../rfc/rfc9001/section-4.9.2.toml | 6 +- .../rfc/rfc9001/section-4.9.3.toml | 61 +++ .../rfc/rfc9001/section-4.9.toml | 53 +++ .../rfc/rfc9001/section-4.toml | 61 +++ .../rfc/rfc9001/section-5.1.toml | 49 +++ .../rfc/rfc9001/section-5.2.toml | 80 ++++ .../rfc/rfc9001/section-5.3.toml | 74 ++++ .../rfc/rfc9001/section-5.4.1.toml | 95 +++++ .../rfc/rfc9001/section-5.4.2.toml | 65 +++ .../rfc/rfc9001/section-5.5.toml | 35 ++ .../rfc/rfc9001/section-5.6.toml | 117 ++++++ .../rfc/rfc9001/section-5.7.toml | 95 +++++ .../rfc/rfc9001/section-6.1.toml | 78 ++++ .../rfc/rfc9001/section-6.2.toml | 72 ++++ .../rfc/rfc9001/section-6.3.toml | 76 ++++ .../rfc/rfc9001/section-6.4.toml | 30 ++ .../rfc/rfc9001/section-6.5.toml | 91 ++++ .../rfc/rfc9001/section-6.6.toml | 164 ++++++++ .../rfc/rfc9001/section-6.toml | 77 ++++ .../rfc/rfc9001/section-7.toml | 33 ++ .../rfc/rfc9001/section-8.1.toml | 40 +- .../rfc/rfc9001/section-8.2.toml | 81 ++++ .../rfc/rfc9001/section-8.3.toml | 29 ++ .../rfc/rfc9001/section-8.4.toml | 33 ++ .../rfc/rfc9001/section-9.2.toml | 99 +++++ .../rfc/rfc9001/section-9.3.toml | 24 ++ .../rfc/rfc9001/section-9.4.toml | 46 +++ .../rfc/rfc9001/section-9.5.toml | 62 +++ .../rfc/rfc9001/section-9.6.toml | 40 ++ .../rfc/rfc9002/section-5.1.toml | 56 +++ .../rfc/rfc9002/section-5.2.toml | 73 ++++ .../rfc/rfc9002/section-5.3.toml | 157 +++++++ .../rfc/rfc9002/section-6.1.1.toml | 35 ++ .../rfc/rfc9002/section-6.1.2.toml | 86 ++++ .../rfc/rfc9002/section-6.1.toml | 41 ++ .../rfc/rfc9002/section-6.2.1.toml | 116 ++++++ .../rfc/rfc9002/section-6.2.2.1.toml | 68 +++ .../rfc/rfc9002/section-6.2.2.toml | 58 +++ .../rfc/rfc9002/section-6.2.3.toml | 37 ++ .../rfc/rfc9002/section-6.2.4.toml | 124 ++++++ .../rfc/rfc9002/section-6.2.toml | 31 ++ .../rfc/rfc9002/section-6.3.toml | 36 ++ .../rfc/rfc9002/section-6.4.toml | 45 ++ .../rfc/rfc9002/section-7.2.toml | 61 +++ .../rfc/rfc9002/section-7.3.1.toml | 29 ++ .../rfc/rfc9002/section-7.3.2.toml | 57 +++ .../rfc/rfc9002/section-7.3.3.toml | 26 ++ .../rfc/rfc9002/section-7.4.toml | 29 ++ .../rfc/rfc9002/section-7.5.toml | 27 ++ .../rfc/rfc9002/section-7.6.1.toml | 45 ++ .../rfc/rfc9002/section-7.6.2.toml | 82 ++++ .../rfc/rfc9002/section-7.7.toml | 84 ++++ .../rfc/rfc9002/section-7.8.toml | 41 ++ .../rfc/rfc9002/section-7.toml | 62 +++ .../id/draft-banks-quic-performance-00.txt | 0 ...rdwell-iccrg-bbr-congestion-control-02.txt | 0 ...heng-iccrg-delivery-rate-estimation-02.txt | 0 .../id/draft-eggert-tcpm-rfc8312bis-01.txt | 0 .../id/draft-ietf-tcpm-hystartplusplus-04.txt | 0 ...marx-qlog-event-definitions-quic-h3-02.txt | 0 .../www.rfc-editor.org/rfc/rfc1071.txt | 0 .../www.rfc-editor.org/rfc/rfc1112.txt | 0 .../www.rfc-editor.org/rfc/rfc1918.txt | 0 .../www.rfc-editor.org/rfc/rfc2373.txt | 0 .../www.rfc-editor.org/rfc/rfc2460.txt | 0 .../www.rfc-editor.org/rfc/rfc2544.txt | 0 .../www.rfc-editor.org/rfc/rfc3168.txt | 0 .../www.rfc-editor.org/rfc/rfc3849.txt | 0 .../www.rfc-editor.org/rfc/rfc3927.txt | 0 .../www.rfc-editor.org/rfc/rfc4193.txt | 0 .../www.rfc-editor.org/rfc/rfc4291.txt | 0 .../www.rfc-editor.org/rfc/rfc4303.txt | 0 .../www.rfc-editor.org/rfc/rfc5156.txt | 0 .../www.rfc-editor.org/rfc/rfc5180.txt | 0 .../www.rfc-editor.org/rfc/rfc5246.txt | 0 .../www.rfc-editor.org/rfc/rfc5737.txt | 0 .../www.rfc-editor.org/rfc/rfc6052.txt | 0 .../www.rfc-editor.org/rfc/rfc6335.txt | 0 .../www.rfc-editor.org/rfc/rfc6598.txt | 0 .../www.rfc-editor.org/rfc/rfc6666.txt | 0 .../www.rfc-editor.org/rfc/rfc6676.txt | 0 .../www.rfc-editor.org/rfc/rfc6890.txt | 0 .../www.rfc-editor.org/rfc/rfc7301.txt | 0 .../www.rfc-editor.org/rfc/rfc7723.txt | 0 .../www.rfc-editor.org/rfc/rfc791.txt | 0 .../www.rfc-editor.org/rfc/rfc8155.txt | 0 .../www.rfc-editor.org/rfc/rfc8200.txt | 0 .../www.rfc-editor.org/rfc/rfc8312.txt | 0 .../www.rfc-editor.org/rfc/rfc8446.txt | 0 .../www.rfc-editor.org/rfc/rfc8899.txt | 0 .../www.rfc-editor.org/rfc/rfc9000.txt | 0 .../www.rfc-editor.org/rfc/rfc9001.txt | 0 .../www.rfc-editor.org/rfc/rfc9002.txt | 0 .../www.rfc-editor.org/rfc/rfc919.txt | 0 .../www.rfc-editor.org/rfc/rfc9221.txt | 0 .../www.rfc-editor.org/rfc/rfc9308.txt | 0 {specs => .duvet}/todos/recovery/5.2.toml | 0 {specs => .duvet}/todos/recovery/5.3.toml | 0 {specs => .duvet}/todos/recovery/6.1.2.toml | 0 {specs => .duvet}/todos/recovery/6.1.toml | 0 {specs => .duvet}/todos/recovery/6.2.2.toml | 0 {specs => .duvet}/todos/recovery/6.2.3.toml | 0 {specs => .duvet}/todos/recovery/6.2.4.toml | 0 {specs => .duvet}/todos/recovery/7.4.toml | 0 {specs => .duvet}/todos/recovery/7.7.toml | 0 {specs => .duvet}/todos/recovery/7.8.toml | 0 {specs => .duvet}/todos/recovery/7.toml | 0 {specs => .duvet}/todos/rfc8899/3.toml | 0 {specs => .duvet}/todos/rfc8899/4.3.toml | 0 {specs => .duvet}/todos/rfc8899/4.6.1.toml | 0 {specs => .duvet}/todos/rfc8899/4.6.2.toml | 0 {specs => .duvet}/todos/rfc8899/8.toml | 0 {specs => .duvet}/todos/tls/4.1.4.toml | 0 {specs => .duvet}/todos/tls/4.6.1.toml | 0 {specs => .duvet}/todos/tls/4.6.2.toml | 0 {specs => .duvet}/todos/tls/4.9.3.toml | 0 {specs => .duvet}/todos/tls/5.3.toml | 0 {specs => .duvet}/todos/tls/5.5.toml | 0 {specs => .duvet}/todos/tls/6.1.toml | 0 {specs => .duvet}/todos/tls/6.2.toml | 0 {specs => .duvet}/todos/tls/6.3.toml | 0 {specs => .duvet}/todos/tls/6.5.toml | 0 {specs => .duvet}/todos/tls/6.6.toml | 0 {specs => .duvet}/todos/tls/6.toml | 0 {specs => .duvet}/todos/tls/7.toml | 0 {specs => .duvet}/todos/tls/8.1.toml | 0 {specs => .duvet}/todos/tls/8.3.toml | 0 {specs => .duvet}/todos/tls/9.2.toml | 0 {specs => .duvet}/todos/tls/9.5.toml | 0 {specs => .duvet}/todos/transport/10.3.toml | 0 {specs => .duvet}/todos/transport/14.2.1.toml | 0 {specs => .duvet}/todos/transport/17.2.toml | 0 {specs => .duvet}/todos/transport/17.4.toml | 0 {specs => .duvet}/todos/transport/19.7.toml | 0 {specs => .duvet}/todos/transport/2.3.toml | 0 {specs => .duvet}/todos/transport/5.1.2.toml | 0 {specs => .duvet}/todos/transport/6.toml | 0 {specs => .duvet}/todos/transport/7.2.toml | 0 {specs => .duvet}/todos/transport/7.4.1.toml | 0 {specs => .duvet}/todos/transport/8.1.toml | 0 {specs => .duvet}/todos/transport/8.2.toml | 0 scripts/compliance | 12 +- specs/www.rfc-editor.org/rfc/rfc768.txt | 174 -------- specs/www.rfc-editor.org/rfc/rfc8312/4.2.toml | 43 -- specs/www.rfc-editor.org/rfc/rfc8312/4.3.toml | 18 - specs/www.rfc-editor.org/rfc/rfc8312/4.4.toml | 28 -- specs/www.rfc-editor.org/rfc/rfc8312/4.5.toml | 27 -- specs/www.rfc-editor.org/rfc/rfc8312/4.6.toml | 54 --- specs/www.rfc-editor.org/rfc/rfc8312/4.8.toml | 34 -- specs/www.rfc-editor.org/rfc/rfc8312/5.1.toml | 90 ---- specs/www.rfc-editor.org/rfc/rfc8312/5.8.toml | 19 - specs/www.rfc-editor.org/rfc/rfc8899/1.3.toml | 68 --- specs/www.rfc-editor.org/rfc/rfc8899/2.toml | 157 ------- specs/www.rfc-editor.org/rfc/rfc8899/3.toml | 389 ------------------ specs/www.rfc-editor.org/rfc/rfc8899/4.1.toml | 87 ---- specs/www.rfc-editor.org/rfc/rfc8899/4.2.toml | 29 -- specs/www.rfc-editor.org/rfc/rfc8899/4.3.toml | 69 ---- specs/www.rfc-editor.org/rfc/rfc8899/4.4.toml | 72 ---- specs/www.rfc-editor.org/rfc/rfc8899/4.5.toml | 20 - .../www.rfc-editor.org/rfc/rfc8899/4.6.1.toml | 81 ---- .../www.rfc-editor.org/rfc/rfc8899/4.6.2.toml | 111 ----- .../www.rfc-editor.org/rfc/rfc8899/5.1.1.toml | 71 ---- .../www.rfc-editor.org/rfc/rfc8899/5.1.2.toml | 61 --- specs/www.rfc-editor.org/rfc/rfc8899/5.2.toml | 139 ------- .../www.rfc-editor.org/rfc/rfc8899/5.3.1.toml | 45 -- .../www.rfc-editor.org/rfc/rfc8899/5.3.2.toml | 24 -- specs/www.rfc-editor.org/rfc/rfc8899/5.toml | 59 --- .../www.rfc-editor.org/rfc/rfc8899/6.1.1.toml | 20 - .../www.rfc-editor.org/rfc/rfc8899/6.1.6.toml | 28 -- specs/www.rfc-editor.org/rfc/rfc8899/6.1.toml | 32 -- .../rfc/rfc8899/6.2.1.4.toml | 30 -- .../rfc/rfc8899/6.2.2.4.toml | 29 -- .../www.rfc-editor.org/rfc/rfc8899/6.2.2.toml | 21 - specs/www.rfc-editor.org/rfc/rfc8899/6.2.toml | 42 -- specs/www.rfc-editor.org/rfc/rfc8899/8.toml | 110 ----- .../rfc/rfc9000/10.1.2.toml | 39 -- .../www.rfc-editor.org/rfc/rfc9000/10.1.toml | 38 -- .../rfc/rfc9000/10.2.1.toml | 114 ----- .../rfc/rfc9000/10.2.2.toml | 55 --- .../rfc/rfc9000/10.2.3.toml | 131 ------ .../www.rfc-editor.org/rfc/rfc9000/10.2.toml | 85 ---- .../rfc/rfc9000/10.3.1.toml | 82 ---- .../rfc/rfc9000/10.3.2.toml | 98 ----- .../rfc/rfc9000/10.3.3.toml | 37 -- .../www.rfc-editor.org/rfc/rfc9000/10.3.toml | 214 ---------- specs/www.rfc-editor.org/rfc/rfc9000/10.toml | 23 -- .../www.rfc-editor.org/rfc/rfc9000/11.1.toml | 62 --- .../www.rfc-editor.org/rfc/rfc9000/11.2.toml | 38 -- specs/www.rfc-editor.org/rfc/rfc9000/11.toml | 55 --- .../www.rfc-editor.org/rfc/rfc9000/12.2.toml | 104 ----- .../www.rfc-editor.org/rfc/rfc9000/12.3.toml | 113 ----- .../www.rfc-editor.org/rfc/rfc9000/12.4.toml | 195 --------- .../www.rfc-editor.org/rfc/rfc9000/12.5.toml | 75 ---- .../www.rfc-editor.org/rfc/rfc9000/13.1.toml | 35 -- .../rfc/rfc9000/13.2.1.toml | 145 ------- .../rfc/rfc9000/13.2.2.toml | 45 -- .../rfc/rfc9000/13.2.3.toml | 103 ----- .../rfc/rfc9000/13.2.5.toml | 46 --- .../rfc/rfc9000/13.2.6.toml | 38 -- .../rfc/rfc9000/13.2.7.toml | 21 - .../www.rfc-editor.org/rfc/rfc9000/13.2.toml | 26 -- .../www.rfc-editor.org/rfc/rfc9000/13.3.toml | 186 --------- .../rfc/rfc9000/13.4.1.toml | 44 -- .../rfc/rfc9000/13.4.2.1.toml | 54 --- .../rfc/rfc9000/13.4.2.2.toml | 47 --- .../rfc/rfc9000/13.4.2.toml | 45 -- specs/www.rfc-editor.org/rfc/rfc9000/13.toml | 48 --- .../www.rfc-editor.org/rfc/rfc9000/14.1.toml | 80 ---- .../rfc/rfc9000/14.2.1.toml | 92 ----- .../www.rfc-editor.org/rfc/rfc9000/14.2.toml | 97 ----- .../www.rfc-editor.org/rfc/rfc9000/14.3.toml | 26 -- .../www.rfc-editor.org/rfc/rfc9000/14.4.toml | 24 -- specs/www.rfc-editor.org/rfc/rfc9000/14.toml | 82 ---- specs/www.rfc-editor.org/rfc/rfc9000/15.toml | 61 --- .../www.rfc-editor.org/rfc/rfc9000/17.1.toml | 74 ---- .../rfc/rfc9000/17.2.1.toml | 121 ------ .../rfc/rfc9000/17.2.2.toml | 105 ----- .../rfc/rfc9000/17.2.3.toml | 94 ----- .../rfc/rfc9000/17.2.4.toml | 66 --- .../rfc/rfc9000/17.2.5.1.toml | 61 --- .../rfc/rfc9000/17.2.5.2.toml | 69 ---- .../rfc/rfc9000/17.2.5.3.toml | 77 ---- .../rfc/rfc9000/17.2.5.toml | 44 -- .../www.rfc-editor.org/rfc/rfc9000/17.2.toml | 204 --------- .../rfc/rfc9000/17.3.1.toml | 101 ----- .../www.rfc-editor.org/rfc/rfc9000/17.4.toml | 110 ----- .../www.rfc-editor.org/rfc/rfc9000/18.2.toml | 291 ------------- .../www.rfc-editor.org/rfc/rfc9000/19.10.toml | 79 ---- .../www.rfc-editor.org/rfc/rfc9000/19.11.toml | 76 ---- .../www.rfc-editor.org/rfc/rfc9000/19.12.toml | 31 -- .../www.rfc-editor.org/rfc/rfc9000/19.13.toml | 44 -- .../www.rfc-editor.org/rfc/rfc9000/19.14.toml | 49 --- .../www.rfc-editor.org/rfc/rfc9000/19.15.toml | 157 ------- .../www.rfc-editor.org/rfc/rfc9000/19.16.toml | 74 ---- .../www.rfc-editor.org/rfc/rfc9000/19.17.toml | 35 -- .../www.rfc-editor.org/rfc/rfc9000/19.18.toml | 30 -- .../www.rfc-editor.org/rfc/rfc9000/19.19.toml | 67 --- .../www.rfc-editor.org/rfc/rfc9000/19.20.toml | 36 -- .../www.rfc-editor.org/rfc/rfc9000/19.21.toml | 60 --- .../rfc/rfc9000/19.3.1.toml | 70 ---- .../www.rfc-editor.org/rfc/rfc9000/19.3.toml | 85 ---- .../www.rfc-editor.org/rfc/rfc9000/19.4.toml | 46 --- .../www.rfc-editor.org/rfc/rfc9000/19.5.toml | 50 --- .../www.rfc-editor.org/rfc/rfc9000/19.6.toml | 56 --- .../www.rfc-editor.org/rfc/rfc9000/19.7.toml | 66 --- .../www.rfc-editor.org/rfc/rfc9000/19.8.toml | 86 ---- .../www.rfc-editor.org/rfc/rfc9000/19.9.toml | 48 --- specs/www.rfc-editor.org/rfc/rfc9000/2.1.toml | 54 --- specs/www.rfc-editor.org/rfc/rfc9000/2.2.toml | 63 --- specs/www.rfc-editor.org/rfc/rfc9000/2.3.toml | 24 -- .../www.rfc-editor.org/rfc/rfc9000/21.11.toml | 53 --- .../www.rfc-editor.org/rfc/rfc9000/21.12.toml | 21 - .../www.rfc-editor.org/rfc/rfc9000/21.3.toml | 22 - .../www.rfc-editor.org/rfc/rfc9000/21.4.toml | 18 - .../rfc/rfc9000/21.5.3.toml | 26 -- .../rfc/rfc9000/21.5.6.toml | 102 ----- .../www.rfc-editor.org/rfc/rfc9000/21.5.toml | 70 ---- .../www.rfc-editor.org/rfc/rfc9000/21.6.toml | 31 -- .../www.rfc-editor.org/rfc/rfc9000/21.7.toml | 34 -- .../www.rfc-editor.org/rfc/rfc9000/21.9.toml | 39 -- .../rfc/rfc9000/22.1.1.toml | 48 --- .../rfc/rfc9000/22.1.2.toml | 65 --- .../rfc/rfc9000/22.1.3.toml | 81 ---- .../rfc/rfc9000/22.1.4.toml | 50 --- .../www.rfc-editor.org/rfc/rfc9000/22.2.toml | 37 -- .../www.rfc-editor.org/rfc/rfc9000/22.3.toml | 89 ---- .../www.rfc-editor.org/rfc/rfc9000/22.4.toml | 48 --- .../www.rfc-editor.org/rfc/rfc9000/22.5.toml | 105 ----- specs/www.rfc-editor.org/rfc/rfc9000/3.1.toml | 101 ----- specs/www.rfc-editor.org/rfc/rfc9000/3.2.toml | 134 ------ specs/www.rfc-editor.org/rfc/rfc9000/3.3.toml | 51 --- specs/www.rfc-editor.org/rfc/rfc9000/3.5.toml | 104 ----- specs/www.rfc-editor.org/rfc/rfc9000/4.1.toml | 99 ----- specs/www.rfc-editor.org/rfc/rfc9000/4.2.toml | 58 --- specs/www.rfc-editor.org/rfc/rfc9000/4.4.toml | 26 -- specs/www.rfc-editor.org/rfc/rfc9000/4.5.toml | 71 ---- specs/www.rfc-editor.org/rfc/rfc9000/4.6.toml | 93 ----- specs/www.rfc-editor.org/rfc/rfc9000/4.toml | 32 -- .../www.rfc-editor.org/rfc/rfc9000/5.1.1.toml | 160 ------- .../www.rfc-editor.org/rfc/rfc9000/5.1.2.toml | 121 ------ specs/www.rfc-editor.org/rfc/rfc9000/5.1.toml | 85 ---- .../www.rfc-editor.org/rfc/rfc9000/5.2.1.toml | 40 -- .../www.rfc-editor.org/rfc/rfc9000/5.2.2.toml | 100 ----- .../www.rfc-editor.org/rfc/rfc9000/5.2.3.toml | 47 --- specs/www.rfc-editor.org/rfc/rfc9000/5.2.toml | 55 --- specs/www.rfc-editor.org/rfc/rfc9000/6.1.toml | 36 -- specs/www.rfc-editor.org/rfc/rfc9000/6.2.toml | 48 --- specs/www.rfc-editor.org/rfc/rfc9000/6.3.toml | 31 -- specs/www.rfc-editor.org/rfc/rfc9000/6.toml | 29 -- specs/www.rfc-editor.org/rfc/rfc9000/7.2.toml | 115 ------ specs/www.rfc-editor.org/rfc/rfc9000/7.3.toml | 130 ------ .../www.rfc-editor.org/rfc/rfc9000/7.4.1.toml | 192 --------- .../www.rfc-editor.org/rfc/rfc9000/7.4.2.toml | 30 -- specs/www.rfc-editor.org/rfc/rfc9000/7.4.toml | 68 --- specs/www.rfc-editor.org/rfc/rfc9000/7.5.toml | 78 ---- specs/www.rfc-editor.org/rfc/rfc9000/7.toml | 85 ---- .../www.rfc-editor.org/rfc/rfc9000/8.1.1.toml | 17 - .../www.rfc-editor.org/rfc/rfc9000/8.1.2.toml | 71 ---- .../www.rfc-editor.org/rfc/rfc9000/8.1.3.toml | 241 ----------- .../www.rfc-editor.org/rfc/rfc9000/8.1.4.toml | 114 ----- specs/www.rfc-editor.org/rfc/rfc9000/8.1.toml | 113 ----- .../www.rfc-editor.org/rfc/rfc9000/8.2.1.toml | 96 ----- .../www.rfc-editor.org/rfc/rfc9000/8.2.2.toml | 83 ---- .../www.rfc-editor.org/rfc/rfc9000/8.2.3.toml | 29 -- .../www.rfc-editor.org/rfc/rfc9000/8.2.4.toml | 60 --- specs/www.rfc-editor.org/rfc/rfc9000/8.2.toml | 61 --- specs/www.rfc-editor.org/rfc/rfc9000/8.toml | 31 -- specs/www.rfc-editor.org/rfc/rfc9000/9.1.toml | 24 -- specs/www.rfc-editor.org/rfc/rfc9000/9.2.toml | 33 -- .../www.rfc-editor.org/rfc/rfc9000/9.3.2.toml | 52 --- .../www.rfc-editor.org/rfc/rfc9000/9.3.3.toml | 63 --- specs/www.rfc-editor.org/rfc/rfc9000/9.3.toml | 77 ---- specs/www.rfc-editor.org/rfc/rfc9000/9.4.toml | 78 ---- specs/www.rfc-editor.org/rfc/rfc9000/9.5.toml | 133 ------ .../www.rfc-editor.org/rfc/rfc9000/9.6.1.toml | 55 --- .../www.rfc-editor.org/rfc/rfc9000/9.6.2.toml | 77 ---- .../www.rfc-editor.org/rfc/rfc9000/9.6.3.toml | 95 ----- specs/www.rfc-editor.org/rfc/rfc9000/9.6.toml | 27 -- specs/www.rfc-editor.org/rfc/rfc9000/9.7.toml | 36 -- specs/www.rfc-editor.org/rfc/rfc9000/9.toml | 104 ----- .../www.rfc-editor.org/rfc/rfc9001/4.1.2.toml | 31 -- .../www.rfc-editor.org/rfc/rfc9001/4.1.3.toml | 123 ------ .../www.rfc-editor.org/rfc/rfc9001/4.1.4.toml | 84 ---- specs/www.rfc-editor.org/rfc/rfc9001/4.2.toml | 30 -- specs/www.rfc-editor.org/rfc/rfc9001/4.3.toml | 53 --- specs/www.rfc-editor.org/rfc/rfc9001/4.4.toml | 86 ---- specs/www.rfc-editor.org/rfc/rfc9001/4.5.toml | 37 -- .../www.rfc-editor.org/rfc/rfc9001/4.6.1.toml | 47 --- .../www.rfc-editor.org/rfc/rfc9001/4.6.2.toml | 55 --- specs/www.rfc-editor.org/rfc/rfc9001/4.7.toml | 21 - specs/www.rfc-editor.org/rfc/rfc9001/4.8.toml | 42 -- .../www.rfc-editor.org/rfc/rfc9001/4.9.1.toml | 44 -- .../www.rfc-editor.org/rfc/rfc9001/4.9.3.toml | 61 --- specs/www.rfc-editor.org/rfc/rfc9001/4.9.toml | 53 --- specs/www.rfc-editor.org/rfc/rfc9001/4.toml | 61 --- specs/www.rfc-editor.org/rfc/rfc9001/5.1.toml | 49 --- specs/www.rfc-editor.org/rfc/rfc9001/5.2.toml | 80 ---- specs/www.rfc-editor.org/rfc/rfc9001/5.3.toml | 74 ---- .../www.rfc-editor.org/rfc/rfc9001/5.4.1.toml | 95 ----- .../www.rfc-editor.org/rfc/rfc9001/5.4.2.toml | 65 --- specs/www.rfc-editor.org/rfc/rfc9001/5.5.toml | 35 -- specs/www.rfc-editor.org/rfc/rfc9001/5.6.toml | 117 ------ specs/www.rfc-editor.org/rfc/rfc9001/5.7.toml | 95 ----- specs/www.rfc-editor.org/rfc/rfc9001/6.1.toml | 78 ---- specs/www.rfc-editor.org/rfc/rfc9001/6.2.toml | 72 ---- specs/www.rfc-editor.org/rfc/rfc9001/6.3.toml | 76 ---- specs/www.rfc-editor.org/rfc/rfc9001/6.4.toml | 30 -- specs/www.rfc-editor.org/rfc/rfc9001/6.5.toml | 91 ---- specs/www.rfc-editor.org/rfc/rfc9001/6.6.toml | 164 -------- specs/www.rfc-editor.org/rfc/rfc9001/6.toml | 77 ---- specs/www.rfc-editor.org/rfc/rfc9001/7.toml | 33 -- specs/www.rfc-editor.org/rfc/rfc9001/8.2.toml | 81 ---- specs/www.rfc-editor.org/rfc/rfc9001/8.3.toml | 29 -- specs/www.rfc-editor.org/rfc/rfc9001/8.4.toml | 33 -- specs/www.rfc-editor.org/rfc/rfc9001/9.2.toml | 99 ----- specs/www.rfc-editor.org/rfc/rfc9001/9.3.toml | 24 -- specs/www.rfc-editor.org/rfc/rfc9001/9.4.toml | 46 --- specs/www.rfc-editor.org/rfc/rfc9001/9.5.toml | 62 --- specs/www.rfc-editor.org/rfc/rfc9001/9.6.toml | 40 -- specs/www.rfc-editor.org/rfc/rfc9002/5.1.toml | 56 --- specs/www.rfc-editor.org/rfc/rfc9002/5.2.toml | 73 ---- specs/www.rfc-editor.org/rfc/rfc9002/5.3.toml | 157 ------- .../www.rfc-editor.org/rfc/rfc9002/6.1.1.toml | 35 -- .../www.rfc-editor.org/rfc/rfc9002/6.1.2.toml | 86 ---- specs/www.rfc-editor.org/rfc/rfc9002/6.1.toml | 41 -- .../www.rfc-editor.org/rfc/rfc9002/6.2.1.toml | 116 ------ .../rfc/rfc9002/6.2.2.1.toml | 68 --- .../www.rfc-editor.org/rfc/rfc9002/6.2.2.toml | 58 --- .../www.rfc-editor.org/rfc/rfc9002/6.2.3.toml | 37 -- .../www.rfc-editor.org/rfc/rfc9002/6.2.4.toml | 124 ------ specs/www.rfc-editor.org/rfc/rfc9002/6.2.toml | 31 -- specs/www.rfc-editor.org/rfc/rfc9002/6.3.toml | 36 -- specs/www.rfc-editor.org/rfc/rfc9002/6.4.toml | 45 -- specs/www.rfc-editor.org/rfc/rfc9002/7.2.toml | 61 --- .../www.rfc-editor.org/rfc/rfc9002/7.3.1.toml | 29 -- .../www.rfc-editor.org/rfc/rfc9002/7.3.2.toml | 57 --- .../www.rfc-editor.org/rfc/rfc9002/7.3.3.toml | 26 -- specs/www.rfc-editor.org/rfc/rfc9002/7.4.toml | 29 -- specs/www.rfc-editor.org/rfc/rfc9002/7.5.toml | 27 -- .../www.rfc-editor.org/rfc/rfc9002/7.6.1.toml | 45 -- .../www.rfc-editor.org/rfc/rfc9002/7.6.2.toml | 82 ---- specs/www.rfc-editor.org/rfc/rfc9002/7.7.toml | 84 ---- specs/www.rfc-editor.org/rfc/rfc9002/7.8.toml | 41 -- specs/www.rfc-editor.org/rfc/rfc9002/7.toml | 62 --- 639 files changed, 16785 insertions(+), 16944 deletions(-) create mode 100644 .duvet/.gitignore create mode 100644 .duvet/config.toml rename {specs => .duvet}/exceptions/recovery/6.2.2.toml (100%) rename {specs => .duvet}/exceptions/recovery/6.2.4.toml (100%) rename {specs => .duvet}/exceptions/recovery/6.3.toml (100%) rename {specs => .duvet}/exceptions/recovery/7.3.2.toml (100%) rename {specs => .duvet}/exceptions/recovery/7.3.3.toml (100%) rename {specs => .duvet}/exceptions/recovery/7.6.2.toml (100%) rename {specs => .duvet}/exceptions/recovery/7.toml (100%) rename {specs => .duvet}/exceptions/rfc8312/4.6.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/1.3.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/2.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/3.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/4.1.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/4.4.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/5.1.1.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/5.3.1.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.1.1.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.1.4.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.1.5.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.1.6.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.1.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.2.1.3.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.2.1.4.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.2.2.4.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.2.2.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.2.3.3.toml (100%) rename {specs => .duvet}/exceptions/rfc8899/6.2.toml (100%) rename {specs => .duvet}/exceptions/tls/4.1.2.toml (100%) rename {specs => .duvet}/exceptions/tls/4.4.toml (100%) rename {specs => .duvet}/exceptions/tls/4.5.toml (100%) rename {specs => .duvet}/exceptions/tls/4.7.toml (100%) rename {specs => .duvet}/exceptions/tls/5.1.toml (100%) rename {specs => .duvet}/exceptions/tls/5.2.toml (100%) rename {specs => .duvet}/exceptions/tls/5.3.toml (100%) rename {specs => .duvet}/exceptions/tls/5.4.1.toml (100%) rename {specs => .duvet}/exceptions/tls/6.2.toml (100%) rename {specs => .duvet}/exceptions/tls/6.3.toml (100%) rename {specs => .duvet}/exceptions/tls/6.4.toml (100%) rename {specs => .duvet}/exceptions/tls/6.6.toml (100%) rename {specs => .duvet}/exceptions/tls/8.1.toml (100%) rename {specs => .duvet}/exceptions/tls/8.2.toml (100%) rename {specs => .duvet}/exceptions/tls/8.3.toml (100%) rename {specs => .duvet}/exceptions/tls/8.4.toml (100%) rename {specs => .duvet}/exceptions/tls/9.2.toml (100%) rename {specs => .duvet}/exceptions/tls/9.4.toml (100%) rename {specs => .duvet}/exceptions/tls/9.6.toml (100%) rename {specs => .duvet}/exceptions/transport/10.3.1.toml (100%) rename {specs => .duvet}/exceptions/transport/10.3.2.toml (100%) rename {specs => .duvet}/exceptions/transport/10.3.toml (100%) rename {specs => .duvet}/exceptions/transport/19.15.toml (100%) rename {specs => .duvet}/exceptions/transport/19.16.toml (100%) rename {specs => .duvet}/exceptions/transport/2.2.toml (100%) rename {specs => .duvet}/exceptions/transport/5.1.1.toml (100%) rename {specs => .duvet}/exceptions/transport/5.1.2.toml (100%) rename {specs => .duvet}/exceptions/transport/5.1.toml (100%) rename {specs => .duvet}/exceptions/transport/5.2.3.toml (100%) rename {specs => .duvet}/exceptions/transport/7.4.1.toml (100%) rename {specs => .duvet}/exceptions/transport/7.toml (100%) rename {specs => .duvet}/exceptions/transport/8.2.3.toml (100%) rename {specs => .duvet}/exceptions/transport/8.2.4.toml (100%) rename {specs => .duvet}/exceptions/transport/9.4.toml (100%) create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-1.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.1.toml rename specs/www.rfc-editor.org/rfc/rfc8899/6.1.4.toml => .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.4.toml (55%) rename specs/www.rfc-editor.org/rfc/rfc8899/6.1.5.toml => .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.5.toml (55%) create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.toml rename specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.3.toml => .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.3.toml (57%) create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.toml rename specs/www.rfc-editor.org/rfc/rfc8899/6.2.3.3.toml => .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.3.3.toml (57%) create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-15.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.12.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.13.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.14.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.17.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.18.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.19.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.20.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.9.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.11.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.12.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.9.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.1.toml rename specs/www.rfc-editor.org/rfc/rfc9001/4.9.2.toml => .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.2.toml (60%) create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-7.toml rename specs/www.rfc-editor.org/rfc/rfc9001/8.1.toml => .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml (51%) create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.6.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.3.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.4.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.5.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.1.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml create mode 100644 .duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml rename {specs => .duvet/specifications}/tools.ietf.org/id/draft-banks-quic-performance-00.txt (100%) rename {specs => .duvet/specifications}/tools.ietf.org/id/draft-cardwell-iccrg-bbr-congestion-control-02.txt (100%) rename {specs => .duvet/specifications}/tools.ietf.org/id/draft-cheng-iccrg-delivery-rate-estimation-02.txt (100%) rename {specs => .duvet/specifications}/tools.ietf.org/id/draft-eggert-tcpm-rfc8312bis-01.txt (100%) rename {specs => .duvet/specifications}/tools.ietf.org/id/draft-ietf-tcpm-hystartplusplus-04.txt (100%) rename {specs => .duvet/specifications}/tools.ietf.org/id/draft-marx-qlog-event-definitions-quic-h3-02.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc1071.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc1112.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc1918.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc2373.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc2460.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc2544.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc3168.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc3849.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc3927.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc4193.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc4291.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc4303.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc5156.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc5180.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc5246.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc5737.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc6052.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc6335.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc6598.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc6666.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc6676.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc6890.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc7301.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc7723.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc791.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc8155.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc8200.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc8312.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc8446.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc8899.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc9000.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc9001.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc9002.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc919.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc9221.txt (100%) rename {specs => .duvet/specifications}/www.rfc-editor.org/rfc/rfc9308.txt (100%) rename {specs => .duvet}/todos/recovery/5.2.toml (100%) rename {specs => .duvet}/todos/recovery/5.3.toml (100%) rename {specs => .duvet}/todos/recovery/6.1.2.toml (100%) rename {specs => .duvet}/todos/recovery/6.1.toml (100%) rename {specs => .duvet}/todos/recovery/6.2.2.toml (100%) rename {specs => .duvet}/todos/recovery/6.2.3.toml (100%) rename {specs => .duvet}/todos/recovery/6.2.4.toml (100%) rename {specs => .duvet}/todos/recovery/7.4.toml (100%) rename {specs => .duvet}/todos/recovery/7.7.toml (100%) rename {specs => .duvet}/todos/recovery/7.8.toml (100%) rename {specs => .duvet}/todos/recovery/7.toml (100%) rename {specs => .duvet}/todos/rfc8899/3.toml (100%) rename {specs => .duvet}/todos/rfc8899/4.3.toml (100%) rename {specs => .duvet}/todos/rfc8899/4.6.1.toml (100%) rename {specs => .duvet}/todos/rfc8899/4.6.2.toml (100%) rename {specs => .duvet}/todos/rfc8899/8.toml (100%) rename {specs => .duvet}/todos/tls/4.1.4.toml (100%) rename {specs => .duvet}/todos/tls/4.6.1.toml (100%) rename {specs => .duvet}/todos/tls/4.6.2.toml (100%) rename {specs => .duvet}/todos/tls/4.9.3.toml (100%) rename {specs => .duvet}/todos/tls/5.3.toml (100%) rename {specs => .duvet}/todos/tls/5.5.toml (100%) rename {specs => .duvet}/todos/tls/6.1.toml (100%) rename {specs => .duvet}/todos/tls/6.2.toml (100%) rename {specs => .duvet}/todos/tls/6.3.toml (100%) rename {specs => .duvet}/todos/tls/6.5.toml (100%) rename {specs => .duvet}/todos/tls/6.6.toml (100%) rename {specs => .duvet}/todos/tls/6.toml (100%) rename {specs => .duvet}/todos/tls/7.toml (100%) rename {specs => .duvet}/todos/tls/8.1.toml (100%) rename {specs => .duvet}/todos/tls/8.3.toml (100%) rename {specs => .duvet}/todos/tls/9.2.toml (100%) rename {specs => .duvet}/todos/tls/9.5.toml (100%) rename {specs => .duvet}/todos/transport/10.3.toml (100%) rename {specs => .duvet}/todos/transport/14.2.1.toml (100%) rename {specs => .duvet}/todos/transport/17.2.toml (100%) rename {specs => .duvet}/todos/transport/17.4.toml (100%) rename {specs => .duvet}/todos/transport/19.7.toml (100%) rename {specs => .duvet}/todos/transport/2.3.toml (100%) rename {specs => .duvet}/todos/transport/5.1.2.toml (100%) rename {specs => .duvet}/todos/transport/6.toml (100%) rename {specs => .duvet}/todos/transport/7.2.toml (100%) rename {specs => .duvet}/todos/transport/7.4.1.toml (100%) rename {specs => .duvet}/todos/transport/8.1.toml (100%) rename {specs => .duvet}/todos/transport/8.2.toml (100%) delete mode 100644 specs/www.rfc-editor.org/rfc/rfc768.txt delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/4.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/4.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/4.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/4.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/4.8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/5.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8312/5.8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/1.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/4.6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/5.1.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/5.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/5.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/5.3.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/5.3.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.1.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.1.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc8899/8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.3.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.3.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.3.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/10.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/11.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/11.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/11.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/12.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/12.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/12.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/12.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.4.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/13.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/14.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/14.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/14.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/14.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/14.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/14.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/15.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.3.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/17.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/18.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.10.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.11.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.12.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.13.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.14.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.15.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.16.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.17.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.18.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.19.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.20.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.21.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.3.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/19.9.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.11.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.12.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.5.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.5.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/21.9.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.1.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.1.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.1.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/22.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/3.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/3.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/3.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/3.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/4.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/4.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/4.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/4.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.1.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/5.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/6.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.4.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.1.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.1.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.1.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.2.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.3.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.3.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.6.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9000/9.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.1.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.1.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.9.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.9.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.9.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.4.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.4.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/5.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/8.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/8.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/8.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/9.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/9.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/9.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/9.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9001/9.6.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/5.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/5.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/5.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.1.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.1.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.2.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.2.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/6.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.3.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.3.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.3.3.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.4.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.5.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.6.1.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.6.2.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.7.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.8.toml delete mode 100644 specs/www.rfc-editor.org/rfc/rfc9002/7.toml diff --git a/.duvet/.gitignore b/.duvet/.gitignore new file mode 100644 index 0000000000..a9a1bd38ab --- /dev/null +++ b/.duvet/.gitignore @@ -0,0 +1 @@ +reports/ diff --git a/.duvet/config.toml b/.duvet/config.toml new file mode 100644 index 0000000000..71d8e8c4b1 --- /dev/null +++ b/.duvet/config.toml @@ -0,0 +1,24 @@ +'$schema' = "https://awslabs.github.io/duvet/config/v0.4.0.json" + +[[source]] +pattern = "quic/**/*.rs" + +[report.html] +enabled = true +issue-link = "https://github.com/aws/s2n-quic/issues" +blob-link = "https://github.com/aws/s2n-quic/blob/${{ GITHUB_SHA || 'main' }}" + +[[specification]] +source = "https://www.rfc-editor.org/rfc/rfc8312" + +[[specification]] +source = "https://www.rfc-editor.org/rfc/rfc8899" + +[[specification]] +source = "https://www.rfc-editor.org/rfc/rfc9000" + +[[specification]] +source = "https://www.rfc-editor.org/rfc/rfc9001" + +[[specification]] +source = "https://www.rfc-editor.org/rfc/rfc9002" diff --git a/specs/exceptions/recovery/6.2.2.toml b/.duvet/exceptions/recovery/6.2.2.toml similarity index 100% rename from specs/exceptions/recovery/6.2.2.toml rename to .duvet/exceptions/recovery/6.2.2.toml diff --git a/specs/exceptions/recovery/6.2.4.toml b/.duvet/exceptions/recovery/6.2.4.toml similarity index 100% rename from specs/exceptions/recovery/6.2.4.toml rename to .duvet/exceptions/recovery/6.2.4.toml diff --git a/specs/exceptions/recovery/6.3.toml b/.duvet/exceptions/recovery/6.3.toml similarity index 100% rename from specs/exceptions/recovery/6.3.toml rename to .duvet/exceptions/recovery/6.3.toml diff --git a/specs/exceptions/recovery/7.3.2.toml b/.duvet/exceptions/recovery/7.3.2.toml similarity index 100% rename from specs/exceptions/recovery/7.3.2.toml rename to .duvet/exceptions/recovery/7.3.2.toml diff --git a/specs/exceptions/recovery/7.3.3.toml b/.duvet/exceptions/recovery/7.3.3.toml similarity index 100% rename from specs/exceptions/recovery/7.3.3.toml rename to .duvet/exceptions/recovery/7.3.3.toml diff --git a/specs/exceptions/recovery/7.6.2.toml b/.duvet/exceptions/recovery/7.6.2.toml similarity index 100% rename from specs/exceptions/recovery/7.6.2.toml rename to .duvet/exceptions/recovery/7.6.2.toml diff --git a/specs/exceptions/recovery/7.toml b/.duvet/exceptions/recovery/7.toml similarity index 100% rename from specs/exceptions/recovery/7.toml rename to .duvet/exceptions/recovery/7.toml diff --git a/specs/exceptions/rfc8312/4.6.toml b/.duvet/exceptions/rfc8312/4.6.toml similarity index 100% rename from specs/exceptions/rfc8312/4.6.toml rename to .duvet/exceptions/rfc8312/4.6.toml diff --git a/specs/exceptions/rfc8899/1.3.toml b/.duvet/exceptions/rfc8899/1.3.toml similarity index 100% rename from specs/exceptions/rfc8899/1.3.toml rename to .duvet/exceptions/rfc8899/1.3.toml diff --git a/specs/exceptions/rfc8899/2.toml b/.duvet/exceptions/rfc8899/2.toml similarity index 100% rename from specs/exceptions/rfc8899/2.toml rename to .duvet/exceptions/rfc8899/2.toml diff --git a/specs/exceptions/rfc8899/3.toml b/.duvet/exceptions/rfc8899/3.toml similarity index 100% rename from specs/exceptions/rfc8899/3.toml rename to .duvet/exceptions/rfc8899/3.toml diff --git a/specs/exceptions/rfc8899/4.1.toml b/.duvet/exceptions/rfc8899/4.1.toml similarity index 100% rename from specs/exceptions/rfc8899/4.1.toml rename to .duvet/exceptions/rfc8899/4.1.toml diff --git a/specs/exceptions/rfc8899/4.4.toml b/.duvet/exceptions/rfc8899/4.4.toml similarity index 100% rename from specs/exceptions/rfc8899/4.4.toml rename to .duvet/exceptions/rfc8899/4.4.toml diff --git a/specs/exceptions/rfc8899/5.1.1.toml b/.duvet/exceptions/rfc8899/5.1.1.toml similarity index 100% rename from specs/exceptions/rfc8899/5.1.1.toml rename to .duvet/exceptions/rfc8899/5.1.1.toml diff --git a/specs/exceptions/rfc8899/5.3.1.toml b/.duvet/exceptions/rfc8899/5.3.1.toml similarity index 100% rename from specs/exceptions/rfc8899/5.3.1.toml rename to .duvet/exceptions/rfc8899/5.3.1.toml diff --git a/specs/exceptions/rfc8899/6.1.1.toml b/.duvet/exceptions/rfc8899/6.1.1.toml similarity index 100% rename from specs/exceptions/rfc8899/6.1.1.toml rename to .duvet/exceptions/rfc8899/6.1.1.toml diff --git a/specs/exceptions/rfc8899/6.1.4.toml b/.duvet/exceptions/rfc8899/6.1.4.toml similarity index 100% rename from specs/exceptions/rfc8899/6.1.4.toml rename to .duvet/exceptions/rfc8899/6.1.4.toml diff --git a/specs/exceptions/rfc8899/6.1.5.toml b/.duvet/exceptions/rfc8899/6.1.5.toml similarity index 100% rename from specs/exceptions/rfc8899/6.1.5.toml rename to .duvet/exceptions/rfc8899/6.1.5.toml diff --git a/specs/exceptions/rfc8899/6.1.6.toml b/.duvet/exceptions/rfc8899/6.1.6.toml similarity index 100% rename from specs/exceptions/rfc8899/6.1.6.toml rename to .duvet/exceptions/rfc8899/6.1.6.toml diff --git a/specs/exceptions/rfc8899/6.1.toml b/.duvet/exceptions/rfc8899/6.1.toml similarity index 100% rename from specs/exceptions/rfc8899/6.1.toml rename to .duvet/exceptions/rfc8899/6.1.toml diff --git a/specs/exceptions/rfc8899/6.2.1.3.toml b/.duvet/exceptions/rfc8899/6.2.1.3.toml similarity index 100% rename from specs/exceptions/rfc8899/6.2.1.3.toml rename to .duvet/exceptions/rfc8899/6.2.1.3.toml diff --git a/specs/exceptions/rfc8899/6.2.1.4.toml b/.duvet/exceptions/rfc8899/6.2.1.4.toml similarity index 100% rename from specs/exceptions/rfc8899/6.2.1.4.toml rename to .duvet/exceptions/rfc8899/6.2.1.4.toml diff --git a/specs/exceptions/rfc8899/6.2.2.4.toml b/.duvet/exceptions/rfc8899/6.2.2.4.toml similarity index 100% rename from specs/exceptions/rfc8899/6.2.2.4.toml rename to .duvet/exceptions/rfc8899/6.2.2.4.toml diff --git a/specs/exceptions/rfc8899/6.2.2.toml b/.duvet/exceptions/rfc8899/6.2.2.toml similarity index 100% rename from specs/exceptions/rfc8899/6.2.2.toml rename to .duvet/exceptions/rfc8899/6.2.2.toml diff --git a/specs/exceptions/rfc8899/6.2.3.3.toml b/.duvet/exceptions/rfc8899/6.2.3.3.toml similarity index 100% rename from specs/exceptions/rfc8899/6.2.3.3.toml rename to .duvet/exceptions/rfc8899/6.2.3.3.toml diff --git a/specs/exceptions/rfc8899/6.2.toml b/.duvet/exceptions/rfc8899/6.2.toml similarity index 100% rename from specs/exceptions/rfc8899/6.2.toml rename to .duvet/exceptions/rfc8899/6.2.toml diff --git a/specs/exceptions/tls/4.1.2.toml b/.duvet/exceptions/tls/4.1.2.toml similarity index 100% rename from specs/exceptions/tls/4.1.2.toml rename to .duvet/exceptions/tls/4.1.2.toml diff --git a/specs/exceptions/tls/4.4.toml b/.duvet/exceptions/tls/4.4.toml similarity index 100% rename from specs/exceptions/tls/4.4.toml rename to .duvet/exceptions/tls/4.4.toml diff --git a/specs/exceptions/tls/4.5.toml b/.duvet/exceptions/tls/4.5.toml similarity index 100% rename from specs/exceptions/tls/4.5.toml rename to .duvet/exceptions/tls/4.5.toml diff --git a/specs/exceptions/tls/4.7.toml b/.duvet/exceptions/tls/4.7.toml similarity index 100% rename from specs/exceptions/tls/4.7.toml rename to .duvet/exceptions/tls/4.7.toml diff --git a/specs/exceptions/tls/5.1.toml b/.duvet/exceptions/tls/5.1.toml similarity index 100% rename from specs/exceptions/tls/5.1.toml rename to .duvet/exceptions/tls/5.1.toml diff --git a/specs/exceptions/tls/5.2.toml b/.duvet/exceptions/tls/5.2.toml similarity index 100% rename from specs/exceptions/tls/5.2.toml rename to .duvet/exceptions/tls/5.2.toml diff --git a/specs/exceptions/tls/5.3.toml b/.duvet/exceptions/tls/5.3.toml similarity index 100% rename from specs/exceptions/tls/5.3.toml rename to .duvet/exceptions/tls/5.3.toml diff --git a/specs/exceptions/tls/5.4.1.toml b/.duvet/exceptions/tls/5.4.1.toml similarity index 100% rename from specs/exceptions/tls/5.4.1.toml rename to .duvet/exceptions/tls/5.4.1.toml diff --git a/specs/exceptions/tls/6.2.toml b/.duvet/exceptions/tls/6.2.toml similarity index 100% rename from specs/exceptions/tls/6.2.toml rename to .duvet/exceptions/tls/6.2.toml diff --git a/specs/exceptions/tls/6.3.toml b/.duvet/exceptions/tls/6.3.toml similarity index 100% rename from specs/exceptions/tls/6.3.toml rename to .duvet/exceptions/tls/6.3.toml diff --git a/specs/exceptions/tls/6.4.toml b/.duvet/exceptions/tls/6.4.toml similarity index 100% rename from specs/exceptions/tls/6.4.toml rename to .duvet/exceptions/tls/6.4.toml diff --git a/specs/exceptions/tls/6.6.toml b/.duvet/exceptions/tls/6.6.toml similarity index 100% rename from specs/exceptions/tls/6.6.toml rename to .duvet/exceptions/tls/6.6.toml diff --git a/specs/exceptions/tls/8.1.toml b/.duvet/exceptions/tls/8.1.toml similarity index 100% rename from specs/exceptions/tls/8.1.toml rename to .duvet/exceptions/tls/8.1.toml diff --git a/specs/exceptions/tls/8.2.toml b/.duvet/exceptions/tls/8.2.toml similarity index 100% rename from specs/exceptions/tls/8.2.toml rename to .duvet/exceptions/tls/8.2.toml diff --git a/specs/exceptions/tls/8.3.toml b/.duvet/exceptions/tls/8.3.toml similarity index 100% rename from specs/exceptions/tls/8.3.toml rename to .duvet/exceptions/tls/8.3.toml diff --git a/specs/exceptions/tls/8.4.toml b/.duvet/exceptions/tls/8.4.toml similarity index 100% rename from specs/exceptions/tls/8.4.toml rename to .duvet/exceptions/tls/8.4.toml diff --git a/specs/exceptions/tls/9.2.toml b/.duvet/exceptions/tls/9.2.toml similarity index 100% rename from specs/exceptions/tls/9.2.toml rename to .duvet/exceptions/tls/9.2.toml diff --git a/specs/exceptions/tls/9.4.toml b/.duvet/exceptions/tls/9.4.toml similarity index 100% rename from specs/exceptions/tls/9.4.toml rename to .duvet/exceptions/tls/9.4.toml diff --git a/specs/exceptions/tls/9.6.toml b/.duvet/exceptions/tls/9.6.toml similarity index 100% rename from specs/exceptions/tls/9.6.toml rename to .duvet/exceptions/tls/9.6.toml diff --git a/specs/exceptions/transport/10.3.1.toml b/.duvet/exceptions/transport/10.3.1.toml similarity index 100% rename from specs/exceptions/transport/10.3.1.toml rename to .duvet/exceptions/transport/10.3.1.toml diff --git a/specs/exceptions/transport/10.3.2.toml b/.duvet/exceptions/transport/10.3.2.toml similarity index 100% rename from specs/exceptions/transport/10.3.2.toml rename to .duvet/exceptions/transport/10.3.2.toml diff --git a/specs/exceptions/transport/10.3.toml b/.duvet/exceptions/transport/10.3.toml similarity index 100% rename from specs/exceptions/transport/10.3.toml rename to .duvet/exceptions/transport/10.3.toml diff --git a/specs/exceptions/transport/19.15.toml b/.duvet/exceptions/transport/19.15.toml similarity index 100% rename from specs/exceptions/transport/19.15.toml rename to .duvet/exceptions/transport/19.15.toml diff --git a/specs/exceptions/transport/19.16.toml b/.duvet/exceptions/transport/19.16.toml similarity index 100% rename from specs/exceptions/transport/19.16.toml rename to .duvet/exceptions/transport/19.16.toml diff --git a/specs/exceptions/transport/2.2.toml b/.duvet/exceptions/transport/2.2.toml similarity index 100% rename from specs/exceptions/transport/2.2.toml rename to .duvet/exceptions/transport/2.2.toml diff --git a/specs/exceptions/transport/5.1.1.toml b/.duvet/exceptions/transport/5.1.1.toml similarity index 100% rename from specs/exceptions/transport/5.1.1.toml rename to .duvet/exceptions/transport/5.1.1.toml diff --git a/specs/exceptions/transport/5.1.2.toml b/.duvet/exceptions/transport/5.1.2.toml similarity index 100% rename from specs/exceptions/transport/5.1.2.toml rename to .duvet/exceptions/transport/5.1.2.toml diff --git a/specs/exceptions/transport/5.1.toml b/.duvet/exceptions/transport/5.1.toml similarity index 100% rename from specs/exceptions/transport/5.1.toml rename to .duvet/exceptions/transport/5.1.toml diff --git a/specs/exceptions/transport/5.2.3.toml b/.duvet/exceptions/transport/5.2.3.toml similarity index 100% rename from specs/exceptions/transport/5.2.3.toml rename to .duvet/exceptions/transport/5.2.3.toml diff --git a/specs/exceptions/transport/7.4.1.toml b/.duvet/exceptions/transport/7.4.1.toml similarity index 100% rename from specs/exceptions/transport/7.4.1.toml rename to .duvet/exceptions/transport/7.4.1.toml diff --git a/specs/exceptions/transport/7.toml b/.duvet/exceptions/transport/7.toml similarity index 100% rename from specs/exceptions/transport/7.toml rename to .duvet/exceptions/transport/7.toml diff --git a/specs/exceptions/transport/8.2.3.toml b/.duvet/exceptions/transport/8.2.3.toml similarity index 100% rename from specs/exceptions/transport/8.2.3.toml rename to .duvet/exceptions/transport/8.2.3.toml diff --git a/specs/exceptions/transport/8.2.4.toml b/.duvet/exceptions/transport/8.2.4.toml similarity index 100% rename from specs/exceptions/transport/8.2.4.toml rename to .duvet/exceptions/transport/8.2.4.toml diff --git a/specs/exceptions/transport/9.4.toml b/.duvet/exceptions/transport/9.4.toml similarity index 100% rename from specs/exceptions/transport/9.4.toml rename to .duvet/exceptions/transport/9.4.toml diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.2.toml new file mode 100644 index 0000000000..a34c5587bb --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.2.toml @@ -0,0 +1,43 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.2" + +# TCP-Friendly Region +# +# Standard TCP performs well in certain types of networks, for example, +# under short RTT and small bandwidth (or small BDP) networks. In +# these networks, we use the TCP-friendly region to ensure that CUBIC +# achieves at least the same throughput as Standard TCP. +# +# The TCP-friendly region is designed according to the analysis +# described in [FHP00]. The analysis studies the performance of an +# Additive Increase and Multiplicative Decrease (AIMD) algorithm with +# an additive factor of alpha_aimd (segments per RTT) and a +# multiplicative factor of beta_aimd, denoted by AIMD(alpha_aimd, +# beta_aimd). Specifically, the average congestion window size of +# AIMD(alpha_aimd, beta_aimd) can be calculated using Eq. 3. The +# analysis shows that AIMD(alpha_aimd, beta_aimd) with +# alpha_aimd=3*(1-beta_aimd)/(1+beta_aimd) achieves the same average +# window size as Standard TCP that uses AIMD(1, 0.5). +# +# AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / +# (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) +# +# Based on the above analysis, CUBIC uses Eq. 4 to estimate the window +# size W_est of AIMD(alpha_aimd, beta_aimd) with +# alpha_aimd=3*(1-beta_cubic)/(1+beta_cubic) and beta_aimd=beta_cubic, +# which achieves the same average window size as Standard TCP. When +# receiving an ACK in congestion avoidance (cwnd could be greater than +# +# or less than W_max), CUBIC checks whether W_cubic(t) is less than +# W_est(t). If so, CUBIC is in the TCP-friendly region and cwnd SHOULD +# be set to W_est(t) at each reception of an ACK. +# +# W_est(t) = W_max*beta_cubic + +# [3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT) (Eq. 4) + +[[spec]] +level = "SHOULD" +quote = ''' +If so, CUBIC is in the TCP-friendly region and cwnd SHOULD +be set to W_est(t) at each reception of an ACK. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.3.toml new file mode 100644 index 0000000000..920ac0f84d --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.3.toml @@ -0,0 +1,18 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.3" + +# Concave Region +# +# When receiving an ACK in congestion avoidance, if CUBIC is not in the +# TCP-friendly region and cwnd is less than W_max, then CUBIC is in the +# concave region. In this region, cwnd MUST be incremented by +# (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where +# W_cubic(t+RTT) is calculated using Eq. 1. + +[[spec]] +level = "MUST" +quote = ''' +In this region, cwnd MUST be incremented by +(W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where +W_cubic(t+RTT) is calculated using Eq. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.4.toml new file mode 100644 index 0000000000..838a118037 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.4.toml @@ -0,0 +1,28 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.4" + +# Convex Region +# +# When receiving an ACK in congestion avoidance, if CUBIC is not in the +# TCP-friendly region and cwnd is larger than or equal to W_max, then +# CUBIC is in the convex region. The convex region indicates that the +# network conditions might have been perturbed since the last +# congestion event, possibly implying more available bandwidth after +# some flow departures. Since the Internet is highly asynchronous, +# some amount of perturbation is always possible without causing a +# major change in available bandwidth. In this region, CUBIC is being +# very careful by very slowly increasing its window size. The convex +# profile ensures that the window increases very slowly at the +# beginning and gradually increases its increase rate. We also call +# this region the "maximum probing phase" since CUBIC is searching for +# a new W_max. In this region, cwnd MUST be incremented by +# (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where +# W_cubic(t+RTT) is calculated using Eq. 1. + +[[spec]] +level = "MUST" +quote = ''' +In this region, cwnd MUST be incremented by +(W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where +W_cubic(t+RTT) is calculated using Eq. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.5.toml new file mode 100644 index 0000000000..539f92ff63 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.5.toml @@ -0,0 +1,27 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.5" + +# Multiplicative Decrease +# +# When a packet loss is detected by duplicate ACKs or a network +# congestion is detected by ECN-Echo ACKs, CUBIC updates its W_max, +# cwnd, and ssthresh as follows. Parameter beta_cubic SHOULD be set to +# 0.7. +# +# W_max = cwnd; // save window size before reduction +# ssthresh = cwnd * beta_cubic; // new slow-start threshold +# ssthresh = max(ssthresh, 2); // threshold is at least 2 MSS +# cwnd = cwnd * beta_cubic; // window reduction +# +# A side effect of setting beta_cubic to a value bigger than 0.5 is +# slower convergence. We believe that while a more adaptive setting of +# beta_cubic could result in faster convergence, it will make the +# analysis of CUBIC much harder. This adaptive adjustment of +# beta_cubic is an item for the next version of CUBIC. + +[[spec]] +level = "SHOULD" +quote = ''' +Parameter beta_cubic SHOULD be set to +0.7. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.6.toml new file mode 100644 index 0000000000..68cd9a04e8 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.6.toml @@ -0,0 +1,54 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.6" + +# Fast Convergence +# +# To improve the convergence speed of CUBIC, we add a heuristic in +# CUBIC. When a new flow joins the network, existing flows in the +# network need to give up some of their bandwidth to allow the new flow +# some room for growth if the existing flows have been using all the +# bandwidth of the network. To speed up this bandwidth release by +# existing flows, the following mechanism called "fast convergence" +# SHOULD be implemented. +# +# With fast convergence, when a congestion event occurs, before the +# window reduction of the congestion window, a flow remembers the last +# value of W_max before it updates W_max for the current congestion +# event. Let us call the last value of W_max to be W_last_max. +# +# if (W_max < W_last_max){ // should we make room for others +# W_last_max = W_max; // remember the last W_max +# W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max +# } else { +# W_last_max = W_max // remember the last W_max +# } +# +# At a congestion event, if the current value of W_max is less than +# W_last_max, this indicates that the saturation point experienced by +# this flow is getting reduced because of the change in available +# bandwidth. Then we allow this flow to release more bandwidth by +# reducing W_max further. This action effectively lengthens the time +# for this flow to increase its congestion window because the reduced +# W_max forces the flow to have the plateau earlier. This allows more +# time for the new flow to catch up to its congestion window size. +# +# The fast convergence is designed for network environments with +# multiple CUBIC flows. In network environments with only a single +# CUBIC flow and without any other traffic, the fast convergence SHOULD +# be disabled. + +[[spec]] +level = "SHOULD" +quote = ''' +To speed up this bandwidth release by +existing flows, the following mechanism called "fast convergence" +SHOULD be implemented. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In network environments with only a single +CUBIC flow and without any other traffic, the fast convergence SHOULD +be disabled. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.8.toml new file mode 100644 index 0000000000..cb3368d5b9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-4.8.toml @@ -0,0 +1,34 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.8" + +# Slow Start +# +# CUBIC MUST employ a slow-start algorithm, when the cwnd is no more +# than ssthresh. Among the slow-start algorithms, CUBIC MAY choose the +# standard TCP slow start [RFC5681] in general networks, or the limited +# slow start [RFC3742] or hybrid slow start [HR08] for fast and long- +# distance networks. +# +# In the case when CUBIC runs the hybrid slow start [HR08], it may exit +# the first slow start without incurring any packet loss and thus W_max +# is undefined. In this special case, CUBIC switches to congestion +# avoidance and increases its congestion window size using Eq. 1, where +# t is the elapsed time since the beginning of the current congestion +# avoidance, K is set to 0, and W_max is set to the congestion window +# size at the beginning of the current congestion avoidance. + +[[spec]] +level = "MUST" +quote = ''' +CUBIC MUST employ a slow-start algorithm, when the cwnd is no more +than ssthresh. +''' + +[[spec]] +level = "MAY" +quote = ''' +Among the slow-start algorithms, CUBIC MAY choose the +standard TCP slow start [RFC5681] in general networks, or the limited +slow start [RFC3742] or hybrid slow start [HR08] for fast and long- +distance networks. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.1.toml new file mode 100644 index 0000000000..bf0a99c7bd --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.1.toml @@ -0,0 +1,90 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-5.1" + +# Fairness to Standard TCP +# +# In environments where Standard TCP is able to make reasonable use of +# the available bandwidth, CUBIC does not significantly change this +# state. +# +# Standard TCP performs well in the following two types of networks: +# +# 1. networks with a small bandwidth-delay product (BDP) +# +# 2. networks with a short RTTs, but not necessarily a small BDP +# +# CUBIC is designed to behave very similarly to Standard TCP in the +# above two types of networks. The following two tables show the +# average window sizes of Standard TCP, HSTCP, and CUBIC. The average +# window sizes of Standard TCP and HSTCP are from [RFC3649]. The +# average window size of CUBIC is calculated using Eq. 6 and the CUBIC +# TCP-friendly region for three different values of C. +# +# +--------+----------+-----------+------------+-----------+----------+ +# | Loss | Average | Average | CUBIC | CUBIC | CUBIC | +# | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | +# +--------+----------+-----------+------------+-----------+----------+ +# | 10^-2 | 12 | 12 | 12 | 12 | 12 | +# | 10^-3 | 38 | 38 | 38 | 38 | 59 | +# | 10^-4 | 120 | 263 | 120 | 187 | 333 | +# | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | +# | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | +# | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | +# | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | +# +--------+----------+-----------+------------+-----------+----------+ +# +# Table 1 +# +# Table 1 describes the response function of Standard TCP, HSTCP, and +# CUBIC in networks with RTT = 0.1 seconds. The average window size is +# in MSS-sized segments. +# +# +--------+-----------+-----------+------------+-----------+---------+ +# | Loss | Average | Average | CUBIC | CUBIC | CUBIC | +# | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | +# +--------+-----------+-----------+------------+-----------+---------+ +# | 10^-2 | 12 | 12 | 12 | 12 | 12 | +# | 10^-3 | 38 | 38 | 38 | 38 | 38 | +# | 10^-4 | 120 | 263 | 120 | 120 | 120 | +# | 10^-5 | 379 | 1795 | 379 | 379 | 379 | +# | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | +# | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | +# | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | +# +--------+-----------+-----------+------------+-----------+---------+ +# +# Table 2 +# +# Table 2 describes the response function of Standard TCP, HSTCP, and +# CUBIC in networks with RTT = 0.01 seconds. The average window size +# is in MSS-sized segments. +# +# Both tables show that CUBIC with any of these three C values is more +# friendly to TCP than HSTCP, especially in networks with a short RTT +# where TCP performs reasonably well. For example, in a network with +# RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 +# packets. If the packet size is 1500 bytes, then TCP can achieve an +# average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 +# achieves exactly the same rate as Standard TCP, whereas HSTCP is +# about ten times more aggressive than Standard TCP. +# +# We can see that C determines the aggressiveness of CUBIC in competing +# with other congestion control algorithms for bandwidth. CUBIC is +# more friendly to Standard TCP, if the value of C is lower. However, +# we do not recommend setting C to a very low value like 0.04, since +# CUBIC with a low C cannot efficiently use the bandwidth in long RTT +# and high-bandwidth networks. Based on these observations and our +# experiments, we find C=0.4 gives a good balance between TCP- +# friendliness and aggressiveness of window increase. Therefore, C +# SHOULD be set to 0.4. With C set to 0.4, Eq. 6 is reduced to: +# +# AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) +# +# Eq. 7 is then used in the next subsection to show the scalability of +# CUBIC. + +[[spec]] +level = "SHOULD" +quote = ''' +Therefore, C +SHOULD be set to 0.4. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.8.toml new file mode 100644 index 0000000000..e4b0c67b55 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8312/section-5.8.toml @@ -0,0 +1,19 @@ +target = "https://www.rfc-editor.org/rfc/rfc8312#section-5.8" + +# Behavior for Application-Limited Flows +# +# CUBIC does not raise its congestion window size if the flow is +# currently limited by the application instead of the congestion +# window. In case of long periods when cwnd has not been updated due +# to the application rate limit, such as idle periods, t in Eq. 1 MUST +# NOT include these periods; otherwise, W_cubic(t) might be very high +# after restarting from these periods. + +[[spec]] +level = "MUST" +quote = ''' +1 MUST +NOT include these periods; otherwise, W_cubic(t) might be very high +after restarting from these periods. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-1.3.toml new file mode 100644 index 0000000000..779caa1983 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-1.3.toml @@ -0,0 +1,68 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-1.3" + +# Path MTU Discovery for Datagram Services +# +# Section 5 of this document presents a set of algorithms for datagram +# protocols to discover the largest size of unfragmented datagram that +# can be sent over a network path. The method relies upon features of +# the PL described in Section 3 and applies to transport protocols +# operating over IPv4 and IPv6. It does not require cooperation from +# the lower layers, although it can utilize PTB messages when these +# received messages are made available to the PL. +# +# The message size guidelines in Section 3.2 of the UDP Usage +# Guidelines [BCP145] state that "an application SHOULD either use the +# Path MTU information provided by the IP layer or implement Path MTU +# Discovery (PMTUD)" but do not provide a mechanism for discovering the +# largest size of unfragmented datagram that can be used on a network +# path. The present document updates RFC 8085 to specify this method +# in place of PLPMTUD [RFC4821] and provides a mechanism for sharing +# the discovered largest size as the MPS (see Section 4.4). +# +# Section 10.2 of [RFC4821] recommended a PLPMTUD probing method for +# the Stream Control Transport Protocol (SCTP). SCTP utilizes probe +# packets consisting of a minimal-sized HEARTBEAT chunk bundled with a +# PAD chunk as defined in [RFC4820]. However, RFC 4821 did not provide +# a complete specification. The present document replaces that +# description by providing a complete specification. +# +# The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires +# implementations to support Classical PMTUD and states that a DCCP +# sender "MUST maintain the MPS allowed for each active DCCP session". +# It also defines the current congestion control MPS (CCMPS) supported +# by a network path. This recommends use of PMTUD and suggests use of +# control packets (DCCP-Sync) as path probe packets because they do not +# risk application data loss. The method defined in this specification +# can be used with DCCP. +# +# Section 4 and Section 5 define the protocol mechanisms and +# specification for Datagram Packetization Layer Path MTU Discovery +# (DPLPMTUD). +# +# Section 6 specifies the method for datagram transports and provides +# information to enable the implementation of PLPMTUD with other +# datagram transports and applications that use datagram transports. +# +# Section 6 also provides recommendations for SCTP endpoints, updating +# [RFC4960], [RFC6951], and [RFC8261] to use the method specified in +# this document instead of the method in [RFC4821]. + +[[spec]] +level = "SHOULD" +quote = ''' +The message size guidelines in Section 3.2 of the UDP Usage +Guidelines [BCP145] state that "an application SHOULD either use the +Path MTU information provided by the IP layer or implement Path MTU +Discovery (PMTUD)" but do not provide a mechanism for discovering the +largest size of unfragmented datagram that can be used on a network +path. +''' + +[[spec]] +level = "MUST" +quote = ''' +The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires +implementations to support Classical PMTUD and states that a DCCP +sender "MUST maintain the MPS allowed for each active DCCP session". +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-2.toml new file mode 100644 index 0000000000..5a1d641c8e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-2.toml @@ -0,0 +1,157 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-2" + +# Terminology +# +# 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. +# +# The following terminology is defined. Relevant terms are directly +# copied from [RFC4821], and the definitions in [RFC1122] apply. +# +# Acknowledged PL: A PL that includes a mechanism that can confirm +# successful delivery of datagrams to the remote PL endpoint (e.g., +# SCTP). Typically, the PL receiver returns acknowledgments +# corresponding to the received datagrams, which can be utilized to +# detect black-holing of packets (c.f., Unacknowledged PL). +# +# Actual PMTU: The actual PMTU is the PMTU of a network path between a +# sender PL and a destination PL, which the DPLPMTUD algorithm seeks +# to determine. +# +# Black Hole: A black hole is encountered when a sender is unaware +# that packets are not being delivered to the destination endpoint. +# Two types of black hole are relevant to DPLPMTUD: +# +# * Packets encounter a packet black hole when packets are not +# delivered to the destination endpoint (e.g., when the sender +# transmits packets of a particular size with a previously known +# effective PMTU, and they are discarded by the network). +# +# * An ICMP black hole is encountered when the sender is unaware +# that packets are not delivered to the destination endpoint +# because PTB messages are not received by the originating PL +# sender. +# +# Classical Path MTU Discovery: Classical PMTUD is a process described +# in [RFC1191] and [RFC8201] in which nodes rely on PTB messages to +# learn the largest size of unfragmented packet that can be used +# across a network path. +# +# Datagram: A datagram is a transport-layer protocol data unit, +# transmitted in the payload of an IP packet. +# +# DPLPMTUD: Datagram Packetization Layer Path MTU Discovery +# (DPLPMTUD), PLPMTUD performed using a datagram transport protocol. +# +# Effective PMTU: The effective PMTU is the current estimated value +# for PMTU that is used by a PMTUD. This is equivalent to the +# PLPMTU derived by PLPMTUD plus the size of any headers added below +# the PL, including the IP layer headers. +# +# EMTU_S: The effective MTU for sending (EMTU_S) is defined in +# [RFC1122] as "the maximum IP datagram size that may be sent, for a +# particular combination of IP source and destination addresses...". +# +# EMTU_R: The effective MTU for receiving (EMTU_R) is designated in +# [RFC1122] as "the largest datagram size that can be reassembled". +# +# Link: A link is a communication facility or medium over which nodes +# can communicate at the link layer, i.e., a layer below the IP +# layer. Examples are Ethernet LANs and Internet (or higher) layer +# tunnels. +# +# Link MTU: The link Maximum Transmission Unit (MTU) is the size in +# bytes of the largest IP packet, including the IP header and +# payload, that can be transmitted over a link. Note that this +# could more properly be called the IP MTU, to be consistent with +# how other standards organizations use the acronym. This includes +# the IP header but excludes link layer headers and other framing +# that is not part of IP or the IP payload. Other standards +# organizations generally define the link MTU to include the link +# layer headers. This specification continues the requirement in +# [RFC4821] that states, "All links MUST enforce their MTU: links +# that might non-deterministically deliver packets that are larger +# than their rated MTU MUST consistently discard such packets." +# +# MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that +# DPLPMTUD will attempt to use (see the constants defined in +# Section 5.1.2). +# +# MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that +# DPLPMTUD will attempt to use (see the constants defined in +# Section 5.1.2). +# +# MPS: The Maximum Packet Size (MPS) is the largest size of +# application data block that can be sent across a network path by a +# PL using a single datagram (see Section 4.4). +# +# MSL: The Maximum Segment Lifetime (MSL) is the maximum delay a +# packet is expected to experience across a path, taken as 2 minutes +# [BCP145]. +# +# Packet: A packet is the IP header(s) and any extension headers/ +# options plus the IP payload. +# +# Packetization Layer (PL): The PL is a layer of the network stack +# that places data into packets and performs transport protocol +# functions. Examples of a PL include TCP, SCTP, SCTP over UDP, +# SCTP over DTLS, or QUIC. +# +# Path: The path is the set of links and routers traversed by a packet +# between a source node and a destination node by a particular flow. +# +# Path MTU (PMTU): The Path MTU (PMTU) is the minimum of the link MTU +# of all the links forming a network path between a source node and +# a destination node, as used by PMTUD. +# +# PTB: In this document, the term PTB message is applied to both IPv4 +# ICMP Unreachable messages (Type 3) that carry the error +# Fragmentation Needed (Type 3, Code 4) [RFC0792] and ICMPv6 Packet +# Too Big messages (Type 2) [RFC4443]. +# +# PTB_SIZE: The PTB_SIZE is a value reported in a validated PTB +# message that indicates next-hop link MTU of a router along the +# path. +# +# PL_PTB_SIZE: The size reported in a validated PTB message, reduced +# by the size of all headers added by layers below the PL. +# +# PLPMTU: The Packetization Layer PMTU is an estimate of the largest +# size of PL datagram that can be sent by a path, controlled by +# PLPMTUD. +# +# PLPMTUD: Packetization Layer Path MTU Discovery (PLPMTUD), the +# method described in this document for datagram PLs, which is an +# extension to Classical PMTU Discovery. +# +# Probe packet: A probe packet is a datagram sent with a purposely +# chosen size (typically the current PLPMTU or larger) to detect if +# packets of this size can be successfully sent end-to-end across +# the network path. +# +# Unacknowledged PL: A PL that does not itself provide a mechanism to +# confirm delivery of datagrams to the remote PL endpoint (e.g., +# UDP), and therefore requires DPLPMTUD to provide a mechanism to +# detect black-holing of packets (c.f., Acknowledged PL). + +[[spec]] +level = "MUST" +quote = ''' +This specification continues the requirement in +[RFC4821] that states, "All links MUST enforce their MTU: links +that might non-deterministically deliver packets that are larger +than their rated MTU MUST consistently discard such packets." +''' + +[[spec]] +level = "MUST" +quote = ''' +This specification continues the requirement in +[RFC4821] that states, "All links MUST enforce their MTU: links +that might non-deterministically deliver packets that are larger +than their rated MTU MUST consistently discard such packets." +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-3.toml new file mode 100644 index 0000000000..bf8e802512 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-3.toml @@ -0,0 +1,389 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-3" + +# Features Required to Provide Datagram PLPMTUD +# +# The principles expressed in [RFC4821] apply to the use of the +# technique with any PL. TCP PLPMTUD has been defined using standard +# TCP protocol mechanisms. Unlike TCP, a datagram PL requires +# additional mechanisms and considerations to implement PLPMTUD. +# +# The requirements for datagram PLPMTUD are: +# +# 1. Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by +# DPLPMTUD. A PL MUST NOT send a datagram (other than a probe +# packet) with a size at the PL that is larger than the current +# PLPMTU. +# +# 2. Probe packets: The network interface below the PL is REQUIRED to +# provide a way to transmit a probe packet that is larger than the +# PLPMTU. In IPv4, a probe packet MUST be sent with the Don't +# Fragment (DF) bit set in the IP header and without network layer +# endpoint fragmentation. In IPv6, a probe packet is always sent +# without source fragmentation (as specified in Section 5.4 of +# [RFC8201]). +# +# 3. Reception feedback: The destination PL endpoint is REQUIRED to +# provide a feedback method that indicates to the DPLPMTUD sender +# when a probe packet has been received by the destination PL +# endpoint. Section 6 provides examples of how a PL can provide +# this acknowledgment of received probe packets. +# +# 4. Probe loss recovery: It is RECOMMENDED to use probe packets that +# do not carry any user data that would require retransmission if +# lost. Most datagram transports permit this. If a probe packet +# contains user data requiring retransmission in case of loss, the +# PL (or layers above) is REQUIRED to arrange any retransmission +# and/or repair of any resulting loss. The PL is REQUIRED to be +# robust in the case where probe packets are lost due to other +# reasons (including link transmission error, congestion). +# +# 5. PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize +# information about the maximum size of packet that can be +# transmitted by the sender on the local link (e.g., the local link +# MTU). A PL sender MAY utilize similar information about the +# maximum size of network-layer packet that a receiver can accept +# when this is supplied (note this could be less than EMTU_R). +# This avoids implementations trying to send probe packets that +# cannot be transferred by the local link. Too high of a value +# could reduce the efficiency of the search algorithm. Some +# applications also have a maximum transport protocol data unit +# (PDU) size, in which case there is no benefit from probing for a +# size larger than this (unless a transport allows multiplexing +# multiple applications' PDUs into the same datagram). +# +# 6. Processing PTB messages: A DPLPMTUD sender MAY optionally utilize +# PTB messages received from the network layer to help identify +# when a network path does not support the current size of probe +# packet. Any received PTB message MUST be validated before it is +# used to update the PLPMTU discovery information [RFC8201]. This +# validation confirms that the PTB message was sent in response to +# a packet originated by the sender and needs to be performed +# before the PLPMTU discovery method reacts to the PTB message. A +# PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but +# could trigger a probe to test for a larger PLPMTU. A valid +# PTB_SIZE is converted to a PL_PTB_SIZE before it is to be used in +# the DPLPMTUD state machine. A PL_PTB_SIZE that is greater than +# that currently probed SHOULD be ignored. (This PTB message ought +# to be discarded without further processing but could be utilized +# as an input that enables a resilience mode). +# +# 7. Probing and congestion control: A PL MAY use a congestion +# controller to decide when to send a probe packet. If +# transmission of probe packets is limited by the congestion +# controller, this could result in transmission of probe packets +# being delayed or suspended during congestion. When the +# transmission of probe packets is not controlled by the congestion +# controller, the interval between probe packets MUST be at least +# one RTT. Loss of a probe packet SHOULD NOT be treated as an +# indication of congestion and SHOULD NOT trigger a congestion +# control reaction [RFC4821] because this could result in +# unnecessary reduction of the sending rate. An update to the +# PLPMTU (or MPS) MUST NOT increase the congestion window measured +# in bytes [RFC4821]. Therefore, an increase in the packet size +# does not cause an increase in the data rate in bytes per second. +# A PL that maintains the congestion window in terms of a limit to +# the number of outstanding fixed-size packets SHOULD adapt this +# limit to compensate for the size of the actual packets. The +# transmission of probe packets can interact with the operation of +# a PL that performs burst mitigation or pacing, and the PL could +# need transmission of probe packets to be regulated by these +# methods. +# +# 8. Probing and flow control: Flow control at the PL concerns the +# end-to-end flow of data using the PL service. Flow control +# SHOULD NOT apply to DPLPMTU when probe packets use a design that +# does not carry user data to the remote application. +# +# 9. Shared PLPMTU state: The PMTU value calculated from the PLPMTU +# MAY also be stored with the corresponding entry associated with +# the destination in the IP layer cache and used by other PL +# instances. The specification of PLPMTUD [RFC4821] states, "If +# PLPMTUD updates the MTU for a particular path, all Packetization +# Layer sessions that share the path representation (as described +# in Section 5.2) SHOULD be notified to make use of the new MTU". +# Such methods MUST be robust to the wide variety of underlying +# network forwarding behaviors. Section 5.2 of [RFC8201] provides +# guidance on the caching of PMTU information and also the relation +# to IPv6 flow labels. +# +# In addition, the following principles are stated for design of a +# DPLPMTUD method: +# +# * A PL MAY be designed to segment data blocks larger than the MPS +# into multiple datagrams. However, not all datagram PLs support +# segmentation of data blocks. It is RECOMMENDED that methods avoid +# forcing an application to use an arbitrary small MPS for +# transmission while the method is searching for the currently +# supported PLPMTU. A reduced MPS can adversely impact the +# performance of an application. +# +# * To assist applications in choosing a suitable data block size, the +# PL is RECOMMENDED to provide a primitive that returns the MPS +# derived from the PLPMTU to the higher layer using the PL. The +# value of the MPS can change following a change in the path or loss +# of probe packets. +# +# * Path validation: It is RECOMMENDED that methods are robust to path +# changes that could have occurred since the path characteristics +# were last confirmed and to the possibility of inconsistent path +# information being received. +# +# * Datagram reordering: A method is REQUIRED to be robust to the +# possibility that a flow encounters reordering or that the traffic +# (including probe packets) is divided over more than one network +# path. +# +# * Datagram delay and duplication: The feedback mechanism is REQUIRED +# to be robust to the possibility that packets could be +# significantly delayed or duplicated along a network path. +# +# * When to probe: It is RECOMMENDED that methods determine whether +# the path has changed since it last measured the path. This can +# help determine when to probe the path again. + +[[spec]] +level = "MUST" +quote = ''' +A PL MUST NOT send a datagram (other than a probe +packet) with a size at the PL that is larger than the current +PLPMTU. +''' + +[[spec]] +level = "MUST" +quote = ''' +Probe packets: The network interface below the PL is REQUIRED to +provide a way to transmit a probe packet that is larger than the +PLPMTU. +''' + +[[spec]] +level = "MUST" +quote = ''' +In IPv4, a probe packet MUST be sent with the Don't +Fragment (DF) bit set in the IP header and without network layer +endpoint fragmentation. +''' + +[[spec]] +level = "MUST" +quote = ''' +Reception feedback: The destination PL endpoint is REQUIRED to +provide a feedback method that indicates to the DPLPMTUD sender +when a probe packet has been received by the destination PL +endpoint. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Probe loss recovery: It is RECOMMENDED to use probe packets that +do not carry any user data that would require retransmission if +lost. +''' + +[[spec]] +level = "MUST" +quote = ''' +If a probe packet +contains user data requiring retransmission in case of loss, the +PL (or layers above) is REQUIRED to arrange any retransmission +and/or repair of any resulting loss. +''' + +[[spec]] +level = "MUST" +quote = ''' +The PL is REQUIRED to be +robust in the case where probe packets are lost due to other +reasons (including link transmission error, congestion). +''' + +[[spec]] +level = "SHOULD" +quote = ''' +PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize +information about the maximum size of packet that can be +transmitted by the sender on the local link (e.g., the local link +MTU). +''' + +[[spec]] +level = "MAY" +quote = ''' +A PL sender MAY utilize similar information about the +maximum size of network-layer packet that a receiver can accept +when this is supplied (note this could be less than EMTU_R). +''' + +[[spec]] +level = "MAY" +quote = ''' +Processing PTB messages: A DPLPMTUD sender MAY optionally utilize +PTB messages received from the network layer to help identify +when a network path does not support the current size of probe +packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +Any received PTB message MUST be validated before it is +used to update the PLPMTU discovery information [RFC8201]. +''' + +[[spec]] +level = "MUST" +quote = ''' +A +PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but +could trigger a probe to test for a larger PLPMTU. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A PL_PTB_SIZE that is greater than +that currently probed SHOULD be ignored. +''' + +[[spec]] +level = "MAY" +quote = ''' +Probing and congestion control: A PL MAY use a congestion +controller to decide when to send a probe packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +When the +transmission of probe packets is not controlled by the congestion +controller, the interval between probe packets MUST be at least +one RTT. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Loss of a probe packet SHOULD NOT be treated as an +indication of congestion and SHOULD NOT trigger a congestion +control reaction [RFC4821] because this could result in +unnecessary reduction of the sending rate. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Loss of a probe packet SHOULD NOT be treated as an +indication of congestion and SHOULD NOT trigger a congestion +control reaction [RFC4821] because this could result in +unnecessary reduction of the sending rate. +''' + +[[spec]] +level = "MUST" +quote = ''' +An update to the +PLPMTU (or MPS) MUST NOT increase the congestion window measured +in bytes [RFC4821]. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A PL that maintains the congestion window in terms of a limit to +the number of outstanding fixed-size packets SHOULD adapt this +limit to compensate for the size of the actual packets. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Flow control +SHOULD NOT apply to DPLPMTU when probe packets use a design that +does not carry user data to the remote application. +''' + +[[spec]] +level = "MAY" +quote = ''' +Shared PLPMTU state: The PMTU value calculated from the PLPMTU +MAY also be stored with the corresponding entry associated with +the destination in the IP layer cache and used by other PL +instances. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The specification of PLPMTUD [RFC4821] states, "If +PLPMTUD updates the MTU for a particular path, all Packetization +Layer sessions that share the path representation (as described +in Section 5.2) SHOULD be notified to make use of the new MTU". +''' + +[[spec]] +level = "MUST" +quote = ''' +Such methods MUST be robust to the wide variety of underlying +network forwarding behaviors. +''' + +[[spec]] +level = "MAY" +quote = ''' +* A PL MAY be designed to segment data blocks larger than the MPS +into multiple datagrams. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +It is RECOMMENDED that methods avoid +forcing an application to use an arbitrary small MPS for +transmission while the method is searching for the currently +supported PLPMTU. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +* To assist applications in choosing a suitable data block size, the +PL is RECOMMENDED to provide a primitive that returns the MPS +derived from the PLPMTU to the higher layer using the PL. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +* Path validation: It is RECOMMENDED that methods are robust to path +changes that could have occurred since the path characteristics +were last confirmed and to the possibility of inconsistent path +information being received. +''' + +[[spec]] +level = "MUST" +quote = ''' +* Datagram reordering: A method is REQUIRED to be robust to the +possibility that a flow encounters reordering or that the traffic +(including probe packets) is divided over more than one network +path. +''' + +[[spec]] +level = "MUST" +quote = ''' +* Datagram delay and duplication: The feedback mechanism is REQUIRED +to be robust to the possibility that packets could be +significantly delayed or duplicated along a network path. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +* When to probe: It is RECOMMENDED that methods determine whether +the path has changed since it last measured the path. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.1.toml new file mode 100644 index 0000000000..7dc8ce2b7b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.1.toml @@ -0,0 +1,87 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.1" + +# PLPMTU Probe Packets +# +# The DPLPMTUD method relies upon the PL sender being able to generate +# probe packets with a specific size. TCP is able to generate these +# probe packets by choosing to appropriately segment data being sent +# [RFC4821]. In contrast, a datagram PL that constructs a probe packet +# has to either request an application to send a data block that is +# larger than that generated by an application, or to utilize padding +# functions to extend a datagram beyond the size of the application +# data block. Protocols that permit exchange of control messages +# (without an application data block) can generate a probe packet by +# extending a control message with padding data. The total size of a +# probe packet includes all headers and padding added to the payload +# data being sent (e.g., including protocol option fields, security- +# related fields such as an Authenticated Encryption with Associated +# Data (AEAD) tag, and TLS record layer padding). +# +# A receiver is REQUIRED to be able to distinguish an in-band data +# block from any added padding. This is needed to ensure that any +# added padding is not passed on to an application at the receiver. +# +# This results in three possible ways that a sender can create a probe +# packet: +# +# Probing using padding data: A probe packet that contains only +# control information together with any padding, which is needed to +# inflate to the size of the probe packet. Since these probe +# packets do not carry an application-supplied data block, they do +# not typically require retransmission, although they do still +# consume network capacity and incur endpoint processing. +# +# Probing using application data and padding data: A probe packet that +# contains a data block supplied by an application that is combined +# with padding to inflate the length of the datagram to the size of +# the probe packet. +# +# Probing using application data: A probe packet that contains a data +# block supplied by an application that matches the size of the +# probe packet. This method requests the application to issue a +# data block of the desired probe size. +# +# A PL that uses a probe packet carrying application data and that +# needs protection from the loss of this probe packet could perform +# transport-layer retransmission/repair of the data block (e.g., by +# retransmitting after loss is detected or by duplicating the data +# block in a datagram without the padding data). This retransmitted +# data block might possibly need to be sent using a smaller PLPMTU, +# which could force the PL to use a smaller packet size to traverse the +# end-to-end path. (This could utilize endpoint network-layer +# fragmentation or a PL that can resegment the data block into multiple +# datagrams). +# +# DPLPMTUD MAY choose to use only one of these methods to simplify the +# implementation. +# +# Probe messages sent by a PL MUST contain enough information to +# uniquely identify the probe within the Maximum Segment Lifetime +# (e.g., including a unique identifier from the PL or the DPLPMTUD +# implementation), while being robust to reordering and replay of probe +# response and PTB messages. + +[[spec]] +level = "MUST" +quote = ''' +A receiver is REQUIRED to be able to distinguish an in-band data +block from any added padding. +''' + +[[spec]] +level = "MAY" +quote = ''' +DPLPMTUD MAY choose to use only one of these methods to simplify the +implementation. +''' + +[[spec]] +level = "MUST" +quote = ''' +Probe messages sent by a PL MUST contain enough information to +uniquely identify the probe within the Maximum Segment Lifetime +(e.g., including a unique identifier from the PL or the DPLPMTUD +implementation), while being robust to reordering and replay of probe +response and PTB messages. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.2.toml new file mode 100644 index 0000000000..3272eb5a57 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.2.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.2" + +# Confirmation of Probed Packet Size +# +# The PL needs a method to determine (confirm) when probe packets have +# been successfully received end-to-end across a network path. +# +# Transport protocols can include end-to-end methods that detect and +# report reception of specific datagrams that they send (e.g., DCCP, +# SCTP, and QUIC provide keep-alive/heartbeat features). When +# supported, this mechanism MAY also be used by DPLPMTUD to acknowledge +# reception of a probe packet. +# +# A PL that does not acknowledge data reception (e.g., UDP and UDP- +# Lite) is unable itself to detect when the packets that it sends are +# discarded because their size is greater than the actual PMTU. These +# PLs need to rely on an application protocol to detect this loss. +# +# Section 6 specifies this function for a set of IETF-specified +# protocols. + +[[spec]] +level = "MAY" +quote = ''' +When +supported, this mechanism MAY also be used by DPLPMTUD to acknowledge +reception of a probe packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.3.toml new file mode 100644 index 0000000000..87bc1a9989 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.3.toml @@ -0,0 +1,69 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.3" + +# Black Hole Detection and Reducing the PLPMTU +# +# The description that follows uses the set of constants defined in +# Section 5.1.2 and variables defined in Section 5.1.3. +# +# Black hole detection is triggered by an indication that the network +# path could be unable to support the current PLPMTU size. +# +# There are three indicators that can be used to detect black holes: +# +# * A validated PTB message can be received that indicates a +# PL_PTB_SIZE less than the current PLPMTU. A DPLPMTUD method MUST +# NOT rely solely on this method. +# +# * A PL can use the DPLPMTUD probing mechanism to periodically +# generate probe packets of the size of the current PLPMTU (e.g., +# using the CONFIRMATION_TIMER, Section 5.1.1). A timer tracks +# whether acknowledgments are received. Successive loss of probes +# is an indication that the current path no longer supports the +# PLPMTU (e.g., when the number of probe packets sent without +# receiving an acknowledgment, PROBE_COUNT, becomes greater than +# MAX_PROBES). +# +# * A PL can utilize an event that indicates the network path no +# longer sustains the sender's PLPMTU size. This could use a +# mechanism implemented within the PL to detect excessive loss of +# data sent with a specific packet size and then conclude that this +# excessive loss could be a result of an invalid PLPMTU (as in +# PLPMTUD for TCP [RFC4821]). +# +# The three methods can result in different transmission patterns for +# packet probes and are expected to result in different responsiveness +# following a change in the actual PMTU. +# +# A PL MAY inhibit sending probe packets when no application data has +# been sent since the previous probe packet. A PL that resumes sending +# user data MAY continue PLPMTU discovery for each path. This allows +# it to use an up-to-date PLPMTU. However, this could result in +# additional packets being sent. +# +# When the method detects that the current PLPMTU is not supported, +# DPLPMTUD sets a lower PLPMTU and a lower MPS. The PL then confirms +# that the new PLPMTU can be successfully used across the path. A +# probe packet could need to be smaller than the size of the data block +# generated by the application. + +[[spec]] +level = "MUST" +quote = ''' +A DPLPMTUD method MUST +NOT rely solely on this method. +''' + +[[spec]] +level = "MAY" +quote = ''' +A PL MAY inhibit sending probe packets when no application data has +been sent since the previous probe packet. +''' + +[[spec]] +level = "MAY" +quote = ''' +A PL that resumes sending +user data MAY continue PLPMTU discovery for each path. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.4.toml new file mode 100644 index 0000000000..0fd95f9275 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.4.toml @@ -0,0 +1,72 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.4" + +# The Maximum Packet Size (MPS) +# +# The result of probing determines a usable PLPMTU, which is used to +# set the MPS used by the application. The MPS is smaller than the +# PLPMTU because it is reduced by the size of PL headers (including the +# overhead of security-related fields such as an AEAD tag and TLS +# record layer padding). The relationship between the MPS and the +# PLPMTUD is illustrated in Figure 1. +# +# Any additional +# headers .--- MPS -----. +# | | | +# v v v +# +------------------------------+ +# | IP | ** | PL | protocol data | +# +------------------------------+ +# +# <----- PLPMTU -----> +# <---------- PMTU --------------> +# +# Figure 1: Relationship between MPS and PLPMTU +# +# A PL is unable to send a packet (other than a probe packet) with a +# size larger than the current PLPMTU at the network layer. To avoid +# this, a PL MAY be designed to segment data blocks larger than the MPS +# into multiple datagrams. +# +# DPLPMTUD seeks to avoid IP fragmentation. An attempt to send a data +# block larger than the MPS will therefore fail if a PL is unable to +# segment data. To determine the largest data block that can be sent, +# a PL SHOULD provide applications with a primitive that returns the +# MPS, derived from the current PLPMTU. +# +# If DPLPMTUD results in a change to the MPS, the application needs to +# adapt to the new MPS. A particular case can arise when packets have +# been sent with a size less than the MPS and the PLPMTU was +# subsequently reduced. If these packets are lost, the PL MAY segment +# the data using the new MPS. If a PL is unable to resegment a +# previously sent datagram (e.g., [RFC4960]), then the sender either +# discards the datagram or could perform retransmission using network- +# layer fragmentation to form multiple IP packets not larger than the +# PLPMTU. For IPv4, the use of endpoint fragmentation by the sender is +# preferred over clearing the DF bit in the IPv4 header. Operational +# experience reveals that IP fragmentation can reduce the reliability +# of Internet communication [RFC8900], which may reduce the probability +# of successful retransmission. + +[[spec]] +level = "MAY" +quote = ''' +To avoid +this, a PL MAY be designed to segment data blocks larger than the MPS +into multiple datagrams. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +To determine the largest data block that can be sent, +a PL SHOULD provide applications with a primitive that returns the +MPS, derived from the current PLPMTU. +''' + +[[spec]] +level = "MAY" +quote = ''' +If these packets are lost, the PL MAY segment +the data using the new MPS. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.5.toml new file mode 100644 index 0000000000..0c8bca2e54 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.5.toml @@ -0,0 +1,20 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.5" + +# Disabling the Effect of PMTUD +# +# A PL implementing this specification MUST suspend network layer +# processing of outgoing packets that enforces a PMTU +# [RFC1191][RFC8201] for each flow utilizing DPLPMTUD and instead use +# DPLPMTUD to control the size of packets that are sent by a flow. +# This removes the need for the network layer to drop or to fragment +# sent packets that have a size greater than the PMTU. + +[[spec]] +level = "MUST" +quote = ''' +A PL implementing this specification MUST suspend network layer +processing of outgoing packets that enforces a PMTU +[RFC1191][RFC8201] for each flow utilizing DPLPMTUD and instead use +DPLPMTUD to control the size of packets that are sent by a flow. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.1.toml new file mode 100644 index 0000000000..13cdaacef6 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.1.toml @@ -0,0 +1,81 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.6.1" + +# Validation of PTB Messages +# +# This section specifies utilization and validation of PTB messages. +# +# * A simple implementation MAY ignore received PTB messages, and in +# this case, the PLPMTU is not updated when a PTB message is +# received. +# +# * A PL that supports PTB messages MUST validate these messages +# before they are further processed. +# +# A PL that receives a PTB message from a router or middlebox performs +# ICMP validation (see Section 4 of [RFC8201] and Section 5.2 of +# [BCP145]). Because DPLPMTUD operates at the PL, the PL needs to +# check that each received PTB message is received in response to a +# packet transmitted by the endpoint PL performing DPLPMTUD. +# +# The PL MUST check the protocol information in the quoted packet +# carried in an ICMP PTB message payload to validate the message +# originated from the sending node. This validation includes +# determining that the combination of the IP addresses, the protocol, +# the source port, and destination port match those returned in the +# quoted packet -- this is also necessary for the PTB message to be +# passed to the corresponding PL. +# +# The validation SHOULD utilize information that is not simple for an +# off-path attacker to determine [BCP145]. For example, it could check +# the value of a protocol header field known only to the two PL +# endpoints. A datagram application that uses well-known source and +# destination ports ought to also rely on other information to complete +# this validation. +# +# These checks are intended to provide protection from packets that +# originate from a node that is not on the network path. A PTB message +# that does not complete the validation MUST NOT be further utilized by +# the DPLPMTUD method, as discussed in the Security Considerations +# section (Section 8). +# +# Section 4.6.2 describes this processing of PTB messages. + +[[spec]] +level = "MAY" +quote = ''' +* A simple implementation MAY ignore received PTB messages, and in +this case, the PLPMTU is not updated when a PTB message is +received. +''' + +[[spec]] +level = "MUST" +quote = ''' +* A PL that supports PTB messages MUST validate these messages +before they are further processed. +''' + +[[spec]] +level = "MUST" +quote = ''' +The PL MUST check the protocol information in the quoted packet +carried in an ICMP PTB message payload to validate the message +originated from the sending node. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The validation SHOULD utilize information that is not simple for an +off-path attacker to determine [BCP145]. +''' + +[[spec]] +level = "MUST" +quote = ''' +A PTB message +that does not complete the validation MUST NOT be further utilized by +the DPLPMTUD method, as discussed in the Security Considerations +section (Section 8). +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.2.toml new file mode 100644 index 0000000000..d20b27703a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-4.6.2.toml @@ -0,0 +1,111 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.6.2" + +# Use of PTB Messages +# +# PTB messages that have been validated MAY be utilized by the DPLPMTUD +# algorithm but MUST NOT be used directly to set the PLPMTU. +# +# Before using the size reported in the PTB message, it must first be +# converted to a PL_PTB_SIZE. The PL_PTB_SIZE is smaller than the +# PTB_SIZE because it is reduced by headers below the PL, including any +# IP options or extensions added to the PL packet. +# +# A method that utilizes these PTB messages can improve the speed at +# which the algorithm detects an appropriate PLPMTU by triggering an +# immediate probe for the PL_PTB_SIZE (resulting in a network-layer +# packet of size PTB_SIZE), compared to one that relies solely on +# probing using a timer-based search algorithm. +# +# A set of checks are intended to provide protection from a router that +# reports an unexpected PTB_SIZE. The PL also needs to check that the +# indicated PL_PTB_SIZE is less than the size used by probe packets and +# at least the minimum size accepted. +# +# This section provides a summary of how PTB messages can be utilized, +# using the set of constants defined in Section 5.1.2. This processing +# depends on the PL_PTB_SIZE and the current value of a set of +# variables: +# +# PL_PTB_SIZE < MIN_PLPMTU +# * Invalid PL_PTB_SIZE, see Section 4.6.1. +# +# * PTB message ought to be discarded without further processing +# (i.e., PLPMTU is not modified). +# +# * The information could be utilized as an input that triggers the +# enabling of a resilience mode (see Section 5.3.3). +# +# MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU +# * A robust PL MAY enter an error state (see Section 5.2) for an +# IPv4 path when the PL_PTB_SIZE reported in the PTB message is +# larger than or equal to 68 bytes [RFC0791] and when this is +# less than the BASE_PLPMTU. +# +# * A robust PL MAY enter an error state (see Section 5.2) for an +# IPv6 path when the PL_PTB_SIZE reported in the PTB message is +# larger than or equal to 1280 bytes [RFC8200] and when this is +# less than the BASE_PLPMTU. +# +# BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU +# * This could be an indication of a black hole. The PLPMTU SHOULD +# be set to BASE_PLPMTU (the PLPMTU is reduced to the BASE_PLPMTU +# to avoid unnecessary packet loss when a black hole is +# encountered). +# +# * The PL ought to start a search to quickly discover the new +# PLPMTU. The PL_PTB_SIZE reported in the PTB message can be +# used to initialize a search algorithm. +# +# PLPMTU < PL_PTB_SIZE < PROBED_SIZE +# * The PLPMTU continues to be valid, but the size of a packet used +# to search (PROBED_SIZE) was larger than the actual PMTU. +# +# * The PLPMTU is not updated. +# +# * The PL can use the reported PL_PTB_SIZE from the PTB message as +# the next search point when it resumes the search algorithm. +# +# PL_PTB_SIZE >= PROBED_SIZE +# * Inconsistent network signal. +# +# * PTB message ought to be discarded without further processing +# (i.e., PLPMTU is not modified). +# +# * The information could be utilized as an input to trigger the +# enabling of a resilience mode. + +[[spec]] +level = "MUST" +quote = ''' +PTB messages that have been validated MAY be utilized by the DPLPMTUD +algorithm but MUST NOT be used directly to set the PLPMTU. +''' + +[[spec]] +level = "MAY" +quote = ''' +MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU +* A robust PL MAY enter an error state (see Section 5.2) for an +IPv4 path when the PL_PTB_SIZE reported in the PTB message is +larger than or equal to 68 bytes [RFC0791] and when this is +less than the BASE_PLPMTU. +''' + +[[spec]] +level = "MAY" +quote = ''' +* A robust PL MAY enter an error state (see Section 5.2) for an +IPv6 path when the PL_PTB_SIZE reported in the PTB message is +larger than or equal to 1280 bytes [RFC8200] and when this is +less than the BASE_PLPMTU. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The PLPMTU SHOULD +be set to BASE_PLPMTU (the PLPMTU is reduced to the BASE_PLPMTU +to avoid unnecessary packet loss when a black hole is +encountered). +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.1.toml new file mode 100644 index 0000000000..6a71340aea --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.1.toml @@ -0,0 +1,71 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.1.1" + +# Timers +# +# The method utilizes up to three timers: +# +# PROBE_TIMER: The PROBE_TIMER is configured to expire after a period +# longer than the maximum time to receive an acknowledgment to a +# probe packet. This value MUST NOT be smaller than 1 second and +# SHOULD be larger than 15 seconds. Guidance on the selection of +# the timer value is provided in Section 3.1.1 of the UDP Usage +# Guidelines [BCP145]. +# +# PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period a +# sender will continue to use the current PLPMTU, after which it +# reenters the Search Phase. This timer has a period of 600 +# seconds, as recommended by PLPMTUD [RFC4821]. +# +# DPLPMTUD MAY inhibit sending probe packets when no application +# data has been sent since the previous probe packet. A PL +# preferring to use an up-to-date PMTU once user data is sent again +# can choose to continue PMTU discovery for each path. However, +# this will result in sending additional packets. +# +# CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST +# NOT be used. For other PLs, the CONFIRMATION_TIMER is configured +# to the period a PL sender waits before confirming the current +# PLPMTU is still supported. This is less than the PMTU_RAISE_TIMER +# and used to decrease the PLPMTU (e.g., when a black hole is +# encountered). Confirmation needs to be frequent enough when data +# is flowing that the sending PL does not black hole extensive +# amounts of traffic. Guidance on selection of the timer value are +# provided in Section 3.1.1 of the UDP Usage Guidelines [BCP145]. +# +# DPLPMTUD MAY inhibit sending probe packets when no application +# data has been sent since the previous probe packet. A PL +# preferring to use an up-to-date PMTU once user data is sent again, +# can choose to continue PMTU discovery for each path. However, +# this could result in sending additional packets. +# +# DPLPMTUD specifies various timers; however, an implementation could +# choose to realize these timer functions using a single timer. + +[[spec]] +level = "MUST" +quote = ''' +This value MUST NOT be smaller than 1 second and +SHOULD be larger than 15 seconds. +''' + +[[spec]] +level = "MAY" +quote = ''' +DPLPMTUD MAY inhibit sending probe packets when no application +data has been sent since the previous probe packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST +NOT be used. +''' + +[[spec]] +level = "MAY" +quote = ''' +DPLPMTUD MAY inhibit sending probe packets when no application +data has been sent since the previous probe packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.2.toml new file mode 100644 index 0000000000..56bad7f6b9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.1.2.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.1.2" + +# Constants +# +# The following constants are defined: +# +# MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT +# counter (see Section 5.1.3). MAX_PROBES represents the limit for +# the number of consecutive probe attempts of any size. Search +# algorithms benefit from a MAX_PROBES value greater than 1 because +# this can provide robustness to isolated packet loss. The default +# value of MAX_PROBES is 3. +# +# MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that +# DPLPMTUD will attempt to use. An endpoint could need to configure +# the MIN_PLPMTU to provide space for extension headers and other +# encapsulations at layers below the PL. This value can be +# interface and path dependent. For IPv6, this size is greater than +# or equal to the size at the PL that results in an 1280-byte IPv6 +# packet, as specified in [RFC8200]. For IPv4, this size is greater +# than or equal to the size at the PL that results in an 68-byte +# IPv4 packet. Note: An IPv4 router is required to be able to +# forward a datagram of 68 bytes without further fragmentation. +# This is the combined size of an IPv4 header and the minimum +# fragment size of 8 bytes. In addition, receivers are required to +# be able to reassemble fragmented datagrams at least up to 576 +# bytes, as stated in Section 3.3.3 of [RFC1122]. +# +# MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU. This has +# to be less than or equal to the maximum size of the PL packet that +# can be sent on the outgoing interface (constrained by the local +# interface MTU). When known, this also ought to be less than the +# maximum size of PL packet that can be received by the remote +# endpoint (constrained by EMTU_R). It can be limited by the design +# or configuration of the PL being used. An application, or PL, MAY +# choose a smaller MAX_PLPMTU when there is no need to send packets +# larger than a specific size. +# +# BASE_PLPMTU: The BASE_PLPMTU is a configured size expected to work +# for most paths. The size is equal to or larger than the +# MIN_PLPMTU and smaller than the MAX_PLPMTU. For most PLs, a +# suitable BASE_PLPMTU will be larger than 1200 bytes. When using +# IPv4, there is no currently equivalent size specified, and a +# default BASE_PLPMTU of 1200 bytes is RECOMMENDED. + +[[spec]] +level = "MAY" +quote = ''' +An application, or PL, MAY +choose a smaller MAX_PLPMTU when there is no need to send packets +larger than a specific size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When using +IPv4, there is no currently equivalent size specified, and a +default BASE_PLPMTU of 1200 bytes is RECOMMENDED. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.2.toml new file mode 100644 index 0000000000..cd899f02fe --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.2.toml @@ -0,0 +1,139 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.2" + +# State Machine +# +# A state machine for DPLPMTUD is depicted in Figure 5. If multipath +# or multihoming is supported, a state machine is needed for each path. +# +# Note: Not all changes are shown to simplify the diagram. +# +# | | +# | Start | PL indicates loss +# | | of connectivity +# v v +# +---------------+ +---------------+ +# | DISABLED | | ERROR | +# +---------------+ PROBE_TIMER expiry: +---------------+ +# | PL indicates PROBE_COUNT = MAX_PROBES or ^ | +# | connectivity PTB: PL_PTB_SIZE < BASE_PLPMTU | | +# +--------------------+ +------------------+ | +# | | | +# v | BASE_PLPMTU Probe | +# +---------------+ acked | +# | BASE |--------------------->+ +# +---------------+ | +# ^ | ^ ^ | +# Black hole detected | | | | Black hole detected | +# +--------------------+ | | +--------------------+ | +# | +----+ | | +# | PROBE_TIMER expiry: | | +# | PROBE_COUNT < MAX_PROBES | | +# | | | +# | PMTU_RAISE_TIMER expiry | | +# | +-----------------------------------------+ | | +# | | | | | +# | | v | v +# +---------------+ +---------------+ +# |SEARCH_COMPLETE| | SEARCHING | +# +---------------+ +---------------+ +# | ^ ^ | | ^ +# | | | | | | +# | | +-----------------------------------------+ | | +# | | MAX_PLPMTU Probe acked or | | +# | | PROBE_TIMER expiry: PROBE_COUNT = MAX_PROBES or | | +# +----+ PTB: PL_PTB_SIZE = PLPMTU +----+ +# CONFIRMATION_TIMER expiry: PROBE_TIMER expiry: +# PROBE_COUNT < MAX_PROBES or PROBE_COUNT < MAX_PROBES or +# PLPMTU Probe acked Probe acked or PTB: +# PLPMTU < PL_PTB_SIZE < PROBED_SIZE +# +# Figure 5: State Machine for Datagram PLPMTUD +# +# The following states are defined: +# +# DISABLED: The DISABLED state is the initial state before probing has +# started. It is also entered from any other state, when the PL +# indicates loss of connectivity. This state is left once the PL +# indicates connectivity to the remote PL. When transitioning to +# the BASE state, a probe packet of size BASE_PLPMTU can be sent +# immediately. +# +# BASE: The BASE state is used to confirm that the BASE_PLPMTU size is +# supported by the network path and is designed to allow an +# application to continue working when there are transient +# reductions in the actual PMTU. It also seeks to avoid long +# periods when a sender searching for a larger PLPMTU is unaware +# that packets are not being delivered due to a packet or ICMP black +# hole. +# +# On entry, the PROBED_SIZE is set to the BASE_PLPMTU size, and the +# PROBE_COUNT is set to zero. +# +# Each time a probe packet is sent, the PROBE_TIMER is started. The +# state is exited when the probe packet is acknowledged, and the PL +# sender enters the SEARCHING state. +# +# The state is also left when the PROBE_COUNT reaches MAX_PROBES or +# a received PTB message is validated. This causes the PL sender to +# enter the ERROR state. +# +# SEARCHING: The SEARCHING state is the main probing state. This +# state is entered when probing for the BASE_PLPMTU completes. +# +# Each time a probe packet is acknowledged, the PROBE_COUNT is set +# to zero, the PLPMTU is set to the PROBED_SIZE, and then the +# PROBED_SIZE is increased using the search algorithm (as described +# in Section 5.3). +# +# When a probe packet is sent and not acknowledged within the period +# of the PROBE_TIMER, the PROBE_COUNT is incremented, and a new +# probe packet is transmitted. +# +# The state is exited to enter SEARCH_COMPLETE when the PROBE_COUNT +# reaches MAX_PROBES, a validated PTB is received that corresponds +# to the last successfully probed size (PL_PTB_SIZE = PLPMTU), or a +# probe of size MAX_PLPMTU is acknowledged (PLPMTU = MAX_PLPMTU). +# +# When a black hole is detected in the SEARCHING state, this causes +# the PL sender to enter the BASE state. +# +# SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates that a search +# has completed. This is the normal maintenance state, where the PL +# is not probing to update the PLPMTU. DPLPMTUD remains in this +# state until either the PMTU_RAISE_TIMER expires or a black hole is +# detected. +# +# When DPLPMTUD uses an unacknowledged PL and is in the +# SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets +# the PROBE_COUNT and schedules a probe packet with the size of the +# PLPMTU. If MAX_PROBES successive PLPMTUD-sized probes fail to be +# acknowledged, the method enters the BASE state. When used with an +# acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to +# generate PLPMTU probes in this state. +# +# ERROR: The ERROR state represents the case where either the network +# path is not known to support a PLPMTU of at least the BASE_PLPMTU +# size or when there is contradictory information about the network +# path that would otherwise result in excessive variation in the MPS +# signaled to the higher layer. The state implements a method to +# mitigate oscillation in the state-event engine. It signals a +# conservative value of the MPS to the higher layer by the PL. The +# state is exited when packet probes no longer detect the error. +# The PL sender then enters the SEARCHING state. +# +# Implementations are permitted to enable endpoint fragmentation if +# the DPLPMTUD is unable to validate MIN_PLPMTU within PROBE_COUNT +# probes. If DPLPMTUD is unable to validate MIN_PLPMTU, the +# implementation will transition to the DISABLED state. +# +# Note: MIN_PLPMTU could be identical to BASE_PLPMTU, simplifying +# the actions in this state. + +[[spec]] +level = "SHOULD" +quote = ''' +When used with an +acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to +generate PLPMTU probes in this state. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.1.toml new file mode 100644 index 0000000000..a3e820077a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.1.toml @@ -0,0 +1,45 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.3.1" + +# Probing for a Larger PLPMTU +# +# Implementations use a search algorithm across the search range to +# determine whether a larger PLPMTU can be supported across a network +# path. +# +# The method discovers the search range by confirming the minimum +# PLPMTU and then using the probe method to select a PROBED_SIZE less +# than or equal to MAX_PLPMTU. MAX_PLPMTU is the minimum of the local +# MTU and EMTU_R (when this is learned from the remote endpoint). The +# MAX_PLPMTU MAY be reduced by an application that sets a maximum to +# the size of datagrams it will send. +# +# The PROBE_COUNT is initialized to zero when the first probe with a +# size greater than or equal to PLPMTU is sent. Each probe packet +# successfully sent to the remote peer is confirmed by acknowledgment +# at the PL (see Section 4.1). +# +# Each time a probe packet is sent to the destination, the PROBE_TIMER +# is started. The timer is canceled when the PL receives +# acknowledgment that the probe packet has been successfully sent +# across the path (Section 4.1). This confirms that the PROBED_SIZE is +# supported, and the PROBED_SIZE value is then assigned to the PLPMTU. +# The search algorithm can continue to send subsequent probe packets of +# an increasing size. +# +# If the timer expires before a probe packet is acknowledged, the probe +# has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER +# expires, the PROBE_COUNT is incremented, the PROBE_TIMER is +# reinitialized, and a new probe of the same size or any other size +# (determined by the search algorithm) can be sent. The maximum number +# of consecutive failed probes is configured (MAX_PROBES). If the +# value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and +# the PL sender enters the SEARCH_COMPLETE state. + +[[spec]] +level = "MAY" +quote = ''' +The +MAX_PLPMTU MAY be reduced by an application that sets a maximum to +the size of datagrams it will send. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.2.toml new file mode 100644 index 0000000000..b6db04a492 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.3.2.toml @@ -0,0 +1,24 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.3.2" + +# Selection of Probe Sizes +# +# The search algorithm determines a minimum useful gain in PLPMTU. It +# would not be constructive for a PL sender to attempt to probe for all +# sizes. This would incur unnecessary load on the path. +# Implementations SHOULD select the set of probe packet sizes to +# maximize the gain in PLPMTU from each search step. +# +# Implementations could optimize the search procedure by selecting step +# sizes from a table of common PMTU sizes. When selecting the +# appropriate next size to search, an implementer ought to also +# consider that there can be common sizes of MPS that applications seek +# to use, and there could be common sizes of MTU used within the +# network. + +[[spec]] +level = "SHOULD" +quote = ''' +Implementations SHOULD select the set of probe packet sizes to +maximize the gain in PLPMTU from each search step. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.toml new file mode 100644 index 0000000000..78f1393bd2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-5.toml @@ -0,0 +1,59 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-5" + +# Datagram Packetization Layer PMTUD +# +# This section specifies Datagram PLPMTUD (DPLPMTUD). The method can +# be introduced at various points (as indicated with * in Figure 2) in +# the IP protocol stack to discover the PLPMTU so that an application +# can utilize an appropriate MPS for the current network path. +# +# DPLPMTUD SHOULD only be performed at one layer between a pair of +# endpoints. Therefore, an upper PL or application should avoid using +# DPLPMTUD when this is already enabled in a lower layer. A PL MUST +# adjust the MPS indicated by DPLPMTUD to account for any additional +# overhead introduced by the PL. +# +# +----------------------+ +# | Application* | +# +-----+------------+---+ +# | | +# +---+--+ +--+--+ +# | QUIC*| |SCTP*| +# +---+--+ +-+-+-+ +# | | | +# +---+ +----+ | +# | | | +# +-+--+-+ | +# | UDP | | +# +---+--+ | +# | | +# +-----------+-------+--+ +# | Network Interface | +# +----------------------+ +# +# Figure 2: Examples Where DPLPMTUD Can Be Implemented +# +# The central idea of DPLPMTUD is probing by a sender. Probe packets +# are sent to find the maximum size of user message that can be +# completely transferred across the network path from the sender to the +# destination. +# +# The following sections identify the components needed for +# implementation, provide an overview of the phases of operation, and +# specify the state machine and search algorithm. + +[[spec]] +level = "SHOULD" +quote = ''' +DPLPMTUD SHOULD only be performed at one layer between a pair of +endpoints. +''' + +[[spec]] +level = "MUST" +quote = ''' +A PL MUST +adjust the MPS indicated by DPLPMTUD to account for any additional +overhead introduced by the PL. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.1.toml new file mode 100644 index 0000000000..5da2c59e60 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.1.toml @@ -0,0 +1,20 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1.1" + +# Application Request +# +# An application needs an application-layer protocol mechanism (such as +# a message acknowledgment method) that solicits a response from a +# destination endpoint. The method SHOULD allow the sender to check +# the value returned in the response to provide additional protection +# from off-path insertion of data [BCP145]. Suitable methods include a +# parameter known only to the two endpoints, such as a session ID or +# initialized sequence number. + +[[spec]] +level = "SHOULD" +quote = ''' +The method SHOULD allow the sender to check +the value returned in the response to provide additional protection +from off-path insertion of data [BCP145]. +''' + diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.4.toml similarity index 55% rename from specs/www.rfc-editor.org/rfc/rfc8899/6.1.4.toml rename to .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.4.toml index a3ff35e1a9..54cf96335b 100644 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.4.toml @@ -1,11 +1,11 @@ target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1.4" -# 6.1.4. Initial Connectivity +# Initial Connectivity # -# An application that does not have other higher-layer information -# confirming connectivity with the remote peer SHOULD implement a -# connectivity mechanism using acknowledged probe packets before -# entering the BASE state. +# An application that does not have other higher-layer information +# confirming connectivity with the remote peer SHOULD implement a +# connectivity mechanism using acknowledged probe packets before +# entering the BASE state. [[spec]] level = "SHOULD" diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.5.toml similarity index 55% rename from specs/www.rfc-editor.org/rfc/rfc8899/6.1.5.toml rename to .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.5.toml index 7324e66280..98254a9234 100644 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.5.toml @@ -1,11 +1,11 @@ target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1.5" -# 6.1.5. Validating the Path +# Validating the Path # -# An application that does not have other higher-layer information -# confirming correct delivery of datagrams SHOULD implement the -# CONFIRMATION_TIMER to periodically send probe packets while in the -# SEARCH_COMPLETE state. +# An application that does not have other higher-layer information +# confirming correct delivery of datagrams SHOULD implement the +# CONFIRMATION_TIMER to periodically send probe packets while in the +# SEARCH_COMPLETE state. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.6.toml new file mode 100644 index 0000000000..4fbef81ccc --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.6.toml @@ -0,0 +1,28 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1.6" + +# Handling of PTB Messages +# +# An application that is able and wishes to receive PTB messages MUST +# perform ICMP validation as specified in Section 5.2 of [BCP145]. +# This requires that the application checks each received PTB message +# to validate that it was is received in response to transmitted +# traffic and that the reported PL_PTB_SIZE is less than the current +# probed size (see Section 4.6.2). A validated PTB message MAY be used +# as input to the DPLPMTUD algorithm but MUST NOT be used directly to +# set the PLPMTU. + +[[spec]] +level = "MUST" +quote = ''' +An application that is able and wishes to receive PTB messages MUST +perform ICMP validation as specified in Section 5.2 of [BCP145]. +''' + +[[spec]] +level = "MUST" +quote = ''' +A validated PTB message MAY be used +as input to the DPLPMTUD algorithm but MUST NOT be used directly to +set the PLPMTU. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.toml new file mode 100644 index 0000000000..b293cf66c4 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.1.toml @@ -0,0 +1,32 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1" + +# Application Support for DPLPMTUD with UDP or UDP-Lite +# +# The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do +# not define a method in the RFC series that supports PLPMTUD. In +# particular, the UDP transport does not provide the transport features +# needed to implement datagram PLPMTUD. +# +# The DPLPMTUD method can be implemented as a part of an application +# built directly or indirectly on UDP or UDP-Lite but relies on higher- +# layer protocol features to implement the method [BCP145]. +# +# Some primitives used by DPLPMTUD might not be available via the +# Datagram API (e.g., the ability to access the PLPMTU from the IP- +# layer cache or to interpret received PTB messages). +# +# In addition, it is recommended that PMTU discovery is not performed +# by multiple protocol layers. An application SHOULD avoid using +# DPLPMTUD when the underlying transport system provides this +# capability. A common method for managing the PLPMTU has benefits, +# both in the ability to share state between different processes and in +# opportunities to coordinate probing for different PL instances. + +[[spec]] +level = "SHOULD" +quote = ''' +An application SHOULD avoid using +DPLPMTUD when the underlying transport system provides this +capability. +''' + diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.3.toml similarity index 57% rename from specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.3.toml rename to .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.3.toml index 9ef86b2259..af93153a9f 100644 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.3.toml @@ -1,9 +1,9 @@ target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.1.3" -# 6.2.1.3. Validating the Path with SCTP +# Validating the Path with SCTP # -# Since SCTP provides an acknowledged PL, a sender MUST NOT implement -# the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. +# Since SCTP provides an acknowledged PL, a sender MUST NOT implement +# the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.4.toml new file mode 100644 index 0000000000..4c15f12cd0 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.1.4.toml @@ -0,0 +1,30 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.1.4" + +# PTB Message Handling by SCTP +# +# Normal ICMP validation MUST be performed as specified in Appendix C +# of [RFC4960]. This requires that the first 8 bytes of the SCTP +# common header are quoted in the payload of the PTB message, which can +# be the case for ICMPv4 and is normally the case for ICMPv6. +# +# When a PTB message has been validated, the PL_PTB_SIZE calculated +# from the PTB_SIZE reported in the PTB message SHOULD be used with the +# DPLPMTUD algorithm, provided that the reported PL_PTB_SIZE is less +# than the current probe size (see Section 4.6). + +[[spec]] +level = "MUST" +quote = ''' +Normal ICMP validation MUST be performed as specified in Appendix C +of [RFC4960]. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When a PTB message has been validated, the PL_PTB_SIZE calculated +from the PTB_SIZE reported in the PTB message SHOULD be used with the +DPLPMTUD algorithm, provided that the reported PL_PTB_SIZE is less +than the current probe size (see Section 4.6). +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.4.toml new file mode 100644 index 0000000000..e319e9699b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.4.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.2.4" + +# Handling of PTB Messages by SCTP/UDP +# +# ICMP validation MUST be performed for PTB messages as specified in +# Appendix C of [RFC4960]. This requires that the first 8 bytes of the +# SCTP common header are contained in the PTB message, which can be the +# case for ICMPv4 (but note the UDP header also consumes a part of the +# quoted packet header) and is normally the case for ICMPv6. When the +# validation is completed, the PL_PTB_SIZE calculated from the PTB_SIZE +# in the PTB message SHOULD be used with the DPLPMTUD providing that +# the reported PL_PTB_SIZE is less than the current probe size. + +[[spec]] +level = "MUST" +quote = ''' +ICMP validation MUST be performed for PTB messages as specified in +Appendix C of [RFC4960]. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When the +validation is completed, the PL_PTB_SIZE calculated from the PTB_SIZE +in the PTB message SHOULD be used with the DPLPMTUD providing that +the reported PL_PTB_SIZE is less than the current probe size. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.toml new file mode 100644 index 0000000000..fdec78dee2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.2.toml @@ -0,0 +1,21 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.2" + +# DPLPMTUD for SCTP/UDP +# +# The UDP encapsulation of SCTP is specified in [RFC6951]. +# +# This specification updates the reference to RFC 4821 in Section 5.6 +# of RFC 6951 to refer to this document (RFC 8899). RFC 6951 is +# updated by the addition of the following sentence at the end of +# Section 5.6: +# +# | The RECOMMENDED method for determining the MTU of the path is +# | specified in RFC 8899. + +[[spec]] +level = "SHOULD" +quote = ''' +| The RECOMMENDED method for determining the MTU of the path is +| specified in RFC 8899. +''' + diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.3.3.toml similarity index 57% rename from specs/www.rfc-editor.org/rfc/rfc8899/6.2.3.3.toml rename to .duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.3.3.toml index 4b08012695..77b330cfe8 100644 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.3.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.3.3.toml @@ -1,9 +1,9 @@ target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.3.3" -# 6.2.3.3. Validating the Path with SCTP/DTLS +# Validating the Path with SCTP/DTLS # -# Since SCTP provides an acknowledged PL, a sender MUST NOT implement -# the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. +# Since SCTP provides an acknowledged PL, a sender MUST NOT implement +# the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.toml new file mode 100644 index 0000000000..dfa5bcec97 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-6.2.toml @@ -0,0 +1,42 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2" + +# DPLPMTUD for SCTP +# +# Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing +# method for SCTP, and Section 7.3 of [RFC4960] recommends an endpoint +# apply the techniques in RFC 4821 on a per-destination-address basis. +# The specification for DPLPMTUD continues the practice of using the PL +# to discover the PMTU but updates RFC4960 with a recommendation to use +# the method specified in this document: The RECOMMENDED method for +# generating probes is to add a chunk consisting only of padding to an +# SCTP message. The PAD chunk defined in [RFC4820] SHOULD be attached +# to a minimum-length HEARTBEAT (HB) chunk to build a probe packet. +# This enables probing without affecting the transfer of user messages +# and without being limited by congestion control or flow control. +# This is preferred to using DATA chunks (with padding as required) as +# path probes. +# +# Section 6.9 of [RFC4960] describes dividing the user messages into +# DATA chunks sent by the PL when using SCTP. This notes that once an +# SCTP message has been sent, it cannot be resegmented. [RFC4960] +# describes the method for retransmitting DATA chunks when the MPS has +# been reduced, and Section 6.9 of [RFC4960] describes use of IP +# fragmentation for this case. This is unchanged by this document. + +[[spec]] +level = "SHOULD" +quote = ''' +The specification for DPLPMTUD continues the practice of using the PL +to discover the PMTU but updates RFC4960 with a recommendation to use +the method specified in this document: The RECOMMENDED method for +generating probes is to add a chunk consisting only of padding to an +SCTP message. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The PAD chunk defined in [RFC4820] SHOULD be attached +to a minimum-length HEARTBEAT (HB) chunk to build a probe packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-8.toml new file mode 100644 index 0000000000..99e109fee7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8899/section-8.toml @@ -0,0 +1,110 @@ +target = "https://www.rfc-editor.org/rfc/rfc8899#section-8" + +# Security Considerations +# +# The security considerations for the use of UDP and SCTP are provided +# in the referenced RFCs. +# +# To avoid excessive load, the interval between individual probe +# packets MUST be at least one RTT, and the interval between rounds of +# probing is determined by the PMTU_RAISE_TIMER. +# +# A PL sender needs to ensure that the method used to confirm reception +# of probe packets protects from off-path attackers injecting packets +# into the path. This protection is provided in IETF-defined protocols +# (e.g., TCP, SCTP) using a randomly initialized sequence number. A +# description of one way to do this when using UDP is provided in +# Section 5.1 of [BCP145]). +# +# There are cases where ICMP Packet Too Big (PTB) messages are not +# delivered due to policy, configuration, or equipment design (see +# Section 1.1). This method therefore does not rely upon PTB messages +# being received but is able to utilize these when they are received by +# the sender. PTB messages could potentially be used to cause a node +# to inappropriately reduce the PLPMTU. A node supporting DPLPMTUD +# MUST therefore appropriately validate the payload of PTB messages to +# ensure these are received in response to transmitted traffic (i.e., a +# reported error condition that corresponds to a datagram actually sent +# by the path layer, see Section 4.6.1). +# +# An on-path attacker able to create a PTB message could forge PTB +# messages that include a valid quoted IP packet. Such an attack could +# be used to drive down the PLPMTU. An on-path device could similarly +# force a reduction of the PLPMTU by implementing a policy that drops +# packets larger than a configured size. There are two ways this +# method can be mitigated against such attacks: first, by ensuring that +# a PL sender never reduces the PLPMTU below the base size solely in +# response to receiving a PTB message. This is achieved by first +# entering the BASE state when such a message is received. Second, the +# design does not require processing of PTB messages; a PL sender could +# therefore suspend processing of PTB messages (e.g., in a robustness +# mode after detecting that subsequent probes actually confirm that a +# size larger than the PTB_SIZE is supported by a path). +# +# Parsing the quoted packet inside a PTB message can introduce +# additional per-packet processing at the PL sender. This processing +# SHOULD be limited to avoid a denial-of-service attack when arbitrary +# headers are included. Rate-limiting the processing could result in +# PTB messages not being received by a PL; however, the DPLPMTUD method +# is robust to such loss. +# +# The successful processing of an ICMP message can trigger a probe when +# the reported PTB size is valid, but this does not directly update the +# PLPMTU for the path. This prevents a message attempting to black +# hole data by indicating a size larger than supported by the path. +# +# It is possible that the information about a path is not stable. This +# could be a result of forwarding across more than one path that has a +# different actual PMTU or a single path presents a varying PMTU. The +# design of a PLPMTUD implementation SHOULD consider how to mitigate +# the effects of varying path information. One possible mitigation is +# to provide robustness (see Section 5.4) in the method that avoids +# oscillation in the MPS. +# +# DPLPMTUD methods can introduce padding data to inflate the length of +# the datagram to the total size required for a probe packet. The +# total size of a probe packet includes all headers and padding added +# to the payload data being sent (e.g., including security-related +# fields such as an AEAD tag and TLS record layer padding). The value +# of the padding data does not influence the DPLPMTUD search algorithm, +# and therefore needs to be set consistent with the policy of the PL. +# +# If a PL can make use of cryptographic confidentiality or data- +# integrity mechanisms, then the design ought to avoid adding anything +# (e.g., padding) to DPLPMTUD probe packets that is not also protected +# by those cryptographic mechanisms. + +[[spec]] +level = "MUST" +quote = ''' +To avoid excessive load, the interval between individual probe +packets MUST be at least one RTT, and the interval between rounds of +probing is determined by the PMTU_RAISE_TIMER. +''' + +[[spec]] +level = "MUST" +quote = ''' +A node supporting DPLPMTUD +MUST therefore appropriately validate the payload of PTB messages to +ensure these are received in response to transmitted traffic (i.e., a +reported error condition that corresponds to a datagram actually sent +by the path layer, see Section 4.6.1). +''' + +[[spec]] +level = "SHOULD" +quote = ''' +This processing +SHOULD be limited to avoid a denial-of-service attack when arbitrary +headers are included. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The +design of a PLPMTUD implementation SHOULD consider how to mitigate +the effects of varying path information. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.2.toml new file mode 100644 index 0000000000..daaf84c807 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.2.toml @@ -0,0 +1,39 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.1.2" + +# Deferring Idle Timeout +# +# An endpoint might need to send ack-eliciting packets to avoid an idle +# timeout if it is expecting response data but does not have or is +# unable to send application data. +# +# An implementation of QUIC might provide applications with an option +# to defer an idle timeout. This facility could be used when the +# application wishes to avoid losing state that has been associated +# with an open connection but does not expect to exchange application +# data for some time. With this option, an endpoint could send a PING +# frame (Section 19.2) periodically, which will cause the peer to +# restart its idle timeout period. Sending a packet containing a PING +# frame restarts the idle timeout for this endpoint also if this is the +# first ack-eliciting packet sent since receiving a packet. Sending a +# PING frame causes the peer to respond with an acknowledgment, which +# also restarts the idle timeout for the endpoint. +# +# Application protocols that use QUIC SHOULD provide guidance on when +# deferring an idle timeout is appropriate. Unnecessary sending of +# PING frames could have a detrimental effect on performance. +# +# A connection will time out if no packets are sent or received for a +# period longer than the time negotiated using the max_idle_timeout +# transport parameter; see Section 10. However, state in middleboxes +# might time out earlier than that. Though REQ-5 in [RFC4787] +# recommends a 2-minute timeout interval, experience shows that sending +# packets every 30 seconds is necessary to prevent the majority of +# middleboxes from losing state for UDP flows [GATEWAY]. + +[[spec]] +level = "SHOULD" +quote = ''' +Application protocols that use QUIC SHOULD provide guidance on when +deferring an idle timeout is appropriate. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.toml new file mode 100644 index 0000000000..1da0e9aed2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.1.toml @@ -0,0 +1,38 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.1" + +# Idle Timeout +# +# If a max_idle_timeout is specified by either endpoint in its +# transport parameters (Section 18.2), the connection is silently +# closed and its state is discarded when it remains idle for longer +# than the minimum of the max_idle_timeout value advertised by both +# endpoints. +# +# Each endpoint advertises a max_idle_timeout, but the effective value +# at an endpoint is computed as the minimum of the two advertised +# values (or the sole advertised value, if only one endpoint advertises +# a non-zero value). By announcing a max_idle_timeout, an endpoint +# commits to initiating an immediate close (Section 10.2) if it +# abandons the connection prior to the effective value. +# +# An endpoint restarts its idle timer when a packet from its peer is +# received and processed successfully. An endpoint also restarts its +# idle timer when sending an ack-eliciting packet if no other ack- +# eliciting packets have been sent since last receiving and processing +# a packet. Restarting this timer when sending a packet ensures that +# connections are not closed after new activity is initiated. +# +# To avoid excessively small idle timeout periods, endpoints MUST +# increase the idle timeout period to be at least three times the +# current Probe Timeout (PTO). This allows for multiple PTOs to +# expire, and therefore multiple probes to be sent and lost, prior to +# idle timeout. + +[[spec]] +level = "MUST" +quote = ''' +To avoid excessively small idle timeout periods, endpoints MUST +increase the idle timeout period to be at least three times the +current Probe Timeout (PTO). +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml new file mode 100644 index 0000000000..52a7c9716c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.1.toml @@ -0,0 +1,114 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2.1" + +# Closing Connection State +# +# An endpoint enters the closing state after initiating an immediate +# close. +# +# In the closing state, an endpoint retains only enough information to +# generate a packet containing a CONNECTION_CLOSE frame and to identify +# packets as belonging to the connection. An endpoint in the closing +# state sends a packet containing a CONNECTION_CLOSE frame in response +# to any incoming packet that it attributes to the connection. +# +# An endpoint SHOULD limit the rate at which it generates packets in +# the closing state. For instance, an endpoint could wait for a +# progressively increasing number of received packets or amount of time +# before responding to received packets. +# +# An endpoint's selected connection ID and the QUIC version are +# sufficient information to identify packets for a closing connection; +# the endpoint MAY discard all other connection state. An endpoint +# that is closing is not required to process any received frame. An +# endpoint MAY retain packet protection keys for incoming packets to +# allow it to read and process a CONNECTION_CLOSE frame. +# +# An endpoint MAY drop packet protection keys when entering the closing +# state and send a packet containing a CONNECTION_CLOSE frame in +# response to any UDP datagram that is received. However, an endpoint +# that discards packet protection keys cannot identify and discard +# invalid packets. To avoid being used for an amplification attack, +# such endpoints MUST limit the cumulative size of packets it sends to +# three times the cumulative size of the packets that are received and +# attributed to the connection. To minimize the state that an endpoint +# maintains for a closing connection, endpoints MAY send the exact same +# packet in response to any received packet. +# +# | Note: Allowing retransmission of a closing packet is an +# | exception to the requirement that a new packet number be used +# | for each packet; see Section 12.3. Sending new packet numbers +# | is primarily of advantage to loss recovery and congestion +# | control, which are not expected to be relevant for a closed +# | connection. Retransmitting the final packet requires less +# | state. +# +# While in the closing state, an endpoint could receive packets from a +# new source address, possibly indicating a connection migration; see +# Section 9. An endpoint in the closing state MUST either discard +# packets received from an unvalidated address or limit the cumulative +# size of packets it sends to an unvalidated address to three times the +# size of packets it receives from that address. +# +# An endpoint is not expected to handle key updates when it is closing +# (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint +# from moving from the closing state to the draining state, as the +# endpoint will not be able to process subsequently received packets, +# but it otherwise has no impact. + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD limit the rate at which it generates packets in +the closing state. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint's selected connection ID and the QUIC version are +sufficient information to identify packets for a closing connection; +the endpoint MAY discard all other connection state. +''' + +[[spec]] +level = "MAY" +quote = ''' +An +endpoint MAY retain packet protection keys for incoming packets to +allow it to read and process a CONNECTION_CLOSE frame. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY drop packet protection keys when entering the closing +state and send a packet containing a CONNECTION_CLOSE frame in +response to any UDP datagram that is received. +''' + +[[spec]] +level = "MUST" +quote = ''' +To avoid being used for an amplification attack, +such endpoints MUST limit the cumulative size of packets it sends to +three times the cumulative size of the packets that are received and +attributed to the connection. +''' + +[[spec]] +level = "MAY" +quote = ''' +To minimize the state that an endpoint +maintains for a closing connection, endpoints MAY send the exact same +packet in response to any received packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint in the closing state MUST either discard +packets received from an unvalidated address or limit the cumulative +size of packets it sends to an unvalidated address to three times the +size of packets it receives from that address. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml new file mode 100644 index 0000000000..0013c4b54d --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.2.toml @@ -0,0 +1,55 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2.2" + +# Draining Connection State +# +# The draining state is entered once an endpoint receives a +# CONNECTION_CLOSE frame, which indicates that its peer is closing or +# draining. While otherwise identical to the closing state, an +# endpoint in the draining state MUST NOT send any packets. Retaining +# packet protection keys is unnecessary once a connection is in the +# draining state. +# +# An endpoint that receives a CONNECTION_CLOSE frame MAY send a single +# packet containing a CONNECTION_CLOSE frame before entering the +# draining state, using a NO_ERROR code if appropriate. An endpoint +# MUST NOT send further packets. Doing so could result in a constant +# exchange of CONNECTION_CLOSE frames until one of the endpoints exits +# the closing state. +# +# An endpoint MAY enter the draining state from the closing state if it +# receives a CONNECTION_CLOSE frame, which indicates that the peer is +# also closing or draining. In this case, the draining state ends when +# the closing state would have ended. In other words, the endpoint +# uses the same end time but ceases transmission of any packets on this +# connection. + +[[spec]] +level = "MUST" +quote = ''' +While otherwise identical to the closing state, an +endpoint in the draining state MUST NOT send any packets. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint that receives a CONNECTION_CLOSE frame MAY send a single +packet containing a CONNECTION_CLOSE frame before entering the +draining state, using a NO_ERROR code if appropriate. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint +MUST NOT send further packets. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY enter the draining state from the closing state if it +receives a CONNECTION_CLOSE frame, which indicates that the peer is +also closing or draining. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml new file mode 100644 index 0000000000..1e10937514 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.3.toml @@ -0,0 +1,131 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2.3" + +# Immediate Close during the Handshake +# +# When sending a CONNECTION_CLOSE frame, the goal is to ensure that the +# peer will process the frame. Generally, this means sending the frame +# in a packet with the highest level of packet protection to avoid the +# packet being discarded. After the handshake is confirmed (see +# Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any +# CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to +# confirming the handshake, it is possible that more advanced packet +# protection keys are not available to the peer, so another +# CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower +# packet protection level. More specifically: +# +# * A client will always know whether the server has Handshake keys +# (see Section 17.2.2.1), but it is possible that a server does not +# know whether the client has Handshake keys. Under these +# circumstances, a server SHOULD send a CONNECTION_CLOSE frame in +# both Handshake and Initial packets to ensure that at least one of +# them is processable by the client. +# +# * A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet +# cannot be assured that the server has accepted 0-RTT. Sending a +# CONNECTION_CLOSE frame in an Initial packet makes it more likely +# that the server can receive the close signal, even if the +# application error code might not be received. +# +# * Prior to confirming the handshake, a peer might be unable to +# process 1-RTT packets, so an endpoint SHOULD send a +# CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A +# server SHOULD also send a CONNECTION_CLOSE frame in an Initial +# packet. +# +# Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake +# packet could expose application state or be used to alter application +# state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a +# CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or +# Handshake packets. Otherwise, information about the application +# state might be revealed. Endpoints MUST clear the value of the +# Reason Phrase field and SHOULD use the APPLICATION_ERROR code when +# converting to a CONNECTION_CLOSE of type 0x1c. +# +# CONNECTION_CLOSE frames sent in multiple packet types can be +# coalesced into a single UDP datagram; see Section 12.2. +# +# An endpoint can send a CONNECTION_CLOSE frame in an Initial packet. +# This might be in response to unauthenticated information received in +# Initial or Handshake packets. Such an immediate close might expose +# legitimate connections to a denial of service. QUIC does not include +# defensive measures for on-path attacks during the handshake; see +# Section 21.2. However, at the cost of reducing feedback about errors +# for legitimate peers, some forms of denial of service can be made +# more difficult for an attacker if endpoints discard illegal packets +# rather than terminating a connection with CONNECTION_CLOSE. For this +# reason, endpoints MAY discard packets rather than immediately close +# if errors are detected in packets that lack authentication. +# +# An endpoint that has not established state, such as a server that +# detects an error in an Initial packet, does not enter the closing +# state. An endpoint that has no state for the connection does not +# enter a closing or draining period on sending a CONNECTION_CLOSE +# frame. + +[[spec]] +level = "MUST" +quote = ''' +After the handshake is confirmed (see +Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any +CONNECTION_CLOSE frames in a 1-RTT packet. +''' + +[[spec]] +level = "MAY" +quote = ''' +However, prior to +confirming the handshake, it is possible that more advanced packet +protection keys are not available to the peer, so another +CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower +packet protection level. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Under these +circumstances, a server SHOULD send a CONNECTION_CLOSE frame in +both Handshake and Initial packets to ensure that at least one of +them is processable by the client. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +* Prior to confirming the handshake, a peer might be unable to +process 1-RTT packets, so an endpoint SHOULD send a +CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A +server SHOULD also send a CONNECTION_CLOSE frame in an Initial +packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +A CONNECTION_CLOSE of type 0x1d MUST be replaced by a +CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or +Handshake packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST clear the value of the +Reason Phrase field and SHOULD use the APPLICATION_ERROR code when +converting to a CONNECTION_CLOSE of type 0x1c. +''' + +[[spec]] +level = "MAY" +quote = ''' +For this +reason, endpoints MAY discard packets rather than immediately close +if errors are detected in packets that lack authentication. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml new file mode 100644 index 0000000000..09e107573e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.2.toml @@ -0,0 +1,85 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2" + +# Immediate Close +# +# An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to +# terminate the connection immediately. A CONNECTION_CLOSE frame +# causes all streams to immediately become closed; open streams can be +# assumed to be implicitly reset. +# +# After sending a CONNECTION_CLOSE frame, an endpoint immediately +# enters the closing state; see Section 10.2.1. After receiving a +# CONNECTION_CLOSE frame, endpoints enter the draining state; see +# Section 10.2.2. +# +# Violations of the protocol lead to an immediate close. +# +# An immediate close can be used after an application protocol has +# arranged to close a connection. This might be after the application +# protocol negotiates a graceful shutdown. The application protocol +# can exchange messages that are needed for both application endpoints +# to agree that the connection can be closed, after which the +# application requests that QUIC close the connection. When QUIC +# consequently closes the connection, a CONNECTION_CLOSE frame with an +# application-supplied error code will be used to signal closure to the +# peer. +# +# The closing and draining connection states exist to ensure that +# connections close cleanly and that delayed or reordered packets are +# properly discarded. These states SHOULD persist for at least three +# times the current PTO interval as defined in [QUIC-RECOVERY]. +# +# Disposing of connection state prior to exiting the closing or +# draining state could result in an endpoint generating a Stateless +# Reset unnecessarily when it receives a late-arriving packet. +# Endpoints that have some alternative means to ensure that late- +# arriving packets do not induce a response, such as those that are +# able to close the UDP socket, MAY end these states earlier to allow +# for faster resource recovery. Servers that retain an open socket for +# accepting new connections SHOULD NOT end the closing or draining +# state early. +# +# Once its closing or draining state ends, an endpoint SHOULD discard +# all connection state. The endpoint MAY send a Stateless Reset in +# response to any further incoming packets belonging to this +# connection. + +[[spec]] +level = "SHOULD" +quote = ''' +These states SHOULD persist for at least three +times the current PTO interval as defined in [QUIC-RECOVERY]. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints that have some alternative means to ensure that late- +arriving packets do not induce a response, such as those that are +able to close the UDP socket, MAY end these states earlier to allow +for faster resource recovery. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Servers that retain an open socket for +accepting new connections SHOULD NOT end the closing or draining +state early. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Once its closing or draining state ends, an endpoint SHOULD discard +all connection state. +''' + +[[spec]] +level = "MAY" +quote = ''' +The endpoint MAY send a Stateless Reset in +response to any further incoming packets belonging to this +connection. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml new file mode 100644 index 0000000000..96f8213c27 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.1.toml @@ -0,0 +1,82 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.1" + +# Detecting a Stateless Reset +# +# An endpoint detects a potential Stateless Reset using the trailing 16 +# bytes of the UDP datagram. An endpoint remembers all stateless reset +# tokens associated with the connection IDs and remote addresses for +# datagrams it has recently sent. This includes Stateless Reset Token +# field values from NEW_CONNECTION_ID frames and the server's transport +# parameters but excludes stateless reset tokens associated with +# connection IDs that are either unused or retired. The endpoint +# identifies a received datagram as a Stateless Reset by comparing the +# last 16 bytes of the datagram with all stateless reset tokens +# associated with the remote address on which the datagram was +# received. +# +# This comparison can be performed for every inbound datagram. +# Endpoints MAY skip this check if any packet from a datagram is +# successfully processed. However, the comparison MUST be performed +# when the first packet in an incoming datagram either cannot be +# associated with a connection or cannot be decrypted. +# +# An endpoint MUST NOT check for any stateless reset tokens associated +# with connection IDs it has not used or for connection IDs that have +# been retired. +# +# When comparing a datagram to stateless reset token values, endpoints +# MUST perform the comparison without leaking information about the +# value of the token. For example, performing this comparison in +# constant time protects the value of individual stateless reset tokens +# from information leakage through timing side channels. Another +# approach would be to store and compare the transformed values of +# stateless reset tokens instead of the raw token values, where the +# transformation is defined as a cryptographically secure pseudorandom +# function using a secret key (e.g., block cipher, Hashed Message +# Authentication Code (HMAC) [RFC2104]). An endpoint is not expected +# to protect information about whether a packet was successfully +# decrypted or the number of valid stateless reset tokens. +# +# If the last 16 bytes of the datagram are identical in value to a +# stateless reset token, the endpoint MUST enter the draining period +# and not send any further packets on this connection. + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY skip this check if any packet from a datagram is +successfully processed. +''' + +[[spec]] +level = "MUST" +quote = ''' +However, the comparison MUST be performed +when the first packet in an incoming datagram either cannot be +associated with a connection or cannot be decrypted. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT check for any stateless reset tokens associated +with connection IDs it has not used or for connection IDs that have +been retired. +''' + +[[spec]] +level = "MUST" +quote = ''' +When comparing a datagram to stateless reset token values, endpoints +MUST perform the comparison without leaking information about the +value of the token. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the last 16 bytes of the datagram are identical in value to a +stateless reset token, the endpoint MUST enter the draining period +and not send any further packets on this connection. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml new file mode 100644 index 0000000000..3f4f6ea9f2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.2.toml @@ -0,0 +1,98 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.2" + +# Calculating a Stateless Reset Token +# +# The stateless reset token MUST be difficult to guess. In order to +# create a stateless reset token, an endpoint could randomly generate +# [RANDOM] a secret for every connection that it creates. However, +# this presents a coordination problem when there are multiple +# instances in a cluster or a storage problem for an endpoint that +# might lose state. Stateless reset specifically exists to handle the +# case where state is lost, so this approach is suboptimal. +# +# A single static key can be used across all connections to the same +# endpoint by generating the proof using a pseudorandom function that +# takes a static key and the connection ID chosen by the endpoint (see +# Section 5.1) as input. An endpoint could use HMAC [RFC2104] (for +# example, HMAC(static_key, connection_id)) or the HMAC-based Key +# Derivation Function (HKDF) [RFC5869] (for example, using the static +# key as input keying material, with the connection ID as salt). The +# output of this function is truncated to 16 bytes to produce the +# stateless reset token for that connection. +# +# An endpoint that loses state can use the same method to generate a +# valid stateless reset token. The connection ID comes from the packet +# that the endpoint receives. +# +# This design relies on the peer always sending a connection ID in its +# packets so that the endpoint can use the connection ID from a packet +# to reset the connection. An endpoint that uses this design MUST +# either use the same connection ID length for all connections or +# encode the length of the connection ID such that it can be recovered +# without state. In addition, it cannot provide a zero-length +# connection ID. +# +# Revealing the stateless reset token allows any entity to terminate +# the connection, so a value can only be used once. This method for +# choosing the stateless reset token means that the combination of +# connection ID and static key MUST NOT be used for another connection. +# A denial-of-service attack is possible if the same connection ID is +# used by instances that share a static key or if an attacker can cause +# a packet to be routed to an instance that has no state but the same +# static key; see Section 21.11. A connection ID from a connection +# that is reset by revealing the stateless reset token MUST NOT be +# reused for new connections at nodes that share a static key. +# +# The same stateless reset token MUST NOT be used for multiple +# connection IDs. Endpoints are not required to compare new values +# against all previous values, but a duplicate value MAY be treated as +# a connection error of type PROTOCOL_VIOLATION. +# +# Note that Stateless Resets do not have any cryptographic protection. + +[[spec]] +level = "MUST" +quote = ''' +The stateless reset token MUST be difficult to guess. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that uses this design MUST +either use the same connection ID length for all connections or +encode the length of the connection ID such that it can be recovered +without state. +''' + +[[spec]] +level = "MUST" +quote = ''' +This method for +choosing the stateless reset token means that the combination of +connection ID and static key MUST NOT be used for another connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +A connection ID from a connection +that is reset by revealing the stateless reset token MUST NOT be +reused for new connections at nodes that share a static key. +''' + +[[spec]] +level = "MUST" +quote = ''' +The same stateless reset token MUST NOT be used for multiple +connection IDs. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints are not required to compare new values +against all previous values, but a duplicate value MAY be treated as +a connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.3.toml new file mode 100644 index 0000000000..83e62ea142 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.3.toml @@ -0,0 +1,37 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.3" + +# Looping +# +# The design of a Stateless Reset is such that without knowing the +# stateless reset token it is indistinguishable from a valid packet. +# For instance, if a server sends a Stateless Reset to another server, +# it might receive another Stateless Reset in response, which could +# lead to an infinite exchange. +# +# An endpoint MUST ensure that every Stateless Reset that it sends is +# smaller than the packet that triggered it, unless it maintains state +# sufficient to prevent looping. In the event of a loop, this results +# in packets eventually being too small to trigger a response. +# +# An endpoint can remember the number of Stateless Resets that it has +# sent and stop generating new Stateless Resets once a limit is +# reached. Using separate limits for different remote addresses will +# ensure that Stateless Resets can be used to close connections when +# other peers or connections have exhausted limits. +# +# A Stateless Reset that is smaller than 41 bytes might be identifiable +# as a Stateless Reset by an observer, depending upon the length of the +# peer's connection IDs. Conversely, not sending a Stateless Reset in +# response to a small packet might result in Stateless Resets not being +# useful in detecting cases of broken connections where only very small +# packets are sent; such failures might only be detected by other +# means, such as timers. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST ensure that every Stateless Reset that it sends is +smaller than the packet that triggered it, unless it maintains state +sufficient to prevent looping. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml new file mode 100644 index 0000000000..5de2d2798c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.3.toml @@ -0,0 +1,214 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3" + +# Stateless Reset +# +# A stateless reset is provided as an option of last resort for an +# endpoint that does not have access to the state of a connection. A +# crash or outage might result in peers continuing to send data to an +# endpoint that is unable to properly continue the connection. An +# endpoint MAY send a Stateless Reset in response to receiving a packet +# that it cannot associate with an active connection. +# +# A stateless reset is not appropriate for indicating errors in active +# connections. An endpoint that wishes to communicate a fatal +# connection error MUST use a CONNECTION_CLOSE frame if it is able. +# +# To support this process, an endpoint issues a stateless reset token, +# which is a 16-byte value that is hard to guess. If the peer +# subsequently receives a Stateless Reset, which is a UDP datagram that +# ends in that stateless reset token, the peer will immediately end the +# connection. +# +# A stateless reset token is specific to a connection ID. An endpoint +# issues a stateless reset token by including the value in the +# Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers +# can also issue a stateless_reset_token transport parameter during the +# handshake that applies to the connection ID that it selected during +# the handshake. These exchanges are protected by encryption, so only +# client and server know their value. Note that clients cannot use the +# stateless_reset_token transport parameter because their transport +# parameters do not have confidentiality protection. +# +# Tokens are invalidated when their associated connection ID is retired +# via a RETIRE_CONNECTION_ID frame (Section 19.16). +# +# An endpoint that receives packets that it cannot process sends a +# packet in the following layout (see Section 1.3): +# +# Stateless Reset { +# Fixed Bits (2) = 1, +# Unpredictable Bits (38..), +# Stateless Reset Token (128), +# } +# +# Figure 10: Stateless Reset +# +# This design ensures that a Stateless Reset is -- to the extent +# possible -- indistinguishable from a regular packet with a short +# header. +# +# A Stateless Reset uses an entire UDP datagram, starting with the +# first two bits of the packet header. The remainder of the first byte +# and an arbitrary number of bytes following it are set to values that +# SHOULD be indistinguishable from random. The last 16 bytes of the +# datagram contain a stateless reset token. +# +# To entities other than its intended recipient, a Stateless Reset will +# appear to be a packet with a short header. For the Stateless Reset +# to appear as a valid QUIC packet, the Unpredictable Bits field needs +# to include at least 38 bits of data (or 5 bytes, less the two fixed +# bits). +# +# The resulting minimum size of 21 bytes does not guarantee that a +# Stateless Reset is difficult to distinguish from other packets if the +# recipient requires the use of a connection ID. To achieve that end, +# the endpoint SHOULD ensure that all packets it sends are at least 22 +# bytes longer than the minimum connection ID length that it requests +# the peer to include in its packets, adding PADDING frames as +# necessary. This ensures that any Stateless Reset sent by the peer is +# indistinguishable from a valid packet sent to the endpoint. An +# endpoint that sends a Stateless Reset in response to a packet that is +# 43 bytes or shorter SHOULD send a Stateless Reset that is one byte +# shorter than the packet it responds to. +# +# These values assume that the stateless reset token is the same length +# as the minimum expansion of the packet protection AEAD. Additional +# unpredictable bytes are necessary if the endpoint could have +# negotiated a packet protection scheme with a larger minimum +# expansion. +# +# An endpoint MUST NOT send a Stateless Reset that is three times or +# more larger than the packet it receives to avoid being used for +# amplification. Section 10.3.3 describes additional limits on +# Stateless Reset size. +# +# Endpoints MUST discard packets that are too small to be valid QUIC +# packets. To give an example, with the set of AEAD functions defined +# in [QUIC-TLS], short header packets that are smaller than 21 bytes +# are never valid. +# +# Endpoints MUST send Stateless Resets formatted as a packet with a +# short header. However, endpoints MUST treat any packet ending in a +# valid stateless reset token as a Stateless Reset, as other QUIC +# versions might allow the use of a long header. +# +# An endpoint MAY send a Stateless Reset in response to a packet with a +# long header. Sending a Stateless Reset is not effective prior to the +# stateless reset token being available to a peer. In this QUIC +# version, packets with a long header are only used during connection +# establishment. Because the stateless reset token is not available +# until connection establishment is complete or near completion, +# ignoring an unknown packet with a long header might be as effective +# as sending a Stateless Reset. +# +# An endpoint cannot determine the Source Connection ID from a packet +# with a short header; therefore, it cannot set the Destination +# Connection ID in the Stateless Reset. The Destination Connection ID +# will therefore differ from the value used in previous packets. A +# random Destination Connection ID makes the connection ID appear to be +# the result of moving to a new connection ID that was provided using a +# NEW_CONNECTION_ID frame; see Section 19.15. +# +# Using a randomized connection ID results in two problems: +# +# * The packet might not reach the peer. If the Destination +# Connection ID is critical for routing toward the peer, then this +# packet could be incorrectly routed. This might also trigger +# another Stateless Reset in response; see Section 10.3.3. A +# Stateless Reset that is not correctly routed is an ineffective +# error detection and recovery mechanism. In this case, endpoints +# will need to rely on other methods -- such as timers -- to detect +# that the connection has failed. +# +# * The randomly generated connection ID can be used by entities other +# than the peer to identify this as a potential Stateless Reset. An +# endpoint that occasionally uses different connection IDs might +# introduce some uncertainty about this. +# +# This stateless reset design is specific to QUIC version 1. An +# endpoint that supports multiple versions of QUIC needs to generate a +# Stateless Reset that will be accepted by peers that support any +# version that the endpoint might support (or might have supported +# prior to losing state). Designers of new versions of QUIC need to be +# aware of this and either (1) reuse this design or (2) use a portion +# of the packet other than the last 16 bytes for carrying data. + +[[spec]] +level = "MAY" +quote = ''' +An +endpoint MAY send a Stateless Reset in response to receiving a packet +that it cannot associate with an active connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that wishes to communicate a fatal +connection error MUST use a CONNECTION_CLOSE frame if it is able. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The remainder of the first byte +and an arbitrary number of bytes following it are set to values that +SHOULD be indistinguishable from random. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +To achieve that end, +the endpoint SHOULD ensure that all packets it sends are at least 22 +bytes longer than the minimum connection ID length that it requests +the peer to include in its packets, adding PADDING frames as +necessary. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An +endpoint that sends a Stateless Reset in response to a packet that is +43 bytes or shorter SHOULD send a Stateless Reset that is one byte +shorter than the packet it responds to. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send a Stateless Reset that is three times or +more larger than the packet it receives to avoid being used for +amplification. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST discard packets that are too small to be valid QUIC +packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST send Stateless Resets formatted as a packet with a +short header. +''' + +[[spec]] +level = "MUST" +quote = ''' +However, endpoints MUST treat any packet ending in a +valid stateless reset token as a Stateless Reset, as other QUIC +versions might allow the use of a long header. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY send a Stateless Reset in response to a packet with a +long header. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.toml new file mode 100644 index 0000000000..3de73e3e4f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-10.toml @@ -0,0 +1,23 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-10" + +# Connection Termination +# +# An established QUIC connection can be terminated in one of three +# ways: +# +# * idle timeout (Section 10.1) +# +# * immediate close (Section 10.2) +# +# * stateless reset (Section 10.3) +# +# An endpoint MAY discard connection state if it does not have a +# validated path on which it can send packets; see Section 8.2. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY discard connection state if it does not have a +validated path on which it can send packets; see Section 8.2. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml new file mode 100644 index 0000000000..297ada753a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.1.toml @@ -0,0 +1,62 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-11.1" + +# Connection Errors +# +# Errors that result in the connection being unusable, such as an +# obvious violation of protocol semantics or corruption of state that +# affects an entire connection, MUST be signaled using a +# CONNECTION_CLOSE frame (Section 19.19). +# +# Application-specific protocol errors are signaled using the +# CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are +# specific to the transport, including all those described in this +# document, are carried in the CONNECTION_CLOSE frame with a frame type +# of 0x1c. +# +# A CONNECTION_CLOSE frame could be sent in a packet that is lost. An +# endpoint SHOULD be prepared to retransmit a packet containing a +# CONNECTION_CLOSE frame if it receives more packets on a terminated +# connection. Limiting the number of retransmissions and the time over +# which this final packet is sent limits the effort expended on +# terminated connections. +# +# An endpoint that chooses not to retransmit packets containing a +# CONNECTION_CLOSE frame risks a peer missing the first such packet. +# The only mechanism available to an endpoint that continues to receive +# data for a terminated connection is to attempt the stateless reset +# process (Section 10.3). +# +# As the AEAD for Initial packets does not provide strong +# authentication, an endpoint MAY discard an invalid Initial packet. +# Discarding an Initial packet is permitted even where this +# specification otherwise mandates a connection error. An endpoint can +# only discard a packet if it does not process the frames in the packet +# or reverts the effects of any processing. Discarding invalid Initial +# packets might be used to reduce exposure to denial of service; see +# Section 21.2. + +[[spec]] +level = "MUST" +quote = ''' +Errors that result in the connection being unusable, such as an +obvious violation of protocol semantics or corruption of state that +affects an entire connection, MUST be signaled using a +CONNECTION_CLOSE frame (Section 19.19). +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An +endpoint SHOULD be prepared to retransmit a packet containing a +CONNECTION_CLOSE frame if it receives more packets on a terminated +connection. +''' + +[[spec]] +level = "MAY" +quote = ''' +As the AEAD for Initial packets does not provide strong +authentication, an endpoint MAY discard an invalid Initial packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.2.toml new file mode 100644 index 0000000000..df82d2fa51 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.2.toml @@ -0,0 +1,38 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-11.2" + +# Stream Errors +# +# If an application-level error affects a single stream but otherwise +# leaves the connection in a recoverable state, the endpoint can send a +# RESET_STREAM frame (Section 19.4) with an appropriate error code to +# terminate just the affected stream. +# +# Resetting a stream without the involvement of the application +# protocol could cause the application protocol to enter an +# unrecoverable state. RESET_STREAM MUST only be instigated by the +# application protocol that uses QUIC. +# +# The semantics of the application error code carried in RESET_STREAM +# are defined by the application protocol. Only the application +# protocol is able to cause a stream to be terminated. A local +# instance of the application protocol uses a direct API call, and a +# remote instance uses the STOP_SENDING frame, which triggers an +# automatic RESET_STREAM. +# +# Application protocols SHOULD define rules for handling streams that +# are prematurely canceled by either endpoint. + +[[spec]] +level = "MUST" +quote = ''' +RESET_STREAM MUST only be instigated by the +application protocol that uses QUIC. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Application protocols SHOULD define rules for handling streams that +are prematurely canceled by either endpoint. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml new file mode 100644 index 0000000000..86b1399176 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-11.toml @@ -0,0 +1,55 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-11" + +# Error Handling +# +# An endpoint that detects an error SHOULD signal the existence of that +# error to its peer. Both transport-level and application-level errors +# can affect an entire connection; see Section 11.1. Only application- +# level errors can be isolated to a single stream; see Section 11.2. +# +# The most appropriate error code (Section 20) SHOULD be included in +# the frame that signals the error. Where this specification +# identifies error conditions, it also identifies the error code that +# is used; though these are worded as requirements, different +# implementation strategies might lead to different errors being +# reported. In particular, an endpoint MAY use any applicable error +# code when it detects an error condition; a generic error code (such +# as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place +# of specific error codes. +# +# A stateless reset (Section 10.3) is not suitable for any error that +# can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A +# stateless reset MUST NOT be used by an endpoint that has the state +# necessary to send a frame on the connection. + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint that detects an error SHOULD signal the existence of that +error to its peer. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The most appropriate error code (Section 20) SHOULD be included in +the frame that signals the error. +''' + +[[spec]] +level = "MAY" +quote = ''' +In particular, an endpoint MAY use any applicable error +code when it detects an error condition; a generic error code (such +as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place +of specific error codes. +''' + +[[spec]] +level = "MUST" +quote = ''' +A +stateless reset MUST NOT be used by an endpoint that has the state +necessary to send a frame on the connection. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml new file mode 100644 index 0000000000..2192e3c4c1 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.2.toml @@ -0,0 +1,104 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.2" + +# Coalescing Packets +# +# Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake +# (Section 17.2.4) packets contain a Length field that determines the +# end of the packet. The length includes both the Packet Number and +# Payload fields, both of which are confidentiality protected and +# initially of unknown length. The length of the Payload field is +# learned once header protection is removed. +# +# Using the Length field, a sender can coalesce multiple QUIC packets +# into one UDP datagram. This can reduce the number of UDP datagrams +# needed to complete the cryptographic handshake and start sending +# data. This can also be used to construct Path Maximum Transmission +# Unit (PMTU) probes; see Section 14.4.1. Receivers MUST be able to +# process coalesced packets. +# +# Coalescing packets in order of increasing encryption levels (Initial, +# 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it +# more likely that the receiver will be able to process all the packets +# in a single pass. A packet with a short header does not include a +# length, so it can only be the last packet included in a UDP datagram. +# An endpoint SHOULD include multiple frames in a single packet if they +# are to be sent at the same encryption level, instead of coalescing +# multiple packets at the same encryption level. +# +# Receivers MAY route based on the information in the first packet +# contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets +# with different connection IDs into a single UDP datagram. Receivers +# SHOULD ignore any subsequent packets with a different Destination +# Connection ID than the first packet in the datagram. +# +# Every QUIC packet that is coalesced into a single UDP datagram is +# separate and complete. The receiver of coalesced QUIC packets MUST +# individually process each QUIC packet and separately acknowledge +# them, as if they were received as the payload of different UDP +# datagrams. For example, if decryption fails (because the keys are +# not available or for any other reason), the receiver MAY either +# discard or buffer the packet for later processing and MUST attempt to +# process the remaining packets. +# +# Retry packets (Section 17.2.5), Version Negotiation packets +# (Section 17.2.1), and packets with a short header (Section 17.3) do +# not contain a Length field and so cannot be followed by other packets +# in the same UDP datagram. Note also that there is no situation where +# a Retry or Version Negotiation packet is coalesced with another +# packet. + +[[spec]] +level = "MUST" +quote = ''' +Receivers MUST be able to +process coalesced packets. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD include multiple frames in a single packet if they +are to be sent at the same encryption level, instead of coalescing +multiple packets at the same encryption level. +''' + +[[spec]] +level = "MAY" +quote = ''' +Receivers MAY route based on the information in the first packet +contained in a UDP datagram. +''' + +[[spec]] +level = "MUST" +quote = ''' +Senders MUST NOT coalesce QUIC packets +with different connection IDs into a single UDP datagram. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Receivers +SHOULD ignore any subsequent packets with a different Destination +Connection ID than the first packet in the datagram. +''' + +[[spec]] +level = "MUST" +quote = ''' +The receiver of coalesced QUIC packets MUST +individually process each QUIC packet and separately acknowledge +them, as if they were received as the payload of different UDP +datagrams. +''' + +[[spec]] +level = "MUST" +quote = ''' +For example, if decryption fails (because the keys are +not available or for any other reason), the receiver MAY either +discard or buffer the packet for later processing and MUST attempt to +process the remaining packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml new file mode 100644 index 0000000000..cc2de77af1 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.3.toml @@ -0,0 +1,113 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.3" + +# Packet Numbers +# +# The packet number is an integer in the range 0 to 2^62-1. This +# number is used in determining the cryptographic nonce for packet +# protection. Each endpoint maintains a separate packet number for +# sending and receiving. +# +# Packet numbers are limited to this range because they need to be +# representable in whole in the Largest Acknowledged field of an ACK +# frame (Section 19.3). When present in a long or short header, +# however, packet numbers are reduced and encoded in 1 to 4 bytes; see +# Section 17.1. +# +# Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) +# packets do not include a packet number. +# +# Packet numbers are divided into three spaces in QUIC: +# +# Initial space: All Initial packets (Section 17.2.2) are in this +# space. +# +# Handshake space: All Handshake packets (Section 17.2.4) are in this +# space. +# +# Application data space: All 0-RTT (Section 17.2.3) and 1-RTT +# (Section 17.3.1) packets are in this space. +# +# As described in [QUIC-TLS], each packet type uses different +# protection keys. +# +# Conceptually, a packet number space is the context in which a packet +# can be processed and acknowledged. Initial packets can only be sent +# with Initial packet protection keys and acknowledged in packets that +# are also Initial packets. Similarly, Handshake packets are sent at +# the Handshake encryption level and can only be acknowledged in +# Handshake packets. +# +# This enforces cryptographic separation between the data sent in the +# different packet number spaces. Packet numbers in each space start +# at packet number 0. Subsequent packets sent in the same packet +# number space MUST increase the packet number by at least one. +# +# 0-RTT and 1-RTT data exist in the same packet number space to make +# loss recovery algorithms easier to implement between the two packet +# types. +# +# A QUIC endpoint MUST NOT reuse a packet number within the same packet +# number space in one connection. If the packet number for sending +# reaches 2^62-1, the sender MUST close the connection without sending +# a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send +# a Stateless Reset (Section 10.3) in response to further packets that +# it receives. +# +# A receiver MUST discard a newly unprotected packet unless it is +# certain that it has not processed another packet with the same packet +# number from the same packet number space. Duplicate suppression MUST +# happen after removing packet protection for the reasons described in +# Section 9.5 of [QUIC-TLS]. +# +# Endpoints that track all individual packets for the purposes of +# detecting duplicates are at risk of accumulating excessive state. +# The data required for detecting duplicates can be limited by +# maintaining a minimum packet number below which all packets are +# immediately dropped. Any minimum needs to account for large +# variations in round-trip time, which includes the possibility that a +# peer might probe network paths with much larger round-trip times; see +# Section 9. +# +# Packet number encoding at a sender and decoding at a receiver are +# described in Section 17.1. + +[[spec]] +level = "MUST" +quote = ''' +Subsequent packets sent in the same packet +number space MUST increase the packet number by at least one. +''' + +[[spec]] +level = "MUST" +quote = ''' +A QUIC endpoint MUST NOT reuse a packet number within the same packet +number space in one connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the packet number for sending +reaches 2^62-1, the sender MUST close the connection without sending +a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send +a Stateless Reset (Section 10.3) in response to further packets that +it receives. +''' + +[[spec]] +level = "MUST" +quote = ''' +A receiver MUST discard a newly unprotected packet unless it is +certain that it has not processed another packet with the same packet +number from the same packet number space. +''' + +[[spec]] +level = "MUST" +quote = ''' +Duplicate suppression MUST +happen after removing packet protection for the reasons described in +Section 9.5 of [QUIC-TLS]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml new file mode 100644 index 0000000000..11d02860e6 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.4.toml @@ -0,0 +1,195 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.4" + +# Frames and Frame Types +# +# The payload of QUIC packets, after removing packet protection, +# consists of a sequence of complete frames, as shown in Figure 11. +# Version Negotiation, Stateless Reset, and Retry packets do not +# contain frames. +# +# Packet Payload { +# Frame (8..) ..., +# } +# +# Figure 11: QUIC Payload +# +# The payload of a packet that contains frames MUST contain at least +# one frame, and MAY contain multiple frames and multiple frame types. +# An endpoint MUST treat receipt of a packet containing no frames as a +# connection error of type PROTOCOL_VIOLATION. Frames always fit +# within a single QUIC packet and cannot span multiple packets. +# +# Each frame begins with a Frame Type, indicating its type, followed by +# additional type-dependent fields: +# +# Frame { +# Frame Type (i), +# Type-Dependent Fields (..), +# } +# +# Figure 12: Generic Frame Layout +# +# Table 3 lists and summarizes information about each frame type that +# is defined in this specification. A description of this summary is +# included after the table. +# +# +============+======================+===============+======+======+ +# | Type Value | Frame Type Name | Definition | Pkts | Spec | +# +============+======================+===============+======+======+ +# | 0x00 | PADDING | Section 19.1 | IH01 | NP | +# +------------+----------------------+---------------+------+------+ +# | 0x01 | PING | Section 19.2 | IH01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC | +# +------------+----------------------+---------------+------+------+ +# | 0x04 | RESET_STREAM | Section 19.4 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x05 | STOP_SENDING | Section 19.5 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x06 | CRYPTO | Section 19.6 | IH_1 | | +# +------------+----------------------+---------------+------+------+ +# | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | +# +------------+----------------------+---------------+------+------+ +# | 0x08-0x0f | STREAM | Section 19.8 | __01 | F | +# +------------+----------------------+---------------+------+------+ +# | 0x10 | MAX_DATA | Section 19.9 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | +# +------------+----------------------+---------------+------+------+ +# | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | +# +------------+----------------------+---------------+------+------+ +# | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | +# +------------+----------------------+---------------+------+------+ +# | 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P | +# +------------+----------------------+---------------+------+------+ +# | 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N | +# +------------+----------------------+---------------+------+------+ +# | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | +# +------------+----------------------+---------------+------+------+ +# +# Table 3: Frame Types +# +# The format and semantics of each frame type are explained in more +# detail in Section 19. The remainder of this section provides a +# summary of important and general information. +# +# The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and +# CONNECTION_CLOSE frames is used to carry other frame-specific flags. +# For all other frames, the Frame Type field simply identifies the +# frame. +# +# The "Pkts" column in Table 3 lists the types of packets that each +# frame type could appear in, indicated by the following characters: +# +# I: Initial (Section 17.2.2) +# +# H: Handshake (Section 17.2.4) +# +# 0: 0-RTT (Section 17.2.3) +# +# 1: 1-RTT (Section 17.3.1) +# +# ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial +# or Handshake packets. +# +# For more details about these restrictions, see Section 12.5. Note +# that all frames can appear in 1-RTT packets. An endpoint MUST treat +# receipt of a frame in a packet type that is not permitted as a +# connection error of type PROTOCOL_VIOLATION. +# +# The "Spec" column in Table 3 summarizes any special rules governing +# the processing or generation of the frame type, as indicated by the +# following characters: +# +# N: Packets containing only frames with this marking are not ack- +# eliciting; see Section 13.2. +# +# C: Packets containing only frames with this marking do not count +# toward bytes in flight for congestion control purposes; see +# [QUIC-RECOVERY]. +# +# P: Packets containing only frames with this marking can be used to +# probe new network paths during connection migration; see +# Section 9.1. +# +# F: The contents of frames with this marking are flow controlled; +# see Section 4. +# +# The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA +# registry; see Section 22.4. +# +# An endpoint MUST treat the receipt of a frame of unknown type as a +# connection error of type FRAME_ENCODING_ERROR. +# +# All frames are idempotent in this version of QUIC. That is, a valid +# frame does not cause undesirable side effects or errors when received +# more than once. +# +# The Frame Type field uses a variable-length integer encoding (see +# Section 16), with one exception. To ensure simple and efficient +# implementations of frame parsing, a frame type MUST use the shortest +# possible encoding. For frame types defined in this document, this +# means a single-byte encoding, even though it is possible to encode +# these values as a two-, four-, or eight-byte variable-length integer. +# For instance, though 0x4001 is a legitimate two-byte encoding for a +# variable-length integer with a value of 1, PING frames are always +# encoded as a single byte with the value 0x01. This rule applies to +# all current and future QUIC frame types. An endpoint MAY treat the +# receipt of a frame type that uses a longer encoding than necessary as +# a connection error of type PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +The payload of a packet that contains frames MUST contain at least +one frame, and MAY contain multiple frames and multiple frame types. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat receipt of a packet containing no frames as a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat +receipt of a frame in a packet type that is not permitted as a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat the receipt of a frame of unknown type as a +connection error of type FRAME_ENCODING_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +To ensure simple and efficient +implementations of frame parsing, a frame type MUST use the shortest +possible encoding. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY treat the +receipt of a frame type that uses a longer encoding than necessary as +a connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml new file mode 100644 index 0000000000..bf93d1ce59 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-12.5.toml @@ -0,0 +1,75 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.5" + +# Frames and Number Spaces +# +# Some frames are prohibited in different packet number spaces. The +# rules here generalize those of TLS, in that frames associated with +# establishing the connection can usually appear in packets in any +# packet number space, whereas those associated with transferring data +# can only appear in the application data packet number space: +# +# * PADDING, PING, and CRYPTO frames MAY appear in any packet number +# space. +# +# * CONNECTION_CLOSE frames signaling errors at the QUIC layer (type +# 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE +# frames signaling application errors (type 0x1d) MUST only appear +# in the application data packet number space. +# +# * ACK frames MAY appear in any packet number space but can only +# acknowledge packets that appeared in that packet number space. +# However, as noted below, 0-RTT packets cannot contain ACK frames. +# +# * All other frame types MUST only be sent in the application data +# packet number space. +# +# Note that it is not possible to send the following frames in 0-RTT +# packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, +# PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt +# of these frames in 0-RTT packets as a connection error of type +# PROTOCOL_VIOLATION. + +[[spec]] +level = "MAY" +quote = ''' +* PADDING, PING, and CRYPTO frames MAY appear in any packet number +space. +''' + +[[spec]] +level = "MAY" +quote = ''' +* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type +0x1c) MAY appear in any packet number space. +''' + +[[spec]] +level = "MUST" +quote = ''' +CONNECTION_CLOSE +frames signaling application errors (type 0x1d) MUST only appear +in the application data packet number space. +''' + +[[spec]] +level = "MAY" +quote = ''' +* ACK frames MAY appear in any packet number space but can only +acknowledge packets that appeared in that packet number space. +''' + +[[spec]] +level = "MUST" +quote = ''' +* All other frame types MUST only be sent in the application data +packet number space. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY treat receipt +of these frames in 0-RTT packets as a connection error of type +PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.1.toml new file mode 100644 index 0000000000..1ac67ef167 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.1.toml @@ -0,0 +1,35 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.1" + +# Packet Processing +# +# A packet MUST NOT be acknowledged until packet protection has been +# successfully removed and all frames contained in the packet have been +# processed. For STREAM frames, this means the data has been enqueued +# in preparation to be received by the application protocol, but it +# does not require that data be delivered and consumed. +# +# Once the packet has been fully processed, a receiver acknowledges +# receipt by sending one or more ACK frames containing the packet +# number of the received packet. +# +# An endpoint SHOULD treat receipt of an acknowledgment for a packet it +# did not send as a connection error of type PROTOCOL_VIOLATION, if it +# is able to detect the condition. For further discussion of how this +# might be achieved, see Section 21.4. + +[[spec]] +level = "MUST" +quote = ''' +A packet MUST NOT be acknowledged until packet protection has been +successfully removed and all frames contained in the packet have been +processed. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD treat receipt of an acknowledgment for a packet it +did not send as a connection error of type PROTOCOL_VIOLATION, if it +is able to detect the condition. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml new file mode 100644 index 0000000000..24a3b8db17 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.1.toml @@ -0,0 +1,145 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.1" + +# Sending ACK Frames +# +# Every packet SHOULD be acknowledged at least once, and ack-eliciting +# packets MUST be acknowledged at least once within the maximum delay +# an endpoint communicated using the max_ack_delay transport parameter; +# see Section 18.2. max_ack_delay declares an explicit contract: an +# endpoint promises to never intentionally delay acknowledgments of an +# ack-eliciting packet by more than the indicated value. If it does, +# any excess accrues to the RTT estimate and could result in spurious +# or delayed retransmissions from the peer. A sender uses the +# receiver's max_ack_delay value in determining timeouts for timer- +# based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY]. +# +# An endpoint MUST acknowledge all ack-eliciting Initial and Handshake +# packets immediately and all ack-eliciting 0-RTT and 1-RTT packets +# within its advertised max_ack_delay, with the following exception. +# Prior to handshake confirmation, an endpoint might not have packet +# protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets +# when they are received. It might therefore buffer them and +# acknowledge them when the requisite keys become available. +# +# Since packets containing only ACK frames are not congestion +# controlled, an endpoint MUST NOT send more than one such packet in +# response to receiving an ack-eliciting packet. +# +# An endpoint MUST NOT send a non-ack-eliciting packet in response to a +# non-ack-eliciting packet, even if there are packet gaps that precede +# the received packet. This avoids an infinite feedback loop of +# acknowledgments, which could prevent the connection from ever +# becoming idle. Non-ack-eliciting packets are eventually acknowledged +# when the endpoint sends an ACK frame in response to other events. +# +# An endpoint that is only sending ACK frames will not receive +# acknowledgments from its peer unless those acknowledgments are +# included in packets with ack-eliciting frames. An endpoint SHOULD +# send an ACK frame with other frames when there are new ack-eliciting +# packets to acknowledge. When only non-ack-eliciting packets need to +# be acknowledged, an endpoint MAY choose not to send an ACK frame with +# outgoing frames until an ack-eliciting packet has been received. +# +# An endpoint that is only sending non-ack-eliciting packets might +# choose to occasionally add an ack-eliciting frame to those packets to +# ensure that it receives an acknowledgment; see Section 13.2.4. In +# that case, an endpoint MUST NOT send an ack-eliciting frame in all +# packets that would otherwise be non-ack-eliciting, to avoid an +# infinite feedback loop of acknowledgments. +# +# In order to assist loss detection at the sender, an endpoint SHOULD +# generate and send an ACK frame without delay when it receives an ack- +# eliciting packet either: +# +# * when the received packet has a packet number less than another +# ack-eliciting packet that has been received, or +# +# * when the packet has a packet number larger than the highest- +# numbered ack-eliciting packet that has been received and there are +# missing packets between that packet and this packet. +# +# Similarly, packets marked with the ECN Congestion Experienced (CE) +# codepoint in the IP header SHOULD be acknowledged immediately, to +# reduce the peer's response time to congestion events. +# +# The algorithms in [QUIC-RECOVERY] are expected to be resilient to +# receivers that do not follow the guidance offered above. However, an +# implementation should only deviate from these requirements after +# careful consideration of the performance implications of a change, +# for connections made by the endpoint and for other users of the +# network. + +[[spec]] +level = "MUST" +quote = ''' +Every packet SHOULD be acknowledged at least once, and ack-eliciting +packets MUST be acknowledged at least once within the maximum delay +an endpoint communicated using the max_ack_delay transport parameter; +see Section 18.2. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST acknowledge all ack-eliciting Initial and Handshake +packets immediately and all ack-eliciting 0-RTT and 1-RTT packets +within its advertised max_ack_delay, with the following exception. +''' + +[[spec]] +level = "MUST" +quote = ''' +Since packets containing only ACK frames are not congestion +controlled, an endpoint MUST NOT send more than one such packet in +response to receiving an ack-eliciting packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send a non-ack-eliciting packet in response to a +non-ack-eliciting packet, even if there are packet gaps that precede +the received packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD +send an ACK frame with other frames when there are new ack-eliciting +packets to acknowledge. +''' + +[[spec]] +level = "MAY" +quote = ''' +When only non-ack-eliciting packets need to +be acknowledged, an endpoint MAY choose not to send an ACK frame with +outgoing frames until an ack-eliciting packet has been received. +''' + +[[spec]] +level = "MUST" +quote = ''' +In +that case, an endpoint MUST NOT send an ack-eliciting frame in all +packets that would otherwise be non-ack-eliciting, to avoid an +infinite feedback loop of acknowledgments. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In order to assist loss detection at the sender, an endpoint SHOULD +generate and send an ACK frame without delay when it receives an ack- +eliciting packet either: +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Similarly, packets marked with the ECN Congestion Experienced (CE) +codepoint in the IP header SHOULD be acknowledged immediately, to +reduce the peer's response time to congestion events. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.2.toml new file mode 100644 index 0000000000..fe403fb8bc --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.2.toml @@ -0,0 +1,45 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.2" + +# Acknowledgment Frequency +# +# A receiver determines how frequently to send acknowledgments in +# response to ack-eliciting packets. This determination involves a +# trade-off. +# +# Endpoints rely on timely acknowledgment to detect loss; see Section 6 +# of [QUIC-RECOVERY]. Window-based congestion controllers, such as the +# one described in Section 7 of [QUIC-RECOVERY], rely on +# acknowledgments to manage their congestion window. In both cases, +# delaying acknowledgments can adversely affect performance. +# +# On the other hand, reducing the frequency of packets that carry only +# acknowledgments reduces packet transmission and processing cost at +# both endpoints. It can improve connection throughput on severely +# asymmetric links and reduce the volume of acknowledgment traffic +# using return path capacity; see Section 3 of [RFC3449]. +# +# A receiver SHOULD send an ACK frame after receiving at least two ack- +# eliciting packets. This recommendation is general in nature and +# consistent with recommendations for TCP endpoint behavior [RFC5681]. +# Knowledge of network conditions, knowledge of the peer's congestion +# controller, or further research and experimentation might suggest +# alternative acknowledgment strategies with better performance +# characteristics. +# +# A receiver MAY process multiple available packets before determining +# whether to send an ACK frame in response. + +[[spec]] +level = "SHOULD" +quote = ''' +A receiver SHOULD send an ACK frame after receiving at least two ack- +eliciting packets. +''' + +[[spec]] +level = "MAY" +quote = ''' +A receiver MAY process multiple available packets before determining +whether to send an ACK frame in response. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml new file mode 100644 index 0000000000..0abde4ce68 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.3.toml @@ -0,0 +1,103 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.3" + +# Managing ACK Ranges +# +# When an ACK frame is sent, one or more ranges of acknowledged packets +# are included. Including acknowledgments for older packets reduces +# the chance of spurious retransmissions caused by losing previously +# sent ACK frames, at the cost of larger ACK frames. +# +# ACK frames SHOULD always acknowledge the most recently received +# packets, and the more out of order the packets are, the more +# important it is to send an updated ACK frame quickly, to prevent the +# peer from declaring a packet as lost and spuriously retransmitting +# the frames it contains. An ACK frame is expected to fit within a +# single QUIC packet. If it does not, then older ranges (those with +# the smallest packet numbers) are omitted. +# +# A receiver limits the number of ACK Ranges (Section 19.3.1) it +# remembers and sends in ACK frames, both to limit the size of ACK +# frames and to avoid resource exhaustion. After receiving +# acknowledgments for an ACK frame, the receiver SHOULD stop tracking +# those acknowledged ACK Ranges. Senders can expect acknowledgments +# for most packets, but QUIC does not guarantee receipt of an +# acknowledgment for every packet that the receiver processes. +# +# It is possible that retaining many ACK Ranges could cause an ACK +# frame to become too large. A receiver can discard unacknowledged ACK +# Ranges to limit ACK frame size, at the cost of increased +# retransmissions from the sender. This is necessary if an ACK frame +# would be too large to fit in a packet. Receivers MAY also limit ACK +# frame size further to preserve space for other frames or to limit the +# capacity that acknowledgments consume. +# +# A receiver MUST retain an ACK Range unless it can ensure that it will +# not subsequently accept packets with numbers in that range. +# Maintaining a minimum packet number that increases as ranges are +# discarded is one way to achieve this with minimal state. +# +# Receivers can discard all ACK Ranges, but they MUST retain the +# largest packet number that has been successfully processed, as that +# is used to recover packet numbers from subsequent packets; see +# Section 17.1. +# +# A receiver SHOULD include an ACK Range containing the largest +# received packet number in every ACK frame. The Largest Acknowledged +# field is used in ECN validation at a sender, and including a lower +# value than what was included in a previous ACK frame could cause ECN +# to be unnecessarily disabled; see Section 13.4.2. +# +# Section 13.2.4 describes an exemplary approach for determining what +# packets to acknowledge in each ACK frame. Though the goal of this +# algorithm is to generate an acknowledgment for every packet that is +# processed, it is still possible for acknowledgments to be lost. + +[[spec]] +level = "SHOULD" +quote = ''' +ACK frames SHOULD always acknowledge the most recently received +packets, and the more out of order the packets are, the more +important it is to send an updated ACK frame quickly, to prevent the +peer from declaring a packet as lost and spuriously retransmitting +the frames it contains. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +After receiving +acknowledgments for an ACK frame, the receiver SHOULD stop tracking +those acknowledged ACK Ranges. +''' + +[[spec]] +level = "MAY" +quote = ''' +Receivers MAY also limit ACK +frame size further to preserve space for other frames or to limit the +capacity that acknowledgments consume. +''' + +[[spec]] +level = "MUST" +quote = ''' +A receiver MUST retain an ACK Range unless it can ensure that it will +not subsequently accept packets with numbers in that range. +''' + +[[spec]] +level = "MUST" +quote = ''' +Receivers can discard all ACK Ranges, but they MUST retain the +largest packet number that has been successfully processed, as that +is used to recover packet numbers from subsequent packets; see +Section 17.1. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A receiver SHOULD include an ACK Range containing the largest +received packet number in every ACK frame. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml new file mode 100644 index 0000000000..1a689be974 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.5.toml @@ -0,0 +1,46 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.5" + +# Measuring and Reporting Host Delay +# +# An endpoint measures the delays intentionally introduced between the +# time the packet with the largest packet number is received and the +# time an acknowledgment is sent. The endpoint encodes this +# acknowledgment delay in the ACK Delay field of an ACK frame; see +# Section 19.3. This allows the receiver of the ACK frame to adjust +# for any intentional delays, which is important for getting a better +# estimate of the path RTT when acknowledgments are delayed. +# +# A packet might be held in the OS kernel or elsewhere on the host +# before being processed. An endpoint MUST NOT include delays that it +# does not control when populating the ACK Delay field in an ACK frame. +# However, endpoints SHOULD include buffering delays caused by +# unavailability of decryption keys, since these delays can be large +# and are likely to be non-repeating. +# +# When the measured acknowledgment delay is larger than its +# max_ack_delay, an endpoint SHOULD report the measured delay. This +# information is especially useful during the handshake when delays +# might be large; see Section 13.2.1. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT include delays that it +does not control when populating the ACK Delay field in an ACK frame. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +However, endpoints SHOULD include buffering delays caused by +unavailability of decryption keys, since these delays can be large +and are likely to be non-repeating. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When the measured acknowledgment delay is larger than its +max_ack_delay, an endpoint SHOULD report the measured delay. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml new file mode 100644 index 0000000000..e3c35b04ed --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.6.toml @@ -0,0 +1,38 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.6" + +# ACK Frames and Packet Protection +# +# ACK frames MUST only be carried in a packet that has the same packet +# number space as the packet being acknowledged; see Section 12.1. For +# instance, packets that are protected with 1-RTT keys MUST be +# acknowledged in packets that are also protected with 1-RTT keys. +# +# Packets that a client sends with 0-RTT packet protection MUST be +# acknowledged by the server in packets protected by 1-RTT keys. This +# can mean that the client is unable to use these acknowledgments if +# the server cryptographic handshake messages are delayed or lost. +# Note that the same limitation applies to other data sent by the +# server protected by the 1-RTT keys. + +[[spec]] +level = "MUST" +quote = ''' +ACK frames MUST only be carried in a packet that has the same packet +number space as the packet being acknowledged; see Section 12.1. +''' + +[[spec]] +level = "MUST" +quote = ''' +For +instance, packets that are protected with 1-RTT keys MUST be +acknowledged in packets that are also protected with 1-RTT keys. +''' + +[[spec]] +level = "MUST" +quote = ''' +Packets that a client sends with 0-RTT packet protection MUST be +acknowledged by the server in packets protected by 1-RTT keys. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.7.toml new file mode 100644 index 0000000000..d549aa7d49 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.7.toml @@ -0,0 +1,21 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.7" + +# PADDING Frames Consume Congestion Window +# +# Packets containing PADDING frames are considered to be in flight for +# congestion control purposes [QUIC-RECOVERY]. Packets containing only +# PADDING frames therefore consume congestion window but do not +# generate acknowledgments that will open the congestion window. To +# avoid a deadlock, a sender SHOULD ensure that other frames are sent +# periodically in addition to PADDING frames to elicit acknowledgments +# from the receiver. + +[[spec]] +level = "SHOULD" +quote = ''' +To +avoid a deadlock, a sender SHOULD ensure that other frames are sent +periodically in addition to PADDING frames to elicit acknowledgments +from the receiver. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.toml new file mode 100644 index 0000000000..b5361fc115 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.2.toml @@ -0,0 +1,26 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2" + +# Generating Acknowledgments +# +# Endpoints acknowledge all packets they receive and process. However, +# only ack-eliciting packets cause an ACK frame to be sent within the +# maximum ack delay. Packets that are not ack-eliciting are only +# acknowledged when an ACK frame is sent for other reasons. +# +# When sending a packet for any reason, an endpoint SHOULD attempt to +# include an ACK frame if one has not been sent recently. Doing so +# helps with timely loss detection at the peer. +# +# In general, frequent feedback from a receiver improves loss and +# congestion response, but this has to be balanced against excessive +# load generated by a receiver that sends an ACK frame in response to +# every ack-eliciting packet. The guidance offered below seeks to +# strike this balance. + +[[spec]] +level = "SHOULD" +quote = ''' +When sending a packet for any reason, an endpoint SHOULD attempt to +include an ACK frame if one has not been sent recently. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml new file mode 100644 index 0000000000..0f1e160df9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.3.toml @@ -0,0 +1,186 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.3" + +# Retransmission of Information +# +# QUIC packets that are determined to be lost are not retransmitted +# whole. The same applies to the frames that are contained within lost +# packets. Instead, the information that might be carried in frames is +# sent again in new frames as needed. +# +# New frames and packets are used to carry information that is +# determined to have been lost. In general, information is sent again +# when a packet containing that information is determined to be lost, +# and sending ceases when a packet containing that information is +# acknowledged. +# +# * Data sent in CRYPTO frames is retransmitted according to the rules +# in [QUIC-RECOVERY], until all data has been acknowledged. Data in +# CRYPTO frames for Initial and Handshake packets is discarded when +# keys for the corresponding packet number space are discarded. +# +# * Application data sent in STREAM frames is retransmitted in new +# STREAM frames unless the endpoint has sent a RESET_STREAM for that +# stream. Once an endpoint sends a RESET_STREAM frame, no further +# STREAM frames are needed. +# +# * ACK frames carry the most recent set of acknowledgments and the +# acknowledgment delay from the largest acknowledged packet, as +# described in Section 13.2.1. Delaying the transmission of packets +# containing ACK frames or resending old ACK frames can cause the +# peer to generate an inflated RTT sample or unnecessarily disable +# ECN. +# +# * Cancellation of stream transmission, as carried in a RESET_STREAM +# frame, is sent until acknowledged or until all stream data is +# acknowledged by the peer (that is, either the "Reset Recvd" or +# "Data Recvd" state is reached on the sending part of the stream). +# The content of a RESET_STREAM frame MUST NOT change when it is +# sent again. +# +# * Similarly, a request to cancel stream transmission, as encoded in +# a STOP_SENDING frame, is sent until the receiving part of the +# stream enters either a "Data Recvd" or "Reset Recvd" state; see +# Section 3.5. +# +# * Connection close signals, including packets that contain +# CONNECTION_CLOSE frames, are not sent again when packet loss is +# detected. Resending these signals is described in Section 10. +# +# * The current connection maximum data is sent in MAX_DATA frames. +# An updated value is sent in a MAX_DATA frame if the packet +# containing the most recently sent MAX_DATA frame is declared lost +# or when the endpoint decides to update the limit. Care is +# necessary to avoid sending this frame too often, as the limit can +# increase frequently and cause an unnecessarily large number of +# MAX_DATA frames to be sent; see Section 4.2. +# +# * The current maximum stream data offset is sent in MAX_STREAM_DATA +# frames. Like MAX_DATA, an updated value is sent when the packet +# containing the most recent MAX_STREAM_DATA frame for a stream is +# lost or when the limit is updated, with care taken to prevent the +# frame from being sent too often. An endpoint SHOULD stop sending +# MAX_STREAM_DATA frames when the receiving part of the stream +# enters a "Size Known" or "Reset Recvd" state. +# +# * The limit on streams of a given type is sent in MAX_STREAMS +# frames. Like MAX_DATA, an updated value is sent when a packet +# containing the most recent MAX_STREAMS for a stream type frame is +# declared lost or when the limit is updated, with care taken to +# prevent the frame from being sent too often. +# +# * Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, +# and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection +# scope, STREAM_DATA_BLOCKED frames have stream scope, and +# STREAMS_BLOCKED frames are scoped to a specific stream type. A +# new frame is sent if a packet containing the most recent frame for +# a scope is lost, but only while the endpoint is blocked on the +# corresponding limit. These frames always include the limit that +# is causing blocking at the time that they are transmitted. +# +# * A liveness or path validation check using PATH_CHALLENGE frames is +# sent periodically until a matching PATH_RESPONSE frame is received +# or until there is no remaining need for liveness or path +# validation checking. PATH_CHALLENGE frames include a different +# payload each time they are sent. +# +# * Responses to path validation using PATH_RESPONSE frames are sent +# just once. The peer is expected to send more PATH_CHALLENGE +# frames as necessary to evoke additional PATH_RESPONSE frames. +# +# * New connection IDs are sent in NEW_CONNECTION_ID frames and +# retransmitted if the packet containing them is lost. +# Retransmissions of this frame carry the same sequence number +# value. Likewise, retired connection IDs are sent in +# RETIRE_CONNECTION_ID frames and retransmitted if the packet +# containing them is lost. +# +# * NEW_TOKEN frames are retransmitted if the packet containing them +# is lost. No special support is made for detecting reordered and +# duplicated NEW_TOKEN frames other than a direct comparison of the +# frame contents. +# +# * PING and PADDING frames contain no information, so lost PING or +# PADDING frames do not require repair. +# +# * The HANDSHAKE_DONE frame MUST be retransmitted until it is +# acknowledged. +# +# Endpoints SHOULD prioritize retransmission of data over sending new +# data, unless priorities specified by the application indicate +# otherwise; see Section 2.3. +# +# Even though a sender is encouraged to assemble frames containing up- +# to-date information every time it sends a packet, it is not forbidden +# to retransmit copies of frames from lost packets. A sender that +# retransmits copies of frames needs to handle decreases in available +# payload size due to changes in packet number length, connection ID +# length, and path MTU. A receiver MUST accept packets containing an +# outdated frame, such as a MAX_DATA frame carrying a smaller maximum +# data value than one found in an older packet. +# +# A sender SHOULD avoid retransmitting information from packets once +# they are acknowledged. This includes packets that are acknowledged +# after being declared lost, which can happen in the presence of +# network reordering. Doing so requires senders to retain information +# about packets after they are declared lost. A sender can discard +# this information after a period of time elapses that adequately +# allows for reordering, such as a PTO (Section 6.2 of +# [QUIC-RECOVERY]), or based on other events, such as reaching a memory +# limit. +# +# Upon detecting losses, a sender MUST take appropriate congestion +# control action. The details of loss detection and congestion control +# are described in [QUIC-RECOVERY]. + +[[spec]] +level = "MUST" +quote = ''' +The content of a RESET_STREAM frame MUST NOT change when it is +sent again. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD stop sending +MAX_STREAM_DATA frames when the receiving part of the stream +enters a "Size Known" or "Reset Recvd" state. +''' + +[[spec]] +level = "MUST" +quote = ''' +* The HANDSHAKE_DONE frame MUST be retransmitted until it is +acknowledged. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD prioritize retransmission of data over sending new +data, unless priorities specified by the application indicate +otherwise; see Section 2.3. +''' + +[[spec]] +level = "MUST" +quote = ''' +A receiver MUST accept packets containing an +outdated frame, such as a MAX_DATA frame carrying a smaller maximum +data value than one found in an older packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD avoid retransmitting information from packets once +they are acknowledged. +''' + +[[spec]] +level = "MUST" +quote = ''' +Upon detecting losses, a sender MUST take appropriate congestion +control action. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.1.toml new file mode 100644 index 0000000000..d18d00754e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.1.toml @@ -0,0 +1,44 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.1" + +# Reporting ECN Counts +# +# The use of ECN requires the receiving endpoint to read the ECN field +# from an IP packet, which is not possible on all platforms. If an +# endpoint does not implement ECN support or does not have access to +# received ECN fields, it does not report ECN counts for packets it +# receives. +# +# Even if an endpoint does not set an ECT field in packets it sends, +# the endpoint MUST provide feedback about ECN markings it receives, if +# these are accessible. Failing to report the ECN counts will cause +# the sender to disable the use of ECN for this connection. +# +# On receiving an IP packet with an ECT(0), ECT(1), or ECN-CE +# codepoint, an ECN-enabled endpoint accesses the ECN field and +# increases the corresponding ECT(0), ECT(1), or ECN-CE count. These +# ECN counts are included in subsequent ACK frames; see Sections 13.2 +# and 19.3. +# +# Each packet number space maintains separate acknowledgment state and +# separate ECN counts. Coalesced QUIC packets (see Section 12.2) share +# the same IP header so the ECN counts are incremented once for each +# coalesced QUIC packet. +# +# For example, if one each of an Initial, Handshake, and 1-RTT QUIC +# packet are coalesced into a single UDP datagram, the ECN counts for +# all three packet number spaces will be incremented by one each, based +# on the ECN field of the single IP header. +# +# ECN counts are only incremented when QUIC packets from the received +# IP packet are processed. As such, duplicate QUIC packets are not +# processed and do not increase ECN counts; see Section 21.10 for +# relevant security concerns. + +[[spec]] +level = "MUST" +quote = ''' +Even if an endpoint does not set an ECT field in packets it sends, +the endpoint MUST provide feedback about ECN markings it receives, if +these are accessible. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.1.toml new file mode 100644 index 0000000000..68edf4ed42 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.1.toml @@ -0,0 +1,54 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.2.1" + +# Receiving ACK Frames with ECN Counts +# +# Erroneous application of ECN-CE markings by the network can result in +# degraded connection performance. An endpoint that receives an ACK +# frame with ECN counts therefore validates the counts before using +# them. It performs this validation by comparing newly received counts +# against those from the last successfully processed ACK frame. Any +# increase in the ECN counts is validated based on the ECN markings +# that were applied to packets that are newly acknowledged in the ACK +# frame. +# +# If an ACK frame newly acknowledges a packet that the endpoint sent +# with either the ECT(0) or ECT(1) codepoint set, ECN validation fails +# if the corresponding ECN counts are not present in the ACK frame. +# This check detects a network element that zeroes the ECN field or a +# peer that does not report ECN markings. +# +# ECN validation also fails if the sum of the increase in ECT(0) and +# ECN-CE counts is less than the number of newly acknowledged packets +# that were originally sent with an ECT(0) marking. Similarly, ECN +# validation fails if the sum of the increases to ECT(1) and ECN-CE +# counts is less than the number of newly acknowledged packets sent +# with an ECT(1) marking. These checks can detect remarking of ECN-CE +# markings by the network. +# +# An endpoint could miss acknowledgments for a packet when ACK frames +# are lost. It is therefore possible for the total increase in ECT(0), +# ECT(1), and ECN-CE counts to be greater than the number of packets +# that are newly acknowledged by an ACK frame. This is why ECN counts +# are permitted to be larger than the total number of packets that are +# acknowledged. +# +# Validating ECN counts from reordered ACK frames can result in +# failure. An endpoint MUST NOT fail ECN validation as a result of +# processing an ACK frame that does not increase the largest +# acknowledged packet number. +# +# ECN validation can fail if the received total count for either ECT(0) +# or ECT(1) exceeds the total number of packets sent with each +# corresponding ECT codepoint. In particular, validation will fail +# when an endpoint receives a non-zero ECN count corresponding to an +# ECT codepoint that it never applied. This check detects when packets +# are remarked to ECT(0) or ECT(1) in the network. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT fail ECN validation as a result of +processing an ACK frame that does not increase the largest +acknowledged packet number. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml new file mode 100644 index 0000000000..2860194fab --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.2.toml @@ -0,0 +1,47 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.2.2" + +# ECN Validation Outcomes +# +# If validation fails, then the endpoint MUST disable ECN. It stops +# setting the ECT codepoint in IP packets that it sends, assuming that +# either the network path or the peer does not support ECN. +# +# Even if validation fails, an endpoint MAY revalidate ECN for the same +# path at any later time in the connection. An endpoint could continue +# to periodically attempt validation. +# +# Upon successful validation, an endpoint MAY continue to set an ECT +# codepoint in subsequent packets it sends, with the expectation that +# the path is ECN capable. Network routing and path elements can +# change mid-connection; an endpoint MUST disable ECN if validation +# later fails. + +[[spec]] +level = "MUST" +quote = ''' +If validation fails, then the endpoint MUST disable ECN. +''' + +[[spec]] +level = "MAY" +quote = ''' +Even if validation fails, an endpoint MAY revalidate ECN for the same +path at any later time in the connection. +''' + +[[spec]] +level = "MAY" +quote = ''' +Upon successful validation, an endpoint MAY continue to set an ECT +codepoint in subsequent packets it sends, with the expectation that +the path is ECN capable. +''' + +[[spec]] +level = "MUST" +quote = ''' +Network routing and path elements can +change mid-connection; an endpoint MUST disable ECN if validation +later fails. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.toml new file mode 100644 index 0000000000..e2eeb8b7ab --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.4.2.toml @@ -0,0 +1,45 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.2" + +# ECN Validation +# +# It is possible for faulty network devices to corrupt or erroneously +# drop packets that carry a non-zero ECN codepoint. To ensure +# connectivity in the presence of such devices, an endpoint validates +# the ECN counts for each network path and disables the use of ECN on +# that path if errors are detected. +# +# To perform ECN validation for a new path: +# +# * The endpoint sets an ECT(0) codepoint in the IP header of early +# outgoing packets sent on a new path to the peer [RFC8311]. +# +# * The endpoint monitors whether all packets sent with an ECT +# codepoint are eventually deemed lost (Section 6 of +# [QUIC-RECOVERY]), indicating that ECN validation has failed. +# +# If an endpoint has cause to expect that IP packets with an ECT +# codepoint might be dropped by a faulty network element, the endpoint +# could set an ECT codepoint for only the first ten outgoing packets on +# a path, or for a period of three PTOs (see Section 6.2 of +# [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints +# are subsequently lost, it can disable marking on the assumption that +# the marking caused the loss. +# +# An endpoint thus attempts to use ECN and validates this for each new +# connection, when switching to a server's preferred address, and on +# active connection migration to a new path. Appendix A.4 describes +# one possible algorithm. +# +# Other methods of probing paths for ECN support are possible, as are +# different marking strategies. Implementations MAY use other methods +# defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) +# codepoint need to perform ECN validation using the reported ECT(1) +# counts. + +[[spec]] +level = "MAY" +quote = ''' +Implementations MAY use other methods +defined in RFCs; see [RFC8311]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.toml new file mode 100644 index 0000000000..91212b0c0a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-13.toml @@ -0,0 +1,48 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-13" + +# Packetization and Reliability +# +# A sender sends one or more frames in a QUIC packet; see Section 12.4. +# +# A sender can minimize per-packet bandwidth and computational costs by +# including as many frames as possible in each QUIC packet. A sender +# MAY wait for a short period of time to collect multiple frames before +# sending a packet that is not maximally packed, to avoid sending out +# large numbers of small packets. An implementation MAY use knowledge +# about application sending behavior or heuristics to determine whether +# and for how long to wait. This waiting period is an implementation +# decision, and an implementation should be careful to delay +# conservatively, since any delay is likely to increase application- +# visible latency. +# +# Stream multiplexing is achieved by interleaving STREAM frames from +# multiple streams into one or more QUIC packets. A single QUIC packet +# can include multiple STREAM frames from one or more streams. +# +# One of the benefits of QUIC is avoidance of head-of-line blocking +# across multiple streams. When a packet loss occurs, only streams +# with data in that packet are blocked waiting for a retransmission to +# be received, while other streams can continue making progress. Note +# that when data from multiple streams is included in a single QUIC +# packet, loss of that packet blocks all those streams from making +# progress. Implementations are advised to include as few streams as +# necessary in outgoing packets without losing transmission efficiency +# to underfilled packets. + +[[spec]] +level = "MAY" +quote = ''' +A sender +MAY wait for a short period of time to collect multiple frames before +sending a packet that is not maximally packed, to avoid sending out +large numbers of small packets. +''' + +[[spec]] +level = "MAY" +quote = ''' +An implementation MAY use knowledge +about application sending behavior or heuristics to determine whether +and for how long to wait. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml new file mode 100644 index 0000000000..10e450b090 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.1.toml @@ -0,0 +1,80 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.1" + +# Initial Datagram Size +# +# A client MUST expand the payload of all UDP datagrams carrying +# Initial packets to at least the smallest allowed maximum datagram +# size of 1200 bytes by adding PADDING frames to the Initial packet or +# by coalescing the Initial packet; see Section 12.2. Initial packets +# can even be coalesced with invalid packets, which a receiver will +# discard. Similarly, a server MUST expand the payload of all UDP +# datagrams carrying ack-eliciting Initial packets to at least the +# smallest allowed maximum datagram size of 1200 bytes. +# +# Sending UDP datagrams of this size ensures that the network path +# supports a reasonable Path Maximum Transmission Unit (PMTU), in both +# directions. Additionally, a client that expands Initial packets +# helps reduce the amplitude of amplification attacks caused by server +# responses toward an unverified client address; see Section 8. +# +# Datagrams containing Initial packets MAY exceed 1200 bytes if the +# sender believes that the network path and peer both support the size +# that it chooses. +# +# A server MUST discard an Initial packet that is carried in a UDP +# datagram with a payload that is smaller than the smallest allowed +# maximum datagram size of 1200 bytes. A server MAY also immediately +# close the connection by sending a CONNECTION_CLOSE frame with an +# error code of PROTOCOL_VIOLATION; see Section 10.2.3. +# +# The server MUST also limit the number of bytes it sends before +# validating the address of the client; see Section 8. + +[[spec]] +level = "MUST" +quote = ''' +A client MUST expand the payload of all UDP datagrams carrying +Initial packets to at least the smallest allowed maximum datagram +size of 1200 bytes by adding PADDING frames to the Initial packet or +by coalescing the Initial packet; see Section 12.2. +''' + +[[spec]] +level = "MUST" +quote = ''' +Similarly, a server MUST expand the payload of all UDP +datagrams carrying ack-eliciting Initial packets to at least the +smallest allowed maximum datagram size of 1200 bytes. +''' + +[[spec]] +level = "MAY" +quote = ''' +Datagrams containing Initial packets MAY exceed 1200 bytes if the +sender believes that the network path and peer both support the size +that it chooses. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST discard an Initial packet that is carried in a UDP +datagram with a payload that is smaller than the smallest allowed +maximum datagram size of 1200 bytes. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY also immediately +close the connection by sending a CONNECTION_CLOSE frame with an +error code of PROTOCOL_VIOLATION; see Section 10.2.3. +''' + +[[spec]] +level = "MUST" +quote = ''' +The server MUST also limit the number of bytes it sends before +validating the address of the client; see Section 8. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml new file mode 100644 index 0000000000..1e8cd473a7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.1.toml @@ -0,0 +1,92 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.2.1" + +# Handling of ICMP Messages by PMTUD +# +# PMTUD [RFC1191] [RFC8201] relies on reception of ICMP messages (that +# is, IPv6 Packet Too Big (PTB) messages) that indicate when an IP +# packet is dropped because it is larger than the local router MTU. +# DPLPMTUD can also optionally use these messages. This use of ICMP +# messages is potentially vulnerable to attacks by entities that cannot +# observe packets but might successfully guess the addresses used on +# the path. These attacks could reduce the PMTU to a bandwidth- +# inefficient value. +# +# An endpoint MUST ignore an ICMP message that claims the PMTU has +# decreased below QUIC's smallest allowed maximum datagram size. +# +# The requirements for generating ICMP [RFC1812] [RFC4443] state that +# the quoted packet should contain as much of the original packet as +# possible without exceeding the minimum MTU for the IP version. The +# size of the quoted packet can actually be smaller, or the information +# unintelligible, as described in Section 1.1 of [DPLPMTUD]. +# +# QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect +# from packet injection as specified in [RFC8201] and Section 5.2 of +# [RFC8085]. This validation SHOULD use the quoted packet supplied in +# the payload of an ICMP message to associate the message with a +# corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). +# ICMP message validation MUST include matching IP addresses and UDP +# ports [RFC8085] and, when possible, connection IDs to an active QUIC +# session. The endpoint SHOULD ignore all ICMP messages that fail +# validation. +# +# An endpoint MUST NOT increase the PMTU based on ICMP messages; see +# Item 6 in Section 3 of [DPLPMTUD]. Any reduction in QUIC's maximum +# datagram size in response to ICMP messages MAY be provisional until +# QUIC's loss detection algorithm determines that the quoted packet has +# actually been lost. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST ignore an ICMP message that claims the PMTU has +decreased below QUIC's smallest allowed maximum datagram size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect +from packet injection as specified in [RFC8201] and Section 5.2 of +[RFC8085]. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +This validation SHOULD use the quoted packet supplied in +the payload of an ICMP message to associate the message with a +corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). +''' + +[[spec]] +level = "MUST" +quote = ''' +ICMP message validation MUST include matching IP addresses and UDP +ports [RFC8085] and, when possible, connection IDs to an active QUIC +session. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The endpoint SHOULD ignore all ICMP messages that fail +validation. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT increase the PMTU based on ICMP messages; see +Item 6 in Section 3 of [DPLPMTUD]. +''' + +[[spec]] +level = "MAY" +quote = ''' +Any reduction in QUIC's maximum +datagram size in response to ICMP messages MAY be provisional until +QUIC's loss detection algorithm determines that the quoted packet has +actually been lost. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml new file mode 100644 index 0000000000..dc57e99752 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.2.toml @@ -0,0 +1,97 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.2" + +# Path Maximum Transmission Unit +# +# The PMTU is the maximum size of the entire IP packet, including the +# IP header, UDP header, and UDP payload. The UDP payload includes one +# or more QUIC packet headers and protected payloads. The PMTU can +# depend on path characteristics and can therefore change over time. +# The largest UDP payload an endpoint sends at any given time is +# referred to as the endpoint's maximum datagram size. +# +# An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD +# (Section 14.2.1) to determine whether the path to a destination will +# support a desired maximum datagram size without fragmentation. In +# the absence of these mechanisms, QUIC endpoints SHOULD NOT send +# datagrams larger than the smallest allowed maximum datagram size. +# +# Both DPLPMTUD and PMTUD send datagrams that are larger than the +# current maximum datagram size, referred to as PMTU probes. All QUIC +# packets that are not sent in a PMTU probe SHOULD be sized to fit +# within the maximum datagram size to avoid the datagram being +# fragmented or dropped [RFC8085]. +# +# If a QUIC endpoint determines that the PMTU between any pair of local +# and remote IP addresses cannot support the smallest allowed maximum +# datagram size of 1200 bytes, it MUST immediately cease sending QUIC +# packets, except for those in PMTU probes or those containing +# CONNECTION_CLOSE frames, on the affected path. An endpoint MAY +# terminate the connection if an alternative path cannot be found. +# +# Each pair of local and remote addresses could have a different PMTU. +# QUIC implementations that implement any kind of PMTU discovery +# therefore SHOULD maintain a maximum datagram size for each +# combination of local and remote IP addresses. +# +# A QUIC implementation MAY be more conservative in computing the +# maximum datagram size to allow for unknown tunnel overheads or IP +# header options/extensions. + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD +(Section 14.2.1) to determine whether the path to a destination will +support a desired maximum datagram size without fragmentation. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In +the absence of these mechanisms, QUIC endpoints SHOULD NOT send +datagrams larger than the smallest allowed maximum datagram size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +All QUIC +packets that are not sent in a PMTU probe SHOULD be sized to fit +within the maximum datagram size to avoid the datagram being +fragmented or dropped [RFC8085]. +''' + +[[spec]] +level = "MUST" +quote = ''' +If a QUIC endpoint determines that the PMTU between any pair of local +and remote IP addresses cannot support the smallest allowed maximum +datagram size of 1200 bytes, it MUST immediately cease sending QUIC +packets, except for those in PMTU probes or those containing +CONNECTION_CLOSE frames, on the affected path. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY +terminate the connection if an alternative path cannot be found. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +QUIC implementations that implement any kind of PMTU discovery +therefore SHOULD maintain a maximum datagram size for each +combination of local and remote IP addresses. +''' + +[[spec]] +level = "MAY" +quote = ''' +A QUIC implementation MAY be more conservative in computing the +maximum datagram size to allow for unknown tunnel overheads or IP +header options/extensions. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.3.toml new file mode 100644 index 0000000000..b4d6a646bf --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.3.toml @@ -0,0 +1,26 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.3" + +# Datagram Packetization Layer PMTU Discovery +# +# DPLPMTUD [DPLPMTUD] relies on tracking loss or acknowledgment of QUIC +# packets that are carried in PMTU probes. PMTU probes for DPLPMTUD +# that use the PADDING frame implement "Probing using padding data", as +# defined in Section 4.1 of [DPLPMTUD]. +# +# Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of +# [DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum +# datagram size. The MIN_PLPMTU is the same as the BASE_PLPMTU. +# +# QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum +# Packet Size (MPS) (Section 4.4 of [DPLPMTUD]) for each combination of +# local and remote IP addresses. This corresponds to the maximum +# datagram size. + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of +[DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum +datagram size. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.4.toml new file mode 100644 index 0000000000..fcee0d621f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.4.toml @@ -0,0 +1,24 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.4" + +# Sending QUIC PMTU Probes +# +# PMTU probes are ack-eliciting packets. +# +# Endpoints could limit the content of PMTU probes to PING and PADDING +# frames, since packets that are larger than the current maximum +# datagram size are more likely to be dropped by the network. Loss of +# a QUIC packet that is carried in a PMTU probe is therefore not a +# reliable indication of congestion and SHOULD NOT trigger a congestion +# control reaction; see Item 7 in Section 3 of [DPLPMTUD]. However, +# PMTU probes consume congestion window, which could delay subsequent +# transmission by an application. + +[[spec]] +level = "SHOULD" +quote = ''' +Loss of +a QUIC packet that is carried in a PMTU probe is therefore not a +reliable indication of congestion and SHOULD NOT trigger a congestion +control reaction; see Item 7 in Section 3 of [DPLPMTUD]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml new file mode 100644 index 0000000000..df75757a83 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-14.toml @@ -0,0 +1,82 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-14" + +# Datagram Size +# +# A UDP datagram can include one or more QUIC packets. The datagram +# size refers to the total UDP payload size of a single UDP datagram +# carrying QUIC packets. The datagram size includes one or more QUIC +# packet headers and protected payloads, but not the UDP or IP headers. +# +# The maximum datagram size is defined as the largest size of UDP +# payload that can be sent across a network path using a single UDP +# datagram. QUIC MUST NOT be used if the network path cannot support a +# maximum datagram size of at least 1200 bytes. +# +# QUIC assumes a minimum IP packet size of at least 1280 bytes. This +# is the IPv6 minimum size [IPv6] and is also supported by most modern +# IPv4 networks. Assuming the minimum IP header size of 40 bytes for +# IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this +# results in a maximum datagram size of 1232 bytes for IPv6 and 1252 +# bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are +# expected to be able to support QUIC. +# +# | Note: This requirement to support a UDP payload of 1200 bytes +# | limits the space available for IPv6 extension headers to 32 +# | bytes or IPv4 options to 52 bytes if the path only supports the +# | IPv6 minimum MTU of 1280 bytes. This affects Initial packets +# | and path validation. +# +# Any maximum datagram size larger than 1200 bytes can be discovered +# using Path Maximum Transmission Unit Discovery (PMTUD) (see +# Section 14.2.1) or Datagram Packetization Layer PMTU Discovery +# (DPLPMTUD) (see Section 14.3). +# +# Enforcement of the max_udp_payload_size transport parameter +# (Section 18.2) might act as an additional limit on the maximum +# datagram size. A sender can avoid exceeding this limit, once the +# value is known. However, prior to learning the value of the +# transport parameter, endpoints risk datagrams being lost if they send +# datagrams larger than the smallest allowed maximum datagram size of +# 1200 bytes. +# +# UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 +# [IPv4], the Don't Fragment (DF) bit MUST be set if possible, to +# prevent fragmentation on the path. +# +# QUIC sometimes requires datagrams to be no smaller than a certain +# size; see Section 8.1 as an example. However, the size of a datagram +# is not authenticated. That is, if an endpoint receives a datagram of +# a certain size, it cannot know that the sender sent the datagram at +# the same size. Therefore, an endpoint MUST NOT close a connection +# when it receives a datagram that does not meet size constraints; the +# endpoint MAY discard such datagrams. + +[[spec]] +level = "MUST" +quote = ''' +QUIC MUST NOT be used if the network path cannot support a +maximum datagram size of at least 1200 bytes. +''' + +[[spec]] +level = "MUST" +quote = ''' +UDP datagrams MUST NOT be fragmented at the IP layer. +''' + +[[spec]] +level = "MUST" +quote = ''' +In IPv4 +[IPv4], the Don't Fragment (DF) bit MUST be set if possible, to +prevent fragmentation on the path. +''' + +[[spec]] +level = "MUST" +quote = ''' +Therefore, an endpoint MUST NOT close a connection +when it receives a datagram that does not meet size constraints; the +endpoint MAY discard such datagrams. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-15.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-15.toml new file mode 100644 index 0000000000..b8c6271fec --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-15.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-15" + +# Versions +# +# QUIC versions are identified using a 32-bit unsigned number. +# +# The version 0x00000000 is reserved to represent version negotiation. +# This version of the specification is identified by the number +# 0x00000001. +# +# Other versions of QUIC might have different properties from this +# version. The properties of QUIC that are guaranteed to be consistent +# across all versions of the protocol are described in +# [QUIC-INVARIANTS]. +# +# Version 0x00000001 of QUIC uses TLS as a cryptographic handshake +# protocol, as described in [QUIC-TLS]. +# +# Versions with the most significant 16 bits of the version number +# cleared are reserved for use in future IETF consensus documents. +# +# Versions that follow the pattern 0x?a?a?a?a are reserved for use in +# forcing version negotiation to be exercised -- that is, any version +# number where the low four bits of all bytes is 1010 (in binary). A +# client or server MAY advertise support for any of these reserved +# versions. +# +# Reserved version numbers will never represent a real protocol; a +# client MAY use one of these version numbers with the expectation that +# the server will initiate version negotiation; a server MAY advertise +# support for one of these versions and can expect that clients ignore +# the value. + +[[spec]] +level = "MAY" +quote = ''' +A +client or server MAY advertise support for any of these reserved +versions. +''' + +[[spec]] +level = "MAY" +quote = ''' +Reserved version numbers will never represent a real protocol; a +client MAY use one of these version numbers with the expectation that +the server will initiate version negotiation; a server MAY advertise +support for one of these versions and can expect that clients ignore +the value. +''' + +[[spec]] +level = "MAY" +quote = ''' +Reserved version numbers will never represent a real protocol; a +client MAY use one of these version numbers with the expectation that +the server will initiate version negotiation; a server MAY advertise +support for one of these versions and can expect that clients ignore +the value. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml new file mode 100644 index 0000000000..93136c3a84 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.1.toml @@ -0,0 +1,74 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.1" + +# Packet Number Encoding and Decoding +# +# Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). +# When present in long or short packet headers, they are encoded in 1 +# to 4 bytes. The number of bits required to represent the packet +# number is reduced by including only the least significant bits of the +# packet number. +# +# The encoded packet number is protected as described in Section 5.4 of +# [QUIC-TLS]. +# +# Prior to receiving an acknowledgment for a packet number space, the +# full packet number MUST be included; it is not to be truncated, as +# described below. +# +# After an acknowledgment is received for a packet number space, the +# sender MUST use a packet number size able to represent more than +# twice as large a range as the difference between the largest +# acknowledged packet number and the packet number being sent. A peer +# receiving the packet will then correctly decode the packet number, +# unless the packet is delayed in transit such that it arrives after +# many higher-numbered packets have been received. An endpoint SHOULD +# use a large enough packet number encoding to allow the packet number +# to be recovered even if the packet arrives after packets that are +# sent afterwards. +# +# As a result, the size of the packet number encoding is at least one +# bit more than the base-2 logarithm of the number of contiguous +# unacknowledged packet numbers, including the new packet. Pseudocode +# and an example for packet number encoding can be found in +# Appendix A.2. +# +# At a receiver, protection of the packet number is removed prior to +# recovering the full packet number. The full packet number is then +# reconstructed based on the number of significant bits present, the +# value of those bits, and the largest packet number received in a +# successfully authenticated packet. Recovering the full packet number +# is necessary to successfully complete the removal of packet +# protection. +# +# Once header protection is removed, the packet number is decoded by +# finding the packet number value that is closest to the next expected +# packet. The next expected packet is the highest received packet +# number plus one. Pseudocode and an example for packet number +# decoding can be found in Appendix A.3. + +[[spec]] +level = "MUST" +quote = ''' +Prior to receiving an acknowledgment for a packet number space, the +full packet number MUST be included; it is not to be truncated, as +described below. +''' + +[[spec]] +level = "MUST" +quote = ''' +After an acknowledgment is received for a packet number space, the +sender MUST use a packet number size able to represent more than +twice as large a range as the difference between the largest +acknowledged packet number and the packet number being sent. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD +use a large enough packet number encoding to allow the packet number +to be recovered even if the packet arrives after packets that are +sent afterwards. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml new file mode 100644 index 0000000000..30021577f4 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.1.toml @@ -0,0 +1,121 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.1" + +# Version Negotiation Packet +# +# A Version Negotiation packet is inherently not version specific. +# Upon receipt by a client, it will be identified as a Version +# Negotiation packet based on the Version field having a value of 0. +# +# The Version Negotiation packet is a response to a client packet that +# contains a version that is not supported by the server. It is only +# sent by servers. +# +# The layout of a Version Negotiation packet is: +# +# Version Negotiation Packet { +# Header Form (1) = 1, +# Unused (7), +# Version (32) = 0, +# Destination Connection ID Length (8), +# Destination Connection ID (0..2040), +# Source Connection ID Length (8), +# Source Connection ID (0..2040), +# Supported Version (32) ..., +# } +# +# Figure 14: Version Negotiation Packet +# +# The value in the Unused field is set to an arbitrary value by the +# server. Clients MUST ignore the value of this field. Where QUIC +# might be multiplexed with other protocols (see [RFC7983]), servers +# SHOULD set the most significant bit of this field (0x40) to 1 so that +# Version Negotiation packets appear to have the Fixed Bit field. Note +# that other versions of QUIC might not make a similar recommendation. +# +# The Version field of a Version Negotiation packet MUST be set to +# 0x00000000. +# +# The server MUST include the value from the Source Connection ID field +# of the packet it receives in the Destination Connection ID field. +# The value for Source Connection ID MUST be copied from the +# Destination Connection ID of the received packet, which is initially +# randomly selected by a client. Echoing both connection IDs gives +# clients some assurance that the server received the packet and that +# the Version Negotiation packet was not generated by an entity that +# did not observe the Initial packet. +# +# Future versions of QUIC could have different requirements for the +# lengths of connection IDs. In particular, connection IDs might have +# a smaller minimum length or a greater maximum length. Version- +# specific rules for the connection ID therefore MUST NOT influence a +# decision about whether to send a Version Negotiation packet. +# +# The remainder of the Version Negotiation packet is a list of 32-bit +# versions that the server supports. +# +# A Version Negotiation packet is not acknowledged. It is only sent in +# response to a packet that indicates an unsupported version; see +# Section 5.2.2. +# +# The Version Negotiation packet does not include the Packet Number and +# Length fields present in other packets that use the long header form. +# Consequently, a Version Negotiation packet consumes an entire UDP +# datagram. +# +# A server MUST NOT send more than one Version Negotiation packet in +# response to a single UDP datagram. +# +# See Section 6 for a description of the version negotiation process. + +[[spec]] +level = "MUST" +quote = ''' +Clients MUST ignore the value of this field. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Where QUIC +might be multiplexed with other protocols (see [RFC7983]), servers +SHOULD set the most significant bit of this field (0x40) to 1 so that +Version Negotiation packets appear to have the Fixed Bit field. +''' + +[[spec]] +level = "MUST" +quote = ''' +The Version field of a Version Negotiation packet MUST be set to +0x00000000. +''' + +[[spec]] +level = "MUST" +quote = ''' +The server MUST include the value from the Source Connection ID field +of the packet it receives in the Destination Connection ID field. +''' + +[[spec]] +level = "MUST" +quote = ''' +The value for Source Connection ID MUST be copied from the +Destination Connection ID of the received packet, which is initially +randomly selected by a client. +''' + +[[spec]] +level = "MUST" +quote = ''' +Version- +specific rules for the connection ID therefore MUST NOT influence a +decision about whether to send a Version Negotiation packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST NOT send more than one Version Negotiation packet in +response to a single UDP datagram. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.2.toml new file mode 100644 index 0000000000..939d1386dd --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.2.toml @@ -0,0 +1,105 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.2" + +# Initial Packet +# +# An Initial packet uses long headers with a type value of 0x00. It +# carries the first CRYPTO frames sent by the client and server to +# perform key exchange, and it carries ACK frames in either direction. +# +# Initial Packet { +# Header Form (1) = 1, +# Fixed Bit (1) = 1, +# Long Packet Type (2) = 0, +# Reserved Bits (2), +# Packet Number Length (2), +# Version (32), +# Destination Connection ID Length (8), +# Destination Connection ID (0..160), +# Source Connection ID Length (8), +# Source Connection ID (0..160), +# Token Length (i), +# Token (..), +# Length (i), +# Packet Number (8..32), +# Packet Payload (8..), +# } +# +# Figure 15: Initial Packet +# +# The Initial packet contains a long header as well as the Length and +# Packet Number fields; see Section 17.2. The first byte contains the +# Reserved and Packet Number Length bits; see also Section 17.2. +# Between the Source Connection ID and Length fields, there are two +# additional fields specific to the Initial packet. +# +# Token Length: A variable-length integer specifying the length of the +# Token field, in bytes. This value is 0 if no token is present. +# Initial packets sent by the server MUST set the Token Length field +# to 0; clients that receive an Initial packet with a non-zero Token +# Length field MUST either discard the packet or generate a +# connection error of type PROTOCOL_VIOLATION. +# +# Token: The value of the token that was previously provided in a +# Retry packet or NEW_TOKEN frame; see Section 8.1. +# +# In order to prevent tampering by version-unaware middleboxes, Initial +# packets are protected with connection- and version-specific keys +# (Initial keys) as described in [QUIC-TLS]. This protection does not +# provide confidentiality or integrity against attackers that can +# observe packets, but it does prevent attackers that cannot observe +# packets from spoofing Initial packets. +# +# The client and server use the Initial packet type for any packet that +# contains an initial cryptographic handshake message. This includes +# all cases where a new packet containing the initial cryptographic +# message needs to be created, such as the packets sent after receiving +# a Retry packet; see Section 17.2.5. +# +# A server sends its first Initial packet in response to a client +# Initial. A server MAY send multiple Initial packets. The +# cryptographic key exchange could require multiple round trips or +# retransmissions of this data. +# +# The payload of an Initial packet includes a CRYPTO frame (or frames) +# containing a cryptographic handshake message, ACK frames, or both. +# PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also +# permitted. An endpoint that receives an Initial packet containing +# other frames can either discard the packet as spurious or treat it as +# a connection error. +# +# The first packet sent by a client always includes a CRYPTO frame that +# contains the start or all of the first cryptographic handshake +# message. The first CRYPTO frame sent always begins at an offset of +# 0; see Section 7. +# +# Note that if the server sends a TLS HelloRetryRequest (see +# Section 4.7 of [QUIC-TLS]), the client will send another series of +# Initial packets. These Initial packets will continue the +# cryptographic handshake and will contain CRYPTO frames starting at an +# offset matching the size of the CRYPTO frames sent in the first +# flight of Initial packets. + +[[spec]] +level = "MUST" +quote = ''' +Initial packets sent by the server MUST set the Token Length field +to 0; clients that receive an Initial packet with a non-zero Token +Length field MUST either discard the packet or generate a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +Initial packets sent by the server MUST set the Token Length field +to 0; clients that receive an Initial packet with a non-zero Token +Length field MUST either discard the packet or generate a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY send multiple Initial packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml new file mode 100644 index 0000000000..6b5a14e21a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.3.toml @@ -0,0 +1,94 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.3" + +# 0-RTT +# +# A 0-RTT packet uses long headers with a type value of 0x01, followed +# by the Length and Packet Number fields; see Section 17.2. The first +# byte contains the Reserved and Packet Number Length bits; see +# Section 17.2. A 0-RTT packet is used to carry "early" data from the +# client to the server as part of the first flight, prior to handshake +# completion. As part of the TLS handshake, the server can accept or +# reject this early data. +# +# See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its +# limitations. +# +# 0-RTT Packet { +# Header Form (1) = 1, +# Fixed Bit (1) = 1, +# Long Packet Type (2) = 1, +# Reserved Bits (2), +# Packet Number Length (2), +# Version (32), +# Destination Connection ID Length (8), +# Destination Connection ID (0..160), +# Source Connection ID Length (8), +# Source Connection ID (0..160), +# Length (i), +# Packet Number (8..32), +# Packet Payload (8..), +# } +# +# Figure 16: 0-RTT Packet +# +# Packet numbers for 0-RTT protected packets use the same space as +# 1-RTT protected packets. +# +# After a client receives a Retry packet, 0-RTT packets are likely to +# have been lost or discarded by the server. A client SHOULD attempt +# to resend data in 0-RTT packets after it sends a new Initial packet. +# New packet numbers MUST be used for any new packets that are sent; as +# described in Section 17.2.5.3, reusing packet numbers could +# compromise packet protection. +# +# A client only receives acknowledgments for its 0-RTT packets once the +# handshake is complete, as defined in Section 4.1.1 of [QUIC-TLS]. +# +# A client MUST NOT send 0-RTT packets once it starts processing 1-RTT +# packets from the server. This means that 0-RTT packets cannot +# contain any response to frames from 1-RTT packets. For instance, a +# client cannot send an ACK frame in a 0-RTT packet, because that can +# only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT +# packet MUST be carried in a 1-RTT packet. +# +# A server SHOULD treat a violation of remembered limits +# (Section 7.4.1) as a connection error of an appropriate type (for +# instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). + +[[spec]] +level = "SHOULD" +quote = ''' +A client SHOULD attempt +to resend data in 0-RTT packets after it sends a new Initial packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +New packet numbers MUST be used for any new packets that are sent; as +described in Section 17.2.5.3, reusing packet numbers could +compromise packet protection. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT send 0-RTT packets once it starts processing 1-RTT +packets from the server. +''' + +[[spec]] +level = "MUST" +quote = ''' +An acknowledgment for a 1-RTT +packet MUST be carried in a 1-RTT packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A server SHOULD treat a violation of remembered limits +(Section 7.4.1) as a connection error of an appropriate type (for +instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.4.toml new file mode 100644 index 0000000000..1c2688a76f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.4.toml @@ -0,0 +1,66 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.4" + +# Handshake Packet +# +# A Handshake packet uses long headers with a type value of 0x02, +# followed by the Length and Packet Number fields; see Section 17.2. +# The first byte contains the Reserved and Packet Number Length bits; +# see Section 17.2. It is used to carry cryptographic handshake +# messages and acknowledgments from the server and client. +# +# Handshake Packet { +# Header Form (1) = 1, +# Fixed Bit (1) = 1, +# Long Packet Type (2) = 2, +# Reserved Bits (2), +# Packet Number Length (2), +# Version (32), +# Destination Connection ID Length (8), +# Destination Connection ID (0..160), +# Source Connection ID Length (8), +# Source Connection ID (0..160), +# Length (i), +# Packet Number (8..32), +# Packet Payload (8..), +# } +# +# Figure 17: Handshake Protected Packet +# +# Once a client has received a Handshake packet from a server, it uses +# Handshake packets to send subsequent cryptographic handshake messages +# and acknowledgments to the server. +# +# The Destination Connection ID field in a Handshake packet contains a +# connection ID that is chosen by the recipient of the packet; the +# Source Connection ID includes the connection ID that the sender of +# the packet wishes to use; see Section 7.2. +# +# Handshake packets have their own packet number space, and thus the +# first Handshake packet sent by a server contains a packet number of +# 0. +# +# The payload of this packet contains CRYPTO frames and could contain +# PING, PADDING, or ACK frames. Handshake packets MAY contain +# CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt +# of Handshake packets with other frames as a connection error of type +# PROTOCOL_VIOLATION. +# +# Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames +# for Handshake packets is discarded -- and no longer retransmitted -- +# when Handshake protection keys are discarded. + +[[spec]] +level = "MAY" +quote = ''' +Handshake packets MAY contain +CONNECTION_CLOSE frames of type 0x1c. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST treat receipt +of Handshake packets with other frames as a connection error of type +PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml new file mode 100644 index 0000000000..8c605fb96c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.1.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5.1" + +# Sending a Retry Packet +# +# The server populates the Destination Connection ID with the +# connection ID that the client included in the Source Connection ID of +# the Initial packet. +# +# The server includes a connection ID of its choice in the Source +# Connection ID field. This value MUST NOT be equal to the Destination +# Connection ID field of the packet sent by the client. A client MUST +# discard a Retry packet that contains a Source Connection ID field +# that is identical to the Destination Connection ID field of its +# Initial packet. The client MUST use the value from the Source +# Connection ID field of the Retry packet in the Destination Connection +# ID field of subsequent packets that it sends. +# +# A server MAY send Retry packets in response to Initial and 0-RTT +# packets. A server can either discard or buffer 0-RTT packets that it +# receives. A server can send multiple Retry packets as it receives +# Initial or 0-RTT packets. A server MUST NOT send more than one Retry +# packet in response to a single UDP datagram. + +[[spec]] +level = "MUST" +quote = ''' +This value MUST NOT be equal to the Destination +Connection ID field of the packet sent by the client. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST +discard a Retry packet that contains a Source Connection ID field +that is identical to the Destination Connection ID field of its +Initial packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +The client MUST use the value from the Source +Connection ID field of the Retry packet in the Destination Connection +ID field of subsequent packets that it sends. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY send Retry packets in response to Initial and 0-RTT +packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST NOT send more than one Retry +packet in response to a single UDP datagram. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml new file mode 100644 index 0000000000..a618f34099 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.2.toml @@ -0,0 +1,69 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5.2" + +# Handling a Retry Packet +# +# A client MUST accept and process at most one Retry packet for each +# connection attempt. After the client has received and processed an +# Initial or Retry packet from the server, it MUST discard any +# subsequent Retry packets that it receives. +# +# Clients MUST discard Retry packets that have a Retry Integrity Tag +# that cannot be validated; see Section 5.8 of [QUIC-TLS]. This +# diminishes an attacker's ability to inject a Retry packet and +# protects against accidental corruption of Retry packets. A client +# MUST discard a Retry packet with a zero-length Retry Token field. +# +# The client responds to a Retry packet with an Initial packet that +# includes the provided Retry token to continue connection +# establishment. +# +# A client sets the Destination Connection ID field of this Initial +# packet to the value from the Source Connection ID field in the Retry +# packet. Changing the Destination Connection ID field also results in +# a change to the keys used to protect the Initial packet. It also +# sets the Token field to the token provided in the Retry packet. The +# client MUST NOT change the Source Connection ID because the server +# could include the connection ID as part of its token validation +# logic; see Section 8.1.4. +# +# A Retry packet does not include a packet number and cannot be +# explicitly acknowledged by a client. + +[[spec]] +level = "MUST" +quote = ''' +A client MUST accept and process at most one Retry packet for each +connection attempt. +''' + +[[spec]] +level = "MUST" +quote = ''' +After the client has received and processed an +Initial or Retry packet from the server, it MUST discard any +subsequent Retry packets that it receives. +''' + +[[spec]] +level = "MUST" +quote = ''' +Clients MUST discard Retry packets that have a Retry Integrity Tag +that cannot be validated; see Section 5.8 of [QUIC-TLS]. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client +MUST discard a Retry packet with a zero-length Retry Token field. +''' + +[[spec]] +level = "MUST" +quote = ''' +The +client MUST NOT change the Source Connection ID because the server +could include the connection ID as part of its token validation +logic; see Section 8.1.4. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml new file mode 100644 index 0000000000..cdac4f0692 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.3.toml @@ -0,0 +1,77 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5.3" + +# Continuing a Handshake after Retry +# +# Subsequent Initial packets from the client include the connection ID +# and token values from the Retry packet. The client copies the Source +# Connection ID field from the Retry packet to the Destination +# Connection ID field and uses this value until an Initial packet with +# an updated value is received; see Section 7.2. The value of the +# Token field is copied to all subsequent Initial packets; see +# Section 8.1.2. +# +# Other than updating the Destination Connection ID and Token fields, +# the Initial packet sent by the client is subject to the same +# restrictions as the first Initial packet. A client MUST use the same +# cryptographic handshake message it included in this packet. A server +# MAY treat a packet that contains a different cryptographic handshake +# message as a connection error or discard it. Note that including a +# Token field reduces the available space for the cryptographic +# handshake message, which might result in the client needing to send +# multiple Initial packets. +# +# A client MAY attempt 0-RTT after receiving a Retry packet by sending +# 0-RTT packets to the connection ID provided by the server. +# +# A client MUST NOT reset the packet number for any packet number space +# after processing a Retry packet. In particular, 0-RTT packets +# contain confidential information that will most likely be +# retransmitted on receiving a Retry packet. The keys used to protect +# these new 0-RTT packets will not change as a result of responding to +# a Retry packet. However, the data sent in these packets could be +# different than what was sent earlier. Sending these new packets with +# the same packet number is likely to compromise the packet protection +# for those packets because the same key and nonce could be used to +# protect different content. A server MAY abort the connection if it +# detects that the client reset the packet number. +# +# The connection IDs used in Initial and Retry packets exchanged +# between client and server are copied to the transport parameters and +# validated as described in Section 7.3. + +[[spec]] +level = "MUST" +quote = ''' +A client MUST use the same +cryptographic handshake message it included in this packet. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server +MAY treat a packet that contains a different cryptographic handshake +message as a connection error or discard it. +''' + +[[spec]] +level = "MAY" +quote = ''' +A client MAY attempt 0-RTT after receiving a Retry packet by sending +0-RTT packets to the connection ID provided by the server. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT reset the packet number for any packet number space +after processing a Retry packet. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY abort the connection if it +detects that the client reset the packet number. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.toml new file mode 100644 index 0000000000..edceced518 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.5.toml @@ -0,0 +1,44 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5" + +# Retry Packet +# +# As shown in Figure 18, a Retry packet uses a long packet header with +# a type value of 0x03. It carries an address validation token created +# by the server. It is used by a server that wishes to perform a +# retry; see Section 8.1. +# +# Retry Packet { +# Header Form (1) = 1, +# Fixed Bit (1) = 1, +# Long Packet Type (2) = 3, +# Unused (4), +# Version (32), +# Destination Connection ID Length (8), +# Destination Connection ID (0..160), +# Source Connection ID Length (8), +# Source Connection ID (0..160), +# Retry Token (..), +# Retry Integrity Tag (128), +# } +# +# Figure 18: Retry Packet +# +# A Retry packet does not contain any protected fields. The value in +# the Unused field is set to an arbitrary value by the server; a client +# MUST ignore these bits. In addition to the fields from the long +# header, it contains these additional fields: +# +# Retry Token: An opaque token that the server can use to validate the +# client's address. +# +# Retry Integrity Tag: Defined in Section 5.8 ("Retry Packet +# Integrity") of [QUIC-TLS]. + +[[spec]] +level = "MUST" +quote = ''' +The value in +the Unused field is set to an arbitrary value by the server; a client +MUST ignore these bits. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml new file mode 100644 index 0000000000..6aa7bdb957 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.2.toml @@ -0,0 +1,204 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2" + +# Long Header Packets +# +# Long Header Packet { +# Header Form (1) = 1, +# Fixed Bit (1) = 1, +# Long Packet Type (2), +# Type-Specific Bits (4), +# Version (32), +# Destination Connection ID Length (8), +# Destination Connection ID (0..160), +# Source Connection ID Length (8), +# Source Connection ID (0..160), +# Type-Specific Payload (..), +# } +# +# Figure 13: Long Header Packet Format +# +# Long headers are used for packets that are sent prior to the +# establishment of 1-RTT keys. Once 1-RTT keys are available, a sender +# switches to sending packets using the short header (Section 17.3). +# The long form allows for special packets -- such as the Version +# Negotiation packet -- to be represented in this uniform fixed-length +# packet format. Packets that use the long header contain the +# following fields: +# +# Header Form: 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, unless the +# packet is a Version Negotiation packet. Packets containing a zero +# value for this bit are not valid packets in this version and MUST +# be discarded. A value of 1 for this bit allows QUIC to coexist +# with other protocols; see [RFC7983]. +# +# Long Packet Type: The next two bits (those with a mask of 0x30) of +# byte 0 contain a packet type. Packet types are listed in Table 5. +# +# Type-Specific Bits: The semantics of the lower four bits (those with +# a mask of 0x0f) of byte 0 are determined by the packet type. +# +# Version: The QUIC Version is a 32-bit field that follows the first +# byte. This field indicates the version of QUIC that is in use and +# determines how the rest of the protocol fields are interpreted. +# +# 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. In QUIC version 1, this value MUST NOT exceed +# 20 bytes. Endpoints that receive a version 1 long header with a +# value larger than 20 MUST drop the packet. In order to properly +# form a Version Negotiation packet, servers SHOULD be able to read +# longer connection IDs from other QUIC versions. +# +# Destination Connection ID: The Destination Connection ID field +# follows the Destination Connection ID Length field, which +# indicates the length of this field. Section 7.2 describes the use +# of this field in more detail. +# +# 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. In QUIC version 1, this value MUST NOT +# exceed 20 bytes. Endpoints that receive a version 1 long header +# with a value larger than 20 MUST drop the packet. In order to +# properly form a Version Negotiation packet, servers SHOULD be able +# to read longer connection IDs from other QUIC versions. +# +# Source Connection ID: The Source Connection ID field follows the +# Source Connection ID Length field, which indicates the length of +# this field. Section 7.2 describes the use of this field in more +# detail. +# +# Type-Specific Payload: The remainder of the packet, if any, is type +# specific. +# +# In this version of QUIC, the following packet types with the long +# header are defined: +# +# +======+===========+================+ +# | Type | Name | Section | +# +======+===========+================+ +# | 0x00 | Initial | Section 17.2.2 | +# +------+-----------+----------------+ +# | 0x01 | 0-RTT | Section 17.2.3 | +# +------+-----------+----------------+ +# | 0x02 | Handshake | Section 17.2.4 | +# +------+-----------+----------------+ +# | 0x03 | Retry | Section 17.2.5 | +# +------+-----------+----------------+ +# +# Table 5: Long Header Packet Types +# +# The header form bit, Destination and Source Connection ID lengths, +# Destination and Source Connection ID fields, and Version fields of a +# long header packet are version independent. The other fields in the +# first byte are version specific. See [QUIC-INVARIANTS] for details +# on how packets from different versions of QUIC are interpreted. +# +# The interpretation of the fields and the payload are specific to a +# version and packet type. While type-specific semantics for this +# version are described in the following sections, several long header +# packets in this version of QUIC contain these additional fields: +# +# Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are +# reserved across multiple packet types. These bits are protected +# using header protection; see Section 5.4 of [QUIC-TLS]. The value +# included prior to protection MUST be set to 0. An endpoint MUST +# treat receipt of a packet that has a non-zero value for these bits +# after removing both packet and header protection as a connection +# error of type PROTOCOL_VIOLATION. Discarding such a packet after +# only removing header protection can expose the endpoint to +# attacks; see Section 9.5 of [QUIC-TLS]. +# +# Packet Number Length: In packet types that contain a Packet Number +# field, the least significant two bits (those with a mask of 0x03) +# of byte 0 contain the length of the Packet Number field, encoded +# as an unsigned two-bit integer that is one less than the length of +# the Packet Number field in bytes. That is, the length of the +# Packet Number field is the value of this field plus one. These +# bits are protected using header protection; see Section 5.4 of +# [QUIC-TLS]. +# +# Length: This is the length of the remainder of the packet (that is, +# the Packet Number and Payload fields) in bytes, encoded as a +# variable-length integer (Section 16). +# +# Packet Number: This field is 1 to 4 bytes long. The packet number +# is protected using header protection; see Section 5.4 of +# [QUIC-TLS]. The length of the Packet Number field is encoded in +# the Packet Number Length bits of byte 0; see above. +# +# Packet Payload: This is the payload of the packet -- containing a +# sequence of frames -- that is protected using packet protection. + +[[spec]] +level = "MUST" +quote = ''' +Packets containing a zero +value for this bit are not valid packets in this version and MUST +be discarded. +''' + +[[spec]] +level = "MUST" +quote = ''' +In QUIC version 1, this value MUST NOT exceed +20 bytes. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints that receive a version 1 long header with a +value larger than 20 MUST drop the packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In order to properly +form a Version Negotiation packet, servers SHOULD be able to read +longer connection IDs from other QUIC versions. +''' + +[[spec]] +level = "MUST" +quote = ''' +In QUIC version 1, this value MUST NOT +exceed 20 bytes. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints that receive a version 1 long header +with a value larger than 20 MUST drop the packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In order to +properly form a Version Negotiation packet, servers SHOULD be able +to read longer connection IDs from other QUIC versions. +''' + +[[spec]] +level = "MUST" +quote = ''' +The value +included prior to protection MUST be set to 0. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST +treat receipt of a packet that has a non-zero value for these bits +after removing both packet and header protection as a connection +error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml new file mode 100644 index 0000000000..10436611b5 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.3.1.toml @@ -0,0 +1,101 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.3.1" + +# 1-RTT Packet +# +# A 1-RTT packet uses a short packet header. It is used after the +# version and 1-RTT keys are negotiated. +# +# 1-RTT Packet { +# Header Form (1) = 0, +# Fixed Bit (1) = 1, +# Spin Bit (1), +# Reserved Bits (2), +# Key Phase (1), +# Packet Number Length (2), +# Destination Connection ID (0..160), +# Packet Number (8..32), +# Packet Payload (8..), +# } +# +# Figure 19: 1-RTT Packet +# +# 1-RTT packets contain the following fields: +# +# Header Form: The most significant bit (0x80) of byte 0 is set to 0 +# for the short header. +# +# Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets +# containing a zero value for this bit are not valid packets in this +# version and MUST be discarded. A value of 1 for this bit allows +# QUIC to coexist with other protocols; see [RFC7983]. +# +# Spin Bit: The third most significant bit (0x20) of byte 0 is the +# latency spin bit, set as described in Section 17.4. +# +# Reserved Bits: The next two bits (those with a mask of 0x18) of byte +# 0 are reserved. These bits are protected using header protection; +# see Section 5.4 of [QUIC-TLS]. The value included prior to +# protection MUST be set to 0. An endpoint MUST treat receipt of a +# packet that has a non-zero value for these bits, after removing +# both packet and header protection, as a connection error of type +# PROTOCOL_VIOLATION. Discarding such a packet after only removing +# header protection can expose the endpoint to attacks; see +# Section 9.5 of [QUIC-TLS]. +# +# Key Phase: The next bit (0x04) of byte 0 indicates the key phase, +# which allows a recipient of a packet to identify the packet +# protection keys that are used to protect the packet. See +# [QUIC-TLS] for details. This bit is protected using header +# protection; see Section 5.4 of [QUIC-TLS]. +# +# Packet Number Length: The least significant two bits (those with a +# mask of 0x03) of byte 0 contain the length of the Packet Number +# field, encoded as an unsigned two-bit integer that is one less +# than the length of the Packet Number field in bytes. That is, the +# length of the Packet Number field is the value of this field plus +# one. These bits are protected using header protection; see +# Section 5.4 of [QUIC-TLS]. +# +# Destination Connection ID: The Destination Connection ID is a +# connection ID that is chosen by the intended recipient of the +# packet. See Section 5.1 for more details. +# +# Packet Number: The Packet Number field is 1 to 4 bytes long. The +# packet number is protected using header protection; see +# Section 5.4 of [QUIC-TLS]. The length of the Packet Number field +# is encoded in Packet Number Length field. See Section 17.1 for +# details. +# +# Packet Payload: 1-RTT packets always include a 1-RTT protected +# payload. +# +# The header form bit and the Destination Connection ID field of a +# short header packet are version independent. The remaining fields +# are specific to the selected QUIC version. See [QUIC-INVARIANTS] for +# details on how packets from different versions of QUIC are +# interpreted. + +[[spec]] +level = "MUST" +quote = ''' +Packets +containing a zero value for this bit are not valid packets in this +version and MUST be discarded. +''' + +[[spec]] +level = "MUST" +quote = ''' +The value included prior to +protection MUST be set to 0. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat receipt of a +packet that has a non-zero value for these bits, after removing +both packet and header protection, as a connection error of type +PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml new file mode 100644 index 0000000000..a04acb530b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-17.4.toml @@ -0,0 +1,110 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.4" + +# Latency Spin Bit +# +# The latency spin bit, which is defined for 1-RTT packets +# (Section 17.3.1), enables passive latency monitoring from observation +# points on the network path throughout the duration of a connection. +# The server reflects the spin value received, while the client "spins" +# it after one RTT. On-path observers can measure the time between two +# spin bit toggle events to estimate the end-to-end RTT of a +# connection. +# +# The spin bit is only present in 1-RTT packets, since it is possible +# to measure the initial RTT of a connection by observing the +# handshake. Therefore, the spin bit is available after version +# negotiation and connection establishment are completed. On-path +# measurement and use of the latency spin bit are further discussed in +# [QUIC-MANAGEABILITY]. +# +# The spin bit is an OPTIONAL feature of this version of QUIC. An +# endpoint that does not support this feature MUST disable it, as +# defined below. +# +# Each endpoint unilaterally decides if the spin bit is enabled or +# disabled for a connection. Implementations MUST allow administrators +# of clients and servers to disable the spin bit either globally or on +# a per-connection basis. Even when the spin bit is not disabled by +# the administrator, endpoints MUST disable their use of the spin bit +# for a random selection of at least one in every 16 network paths, or +# for one in every 16 connection IDs, in order to ensure that QUIC +# connections that disable the spin bit are commonly observed on the +# network. As each endpoint disables the spin bit independently, this +# ensures that the spin bit signal is disabled on approximately one in +# eight network paths. +# +# When the spin bit is disabled, endpoints MAY set the spin bit to any +# value and MUST ignore any incoming value. It is RECOMMENDED that +# endpoints set the spin bit to a random value either chosen +# independently for each packet or chosen independently for each +# connection ID. +# +# If the spin bit is enabled for the connection, the endpoint maintains +# a spin value for each network path and sets the spin bit in the +# packet header to the currently stored value when a 1-RTT packet is +# sent on that path. The spin value is initialized to 0 in the +# endpoint for each network path. Each endpoint also remembers the +# highest packet number seen from its peer on each path. +# +# When a server receives a 1-RTT packet that increases the highest +# packet number seen by the server from the client on a given network +# path, it sets the spin value for that path to be equal to the spin +# bit in the received packet. +# +# When a client receives a 1-RTT packet that increases the highest +# packet number seen by the client from the server on a given network +# path, it sets the spin value for that path to the inverse of the spin +# bit in the received packet. +# +# An endpoint resets the spin value for a network path to 0 when +# changing the connection ID being used on that network path. + +[[spec]] +level = "MAY" +quote = ''' +The spin bit is an OPTIONAL feature of this version of QUIC. +''' + +[[spec]] +level = "MUST" +quote = ''' +An +endpoint that does not support this feature MUST disable it, as +defined below. +''' + +[[spec]] +level = "MUST" +quote = ''' +Implementations MUST allow administrators +of clients and servers to disable the spin bit either globally or on +a per-connection basis. +''' + +[[spec]] +level = "MUST" +quote = ''' +Even when the spin bit is not disabled by +the administrator, endpoints MUST disable their use of the spin bit +for a random selection of at least one in every 16 network paths, or +for one in every 16 connection IDs, in order to ensure that QUIC +connections that disable the spin bit are commonly observed on the +network. +''' + +[[spec]] +level = "MUST" +quote = ''' +When the spin bit is disabled, endpoints MAY set the spin bit to any +value and MUST ignore any incoming value. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +It is RECOMMENDED that +endpoints set the spin bit to a random value either chosen +independently for each packet or chosen independently for each +connection ID. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml new file mode 100644 index 0000000000..7b23860a87 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-18.2.toml @@ -0,0 +1,291 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-18.2" + +# Transport Parameter Definitions +# +# This section details the transport parameters defined in this +# document. +# +# Many transport parameters listed here have integer values. Those +# transport parameters that are identified as integers use a variable- +# length integer encoding; see Section 16. Transport parameters have a +# default value of 0 if the transport parameter is absent, unless +# otherwise stated. +# +# The following transport parameters are defined: +# +# original_destination_connection_id (0x00): This parameter is the +# value of the Destination Connection ID field from the first +# Initial packet sent by the client; see Section 7.3. This +# transport parameter is only sent by a server. +# +# max_idle_timeout (0x01): The maximum idle timeout is a value in +# milliseconds that is encoded as an integer; see (Section 10.1). +# Idle timeout is disabled when both endpoints omit this transport +# parameter or specify a value of 0. +# +# stateless_reset_token (0x02): A stateless reset token is used in +# verifying a stateless reset; see Section 10.3. This parameter is +# a sequence of 16 bytes. This transport parameter MUST NOT be sent +# by a client but MAY be sent by a server. A server that does not +# send this transport parameter cannot use stateless reset +# (Section 10.3) for the connection ID negotiated during the +# handshake. +# +# max_udp_payload_size (0x03): The maximum UDP payload size parameter +# is an integer value that limits the size of UDP payloads that the +# endpoint is willing to receive. UDP datagrams with payloads +# larger than this limit are not likely to be processed by the +# receiver. +# +# The default for this parameter is the maximum permitted UDP +# payload of 65527. Values below 1200 are invalid. +# +# This limit does act as an additional constraint on datagram size +# in the same way as the path MTU, but it is a property of the +# endpoint and not the path; see Section 14. It is expected that +# this is the space an endpoint dedicates to holding incoming +# packets. +# +# initial_max_data (0x04): The initial maximum data parameter is an +# integer value that contains the initial value for the maximum +# amount of data that can be sent on the connection. This is +# equivalent to sending a MAX_DATA (Section 19.9) for the connection +# immediately after completing the handshake. +# +# initial_max_stream_data_bidi_local (0x05): This parameter is an +# integer value specifying the initial flow control limit for +# locally initiated bidirectional streams. This limit applies to +# newly created bidirectional streams opened by the endpoint that +# sends the transport parameter. In client transport parameters, +# this applies to streams with an identifier with the least +# significant two bits set to 0x00; in server transport parameters, +# this applies to streams with the least significant two bits set to +# 0x01. +# +# initial_max_stream_data_bidi_remote (0x06): This parameter is an +# integer value specifying the initial flow control limit for peer- +# initiated bidirectional streams. This limit applies to newly +# created bidirectional streams opened by the endpoint that receives +# the transport parameter. In client transport parameters, this +# applies to streams with an identifier with the least significant +# two bits set to 0x01; in server transport parameters, this applies +# to streams with the least significant two bits set to 0x00. +# +# initial_max_stream_data_uni (0x07): This parameter is an integer +# value specifying the initial flow control limit for unidirectional +# streams. This limit applies to newly created unidirectional +# streams opened by the endpoint that receives the transport +# parameter. In client transport parameters, this applies to +# streams with an identifier with the least significant two bits set +# to 0x03; in server transport parameters, this applies to streams +# with the least significant two bits set to 0x02. +# +# initial_max_streams_bidi (0x08): The initial maximum bidirectional +# streams parameter is an integer value that contains the initial +# maximum number of bidirectional streams the endpoint that receives +# this transport parameter is permitted to initiate. If this +# parameter is absent or zero, the peer cannot open bidirectional +# streams until a MAX_STREAMS frame is sent. Setting this parameter +# is equivalent to sending a MAX_STREAMS (Section 19.11) of the +# corresponding type with the same value. +# +# initial_max_streams_uni (0x09): The initial maximum unidirectional +# streams parameter is an integer value that contains the initial +# maximum number of unidirectional streams the endpoint that +# receives this transport parameter is permitted to initiate. If +# this parameter is absent or zero, the peer cannot open +# unidirectional streams until a MAX_STREAMS frame is sent. Setting +# this parameter is equivalent to sending a MAX_STREAMS +# (Section 19.11) of the corresponding type with the same value. +# +# ack_delay_exponent (0x0a): The acknowledgment delay exponent is an +# integer value indicating an exponent used to decode the ACK Delay +# field in the ACK frame (Section 19.3). If this value is absent, a +# default value of 3 is assumed (indicating a multiplier of 8). +# Values above 20 are invalid. +# +# max_ack_delay (0x0b): The maximum acknowledgment delay is an integer +# value indicating the maximum amount of time in milliseconds by +# which the endpoint will delay sending acknowledgments. This value +# SHOULD include the receiver's expected delays in alarms firing. +# For example, if a receiver sets a timer for 5ms and alarms +# commonly fire up to 1ms late, then it should send a max_ack_delay +# of 6ms. If this value is absent, a default of 25 milliseconds is +# assumed. Values of 2^14 or greater are invalid. +# +# disable_active_migration (0x0c): The disable active migration +# transport parameter is included if the endpoint does not support +# active connection migration (Section 9) on the address being used +# during the handshake. An endpoint that receives this transport +# parameter MUST NOT use a new local address when sending to the +# address that the peer used during the handshake. This transport +# parameter does not prohibit connection migration after a client +# has acted on a preferred_address transport parameter. This +# parameter is a zero-length value. +# +# preferred_address (0x0d): The server's preferred address is used to +# effect a change in server address at the end of the handshake, as +# described in Section 9.6. This transport parameter is only sent +# by a server. Servers MAY choose to only send a preferred address +# of one address family by sending an all-zero address and port +# (0.0.0.0:0 or [::]:0) for the other family. IP addresses are +# encoded in network byte order. +# +# The preferred_address transport parameter contains an address and +# port for both IPv4 and IPv6. The four-byte IPv4 Address field is +# followed by the associated two-byte IPv4 Port field. This is +# followed by a 16-byte IPv6 Address field and two-byte IPv6 Port +# field. After address and port pairs, a Connection ID Length field +# describes the length of the following Connection ID field. +# Finally, a 16-byte Stateless Reset Token field includes the +# stateless reset token associated with the connection ID. The +# format of this transport parameter is shown in Figure 22 below. +# +# The Connection ID field and the Stateless Reset Token field +# contain an alternative connection ID that has a sequence number of +# 1; see Section 5.1.1. Having these values sent alongside the +# preferred address ensures that there will be at least one unused +# active connection ID when the client initiates migration to the +# preferred address. +# +# The Connection ID and Stateless Reset Token fields of a preferred +# address are identical in syntax and semantics to the corresponding +# fields of a NEW_CONNECTION_ID frame (Section 19.15). A server +# that chooses a zero-length connection ID MUST NOT provide a +# preferred address. Similarly, a server MUST NOT include a zero- +# length connection ID in this transport parameter. A client MUST +# treat a violation of these requirements as a connection error of +# type TRANSPORT_PARAMETER_ERROR. +# +# Preferred Address { +# IPv4 Address (32), +# IPv4 Port (16), +# IPv6 Address (128), +# IPv6 Port (16), +# Connection ID Length (8), +# Connection ID (..), +# Stateless Reset Token (128), +# } +# +# Figure 22: Preferred Address Format +# +# active_connection_id_limit (0x0e): This is an integer value +# specifying the maximum number of connection IDs from the peer that +# an endpoint is willing to store. This value includes the +# connection ID received during the handshake, that received in the +# preferred_address transport parameter, and those received in +# NEW_CONNECTION_ID frames. The value of the +# active_connection_id_limit parameter MUST be at least 2. An +# endpoint that receives a value less than 2 MUST close the +# connection with an error of type TRANSPORT_PARAMETER_ERROR. If +# this transport parameter is absent, a default of 2 is assumed. If +# an endpoint issues a zero-length connection ID, it will never send +# a NEW_CONNECTION_ID frame and therefore ignores the +# active_connection_id_limit value received from its peer. +# +# initial_source_connection_id (0x0f): This is the value that the +# endpoint included in the Source Connection ID field of the first +# Initial packet it sends for the connection; see Section 7.3. +# +# retry_source_connection_id (0x10): This is the value that the server +# included in the Source Connection ID field of a Retry packet; see +# Section 7.3. This transport parameter is only sent by a server. +# +# If present, transport parameters that set initial per-stream flow +# control limits (initial_max_stream_data_bidi_local, +# initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) +# are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on +# every stream of the corresponding type immediately after opening. If +# the transport parameter is absent, streams of that type start with a +# flow control limit of 0. +# +# A client MUST NOT include any server-only transport parameter: +# original_destination_connection_id, preferred_address, +# retry_source_connection_id, or stateless_reset_token. A server MUST +# treat receipt of any of these transport parameters as a connection +# error of type TRANSPORT_PARAMETER_ERROR. + +[[spec]] +level = "MUST" +quote = ''' +This transport parameter MUST NOT be sent +by a client but MAY be sent by a server. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +This value +SHOULD include the receiver's expected delays in alarms firing. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that receives this transport +parameter MUST NOT use a new local address when sending to the +address that the peer used during the handshake. +''' + +[[spec]] +level = "MAY" +quote = ''' +Servers MAY choose to only send a preferred address +of one address family by sending an all-zero address and port +(0.0.0.0:0 or [::]:0) for the other family. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server +that chooses a zero-length connection ID MUST NOT provide a +preferred address. +''' + +[[spec]] +level = "MUST" +quote = ''' +Similarly, a server MUST NOT include a zero- +length connection ID in this transport parameter. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST +treat a violation of these requirements as a connection error of +type TRANSPORT_PARAMETER_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +The value of the +active_connection_id_limit parameter MUST be at least 2. +''' + +[[spec]] +level = "MUST" +quote = ''' +An +endpoint that receives a value less than 2 MUST close the +connection with an error of type TRANSPORT_PARAMETER_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT include any server-only transport parameter: +original_destination_connection_id, preferred_address, +retry_source_connection_id, or stateless_reset_token. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST +treat receipt of any of these transport parameters as a connection +error of type TRANSPORT_PARAMETER_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml new file mode 100644 index 0000000000..a7600ed46b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.10.toml @@ -0,0 +1,79 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.10" + +# MAX_STREAM_DATA Frames +# +# A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform +# a peer of the maximum amount of data that can be sent on a stream. +# +# A MAX_STREAM_DATA frame can be sent for streams in the "Recv" state; +# see Section 3.2. Receiving a MAX_STREAM_DATA frame for a locally +# initiated stream that has not yet been created MUST be treated as a +# connection error of type STREAM_STATE_ERROR. An endpoint that +# receives a MAX_STREAM_DATA frame for a receive-only stream MUST +# terminate the connection with error STREAM_STATE_ERROR. +# +# MAX_STREAM_DATA frames are formatted as shown in Figure 34. +# +# MAX_STREAM_DATA Frame { +# Type (i) = 0x11, +# Stream ID (i), +# Maximum Stream Data (i), +# } +# +# Figure 34: MAX_STREAM_DATA Frame Format +# +# MAX_STREAM_DATA frames contain the following fields: +# +# Stream ID: The stream ID of the affected stream, encoded as a +# variable-length integer. +# +# Maximum Stream Data: A variable-length integer indicating the +# maximum amount of data that can be sent on the identified stream, +# in units of bytes. +# +# When counting data toward this limit, an endpoint accounts for the +# largest received offset of data that is sent or received on the +# stream. Loss or reordering can mean that the largest received offset +# on a stream can be greater than the total size of data received on +# that stream. Receiving STREAM frames might not increase the largest +# received offset. +# +# The data sent on a stream MUST NOT exceed the largest maximum stream +# data value advertised by the receiver. An endpoint MUST terminate a +# connection with an error of type FLOW_CONTROL_ERROR if it receives +# more data than the largest maximum stream data that it has sent for +# the affected stream. This includes violations of remembered limits +# in Early Data; see Section 7.4.1. + +[[spec]] +level = "MUST" +quote = ''' +Receiving a MAX_STREAM_DATA frame for a locally +initiated stream that has not yet been created MUST be treated as a +connection error of type STREAM_STATE_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that +receives a MAX_STREAM_DATA frame for a receive-only stream MUST +terminate the connection with error STREAM_STATE_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +The data sent on a stream MUST NOT exceed the largest maximum stream +data value advertised by the receiver. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST terminate a +connection with an error of type FLOW_CONTROL_ERROR if it receives +more data than the largest maximum stream data that it has sent for +the affected stream. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml new file mode 100644 index 0000000000..e534bf9149 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.11.toml @@ -0,0 +1,76 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.11" + +# MAX_STREAMS Frames +# +# A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the +# cumulative number of streams of a given type it is permitted to open. +# A MAX_STREAMS frame with a type of 0x12 applies to bidirectional +# streams, and a MAX_STREAMS frame with a type of 0x13 applies to +# unidirectional streams. +# +# MAX_STREAMS frames are formatted as shown in Figure 35. +# +# MAX_STREAMS Frame { +# Type (i) = 0x12..0x13, +# Maximum Streams (i), +# } +# +# Figure 35: MAX_STREAMS Frame Format +# +# MAX_STREAMS frames contain the following field: +# +# Maximum Streams: A count of the cumulative number of streams of the +# corresponding type that can be opened over the lifetime of the +# connection. This value cannot exceed 2^60, as it is not possible +# to encode stream IDs larger than 2^62-1. Receipt of a frame that +# permits opening of a stream larger than this limit MUST be treated +# as a connection error of type FRAME_ENCODING_ERROR. +# +# Loss or reordering can cause an endpoint to receive a MAX_STREAMS +# frame with a lower stream limit than was previously received. +# MAX_STREAMS frames that do not increase the stream limit MUST be +# ignored. +# +# An endpoint MUST NOT open more streams than permitted by the current +# stream limit set by its peer. For instance, a server that receives a +# unidirectional stream limit of 3 is permitted to open streams 3, 7, +# and 11, but not stream 15. An endpoint MUST terminate a connection +# with an error of type STREAM_LIMIT_ERROR if a peer opens more streams +# than was permitted. This includes violations of remembered limits in +# Early Data; see Section 7.4.1. +# +# Note that these frames (and the corresponding transport parameters) +# do not describe the number of streams that can be opened +# concurrently. The limit includes streams that have been closed as +# well as those that are open. + +[[spec]] +level = "MUST" +quote = ''' +Receipt of a frame that +permits opening of a stream larger than this limit MUST be treated +as a connection error of type FRAME_ENCODING_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +MAX_STREAMS frames that do not increase the stream limit MUST be +ignored. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT open more streams than permitted by the current +stream limit set by its peer. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST terminate a connection +with an error of type STREAM_LIMIT_ERROR if a peer opens more streams +than was permitted. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.12.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.12.toml new file mode 100644 index 0000000000..f49476518d --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.12.toml @@ -0,0 +1,31 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.12" + +# DATA_BLOCKED Frames +# +# A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes +# to send data but is unable to do so due to connection-level flow +# control; see Section 4. DATA_BLOCKED frames can be used as input to +# tuning of flow control algorithms; see Section 4.2. +# +# DATA_BLOCKED frames are formatted as shown in Figure 36. +# +# DATA_BLOCKED Frame { +# Type (i) = 0x14, +# Maximum Data (i), +# } +# +# Figure 36: DATA_BLOCKED Frame Format +# +# DATA_BLOCKED frames contain the following field: +# +# Maximum Data: A variable-length integer indicating the connection- +# level limit at which blocking occurred. + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes +to send data but is unable to do so due to connection-level flow +control; see Section 4. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.13.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.13.toml new file mode 100644 index 0000000000..38cd88e9f4 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.13.toml @@ -0,0 +1,44 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.13" + +# STREAM_DATA_BLOCKED Frames +# +# A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it +# wishes to send data but is unable to do so due to stream-level flow +# control. This frame is analogous to DATA_BLOCKED (Section 19.12). +# +# An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only +# stream MUST terminate the connection with error STREAM_STATE_ERROR. +# +# STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37. +# +# STREAM_DATA_BLOCKED Frame { +# Type (i) = 0x15, +# Stream ID (i), +# Maximum Stream Data (i), +# } +# +# Figure 37: STREAM_DATA_BLOCKED Frame Format +# +# STREAM_DATA_BLOCKED frames contain the following fields: +# +# Stream ID: A variable-length integer indicating the stream that is +# blocked due to flow control. +# +# Maximum Stream Data: A variable-length integer indicating the offset +# of the stream at which the blocking occurred. + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it +wishes to send data but is unable to do so due to stream-level flow +control. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only +stream MUST terminate the connection with error STREAM_STATE_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.14.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.14.toml new file mode 100644 index 0000000000..5392cf7c5f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.14.toml @@ -0,0 +1,49 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.14" + +# STREAMS_BLOCKED Frames +# +# A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when +# it wishes to open a stream but is unable to do so due to the maximum +# stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED +# frame of type 0x16 is used to indicate reaching the bidirectional +# stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to +# indicate reaching the unidirectional stream limit. +# +# A STREAMS_BLOCKED frame does not open the stream, but informs the +# peer that a new stream was needed and the stream limit prevented the +# creation of the stream. +# +# STREAMS_BLOCKED frames are formatted as shown in Figure 38. +# +# STREAMS_BLOCKED Frame { +# Type (i) = 0x16..0x17, +# Maximum Streams (i), +# } +# +# Figure 38: STREAMS_BLOCKED Frame Format +# +# STREAMS_BLOCKED frames contain the following field: +# +# Maximum Streams: A variable-length integer indicating the maximum +# number of streams allowed at the time the frame was sent. This +# value cannot exceed 2^60, as it is not possible to encode stream +# IDs larger than 2^62-1. Receipt of a frame that encodes a larger +# stream ID MUST be treated as a connection error of type +# STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR. + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when +it wishes to open a stream but is unable to do so due to the maximum +stream limit set by its peer; see Section 19.11. +''' + +[[spec]] +level = "MUST" +quote = ''' +Receipt of a frame that encodes a larger +stream ID MUST be treated as a connection error of type +STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml new file mode 100644 index 0000000000..bf9cf2f98f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.15.toml @@ -0,0 +1,157 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.15" + +# NEW_CONNECTION_ID Frames +# +# An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide +# its peer with alternative connection IDs that can be used to break +# linkability when migrating connections; see Section 9.5. +# +# NEW_CONNECTION_ID frames are formatted as shown in Figure 39. +# +# NEW_CONNECTION_ID Frame { +# Type (i) = 0x18, +# Sequence Number (i), +# Retire Prior To (i), +# Length (8), +# Connection ID (8..160), +# Stateless Reset Token (128), +# } +# +# Figure 39: NEW_CONNECTION_ID Frame Format +# +# NEW_CONNECTION_ID frames contain the following fields: +# +# Sequence Number: The sequence number assigned to the connection ID +# by the sender, encoded as a variable-length integer; see +# Section 5.1.1. +# +# Retire Prior To: A variable-length integer indicating which +# connection IDs should be retired; see Section 5.1.2. +# +# Length: An 8-bit unsigned integer containing the length of the +# connection ID. Values less than 1 and greater than 20 are invalid +# and MUST be treated as a connection error of type +# FRAME_ENCODING_ERROR. +# +# Connection ID: A connection ID of the specified length. +# +# Stateless Reset Token: A 128-bit value that will be used for a +# stateless reset when the associated connection ID is used; see +# Section 10.3. +# +# An endpoint MUST NOT send this frame if it currently requires that +# its peer send packets with a zero-length Destination Connection ID. +# Changing the length of a connection ID to or from zero length makes +# it difficult to identify when the value of the connection ID changed. +# An endpoint that is sending packets with a zero-length Destination +# Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a +# connection error of type PROTOCOL_VIOLATION. +# +# Transmission errors, timeouts, and retransmissions might cause the +# same NEW_CONNECTION_ID frame to be received multiple times. Receipt +# of the same frame multiple times MUST NOT be treated as a connection +# error. A receiver can use the sequence number supplied in the +# NEW_CONNECTION_ID frame to handle receiving the same +# NEW_CONNECTION_ID frame multiple times. +# +# If an endpoint receives a NEW_CONNECTION_ID frame that repeats a +# previously issued connection ID with a different Stateless Reset +# Token field value or a different Sequence Number field value, or if a +# sequence number is used for different connection IDs, the endpoint +# MAY treat that receipt as a connection error of type +# PROTOCOL_VIOLATION. +# +# The Retire Prior To field applies to connection IDs established +# during connection setup and the preferred_address transport +# parameter; see Section 5.1.2. The value in the Retire Prior To field +# MUST be less than or equal to the value in the Sequence Number field. +# Receiving a value in the Retire Prior To field that is greater than +# that in the Sequence Number field MUST be treated as a connection +# error of type FRAME_ENCODING_ERROR. +# +# Once a sender indicates a Retire Prior To value, smaller values sent +# in subsequent NEW_CONNECTION_ID frames have no effect. A receiver +# MUST ignore any Retire Prior To fields that do not increase the +# largest received Retire Prior To value. +# +# An endpoint that receives a NEW_CONNECTION_ID frame with a sequence +# number smaller than the Retire Prior To field of a previously +# received NEW_CONNECTION_ID frame MUST send a corresponding +# RETIRE_CONNECTION_ID frame that retires the newly received connection +# ID, unless it has already done so for that sequence number. + +[[spec]] +level = "MUST" +quote = ''' +Values less than 1 and greater than 20 are invalid +and MUST be treated as a connection error of type +FRAME_ENCODING_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send this frame if it currently requires that +its peer send packets with a zero-length Destination Connection ID. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that is sending packets with a zero-length Destination +Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +Receipt +of the same frame multiple times MUST NOT be treated as a connection +error. +''' + +[[spec]] +level = "MAY" +quote = ''' +If an endpoint receives a NEW_CONNECTION_ID frame that repeats a +previously issued connection ID with a different Stateless Reset +Token field value or a different Sequence Number field value, or if a +sequence number is used for different connection IDs, the endpoint +MAY treat that receipt as a connection error of type +PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +The value in the Retire Prior To field +MUST be less than or equal to the value in the Sequence Number field. +''' + +[[spec]] +level = "MUST" +quote = ''' +Receiving a value in the Retire Prior To field that is greater than +that in the Sequence Number field MUST be treated as a connection +error of type FRAME_ENCODING_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +A receiver +MUST ignore any Retire Prior To fields that do not increase the +largest received Retire Prior To value. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that receives a NEW_CONNECTION_ID frame with a sequence +number smaller than the Retire Prior To field of a previously +received NEW_CONNECTION_ID frame MUST send a corresponding +RETIRE_CONNECTION_ID frame that retires the newly received connection +ID, unless it has already done so for that sequence number. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml new file mode 100644 index 0000000000..5adef49e76 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.16.toml @@ -0,0 +1,74 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.16" + +# RETIRE_CONNECTION_ID Frames +# +# An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to +# indicate that it will no longer use a connection ID that was issued +# by its peer. This includes the connection ID provided during the +# handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a +# request to the peer to send additional connection IDs for future use; +# see Section 5.1. New connection IDs can be delivered to a peer using +# the NEW_CONNECTION_ID frame (Section 19.15). +# +# Retiring a connection ID invalidates the stateless reset token +# associated with that connection ID. +# +# RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40. +# +# RETIRE_CONNECTION_ID Frame { +# Type (i) = 0x19, +# Sequence Number (i), +# } +# +# Figure 40: RETIRE_CONNECTION_ID Frame Format +# +# RETIRE_CONNECTION_ID frames contain the following field: +# +# Sequence Number: The sequence number of the connection ID being +# retired; see Section 5.1.2. +# +# Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number +# greater than any previously sent to the peer MUST be treated as a +# connection error of type PROTOCOL_VIOLATION. +# +# The sequence number specified in a RETIRE_CONNECTION_ID frame MUST +# NOT refer to the Destination Connection ID field of the packet in +# which the frame is contained. The peer MAY treat this as a +# connection error of type PROTOCOL_VIOLATION. +# +# An endpoint cannot send this frame if it was provided with a zero- +# length connection ID by its peer. An endpoint that provides a zero- +# length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID +# frame as a connection error of type PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number +greater than any previously sent to the peer MUST be treated as a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +The sequence number specified in a RETIRE_CONNECTION_ID frame MUST +NOT refer to the Destination Connection ID field of the packet in +which the frame is contained. +''' + +[[spec]] +level = "MAY" +quote = ''' +The peer MAY treat this as a +connection error of type PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that provides a zero- +length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID +frame as a connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.17.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.17.toml new file mode 100644 index 0000000000..5708304d9b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.17.toml @@ -0,0 +1,35 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.17" + +# PATH_CHALLENGE Frames +# +# Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check +# reachability to the peer and for path validation during connection +# migration. +# +# PATH_CHALLENGE frames are formatted as shown in Figure 41. +# +# PATH_CHALLENGE Frame { +# Type (i) = 0x1a, +# Data (64), +# } +# +# Figure 41: PATH_CHALLENGE Frame Format +# +# PATH_CHALLENGE frames contain the following field: +# +# Data: This 8-byte field contains arbitrary data. +# +# Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that +# it is easier to receive the packet than it is to guess the value +# correctly. +# +# The recipient of this frame MUST generate a PATH_RESPONSE frame +# (Section 19.18) containing the same Data value. + +[[spec]] +level = "MUST" +quote = ''' +The recipient of this frame MUST generate a PATH_RESPONSE frame +(Section 19.18) containing the same Data value. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.18.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.18.toml new file mode 100644 index 0000000000..85c375ce47 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.18.toml @@ -0,0 +1,30 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.18" + +# PATH_RESPONSE Frames +# +# A PATH_RESPONSE frame (type=0x1b) is sent in response to a +# PATH_CHALLENGE frame. +# +# PATH_RESPONSE frames are formatted as shown in Figure 42. The format +# of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE +# frame; see Section 19.17. +# +# PATH_RESPONSE Frame { +# Type (i) = 0x1b, +# Data (64), +# } +# +# Figure 42: PATH_RESPONSE Frame Format +# +# If the content of a PATH_RESPONSE frame does not match the content of +# a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint +# MAY generate a connection error of type PROTOCOL_VIOLATION. + +[[spec]] +level = "MAY" +quote = ''' +If the content of a PATH_RESPONSE frame does not match the content of +a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint +MAY generate a connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.19.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.19.toml new file mode 100644 index 0000000000..c640068d68 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.19.toml @@ -0,0 +1,67 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.19" + +# CONNECTION_CLOSE Frames +# +# An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to +# notify its peer that the connection is being closed. The +# CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors +# at only the QUIC layer, or the absence of errors (with the NO_ERROR +# code). The CONNECTION_CLOSE frame with a type of 0x1d is used to +# signal an error with the application that uses QUIC. +# +# If there are open streams that have not been explicitly closed, they +# are implicitly closed when the connection is closed. +# +# CONNECTION_CLOSE frames are formatted as shown in Figure 43. +# +# CONNECTION_CLOSE Frame { +# Type (i) = 0x1c..0x1d, +# Error Code (i), +# [Frame Type (i)], +# Reason Phrase Length (i), +# Reason Phrase (..), +# } +# +# Figure 43: CONNECTION_CLOSE Frame Format +# +# CONNECTION_CLOSE frames contain the following fields: +# +# Error Code: A variable-length integer that indicates the reason for +# closing this connection. A CONNECTION_CLOSE frame of type 0x1c +# uses codes from the space defined in Section 20.1. A +# CONNECTION_CLOSE frame of type 0x1d uses codes defined by the +# application protocol; see Section 20.2. +# +# Frame Type: A variable-length integer encoding the type of frame +# that triggered the error. A value of 0 (equivalent to the mention +# of the PADDING frame) is used when the frame type is unknown. The +# application-specific variant of CONNECTION_CLOSE (type 0x1d) does +# not include this field. +# +# Reason Phrase Length: A variable-length integer specifying the +# length of the reason phrase in bytes. Because a CONNECTION_CLOSE +# frame cannot be split between packets, any limits on packet size +# will also limit the space available for a reason phrase. +# +# Reason Phrase: Additional diagnostic information for the closure. +# This can be zero length if the sender chooses not to give details +# beyond the Error Code value. This SHOULD be a UTF-8 encoded +# string [RFC3629], though the frame does not carry information, +# such as language tags, that would aid comprehension by any entity +# other than the one that created the text. +# +# The application-specific variant of CONNECTION_CLOSE (type 0x1d) can +# only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an +# application wishes to abandon a connection during the handshake, an +# endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error +# code of APPLICATION_ERROR in an Initial or Handshake packet. + +[[spec]] +level = "SHOULD" +quote = ''' +This SHOULD be a UTF-8 encoded +string [RFC3629], though the frame does not carry information, +such as language tags, that would aid comprehension by any entity +other than the one that created the text. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.20.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.20.toml new file mode 100644 index 0000000000..1a33b63715 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.20.toml @@ -0,0 +1,36 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.20" + +# HANDSHAKE_DONE Frames +# +# The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal +# confirmation of the handshake to the client. +# +# HANDSHAKE_DONE frames are formatted as shown in Figure 44, which +# shows that HANDSHAKE_DONE frames have no content. +# +# HANDSHAKE_DONE Frame { +# Type (i) = 0x1e, +# } +# +# Figure 44: HANDSHAKE_DONE Frame Format +# +# A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST +# NOT send a HANDSHAKE_DONE frame before completing the handshake. A +# server MUST treat receipt of a HANDSHAKE_DONE frame as a connection +# error of type PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +Servers MUST +NOT send a HANDSHAKE_DONE frame before completing the handshake. +''' + +[[spec]] +level = "MUST" +quote = ''' +A +server MUST treat receipt of a HANDSHAKE_DONE frame as a connection +error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml new file mode 100644 index 0000000000..e57c56c059 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.21.toml @@ -0,0 +1,60 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.21" + +# Extension Frames +# +# QUIC frames do not use a self-describing encoding. An endpoint +# therefore needs to understand the syntax of all frames before it can +# successfully process a packet. This allows for efficient encoding of +# frames, but it means that an endpoint cannot send a frame of a type +# that is unknown to its peer. +# +# An extension to QUIC that wishes to use a new type of frame MUST +# first ensure that a peer is able to understand the frame. An +# endpoint can use a transport parameter to signal its willingness to +# receive extension frame types. One transport parameter can indicate +# support for one or more extension frame types. +# +# Extensions that modify or replace core protocol functionality +# (including frame types) will be difficult to combine with other +# extensions that modify or replace the same functionality unless the +# behavior of the combination is explicitly defined. Such extensions +# SHOULD define their interaction with previously defined extensions +# modifying the same protocol components. +# +# Extension frames MUST be congestion controlled and MUST cause an ACK +# frame to be sent. The exception is extension frames that replace or +# supplement the ACK frame. Extension frames are not included in flow +# control unless specified in the extension. +# +# An IANA registry is used to manage the assignment of frame types; see +# Section 22.4. + +[[spec]] +level = "MUST" +quote = ''' +An extension to QUIC that wishes to use a new type of frame MUST +first ensure that a peer is able to understand the frame. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Such extensions +SHOULD define their interaction with previously defined extensions +modifying the same protocol components. +''' + +[[spec]] +level = "MUST" +quote = ''' +Extension frames MUST be congestion controlled and MUST cause an ACK +frame to be sent. +''' + +[[spec]] +level = "MUST" +quote = ''' +Extension frames MUST be congestion controlled and MUST cause an ACK +frame to be sent. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.1.toml new file mode 100644 index 0000000000..47032699e6 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.1.toml @@ -0,0 +1,70 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.3.1" + +# ACK Ranges +# +# Each ACK Range consists of alternating Gap and ACK Range Length +# values in descending packet number order. ACK Ranges can be +# repeated. The number of Gap and ACK Range Length values is +# determined by the ACK Range Count field; one of each value is present +# for each value in the ACK Range Count field. +# +# ACK Ranges are structured as shown in Figure 26. +# +# ACK Range { +# Gap (i), +# ACK Range Length (i), +# } +# +# Figure 26: ACK Ranges +# +# The fields that form each ACK Range are: +# +# Gap: A variable-length integer indicating the number of contiguous +# unacknowledged packets preceding the packet number one lower than +# the smallest in the preceding ACK Range. +# +# ACK Range Length: A variable-length integer indicating the number of +# contiguous acknowledged packets preceding the largest packet +# number, as determined by the preceding Gap. +# +# Gap and ACK Range Length values use a relative integer encoding for +# efficiency. Though each encoded value is positive, the values are +# subtracted, so that each ACK Range describes progressively lower- +# numbered packets. +# +# Each ACK Range acknowledges a contiguous range of packets by +# indicating the number of acknowledged packets that precede the +# largest packet number in that range. A value of 0 indicates that +# only the largest packet number is acknowledged. Larger ACK Range +# values indicate a larger range, with corresponding lower values for +# the smallest packet number in the range. Thus, given a largest +# packet number for the range, the smallest value is determined by the +# following formula: +# +# smallest = largest - ack_range +# +# An ACK Range acknowledges all packets between the smallest packet +# number and the largest, inclusive. +# +# The largest value for an ACK Range is determined by cumulatively +# subtracting the size of all preceding ACK Range Lengths and Gaps. +# +# Each Gap indicates a range of packets that are not being +# acknowledged. The number of packets in the gap is one higher than +# the encoded value of the Gap field. +# +# The value of the Gap field establishes the largest packet number +# value for the subsequent ACK Range using the following formula: +# +# largest = previous_smallest - gap - 2 +# +# If any computed packet number is negative, an endpoint MUST generate +# a connection error of type FRAME_ENCODING_ERROR. + +[[spec]] +level = "MUST" +quote = ''' +If any computed packet number is negative, an endpoint MUST generate +a connection error of type FRAME_ENCODING_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.toml new file mode 100644 index 0000000000..fcabd8dccd --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.3.toml @@ -0,0 +1,85 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.3" + +# ACK Frames +# +# Receivers send ACK frames (types 0x02 and 0x03) to inform senders of +# packets they have received and processed. The ACK frame contains one +# or more ACK Ranges. ACK Ranges identify acknowledged packets. If +# the frame type is 0x03, ACK frames also contain the cumulative count +# of QUIC packets with associated ECN marks received on the connection +# up until this point. QUIC implementations MUST properly handle both +# types, and, if they have enabled ECN for packets they send, they +# SHOULD use the information in the ECN section to manage their +# congestion state. +# +# QUIC acknowledgments are irrevocable. Once acknowledged, a packet +# remains acknowledged, even if it does not appear in a future ACK +# frame. This is unlike reneging for TCP Selective Acknowledgments +# (SACKs) [RFC2018]. +# +# Packets from different packet number spaces can be identified using +# the same numeric value. An acknowledgment for a packet needs to +# indicate both a packet number and a packet number space. This is +# accomplished by having each ACK frame only acknowledge packet numbers +# in the same space as the packet in which the ACK frame is contained. +# +# Version Negotiation and Retry packets cannot be acknowledged because +# they do not contain a packet number. Rather than relying on ACK +# frames, these packets are implicitly acknowledged by the next Initial +# packet sent by the client. +# +# ACK frames are formatted as shown in Figure 25. +# +# ACK Frame { +# Type (i) = 0x02..0x03, +# Largest Acknowledged (i), +# ACK Delay (i), +# ACK Range Count (i), +# First ACK Range (i), +# ACK Range (..) ..., +# [ECN Counts (..)], +# } +# +# Figure 25: ACK Frame Format +# +# ACK frames contain the following fields: +# +# Largest Acknowledged: A variable-length integer representing the +# largest packet number the peer is acknowledging; this is usually +# the largest packet number that the peer has received prior to +# generating the ACK frame. Unlike the packet number in the QUIC +# long or short header, the value in an ACK frame is not truncated. +# +# ACK Delay: A variable-length integer encoding the acknowledgment +# delay in microseconds; see Section 13.2.5. It is decoded by +# multiplying the value in the field by 2 to the power of the +# ack_delay_exponent transport parameter sent by the sender of the +# ACK frame; see Section 18.2. Compared to simply expressing the +# delay as an integer, this encoding allows for a larger range of +# values within the same number of bytes, at the cost of lower +# resolution. +# +# ACK Range Count: A variable-length integer specifying the number of +# ACK Range fields in the frame. +# +# First ACK Range: A variable-length integer indicating the number of +# contiguous packets preceding the Largest Acknowledged that are +# being acknowledged. That is, the smallest packet acknowledged in +# the range is determined by subtracting the First ACK Range value +# from the Largest Acknowledged field. +# +# ACK Ranges: Contains additional ranges of packets that are +# alternately not acknowledged (Gap) and acknowledged (ACK Range); +# see Section 19.3.1. +# +# ECN Counts: The three ECN counts; see Section 19.3.2. + +[[spec]] +level = "MUST" +quote = ''' +QUIC implementations MUST properly handle both +types, and, if they have enabled ECN for packets they send, they +SHOULD use the information in the ECN section to manage their +congestion state. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.4.toml new file mode 100644 index 0000000000..794fe64f5a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.4.toml @@ -0,0 +1,46 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.4" + +# RESET_STREAM Frames +# +# An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly +# terminate the sending part of a stream. +# +# After sending a RESET_STREAM, an endpoint ceases transmission and +# retransmission of STREAM frames on the identified stream. A receiver +# of RESET_STREAM can discard any data that it already received on that +# stream. +# +# An endpoint that receives a RESET_STREAM frame for a send-only stream +# MUST terminate the connection with error STREAM_STATE_ERROR. +# +# RESET_STREAM frames are formatted as shown in Figure 28. +# +# RESET_STREAM Frame { +# Type (i) = 0x04, +# Stream ID (i), +# Application Protocol Error Code (i), +# Final Size (i), +# } +# +# Figure 28: RESET_STREAM Frame Format +# +# RESET_STREAM frames contain the following fields: +# +# Stream ID: A variable-length integer encoding of the stream ID of +# the stream being terminated. +# +# Application Protocol Error Code: A variable-length integer +# containing the application protocol error code (see Section 20.2) +# that indicates why the stream is being closed. +# +# Final Size: A variable-length integer indicating the final size of +# the stream by the RESET_STREAM sender, in units of bytes; see +# Section 4.5. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that receives a RESET_STREAM frame for a send-only stream +MUST terminate the connection with error STREAM_STATE_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.5.toml new file mode 100644 index 0000000000..1e4b0d8da6 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.5.toml @@ -0,0 +1,50 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.5" + +# STOP_SENDING Frames +# +# An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that +# incoming data is being discarded on receipt per application request. +# STOP_SENDING requests that a peer cease transmission on a stream. +# +# A STOP_SENDING frame can be sent for streams in the "Recv" or "Size +# Known" states; see Section 3.2. Receiving a STOP_SENDING frame for a +# locally initiated stream that has not yet been created MUST be +# treated as a connection error of type STREAM_STATE_ERROR. An +# endpoint that receives a STOP_SENDING frame for a receive-only stream +# MUST terminate the connection with error STREAM_STATE_ERROR. +# +# STOP_SENDING frames are formatted as shown in Figure 29. +# +# STOP_SENDING Frame { +# Type (i) = 0x05, +# Stream ID (i), +# Application Protocol Error Code (i), +# } +# +# Figure 29: STOP_SENDING Frame Format +# +# STOP_SENDING frames contain the following fields: +# +# Stream ID: A variable-length integer carrying the stream ID of the +# stream being ignored. +# +# Application Protocol Error Code: A variable-length integer +# containing the application-specified reason the sender is ignoring +# the stream; see Section 20.2. + +[[spec]] +level = "MUST" +quote = ''' +Receiving a STOP_SENDING frame for a +locally initiated stream that has not yet been created MUST be +treated as a connection error of type STREAM_STATE_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +An +endpoint that receives a STOP_SENDING frame for a receive-only stream +MUST terminate the connection with error STREAM_STATE_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.6.toml new file mode 100644 index 0000000000..91f41bff7c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.6.toml @@ -0,0 +1,56 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.6" + +# CRYPTO Frames +# +# A CRYPTO frame (type=0x06) is used to transmit cryptographic +# handshake messages. It can be sent in all packet types except 0-RTT. +# The CRYPTO frame offers the cryptographic protocol an in-order stream +# of bytes. CRYPTO frames are functionally identical to STREAM frames, +# except that they do not bear a stream identifier; they are not flow +# controlled; and they do not carry markers for optional offset, +# optional length, and the end of the stream. +# +# CRYPTO frames are formatted as shown in Figure 30. +# +# CRYPTO Frame { +# Type (i) = 0x06, +# Offset (i), +# Length (i), +# Crypto Data (..), +# } +# +# Figure 30: CRYPTO Frame Format +# +# CRYPTO frames contain the following fields: +# +# Offset: A variable-length integer specifying the byte offset in the +# stream for the data in this CRYPTO frame. +# +# Length: A variable-length integer specifying the length of the +# Crypto Data field in this CRYPTO frame. +# +# Crypto Data: The cryptographic message data. +# +# There is a separate flow of cryptographic handshake data in each +# encryption level, each of which starts at an offset of 0. This +# implies that each encryption level is treated as a separate CRYPTO +# stream of data. +# +# The largest offset delivered on a stream -- the sum of the offset and +# data length -- cannot exceed 2^62-1. Receipt of a frame that exceeds +# this limit MUST be treated as a connection error of type +# FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. +# +# Unlike STREAM frames, which include a stream ID indicating to which +# stream the data belongs, the CRYPTO frame carries data for a single +# stream per encryption level. The stream does not have an explicit +# end, so CRYPTO frames do not have a FIN bit. + +[[spec]] +level = "MUST" +quote = ''' +Receipt of a frame that exceeds +this limit MUST be treated as a connection error of type +FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml new file mode 100644 index 0000000000..82418e8ac1 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.7.toml @@ -0,0 +1,66 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.7" + +# NEW_TOKEN Frames +# +# A server sends a NEW_TOKEN frame (type=0x07) to provide the client +# with a token to send in the header of an Initial packet for a future +# connection. +# +# NEW_TOKEN frames are formatted as shown in Figure 31. +# +# NEW_TOKEN Frame { +# Type (i) = 0x07, +# Token Length (i), +# Token (..), +# } +# +# Figure 31: NEW_TOKEN Frame Format +# +# NEW_TOKEN frames contain the following fields: +# +# Token Length: A variable-length integer specifying the length of the +# token in bytes. +# +# Token: An opaque blob that the client can use with a future Initial +# packet. The token MUST NOT be empty. A client MUST treat receipt +# of a NEW_TOKEN frame with an empty Token field as a connection +# error of type FRAME_ENCODING_ERROR. +# +# A client might receive multiple NEW_TOKEN frames that contain the +# same token value if packets containing the frame are incorrectly +# determined to be lost. Clients are responsible for discarding +# duplicate values, which might be used to link connection attempts; +# see Section 8.1.3. +# +# Clients MUST NOT send NEW_TOKEN frames. A server MUST treat receipt +# of a NEW_TOKEN frame as a connection error of type +# PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +The token MUST NOT be empty. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST treat receipt +of a NEW_TOKEN frame with an empty Token field as a connection +error of type FRAME_ENCODING_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +Clients MUST NOT send NEW_TOKEN frames. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST treat receipt +of a NEW_TOKEN frame as a connection error of type +PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.8.toml new file mode 100644 index 0000000000..9c1f0188e8 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.8.toml @@ -0,0 +1,86 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.8" + +# STREAM Frames +# +# STREAM frames implicitly create a stream and carry stream data. The +# Type field in the STREAM frame takes the form 0b00001XXX (or the set +# of values from 0x08 to 0x0f). The three low-order bits of the frame +# type determine the fields that are present in the frame: +# +# * The OFF bit (0x04) in the frame type is set to indicate that there +# is an Offset field present. When set to 1, the Offset field is +# present. When set to 0, the Offset field is absent and the Stream +# Data starts at an offset of 0 (that is, the frame contains the +# first bytes of the stream, or the end of a stream that includes no +# data). +# +# * The LEN bit (0x02) in the frame type is set to indicate that there +# is a Length field present. If this bit is set to 0, the Length +# field is absent and the Stream Data field extends to the end of +# the packet. If this bit is set to 1, the Length field is present. +# +# * The FIN bit (0x01) indicates that the frame marks the end of the +# stream. The final size of the stream is the sum of the offset and +# the length of this frame. +# +# An endpoint MUST terminate the connection with error +# STREAM_STATE_ERROR if it receives a STREAM frame for a locally +# initiated stream that has not yet been created, or for a send-only +# stream. +# +# STREAM frames are formatted as shown in Figure 32. +# +# STREAM Frame { +# Type (i) = 0x08..0x0f, +# Stream ID (i), +# [Offset (i)], +# [Length (i)], +# Stream Data (..), +# } +# +# Figure 32: STREAM Frame Format +# +# STREAM frames contain the following fields: +# +# Stream ID: A variable-length integer indicating the stream ID of the +# stream; see Section 2.1. +# +# Offset: A variable-length integer specifying the byte offset in the +# stream for the data in this STREAM frame. This field is present +# when the OFF bit is set to 1. When the Offset field is absent, +# the offset is 0. +# +# Length: A variable-length integer specifying the length of the +# Stream Data field in this STREAM frame. This field is present +# when the LEN bit is set to 1. When the LEN bit is set to 0, the +# Stream Data field consumes all the remaining bytes in the packet. +# +# Stream Data: The bytes from the designated stream to be delivered. +# +# When a Stream Data field has a length of 0, the offset in the STREAM +# frame is the offset of the next byte that would be sent. +# +# The first byte in the stream has an offset of 0. The largest offset +# delivered on a stream -- the sum of the offset and data length -- +# cannot exceed 2^62-1, as it is not possible to provide flow control +# credit for that data. Receipt of a frame that exceeds this limit +# MUST be treated as a connection error of type FRAME_ENCODING_ERROR or +# FLOW_CONTROL_ERROR. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST terminate the connection with error +STREAM_STATE_ERROR if it receives a STREAM frame for a locally +initiated stream that has not yet been created, or for a send-only +stream. +''' + +[[spec]] +level = "MUST" +quote = ''' +Receipt of a frame that exceeds this limit +MUST be treated as a connection error of type FRAME_ENCODING_ERROR or +FLOW_CONTROL_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.9.toml new file mode 100644 index 0000000000..f6519b54ea --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-19.9.toml @@ -0,0 +1,48 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.9" + +# MAX_DATA Frames +# +# A MAX_DATA frame (type=0x10) is used in flow control to inform the +# peer of the maximum amount of data that can be sent on the connection +# as a whole. +# +# MAX_DATA frames are formatted as shown in Figure 33. +# +# MAX_DATA Frame { +# Type (i) = 0x10, +# Maximum Data (i), +# } +# +# Figure 33: MAX_DATA Frame Format +# +# MAX_DATA frames contain the following field: +# +# Maximum Data: A variable-length integer indicating the maximum +# amount of data that can be sent on the entire connection, in units +# of bytes. +# +# All data sent in STREAM frames counts toward this limit. The sum of +# the final sizes on all streams -- including streams in terminal +# states -- MUST NOT exceed the value advertised by a receiver. An +# endpoint MUST terminate a connection with an error of type +# FLOW_CONTROL_ERROR if it receives more data than the maximum data +# value that it has sent. This includes violations of remembered +# limits in Early Data; see Section 7.4.1. + +[[spec]] +level = "MUST" +quote = ''' +The sum of +the final sizes on all streams -- including streams in terminal +states -- MUST NOT exceed the value advertised by a receiver. +''' + +[[spec]] +level = "MUST" +quote = ''' +An +endpoint MUST terminate a connection with an error of type +FLOW_CONTROL_ERROR if it receives more data than the maximum data +value that it has sent. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.1.toml new file mode 100644 index 0000000000..53be006781 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.1.toml @@ -0,0 +1,54 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-2.1" + +# Stream Types and Identifiers +# +# Streams can be unidirectional or bidirectional. Unidirectional +# streams carry data in one direction: from the initiator of the stream +# to its peer. Bidirectional streams allow for data to be sent in both +# directions. +# +# Streams are identified within a connection by a numeric value, +# referred to as the stream ID. A stream ID is a 62-bit integer (0 to +# 2^62-1) that is unique for all streams on a connection. Stream IDs +# are encoded as variable-length integers; see Section 16. A QUIC +# endpoint MUST NOT reuse a stream ID within a connection. +# +# The least significant bit (0x01) of the stream ID identifies the +# initiator of the stream. Client-initiated streams have even-numbered +# stream IDs (with the bit set to 0), and server-initiated streams have +# odd-numbered stream IDs (with the bit set to 1). +# +# The second least significant bit (0x02) of the stream ID +# distinguishes between bidirectional streams (with the bit set to 0) +# and unidirectional streams (with the bit set to 1). +# +# The two least significant bits from a stream ID therefore identify a +# stream as one of four types, as summarized in Table 1. +# +# +======+==================================+ +# | Bits | Stream Type | +# +======+==================================+ +# | 0x00 | Client-Initiated, Bidirectional | +# +------+----------------------------------+ +# | 0x01 | Server-Initiated, Bidirectional | +# +------+----------------------------------+ +# | 0x02 | Client-Initiated, Unidirectional | +# +------+----------------------------------+ +# | 0x03 | Server-Initiated, Unidirectional | +# +------+----------------------------------+ +# +# Table 1: Stream ID Types +# +# The stream space for each type begins at the minimum value (0x00 +# through 0x03, respectively); successive streams of each type are +# created with numerically increasing stream IDs. A stream ID that is +# used out of order results in all streams of that type with lower- +# numbered stream IDs also being opened. + +[[spec]] +level = "MUST" +quote = ''' +A QUIC +endpoint MUST NOT reuse a stream ID within a connection. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml new file mode 100644 index 0000000000..c0218e8e3b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.2.toml @@ -0,0 +1,63 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-2.2" + +# Sending and Receiving Data +# +# STREAM frames (Section 19.8) encapsulate data sent by an application. +# An endpoint uses the Stream ID and Offset fields in STREAM frames to +# place data in order. +# +# Endpoints MUST be able to deliver stream data to an application as an +# ordered byte stream. Delivering an ordered byte stream requires that +# an endpoint buffer any data that is received out of order, up to the +# advertised flow control limit. +# +# QUIC makes no specific allowances for delivery of stream data out of +# order. However, implementations MAY choose to offer the ability to +# deliver data out of order to a receiving application. +# +# An endpoint could receive data for a stream at the same stream offset +# multiple times. Data that has already been received can be +# discarded. The data at a given offset MUST NOT change if it is sent +# multiple times; an endpoint MAY treat receipt of different data at +# the same offset within a stream as a connection error of type +# PROTOCOL_VIOLATION. +# +# Streams are an ordered byte-stream abstraction with no other +# structure visible to QUIC. STREAM frame boundaries are not expected +# to be preserved when data is transmitted, retransmitted after packet +# loss, or delivered to the application at a receiver. +# +# An endpoint MUST NOT send data on any stream without ensuring that it +# is within the flow control limits set by its peer. Flow control is +# described in detail in Section 4. + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST be able to deliver stream data to an application as an +ordered byte stream. +''' + +[[spec]] +level = "MAY" +quote = ''' +However, implementations MAY choose to offer the ability to +deliver data out of order to a receiving application. +''' + +[[spec]] +level = "MUST" +quote = ''' +The data at a given offset MUST NOT change if it is sent +multiple times; an endpoint MAY treat receipt of different data at +the same offset within a stream as a connection error of type +PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send data on any stream without ensuring that it +is within the flow control limits set by its peer. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.3.toml new file mode 100644 index 0000000000..e16a63236a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-2.3.toml @@ -0,0 +1,24 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-2.3" + +# Stream Prioritization +# +# Stream multiplexing can have a significant effect on application +# performance if resources allocated to streams are correctly +# prioritized. +# +# QUIC does not provide a mechanism for exchanging prioritization +# information. Instead, it relies on receiving priority information +# from the application. +# +# A QUIC implementation SHOULD provide ways in which an application can +# indicate the relative priority of streams. An implementation uses +# information provided by the application to determine how to allocate +# resources to active streams. + +[[spec]] +level = "SHOULD" +quote = ''' +A QUIC implementation SHOULD provide ways in which an application can +indicate the relative priority of streams. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.11.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.11.toml new file mode 100644 index 0000000000..40cab2d5be --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.11.toml @@ -0,0 +1,53 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.11" + +# Stateless Reset Oracle +# +# Stateless resets create a possible denial-of-service attack analogous +# to a TCP reset injection. This attack is possible if an attacker is +# able to cause a stateless reset token to be generated for a +# connection with a selected connection ID. An attacker that can cause +# this token to be generated can reset an active connection with the +# same connection ID. +# +# If a packet can be routed to different instances that share a static +# key -- for example, by changing an IP address or port -- then an +# attacker can cause the server to send a stateless reset. To defend +# against this style of denial of service, endpoints that share a +# static key for stateless resets (see Section 10.3.2) MUST be arranged +# so that packets with a given connection ID always arrive at an +# instance that has connection state, unless that connection is no +# longer active. +# +# More generally, servers MUST NOT generate a stateless reset if a +# connection with the corresponding connection ID could be active on +# any endpoint using the same static key. +# +# In the case of a cluster that uses dynamic load balancing, it is +# possible that a change in load-balancer configuration could occur +# while an active instance retains connection state. Even if an +# instance retains connection state, the change in routing and +# resulting stateless reset will result in the connection being +# terminated. If there is no chance of the packet being routed to the +# correct instance, it is better to send a stateless reset than wait +# for the connection to time out. However, this is acceptable only if +# the routing cannot be influenced by an attacker. + +[[spec]] +level = "MUST" +quote = ''' +To defend +against this style of denial of service, endpoints that share a +static key for stateless resets (see Section 10.3.2) MUST be arranged +so that packets with a given connection ID always arrive at an +instance that has connection state, unless that connection is no +longer active. +''' + +[[spec]] +level = "MUST" +quote = ''' +More generally, servers MUST NOT generate a stateless reset if a +connection with the corresponding connection ID could be active on +any endpoint using the same static key. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.12.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.12.toml new file mode 100644 index 0000000000..2616c6d90f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.12.toml @@ -0,0 +1,21 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.12" + +# Version Downgrade +# +# This document defines QUIC Version Negotiation packets (Section 6), +# which can be used to negotiate the QUIC version used between two +# endpoints. However, this document does not specify how this +# negotiation will be performed between this version and subsequent +# future versions. In particular, Version Negotiation packets do not +# contain any mechanism to prevent version downgrade attacks. Future +# versions of QUIC that use Version Negotiation packets MUST define a +# mechanism that is robust against version downgrade attacks. + +[[spec]] +level = "MUST" +quote = ''' +Future +versions of QUIC that use Version Negotiation packets MUST define a +mechanism that is robust against version downgrade attacks. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.3.toml new file mode 100644 index 0000000000..a9019a2895 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.3.toml @@ -0,0 +1,22 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.3" + +# Amplification Attack +# +# An attacker might be able to receive an address validation token +# (Section 8) from a server and then release the IP address it used to +# acquire that token. At a later time, the attacker can initiate a +# 0-RTT connection with a server by spoofing this same address, which +# might now address a different (victim) endpoint. The attacker can +# thus potentially cause the server to send an initial congestion +# window's worth of data towards the victim. +# +# Servers SHOULD provide mitigations for this attack by limiting the +# usage and lifetime of address validation tokens; see Section 8.1.3. + +[[spec]] +level = "SHOULD" +quote = ''' +Servers SHOULD provide mitigations for this attack by limiting the +usage and lifetime of address validation tokens; see Section 8.1.3. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.4.toml new file mode 100644 index 0000000000..ea94ef3c8c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.4.toml @@ -0,0 +1,18 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.4" + +# Optimistic ACK Attack +# +# An endpoint that acknowledges packets it has not received might cause +# a congestion controller to permit sending at rates beyond what the +# network supports. An endpoint MAY skip packet numbers when sending +# packets to detect this behavior. An endpoint can then immediately +# close the connection with a connection error of type +# PROTOCOL_VIOLATION; see Section 10.2. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY skip packet numbers when sending +packets to detect this behavior. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.3.toml new file mode 100644 index 0000000000..e79e6b22ca --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.3.toml @@ -0,0 +1,26 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5.3" + +# Request Forgery with Preferred Addresses +# +# Servers can specify a preferred address, which clients then migrate +# to after confirming the handshake; see Section 9.6. The Destination +# Connection ID field of packets that the client sends to a preferred +# address can be used for request forgery. +# +# A client MUST NOT send non-probing frames to a preferred address +# prior to validating that address; see Section 8. This greatly +# reduces the options that a server has to control the encrypted +# portion of datagrams. +# +# This document does not offer any additional countermeasures that are +# specific to the use of preferred addresses and can be implemented by +# endpoints. The generic measures described in Section 21.5.6 could be +# used as further mitigation. + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT send non-probing frames to a preferred address +prior to validating that address; see Section 8. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml new file mode 100644 index 0000000000..d88760f49e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.6.toml @@ -0,0 +1,102 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5.6" + +# Generic Request Forgery Countermeasures +# +# The most effective defense against request forgery attacks is to +# modify vulnerable services to use strong authentication. However, +# this is not always something that is within the control of a QUIC +# deployment. This section outlines some other steps that QUIC +# endpoints could take unilaterally. These additional steps are all +# discretionary because, depending on circumstances, they could +# interfere with or prevent legitimate uses. +# +# Services offered over loopback interfaces often lack proper +# authentication. Endpoints MAY prevent connection attempts or +# migration to a loopback address. Endpoints SHOULD NOT allow +# connections or migration to a loopback address if the same service +# was previously available at a different interface or if the address +# was provided by a service at a non-loopback address. Endpoints that +# depend on these capabilities could offer an option to disable these +# protections. +# +# Similarly, endpoints could regard a change in address to a link-local +# address [RFC4291] or an address in a private-use range [RFC1918] from +# a global, unique-local [RFC4193], or non-private address as a +# potential attempt at request forgery. Endpoints could refuse to use +# these addresses entirely, but that carries a significant risk of +# interfering with legitimate uses. Endpoints SHOULD NOT refuse to use +# an address unless they have specific knowledge about the network +# indicating that sending datagrams to unvalidated addresses in a given +# range is not safe. +# +# Endpoints MAY choose to reduce the risk of request forgery by not +# including values from NEW_TOKEN frames in Initial packets or by only +# sending probing frames in packets prior to completing address +# validation. Note that this does not prevent an attacker from using +# the Destination Connection ID field for an attack. +# +# Endpoints are not expected to have specific information about the +# location of servers that could be vulnerable targets of a request +# forgery attack. However, it might be possible over time to identify +# specific UDP ports that are common targets of attacks or particular +# patterns in datagrams that are used for attacks. Endpoints MAY +# choose to avoid sending datagrams to these ports or not send +# datagrams that match these patterns prior to validating the +# destination address. Endpoints MAY retire connection IDs containing +# patterns known to be problematic without using them. +# +# | Note: Modifying endpoints to apply these protections is more +# | efficient than deploying network-based protections, as +# | endpoints do not need to perform any additional processing when +# | sending to an address that has been validated. + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY prevent connection attempts or +migration to a loopback address. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD NOT allow +connections or migration to a loopback address if the same service +was previously available at a different interface or if the address +was provided by a service at a non-loopback address. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD NOT refuse to use +an address unless they have specific knowledge about the network +indicating that sending datagrams to unvalidated addresses in a given +range is not safe. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY choose to reduce the risk of request forgery by not +including values from NEW_TOKEN frames in Initial packets or by only +sending probing frames in packets prior to completing address +validation. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY +choose to avoid sending datagrams to these ports or not send +datagrams that match these patterns prior to validating the +destination address. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY retire connection IDs containing +patterns known to be problematic without using them. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.toml new file mode 100644 index 0000000000..a43446003a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.5.toml @@ -0,0 +1,70 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5" + +# Request Forgery Attacks +# +# A request forgery attack occurs where an endpoint causes its peer to +# issue a request towards a victim, with the request controlled by the +# endpoint. Request forgery attacks aim to provide an attacker with +# access to capabilities of its peer that might otherwise be +# unavailable to the attacker. For a networking protocol, a request +# forgery attack is often used to exploit any implicit authorization +# conferred on the peer by the victim due to the peer's location in the +# network. +# +# For request forgery to be effective, an attacker needs to be able to +# influence what packets the peer sends and where these packets are +# sent. If an attacker can target a vulnerable service with a +# controlled payload, that service might perform actions that are +# attributed to the attacker's peer but are decided by the attacker. +# +# For example, cross-site request forgery [CSRF] exploits on the Web +# cause a client to issue requests that include authorization cookies +# [COOKIE], allowing one site access to information and actions that +# are intended to be restricted to a different site. +# +# As QUIC runs over UDP, the primary attack modality of concern is one +# where an attacker can select the address to which its peer sends UDP +# datagrams and can control some of the unprotected content of those +# packets. As much of the data sent by QUIC endpoints is protected, +# this includes control over ciphertext. An attack is successful if an +# attacker can cause a peer to send a UDP datagram to a host that will +# perform some action based on content in the datagram. +# +# This section discusses ways in which QUIC might be used for request +# forgery attacks. +# +# This section also describes limited countermeasures that can be +# implemented by QUIC endpoints. These mitigations can be employed +# unilaterally by a QUIC implementation or deployment, without +# potential targets for request forgery attacks taking action. +# However, these countermeasures could be insufficient if UDP-based +# services do not properly authorize requests. +# +# Because the migration attack described in Section 21.5.4 is quite +# powerful and does not have adequate countermeasures, QUIC server +# implementations should assume that attackers can cause them to +# generate arbitrary UDP payloads to arbitrary destinations. QUIC +# servers SHOULD NOT be deployed in networks that do not deploy ingress +# filtering [BCP38] and also have inadequately secured UDP endpoints. +# +# Although it is not generally possible to ensure that clients are not +# co-located with vulnerable endpoints, this version of QUIC does not +# allow servers to migrate, thus preventing spoofed migration attacks +# on clients. Any future extension that allows server migration MUST +# also define countermeasures for forgery attacks. + +[[spec]] +level = "SHOULD" +quote = ''' +QUIC +servers SHOULD NOT be deployed in networks that do not deploy ingress +filtering [BCP38] and also have inadequately secured UDP endpoints. +''' + +[[spec]] +level = "MUST" +quote = ''' +Any future extension that allows server migration MUST +also define countermeasures for forgery attacks. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.6.toml new file mode 100644 index 0000000000..c659bcd8b9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.6.toml @@ -0,0 +1,31 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.6" + +# Slowloris Attacks +# +# The attacks commonly known as Slowloris [SLOWLORIS] try to keep many +# connections to the target endpoint open and hold them open as long as +# possible. These attacks can be executed against a QUIC endpoint by +# generating the minimum amount of activity necessary to avoid being +# closed for inactivity. This might involve sending small amounts of +# data, gradually opening flow control windows in order to control the +# sender rate, or manufacturing ACK frames that simulate a high loss +# rate. +# +# QUIC deployments SHOULD provide mitigations for the Slowloris +# attacks, such as increasing the maximum number of clients the server +# will allow, limiting the number of connections a single IP address is +# allowed to make, imposing restrictions on the minimum transfer speed +# a connection is allowed to have, and restricting the length of time +# an endpoint is allowed to stay connected. + +[[spec]] +level = "SHOULD" +quote = ''' +QUIC deployments SHOULD provide mitigations for the Slowloris +attacks, such as increasing the maximum number of clients the server +will allow, limiting the number of connections a single IP address is +allowed to make, imposing restrictions on the minimum transfer speed +a connection is allowed to have, and restricting the length of time +an endpoint is allowed to stay connected. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.7.toml new file mode 100644 index 0000000000..a8705edba7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.7.toml @@ -0,0 +1,34 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.7" + +# Stream Fragmentation and Reassembly Attacks +# +# An adversarial sender might intentionally not send portions of the +# stream data, causing the receiver to commit resources for the unsent +# data. This could cause a disproportionate receive buffer memory +# commitment and/or the creation of a large and inefficient data +# structure at the receiver. +# +# An adversarial receiver might intentionally not acknowledge packets +# containing stream data in an attempt to force the sender to store the +# unacknowledged stream data for retransmission. +# +# The attack on receivers is mitigated if flow control windows +# correspond to available memory. However, some receivers will +# overcommit memory and advertise flow control offsets in the aggregate +# that exceed actual available memory. The overcommitment strategy can +# lead to better performance when endpoints are well behaved, but +# renders endpoints vulnerable to the stream fragmentation attack. +# +# QUIC deployments SHOULD provide mitigations for stream fragmentation +# attacks. Mitigations could consist of avoiding overcommitting +# memory, limiting the size of tracking data structures, delaying +# reassembly of STREAM frames, implementing heuristics based on the age +# and duration of reassembly holes, or some combination of these. + +[[spec]] +level = "SHOULD" +quote = ''' +QUIC deployments SHOULD provide mitigations for stream fragmentation +attacks. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.9.toml new file mode 100644 index 0000000000..b20f466534 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-21.9.toml @@ -0,0 +1,39 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.9" + +# Peer Denial of Service +# +# QUIC and TLS both contain frames or messages that have legitimate +# uses in some contexts, but these frames or messages can be abused to +# cause a peer to expend processing resources without having any +# observable impact on the state of the connection. +# +# Messages can also be used to change and revert state in small or +# inconsequential ways, such as by sending small increments to flow +# control limits. +# +# If processing costs are disproportionately large in comparison to +# bandwidth consumption or effect on state, then this could allow a +# malicious peer to exhaust processing capacity. +# +# While there are legitimate uses for all messages, implementations +# SHOULD track cost of processing relative to progress and treat +# excessive quantities of any non-productive packets as indicative of +# an attack. Endpoints MAY respond to this condition with a connection +# error or by dropping packets. + +[[spec]] +level = "SHOULD" +quote = ''' +While there are legitimate uses for all messages, implementations +SHOULD track cost of processing relative to progress and treat +excessive quantities of any non-productive packets as indicative of +an attack. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY respond to this condition with a connection +error or by dropping packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.1.toml new file mode 100644 index 0000000000..7775cdb1e0 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.1.toml @@ -0,0 +1,48 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.1" + +# Provisional Registrations +# +# Provisional registrations of codepoints are intended to allow for +# private use and experimentation with extensions to QUIC. Provisional +# registrations only require the inclusion of the codepoint value and +# contact information. However, provisional registrations could be +# reclaimed and reassigned for another purpose. +# +# Provisional registrations require Expert Review, as defined in +# Section 4.5 of [RFC8126]. The designated expert or experts are +# advised that only registrations for an excessive proportion of +# remaining codepoint space or the very first unassigned value (see +# Section 22.1.2) can be rejected. +# +# Provisional registrations will include a Date field that indicates +# when the registration was last updated. A request to update the date +# on any provisional registration can be made without review from the +# designated expert(s). +# +# All QUIC registries include the following fields to support +# provisional registration: +# +# Value: The assigned codepoint. +# Status: "permanent" or "provisional". +# Specification: A reference to a publicly available specification for +# the value. +# Date: The date of the last update to the registration. +# Change Controller: The entity that is responsible for the definition +# of the registration. +# Contact: Contact details for the registrant. +# Notes: Supplementary notes about the registration. +# +# Provisional registrations MAY omit the Specification and Notes +# fields, plus any additional fields that might be required for a +# permanent registration. The Date field is not required as part of +# requesting a registration, as it is set to the date the registration +# is created or updated. + +[[spec]] +level = "MAY" +quote = ''' +Provisional registrations MAY omit the Specification and Notes +fields, plus any additional fields that might be required for a +permanent registration. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml new file mode 100644 index 0000000000..cfa3bee494 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.2.toml @@ -0,0 +1,65 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.2" + +# Selecting Codepoints +# +# New requests for codepoints from QUIC registries SHOULD use a +# randomly selected codepoint that excludes both existing allocations +# and the first unallocated codepoint in the selected space. Requests +# for multiple codepoints MAY use a contiguous range. This minimizes +# the risk that differing semantics are attributed to the same +# codepoint by different implementations. +# +# The use of the first unassigned codepoint is reserved for allocation +# using the Standards Action policy; see Section 4.9 of [RFC8126]. The +# early codepoint assignment process [EARLY-ASSIGN] can be used for +# these values. +# +# For codepoints that are encoded in variable-length integers +# (Section 16), such as frame types, codepoints that encode to four or +# eight bytes (that is, values 2^14 and above) SHOULD be used unless +# the usage is especially sensitive to having a longer encoding. +# +# Applications to register codepoints in QUIC registries MAY include a +# requested codepoint as part of the registration. IANA MUST allocate +# the selected codepoint if the codepoint is unassigned and the +# requirements of the registration policy are met. + +[[spec]] +level = "SHOULD" +quote = ''' +New requests for codepoints from QUIC registries SHOULD use a +randomly selected codepoint that excludes both existing allocations +and the first unallocated codepoint in the selected space. +''' + +[[spec]] +level = "MAY" +quote = ''' +Requests +for multiple codepoints MAY use a contiguous range. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +For codepoints that are encoded in variable-length integers +(Section 16), such as frame types, codepoints that encode to four or +eight bytes (that is, values 2^14 and above) SHOULD be used unless +the usage is especially sensitive to having a longer encoding. +''' + +[[spec]] +level = "MAY" +quote = ''' +Applications to register codepoints in QUIC registries MAY include a +requested codepoint as part of the registration. +''' + +[[spec]] +level = "MUST" +quote = ''' +IANA MUST allocate +the selected codepoint if the codepoint is unassigned and the +requirements of the registration policy are met. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml new file mode 100644 index 0000000000..504e36df08 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.3.toml @@ -0,0 +1,81 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.3" + +# Reclaiming Provisional Codepoints +# +# A request might be made to remove an unused provisional registration +# from the registry to reclaim space in a registry, or a portion of the +# registry (such as the 64-16383 range for codepoints that use +# variable-length encodings). This SHOULD be done only for the +# codepoints with the earliest recorded date, and entries that have +# been updated less than a year prior SHOULD NOT be reclaimed. +# +# A request to remove a codepoint MUST be reviewed by the designated +# experts. The experts MUST attempt to determine whether the codepoint +# is still in use. Experts are advised to contact the listed contacts +# for the registration, plus as wide a set of protocol implementers as +# possible in order to determine whether any use of the codepoint is +# known. The experts are also advised to allow at least four weeks for +# responses. +# +# If any use of the codepoints is identified by this search or a +# request to update the registration is made, the codepoint MUST NOT be +# reclaimed. Instead, the date on the registration is updated. A note +# might be added for the registration recording relevant information +# that was learned. +# +# If no use of the codepoint was identified and no request was made to +# update the registration, the codepoint MAY be removed from the +# registry. +# +# This review and consultation process also applies to requests to +# change a provisional registration into a permanent registration, +# except that the goal is not to determine whether there is no use of +# the codepoint but to determine that the registration is an accurate +# representation of any deployed usage. + +[[spec]] +level = "SHOULD" +quote = ''' +This SHOULD be done only for the +codepoints with the earliest recorded date, and entries that have +been updated less than a year prior SHOULD NOT be reclaimed. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +This SHOULD be done only for the +codepoints with the earliest recorded date, and entries that have +been updated less than a year prior SHOULD NOT be reclaimed. +''' + +[[spec]] +level = "MUST" +quote = ''' +A request to remove a codepoint MUST be reviewed by the designated +experts. +''' + +[[spec]] +level = "MUST" +quote = ''' +The experts MUST attempt to determine whether the codepoint +is still in use. +''' + +[[spec]] +level = "MUST" +quote = ''' +If any use of the codepoints is identified by this search or a +request to update the registration is made, the codepoint MUST NOT be +reclaimed. +''' + +[[spec]] +level = "MAY" +quote = ''' +If no use of the codepoint was identified and no request was made to +update the registration, the codepoint MAY be removed from the +registry. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml new file mode 100644 index 0000000000..bfd2cf9f6c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.1.4.toml @@ -0,0 +1,50 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.4" + +# Permanent Registrations +# +# Permanent registrations in QUIC registries use the Specification +# Required policy (Section 4.6 of [RFC8126]), unless otherwise +# specified. The designated expert or experts verify that a +# specification exists and is readily accessible. Experts are +# encouraged to be biased towards approving registrations unless they +# are abusive, frivolous, or actively harmful (not merely aesthetically +# displeasing or architecturally dubious). The creation of a registry +# MAY specify additional constraints on permanent registrations. +# +# The creation of a registry MAY identify a range of codepoints where +# registrations are governed by a different registration policy. For +# instance, the "QUIC Frame Types" registry (Section 22.4) has a +# stricter policy for codepoints in the range from 0 to 63. +# +# Any stricter requirements for permanent registrations do not prevent +# provisional registrations for affected codepoints. For instance, a +# provisional registration for a frame type of 61 could be requested. +# +# All registrations made by Standards Track publications MUST be +# permanent. +# +# All registrations in this document are assigned a permanent status +# and list a change controller of the IETF and a contact of the QUIC +# Working Group (quic@ietf.org). + +[[spec]] +level = "MAY" +quote = ''' +The creation of a registry +MAY specify additional constraints on permanent registrations. +''' + +[[spec]] +level = "MAY" +quote = ''' +The creation of a registry MAY identify a range of codepoints where +registrations are governed by a different registration policy. +''' + +[[spec]] +level = "MUST" +quote = ''' +All registrations made by Standards Track publications MUST be +permanent. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.2.toml new file mode 100644 index 0000000000..6b182c3d40 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.2.toml @@ -0,0 +1,37 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.2" + +# QUIC Versions Registry +# +# IANA has added a registry for "QUIC Versions" under a "QUIC" heading. +# +# The "QUIC Versions" registry governs a 32-bit space; see Section 15. +# This registry follows the registration policy from Section 22.1. +# Permanent registrations in this registry are assigned using the +# Specification Required policy (Section 4.6 of [RFC8126]). +# +# The codepoint of 0x00000001 for the protocol is assigned with +# permanent status to the protocol defined in this document. The +# codepoint of 0x00000000 is permanently reserved; the note for this +# codepoint indicates that this version is reserved for version +# negotiation. +# +# All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST +# NOT be assigned by IANA, and MUST NOT appear in the listing of +# assigned values. + +[[spec]] +level = "MUST" +quote = ''' +All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST +NOT be assigned by IANA, and MUST NOT appear in the listing of +assigned values. +''' + +[[spec]] +level = "MUST" +quote = ''' +All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST +NOT be assigned by IANA, and MUST NOT appear in the listing of +assigned values. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.3.toml new file mode 100644 index 0000000000..2c5913462f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.3.toml @@ -0,0 +1,89 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.3" + +# QUIC Transport Parameters Registry +# +# IANA has added a registry for "QUIC Transport Parameters" under a +# "QUIC" heading. +# +# The "QUIC Transport Parameters" registry governs a 62-bit space. +# This registry follows the registration policy from Section 22.1. +# Permanent registrations in this registry are assigned using the +# Specification Required policy (Section 4.6 of [RFC8126]), except for +# values between 0x00 and 0x3f (in hexadecimal), inclusive, which are +# assigned using Standards Action or IESG Approval as defined in +# Sections 4.9 and 4.10 of [RFC8126]. +# +# In addition to the fields listed in Section 22.1.1, permanent +# registrations in this registry MUST include the following field: +# +# Parameter Name: A short mnemonic for the parameter. +# +# The initial contents of this registry are shown in Table 6. +# +# +=======+=====================================+===============+ +# | Value | Parameter Name | Specification | +# +=======+=====================================+===============+ +# | 0x00 | original_destination_connection_id | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x01 | max_idle_timeout | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x02 | stateless_reset_token | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x03 | max_udp_payload_size | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x04 | initial_max_data | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x07 | initial_max_stream_data_uni | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x08 | initial_max_streams_bidi | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x09 | initial_max_streams_uni | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x0a | ack_delay_exponent | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x0b | max_ack_delay | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x0c | disable_active_migration | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x0d | preferred_address | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x0e | active_connection_id_limit | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x0f | initial_source_connection_id | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# | 0x10 | retry_source_connection_id | Section 18.2 | +# +-------+-------------------------------------+---------------+ +# +# Table 6: Initial QUIC Transport Parameters Registry Entries +# +# 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. + +[[spec]] +level = "MUST" +quote = ''' +In addition to the fields listed in Section 22.1.1, permanent +registrations in this registry MUST include the following field: +''' + +[[spec]] +level = "MUST" +quote = ''' +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. +''' + +[[spec]] +level = "MUST" +quote = ''' +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. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.4.toml new file mode 100644 index 0000000000..b3bc44b109 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.4.toml @@ -0,0 +1,48 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.4" + +# QUIC Frame Types Registry +# +# IANA has added a registry for "QUIC Frame Types" under a "QUIC" +# heading. +# +# The "QUIC Frame Types" registry governs a 62-bit space. This +# registry follows the registration policy from Section 22.1. +# Permanent registrations in this registry are assigned using the +# Specification Required policy (Section 4.6 of [RFC8126]), except for +# values between 0x00 and 0x3f (in hexadecimal), inclusive, which are +# assigned using Standards Action or IESG Approval as defined in +# Sections 4.9 and 4.10 of [RFC8126]. +# +# In addition to the fields listed in Section 22.1.1, permanent +# registrations in this registry MUST include the following field: +# +# Frame Type Name: A short mnemonic for the frame type. +# +# In addition to the advice in Section 22.1, specifications for new +# permanent registrations SHOULD describe the means by which an +# endpoint might determine that it can send the identified type of +# frame. An accompanying transport parameter registration is expected +# for most registrations; see Section 22.3. Specifications for +# permanent registrations also need to describe the format and assigned +# semantics of any fields in the frame. +# +# The initial contents of this registry are tabulated in Table 3. Note +# that the registry does not include the "Pkts" and "Spec" columns from +# Table 3. + +[[spec]] +level = "MUST" +quote = ''' +In addition to the fields listed in Section 22.1.1, permanent +registrations in this registry MUST include the following field: +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In addition to the advice in Section 22.1, specifications for new +permanent registrations SHOULD describe the means by which an +endpoint might determine that it can send the identified type of +frame. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.5.toml new file mode 100644 index 0000000000..5b6b20c562 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-22.5.toml @@ -0,0 +1,105 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.5" + +# QUIC Transport Error Codes Registry +# +# IANA has added a registry for "QUIC Transport Error Codes" under a +# "QUIC" heading. +# +# The "QUIC Transport Error Codes" registry governs a 62-bit space. +# This space is split into three ranges that are governed by different +# policies. Permanent registrations in this registry are assigned +# using the Specification Required policy (Section 4.6 of [RFC8126]), +# except for values between 0x00 and 0x3f (in hexadecimal), inclusive, +# which are assigned using Standards Action or IESG Approval as defined +# in Sections 4.9 and 4.10 of [RFC8126]. +# +# In addition to the fields listed in Section 22.1.1, permanent +# registrations in this registry MUST include the following fields: +# +# Code: A short mnemonic for the parameter. +# +# Description: A brief description of the error code semantics, which +# MAY be a summary if a specification reference is provided. +# +# The initial contents of this registry are shown in Table 7. +# +# +=======+===========================+================+==============+ +# |Value | Code |Description |Specification | +# +=======+===========================+================+==============+ +# |0x00 | NO_ERROR |No error |Section 20 | +# +-------+---------------------------+----------------+--------------+ +# |0x01 | INTERNAL_ERROR |Implementation |Section 20 | +# | | |error | | +# +-------+---------------------------+----------------+--------------+ +# |0x02 | CONNECTION_REFUSED |Server refuses a|Section 20 | +# | | |connection | | +# +-------+---------------------------+----------------+--------------+ +# |0x03 | FLOW_CONTROL_ERROR |Flow control |Section 20 | +# | | |error | | +# +-------+---------------------------+----------------+--------------+ +# |0x04 | STREAM_LIMIT_ERROR |Too many streams|Section 20 | +# | | |opened | | +# +-------+---------------------------+----------------+--------------+ +# |0x05 | STREAM_STATE_ERROR |Frame received |Section 20 | +# | | |in invalid | | +# | | |stream state | | +# +-------+---------------------------+----------------+--------------+ +# |0x06 | FINAL_SIZE_ERROR |Change to final |Section 20 | +# | | |size | | +# +-------+---------------------------+----------------+--------------+ +# |0x07 | FRAME_ENCODING_ERROR |Frame encoding |Section 20 | +# | | |error | | +# +-------+---------------------------+----------------+--------------+ +# |0x08 | TRANSPORT_PARAMETER_ERROR |Error in |Section 20 | +# | | |transport | | +# | | |parameters | | +# +-------+---------------------------+----------------+--------------+ +# |0x09 | CONNECTION_ID_LIMIT_ERROR |Too many |Section 20 | +# | | |connection IDs | | +# | | |received | | +# +-------+---------------------------+----------------+--------------+ +# |0x0a | PROTOCOL_VIOLATION |Generic protocol|Section 20 | +# | | |violation | | +# +-------+---------------------------+----------------+--------------+ +# |0x0b | INVALID_TOKEN |Invalid Token |Section 20 | +# | | |received | | +# +-------+---------------------------+----------------+--------------+ +# |0x0c | APPLICATION_ERROR |Application |Section 20 | +# | | |error | | +# +-------+---------------------------+----------------+--------------+ +# |0x0d | CRYPTO_BUFFER_EXCEEDED |CRYPTO data |Section 20 | +# | | |buffer | | +# | | |overflowed | | +# +-------+---------------------------+----------------+--------------+ +# |0x0e | KEY_UPDATE_ERROR |Invalid packet |Section 20 | +# | | |protection | | +# | | |update | | +# +-------+---------------------------+----------------+--------------+ +# |0x0f | AEAD_LIMIT_REACHED |Excessive use of|Section 20 | +# | | |packet | | +# | | |protection keys | | +# +-------+---------------------------+----------------+--------------+ +# |0x10 | NO_VIABLE_PATH |No viable |Section 20 | +# | | |network path | | +# | | |exists | | +# +-------+---------------------------+----------------+--------------+ +# |0x0100-| CRYPTO_ERROR |TLS alert code |Section 20 | +# |0x01ff | | | | +# +-------+---------------------------+----------------+--------------+ +# +# Table 7: Initial QUIC Transport Error Codes Registry Entries + +[[spec]] +level = "MUST" +quote = ''' +In addition to the fields listed in Section 22.1.1, permanent +registrations in this registry MUST include the following fields: +''' + +[[spec]] +level = "MAY" +quote = ''' +Description: A brief description of the error code semantics, which +MAY be a summary if a specification reference is provided. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.1.toml new file mode 100644 index 0000000000..92a6592d7d --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.1.toml @@ -0,0 +1,101 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.1" + +# Sending Stream States +# +# Figure 2 shows the states for the part of a stream that sends data to +# a peer. +# +# o +# | Create Stream (Sending) +# | Peer Creates Bidirectional Stream +# v +# +-------+ +# | Ready | Send RESET_STREAM +# | |-----------------------. +# +-------+ | +# | | +# | Send STREAM / | +# | STREAM_DATA_BLOCKED | +# v | +# +-------+ | +# | Send | Send RESET_STREAM | +# | |---------------------->| +# +-------+ | +# | | +# | Send STREAM + FIN | +# v v +# +-------+ +-------+ +# | Data | Send RESET_STREAM | Reset | +# | Sent |------------------>| Sent | +# +-------+ +-------+ +# | | +# | Recv All ACKs | Recv ACK +# v v +# +-------+ +-------+ +# | Data | | Reset | +# | Recvd | | Recvd | +# +-------+ +-------+ +# +# Figure 2: States for Sending Parts of Streams +# +# The sending part of a stream that the endpoint initiates (types 0 and +# 2 for clients, 1 and 3 for servers) is opened by the application. +# The "Ready" state represents a newly created stream that is able to +# accept data from the application. Stream data might be buffered in +# this state in preparation for sending. +# +# Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a +# sending part of a stream to enter the "Send" state. An +# implementation might choose to defer allocating a stream ID to a +# stream until it sends the first STREAM frame and enters this state, +# which can allow for better stream prioritization. +# +# The sending part of a bidirectional stream initiated by a peer (type +# 0 for a server, type 1 for a client) starts in the "Ready" state when +# the receiving part is created. +# +# In the "Send" state, an endpoint transmits -- and retransmits as +# necessary -- stream data in STREAM frames. The endpoint respects the +# flow control limits set by its peer and continues to accept and +# process MAX_STREAM_DATA frames. An endpoint in the "Send" state +# generates STREAM_DATA_BLOCKED frames if it is blocked from sending by +# stream flow control limits (Section 4.1). +# +# After the application indicates that all stream data has been sent +# and a STREAM frame containing the FIN bit is sent, the sending part +# of the stream enters the "Data Sent" state. From this state, the +# endpoint only retransmits stream data as necessary. The endpoint +# does not need to check flow control limits or send +# STREAM_DATA_BLOCKED frames for a stream in this state. +# MAX_STREAM_DATA frames might be received until the peer receives the +# final stream offset. The endpoint can safely ignore any +# MAX_STREAM_DATA frames it receives from its peer for a stream in this +# state. +# +# Once all stream data has been successfully acknowledged, the sending +# part of the stream enters the "Data Recvd" state, which is a terminal +# state. +# +# From any state that is one of "Ready", "Send", or "Data Sent", an +# application can signal that it wishes to abandon transmission of +# stream data. Alternatively, an endpoint might receive a STOP_SENDING +# frame from its peer. In either case, the endpoint sends a +# RESET_STREAM frame, which causes the stream to enter the "Reset Sent" +# state. +# +# An endpoint MAY send a RESET_STREAM as the first frame that mentions +# a stream; this causes the sending part of that stream to open and +# then immediately transition to the "Reset Sent" state. +# +# Once a packet containing a RESET_STREAM has been acknowledged, the +# sending part of the stream enters the "Reset Recvd" state, which is a +# terminal state. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY send a RESET_STREAM as the first frame that mentions +a stream; this causes the sending part of that stream to open and +then immediately transition to the "Reset Sent" state. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.2.toml new file mode 100644 index 0000000000..6a4de301af --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.2.toml @@ -0,0 +1,134 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.2" + +# Receiving Stream States +# +# Figure 3 shows the states for the part of a stream that receives data +# from a peer. The states for a receiving part of a stream mirror only +# some of the states of the sending part of the stream at the peer. +# The receiving part of a stream does not track states on the sending +# part that cannot be observed, such as the "Ready" state. Instead, +# the receiving part of a stream tracks the delivery of data to the +# application, some of which cannot be observed by the sender. +# +# o +# | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM +# | Create Bidirectional Stream (Sending) +# | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) +# | Create Higher-Numbered Stream +# v +# +-------+ +# | Recv | Recv RESET_STREAM +# | |-----------------------. +# +-------+ | +# | | +# | Recv STREAM + FIN | +# v | +# +-------+ | +# | Size | Recv RESET_STREAM | +# | Known |---------------------->| +# +-------+ | +# | | +# | Recv All Data | +# v v +# +-------+ Recv RESET_STREAM +-------+ +# | Data |--- (optional) --->| Reset | +# | Recvd | Recv All Data | Recvd | +# +-------+<-- (optional) ----+-------+ +# | | +# | App Read All Data | App Read Reset +# v v +# +-------+ +-------+ +# | Data | | Reset | +# | Read | | Read | +# +-------+ +-------+ +# +# Figure 3: States for Receiving Parts of Streams +# +# The receiving part of a stream initiated by a peer (types 1 and 3 for +# a client, or 0 and 2 for a server) is created when the first STREAM, +# STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that +# stream. For bidirectional streams initiated by a peer, receipt of a +# MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the +# stream also creates the receiving part. The initial state for the +# receiving part of a stream is "Recv". +# +# For a bidirectional stream, the receiving part enters the "Recv" +# state when the sending part initiated by the endpoint (type 0 for a +# client, type 1 for a server) enters the "Ready" state. +# +# An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or +# STOP_SENDING frame is received from the peer for that stream. +# Receiving a MAX_STREAM_DATA frame for an unopened stream indicates +# that the remote peer has opened the stream and is providing flow +# control credit. Receiving a STOP_SENDING frame for an unopened +# stream indicates that the remote peer no longer wishes to receive +# data on this stream. Either frame might arrive before a STREAM or +# STREAM_DATA_BLOCKED frame if packets are lost or reordered. +# +# Before a stream is created, all streams of the same type with lower- +# numbered stream IDs MUST be created. This ensures that the creation +# order for streams is consistent on both endpoints. +# +# In the "Recv" state, the endpoint receives STREAM and +# STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be +# reassembled into the correct order for delivery to the application. +# As data is consumed by the application and buffer space becomes +# available, the endpoint sends MAX_STREAM_DATA frames to allow the +# peer to send more data. +# +# When a STREAM frame with a FIN bit is received, the final size of the +# stream is known; see Section 4.5. The receiving part of the stream +# then enters the "Size Known" state. In this state, the endpoint no +# longer needs to send MAX_STREAM_DATA frames; it only receives any +# retransmissions of stream data. +# +# Once all data for the stream has been received, the receiving part +# enters the "Data Recvd" state. This might happen as a result of +# receiving the same STREAM frame that causes the transition to "Size +# Known". After all data has been received, any STREAM or +# STREAM_DATA_BLOCKED frames for the stream can be discarded. +# +# The "Data Recvd" state persists until stream data has been delivered +# to the application. Once stream data has been delivered, the stream +# enters the "Data Read" state, which is a terminal state. +# +# Receiving a RESET_STREAM frame in the "Recv" or "Size Known" state +# causes the stream to enter the "Reset Recvd" state. This might cause +# the delivery of stream data to the application to be interrupted. +# +# It is possible that all stream data has already been received when a +# RESET_STREAM is received (that is, in the "Data Recvd" state). +# Similarly, it is possible for remaining stream data to arrive after +# receiving a RESET_STREAM frame (the "Reset Recvd" state). An +# implementation is free to manage this situation as it chooses. +# +# Sending a RESET_STREAM means that an endpoint cannot guarantee +# delivery of stream data; however, there is no requirement that stream +# data not be delivered if a RESET_STREAM is received. An +# implementation MAY interrupt delivery of stream data, discard any +# data that was not consumed, and signal the receipt of the +# RESET_STREAM. A RESET_STREAM signal might be suppressed or withheld +# if stream data is completely received and is buffered to be read by +# the application. If the RESET_STREAM is suppressed, the receiving +# part of the stream remains in "Data Recvd". +# +# Once the application receives the signal indicating that the stream +# was reset, the receiving part of the stream transitions to the "Reset +# Read" state, which is a terminal state. + +[[spec]] +level = "MUST" +quote = ''' +Before a stream is created, all streams of the same type with lower- +numbered stream IDs MUST be created. +''' + +[[spec]] +level = "MAY" +quote = ''' +An +implementation MAY interrupt delivery of stream data, discard any +data that was not consumed, and signal the receipt of the +RESET_STREAM. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml new file mode 100644 index 0000000000..b45389a9e7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.3.toml @@ -0,0 +1,51 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.3" + +# Permitted Frame Types +# +# The sender of a stream sends just three frame types that affect the +# state of a stream at either the sender or the receiver: STREAM +# (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM +# (Section 19.4). +# +# A sender MUST NOT send any of these frames from a terminal state +# ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send a STREAM or +# STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or +# any terminal state -- that is, after sending a RESET_STREAM frame. A +# receiver could receive any of these three frames in any state, due to +# the possibility of delayed delivery of packets carrying them. +# +# The receiver of a stream sends MAX_STREAM_DATA frames (Section 19.10) +# and STOP_SENDING frames (Section 19.5). +# +# The receiver only sends MAX_STREAM_DATA frames in the "Recv" state. +# A receiver MAY send a STOP_SENDING frame in any state where it has +# not received a RESET_STREAM frame -- that is, states other than +# "Reset Recvd" or "Reset Read". However, there is little value in +# sending a STOP_SENDING frame in the "Data Recvd" state, as all stream +# data has been received. A sender could receive either of these two +# types of frames in any state as a result of delayed delivery of +# packets. + +[[spec]] +level = "MUST" +quote = ''' +A sender MUST NOT send any of these frames from a terminal state +("Data Recvd" or "Reset Recvd"). +''' + +[[spec]] +level = "MUST" +quote = ''' +A sender MUST NOT send a STREAM or +STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or +any terminal state -- that is, after sending a RESET_STREAM frame. +''' + +[[spec]] +level = "MAY" +quote = ''' +A receiver MAY send a STOP_SENDING frame in any state where it has +not received a RESET_STREAM frame -- that is, states other than +"Reset Recvd" or "Reset Read". +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml new file mode 100644 index 0000000000..9de78247b9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-3.5.toml @@ -0,0 +1,104 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.5" + +# Solicited State Transitions +# +# If an application is no longer interested in the data it is receiving +# on a stream, it can abort reading the stream and specify an +# application error code. +# +# If the stream is in the "Recv" or "Size Known" state, the transport +# SHOULD signal this by sending a STOP_SENDING frame to prompt closure +# of the stream in the opposite direction. This typically indicates +# that the receiving application is no longer reading data it receives +# from the stream, but it is not a guarantee that incoming data will be +# ignored. +# +# STREAM frames received after sending a STOP_SENDING frame are still +# counted toward connection and stream flow control, even though these +# frames can be discarded upon receipt. +# +# A STOP_SENDING frame requests that the receiving endpoint send a +# RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame +# MUST send a RESET_STREAM frame if the stream is in the "Ready" or +# "Send" state. If the stream is in the "Data Sent" state, the +# endpoint MAY defer sending the RESET_STREAM frame until the packets +# containing outstanding data are acknowledged or declared lost. If +# any outstanding data is declared lost, the endpoint SHOULD send a +# RESET_STREAM frame instead of retransmitting the data. +# +# An endpoint SHOULD copy the error code from the STOP_SENDING frame to +# the RESET_STREAM frame it sends, but it can use any application error +# code. An endpoint that sends a STOP_SENDING frame MAY ignore the +# error code in any RESET_STREAM frames subsequently received for that +# stream. +# +# STOP_SENDING SHOULD only be sent for a stream that has not been reset +# by the peer. STOP_SENDING is most useful for streams in the "Recv" +# or "Size Known" state. +# +# An endpoint is expected to send another STOP_SENDING frame if a +# packet containing a previous STOP_SENDING is lost. However, once +# either all stream data or a RESET_STREAM frame has been received for +# the stream -- that is, the stream is in any state other than "Recv" +# or "Size Known" -- sending a STOP_SENDING frame is unnecessary. +# +# An endpoint that wishes to terminate both directions of a +# bidirectional stream can terminate one direction by sending a +# RESET_STREAM frame, and it can encourage prompt termination in the +# opposite direction by sending a STOP_SENDING frame. + +[[spec]] +level = "SHOULD" +quote = ''' +If the stream is in the "Recv" or "Size Known" state, the transport +SHOULD signal this by sending a STOP_SENDING frame to prompt closure +of the stream in the opposite direction. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that receives a STOP_SENDING frame +MUST send a RESET_STREAM frame if the stream is in the "Ready" or +"Send" state. +''' + +[[spec]] +level = "MAY" +quote = ''' +If the stream is in the "Data Sent" state, the +endpoint MAY defer sending the RESET_STREAM frame until the packets +containing outstanding data are acknowledged or declared lost. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If +any outstanding data is declared lost, the endpoint SHOULD send a +RESET_STREAM frame instead of retransmitting the data. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD copy the error code from the STOP_SENDING frame to +the RESET_STREAM frame it sends, but it can use any application error +code. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint that sends a STOP_SENDING frame MAY ignore the +error code in any RESET_STREAM frames subsequently received for that +stream. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +STOP_SENDING SHOULD only be sent for a stream that has not been reset +by the peer. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml new file mode 100644 index 0000000000..7a0e5c033a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.1.toml @@ -0,0 +1,99 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.1" + +# Data Flow Control +# +# QUIC employs a limit-based flow control scheme where a receiver +# advertises the limit of total bytes it is prepared to receive on a +# given stream or for the entire connection. This leads to two levels +# of data flow control in QUIC: +# +# * Stream flow control, which prevents a single stream from consuming +# the entire receive buffer for a connection by limiting the amount +# of data that can be sent on each stream. +# +# * Connection flow control, which prevents senders from exceeding a +# receiver's buffer capacity for the connection by limiting the +# total bytes of stream data sent in STREAM frames on all streams. +# +# Senders MUST NOT send data in excess of either limit. +# +# A receiver sets initial limits for all streams through transport +# parameters during the handshake (Section 7.4). Subsequently, a +# receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA +# frames (Section 19.9) to the sender to advertise larger limits. +# +# A receiver can advertise a larger limit for a stream by sending a +# MAX_STREAM_DATA frame with the corresponding stream ID. A +# MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a +# stream. A receiver could determine the flow control offset to be +# advertised based on the current offset of data consumed on that +# stream. +# +# A receiver can advertise a larger limit for a connection by sending a +# MAX_DATA frame, which indicates the maximum of the sum of the +# absolute byte offsets of all streams. A receiver maintains a +# cumulative sum of bytes received on all streams, which is used to +# check for violations of the advertised connection or stream data +# limits. A receiver could determine the maximum data limit to be +# advertised based on the sum of bytes consumed on all streams. +# +# Once a receiver advertises a limit for the connection or a stream, it +# is not an error to advertise a smaller limit, but the smaller limit +# has no effect. +# +# A receiver MUST close the connection with an error of type +# FLOW_CONTROL_ERROR if the sender violates the advertised connection +# or stream data limits; see Section 11 for details on error handling. +# +# A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do +# not increase flow control limits. +# +# If a sender has sent data up to the limit, it will be unable to send +# new data and is considered blocked. A sender SHOULD send a +# STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver +# that it has data to write but is blocked by flow control limits. If +# a sender is blocked for a period longer than the idle timeout +# (Section 10.1), the receiver might close the connection even when the +# sender has data that is available for transmission. To keep the +# connection from closing, a sender that is flow control limited SHOULD +# periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it +# has no ack-eliciting packets in flight. + +[[spec]] +level = "MUST" +quote = ''' +Senders MUST NOT send data in excess of either limit. +''' + +[[spec]] +level = "MUST" +quote = ''' +A receiver MUST close the connection with an error of type +FLOW_CONTROL_ERROR if the sender violates the advertised connection +or stream data limits; see Section 11 for details on error handling. +''' + +[[spec]] +level = "MUST" +quote = ''' +A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do +not increase flow control limits. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD send a +STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver +that it has data to write but is blocked by flow control limits. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +To keep the +connection from closing, a sender that is flow control limited SHOULD +periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it +has no ack-eliciting packets in flight. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.2.toml new file mode 100644 index 0000000000..beffba76e6 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.2.toml @@ -0,0 +1,58 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.2" + +# Increasing Flow Control Limits +# +# Implementations decide when and how much credit to advertise in +# MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few +# considerations. +# +# To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or +# MAX_DATA frame multiple times within a round trip or send it early +# enough to allow time for loss of the frame and subsequent recovery. +# +# Control frames contribute to connection overhead. Therefore, +# frequently sending MAX_STREAM_DATA and MAX_DATA frames with small +# changes is undesirable. On the other hand, if updates are less +# frequent, larger increments to limits are necessary to avoid blocking +# a sender, requiring larger resource commitments at the receiver. +# There is a trade-off between resource commitment and overhead when +# determining how large a limit is advertised. +# +# A receiver can use an autotuning mechanism to tune the frequency and +# amount of advertised additional credit based on a round-trip time +# estimate and the rate at which the receiving application consumes +# data, similar to common TCP implementations. As an optimization, an +# endpoint could send frames related to flow control only when there +# are other frames to send, ensuring that flow control does not cause +# extra packets to be sent. +# +# A blocked sender is not required to send STREAM_DATA_BLOCKED or +# DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a +# STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a +# MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the +# sender being blocked for the rest of the connection. Even if the +# sender sends these frames, waiting for them will result in the sender +# being blocked for at least an entire round trip. +# +# When a sender receives credit after being blocked, it might be able +# to send a large amount of data in response, resulting in short-term +# congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of +# how a sender can avoid this congestion. + +[[spec]] +level = "MAY" +quote = ''' +To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or +MAX_DATA frame multiple times within a round trip or send it early +enough to allow time for loss of the frame and subsequent recovery. +''' + +[[spec]] +level = "MUST" +quote = ''' +Therefore, a receiver MUST NOT wait for a +STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a +MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the +sender being blocked for the rest of the connection. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.4.toml new file mode 100644 index 0000000000..71304f3897 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.4.toml @@ -0,0 +1,26 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.4" + +# Handling Stream Cancellation +# +# Endpoints need to eventually agree on the amount of flow control +# credit that has been consumed on every stream, to be able to account +# for all bytes for connection-level flow control. +# +# On receipt of a RESET_STREAM frame, an endpoint will tear down state +# for the matching stream and ignore further data arriving on that +# stream. +# +# RESET_STREAM terminates one direction of a stream abruptly. For a +# bidirectional stream, RESET_STREAM has no effect on data flow in the +# opposite direction. Both endpoints MUST maintain flow control state +# for the stream in the unterminated direction until that direction +# enters a terminal state. + +[[spec]] +level = "MUST" +quote = ''' +Both endpoints MUST maintain flow control state +for the stream in the unterminated direction until that direction +enters a terminal state. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml new file mode 100644 index 0000000000..53c359f528 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.5.toml @@ -0,0 +1,71 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.5" + +# Stream Final Size +# +# The final size is the amount of flow control credit that is consumed +# by a stream. Assuming that every contiguous byte on the stream was +# sent once, the final size is the number of bytes sent. More +# generally, this is one higher than the offset of the byte with the +# largest offset sent on the stream, or zero if no bytes were sent. +# +# A sender always communicates the final size of a stream to the +# receiver reliably, no matter how the stream is terminated. The final +# size is the sum of the Offset and Length fields of a STREAM frame +# with a FIN flag, noting that these fields might be implicit. +# Alternatively, the Final Size field of a RESET_STREAM frame carries +# this value. This guarantees that both endpoints agree on how much +# flow control credit was consumed by the sender on that stream. +# +# An endpoint will know the final size for a stream when the receiving +# part of the stream enters the "Size Known" or "Reset Recvd" state +# (Section 3). The receiver MUST use the final size of the stream to +# account for all bytes sent on the stream in its connection-level flow +# controller. +# +# An endpoint MUST NOT send data on a stream at or beyond the final +# size. +# +# Once a final size for a stream is known, it cannot change. If a +# RESET_STREAM or STREAM frame is received indicating a change in the +# final size for the stream, an endpoint SHOULD respond with an error +# of type FINAL_SIZE_ERROR; see Section 11 for details on error +# handling. A receiver SHOULD treat receipt of data at or beyond the +# final size as an error of type FINAL_SIZE_ERROR, even after a stream +# is closed. Generating these errors is not mandatory, because +# requiring that an endpoint generate these errors also means that the +# endpoint needs to maintain the final size state for closed streams, +# which could mean a significant state commitment. + +[[spec]] +level = "MUST" +quote = ''' +The receiver MUST use the final size of the stream to +account for all bytes sent on the stream in its connection-level flow +controller. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send data on a stream at or beyond the final +size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If a +RESET_STREAM or STREAM frame is received indicating a change in the +final size for the stream, an endpoint SHOULD respond with an error +of type FINAL_SIZE_ERROR; see Section 11 for details on error +handling. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A receiver SHOULD treat receipt of data at or beyond the +final size as an error of type FINAL_SIZE_ERROR, even after a stream +is closed. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml new file mode 100644 index 0000000000..72a4c38bd9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.6.toml @@ -0,0 +1,93 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.6" + +# Controlling Concurrency +# +# An endpoint limits the cumulative number of incoming streams a peer +# can open. Only streams with a stream ID less than "(max_streams * 4 +# + first_stream_id_of_type)" can be opened; see Table 1. Initial +# limits are set in the transport parameters; see Section 18.2. +# Subsequent limits are advertised using MAX_STREAMS frames; see +# Section 19.11. Separate limits apply to unidirectional and +# bidirectional streams. +# +# If a max_streams transport parameter or a MAX_STREAMS frame is +# received with a value greater than 2^60, this would allow a maximum +# stream ID that cannot be expressed as a variable-length integer; see +# Section 16. If either is received, the connection MUST be closed +# immediately with a connection error of type TRANSPORT_PARAMETER_ERROR +# if the offending value was received in a transport parameter or of +# type FRAME_ENCODING_ERROR if it was received in a frame; see +# Section 10.2. +# +# Endpoints MUST NOT exceed the limit set by their peer. An endpoint +# that receives a frame with a stream ID exceeding the limit it has +# sent MUST treat this as a connection error of type +# STREAM_LIMIT_ERROR; see Section 11 for details on error handling. +# +# Once a receiver advertises a stream limit using the MAX_STREAMS +# frame, advertising a smaller limit has no effect. MAX_STREAMS frames +# that do not increase the stream limit MUST be ignored. +# +# As with stream and connection flow control, this document leaves +# implementations to decide when and how many streams should be +# advertised to a peer via MAX_STREAMS. Implementations might choose +# to increase limits as streams are closed, to keep the number of +# streams available to peers roughly consistent. +# +# An endpoint that is unable to open a new stream due to the peer's +# limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This +# signal is considered useful for debugging. An endpoint MUST NOT wait +# to receive this signal before advertising additional credit, since +# doing so will mean that the peer will be blocked for at least an +# entire round trip, and potentially indefinitely if the peer chooses +# not to send STREAMS_BLOCKED frames. + +[[spec]] +level = "MUST" +quote = ''' +If either is received, the connection MUST be closed +immediately with a connection error of type TRANSPORT_PARAMETER_ERROR +if the offending value was received in a transport parameter or of +type FRAME_ENCODING_ERROR if it was received in a frame; see +Section 10.2. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST NOT exceed the limit set by their peer. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint +that receives a frame with a stream ID exceeding the limit it has +sent MUST treat this as a connection error of type +STREAM_LIMIT_ERROR; see Section 11 for details on error handling. +''' + +[[spec]] +level = "MUST" +quote = ''' +MAX_STREAMS frames +that do not increase the stream limit MUST be ignored. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint that is unable to open a new stream due to the peer's +limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT wait +to receive this signal before advertising additional credit, since +doing so will mean that the peer will be blocked for at least an +entire round trip, and potentially indefinitely if the peer chooses +not to send STREAMS_BLOCKED frames. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.toml new file mode 100644 index 0000000000..e5112d48da --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-4.toml @@ -0,0 +1,32 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-4" + +# Flow Control +# +# Receivers need to limit the amount of data that they are required to +# buffer, in order to prevent a fast sender from overwhelming them or a +# malicious sender from consuming a large amount of memory. To enable +# a receiver to limit memory commitments for a connection, streams are +# flow controlled both individually and across a connection as a whole. +# A QUIC receiver controls the maximum amount of data the sender can +# send on a stream as well as across all streams at any time, as +# described in Sections 4.1 and 4.2. +# +# Similarly, to limit concurrency within a connection, a QUIC endpoint +# controls the maximum cumulative number of streams that its peer can +# initiate, as described in Section 4.6. +# +# Data sent in CRYPTO frames is not flow controlled in the same way as +# stream data. QUIC relies on the cryptographic protocol +# implementation to avoid excessive buffering of data; see [QUIC-TLS]. +# To avoid excessive buffering at multiple layers, QUIC implementations +# SHOULD provide an interface for the cryptographic protocol +# implementation to communicate its buffering limits. + +[[spec]] +level = "SHOULD" +quote = ''' +To avoid excessive buffering at multiple layers, QUIC implementations +SHOULD provide an interface for the cryptographic protocol +implementation to communicate its buffering limits. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml new file mode 100644 index 0000000000..b24aa47850 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.1.toml @@ -0,0 +1,160 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.1.1" + +# Issuing Connection IDs +# +# Each connection ID has an associated sequence number to assist in +# detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer +# to the same value. The initial connection ID issued by an endpoint +# is sent in the Source Connection ID field of the long packet header +# (Section 17.2) during the handshake. The sequence number of the +# initial connection ID is 0. If the preferred_address transport +# parameter is sent, the sequence number of the supplied connection ID +# is 1. +# +# Additional connection IDs are communicated to the peer using +# NEW_CONNECTION_ID frames (Section 19.15). The sequence number on +# each newly issued connection ID MUST increase by 1. The connection +# ID that a client selects for the first Destination Connection ID +# field it sends and any connection ID provided by a Retry packet are +# not assigned sequence numbers. +# +# When an endpoint issues a connection ID, it MUST accept packets that +# carry this connection ID for the duration of the connection or until +# its peer invalidates the connection ID via a RETIRE_CONNECTION_ID +# frame (Section 19.16). Connection IDs that are issued and not +# retired are considered active; any active connection ID is valid for +# use with the current connection at any time, in any packet type. +# This includes the connection ID issued by the server via the +# preferred_address transport parameter. +# +# An endpoint SHOULD ensure that its peer has a sufficient number of +# available and unused connection IDs. Endpoints advertise the number +# of active connection IDs they are willing to maintain using the +# active_connection_id_limit transport parameter. An endpoint MUST NOT +# provide more connection IDs than the peer's limit. An endpoint MAY +# send connection IDs that temporarily exceed a peer's limit if the +# NEW_CONNECTION_ID frame also requires the retirement of any excess, +# by including a sufficiently large value in the Retire Prior To field. +# +# A NEW_CONNECTION_ID frame might cause an endpoint to add some active +# connection IDs and retire others based on the value of the Retire +# Prior To field. After processing a NEW_CONNECTION_ID frame and +# adding and retiring active connection IDs, if the number of active +# connection IDs exceeds the value advertised in its +# active_connection_id_limit transport parameter, an endpoint MUST +# close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. +# +# An endpoint SHOULD supply a new connection ID when the peer retires a +# connection ID. If an endpoint provided fewer connection IDs than the +# peer's active_connection_id_limit, it MAY supply a new connection ID +# when it receives a packet with a previously unused connection ID. An +# endpoint MAY limit the total number of connection IDs issued for each +# connection to avoid the risk of running out of connection IDs; see +# Section 10.3.2. An endpoint MAY also limit the issuance of +# connection IDs to reduce the amount of per-path state it maintains, +# such as path validation status, as its peer might interact with it +# over as many paths as there are issued connection IDs. +# +# An endpoint that initiates migration and requires non-zero-length +# connection IDs SHOULD ensure that the pool of connection IDs +# available to its peer allows the peer to use a new connection ID on +# migration, as the peer will be unable to respond if the pool is +# exhausted. +# +# An endpoint that selects a zero-length connection ID during the +# handshake cannot issue a new connection ID. A zero-length +# Destination Connection ID field is used in all packets sent toward +# such an endpoint over any network path. + +[[spec]] +level = "MUST" +quote = ''' +The sequence number on +each newly issued connection ID MUST increase by 1. +''' + +[[spec]] +level = "MUST" +quote = ''' +When an endpoint issues a connection ID, it MUST accept packets that +carry this connection ID for the duration of the connection or until +its peer invalidates the connection ID via a RETIRE_CONNECTION_ID +frame (Section 19.16). +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD ensure that its peer has a sufficient number of +available and unused connection IDs. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT +provide more connection IDs than the peer's limit. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY +send connection IDs that temporarily exceed a peer's limit if the +NEW_CONNECTION_ID frame also requires the retirement of any excess, +by including a sufficiently large value in the Retire Prior To field. +''' + +[[spec]] +level = "MUST" +quote = ''' +After processing a NEW_CONNECTION_ID frame and +adding and retiring active connection IDs, if the number of active +connection IDs exceeds the value advertised in its +active_connection_id_limit transport parameter, an endpoint MUST +close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD supply a new connection ID when the peer retires a +connection ID. +''' + +[[spec]] +level = "MAY" +quote = ''' +If an endpoint provided fewer connection IDs than the +peer's active_connection_id_limit, it MAY supply a new connection ID +when it receives a packet with a previously unused connection ID. +''' + +[[spec]] +level = "MAY" +quote = ''' +An +endpoint MAY limit the total number of connection IDs issued for each +connection to avoid the risk of running out of connection IDs; see +Section 10.3.2. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY also limit the issuance of +connection IDs to reduce the amount of per-path state it maintains, +such as path validation status, as its peer might interact with it +over as many paths as there are issued connection IDs. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint that initiates migration and requires non-zero-length +connection IDs SHOULD ensure that the pool of connection IDs +available to its peer allows the peer to use a new connection ID on +migration, as the peer will be unable to respond if the pool is +exhausted. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml new file mode 100644 index 0000000000..d9a0cbfae5 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.2.toml @@ -0,0 +1,121 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.1.2" + +# Consuming and Retiring Connection IDs +# +# An endpoint can change the connection ID it uses for a peer to +# another available one at any time during the connection. An endpoint +# consumes connection IDs in response to a migrating peer; see +# Section 9.5 for more details. +# +# An endpoint maintains a set of connection IDs received from its peer, +# any of which it can use when sending packets. When the endpoint +# wishes to remove a connection ID from use, it sends a +# RETIRE_CONNECTION_ID frame to its peer. Sending a +# RETIRE_CONNECTION_ID frame indicates that the connection ID will not +# be used again and requests that the peer replace it with a new +# connection ID using a NEW_CONNECTION_ID frame. +# +# As discussed in Section 9.5, endpoints limit the use of a connection +# ID to packets sent from a single local address to a single +# destination address. Endpoints SHOULD retire connection IDs when +# they are no longer actively using either the local or destination +# address for which the connection ID was used. +# +# An endpoint might need to stop accepting previously issued connection +# IDs in certain circumstances. Such an endpoint can cause its peer to +# retire connection IDs by sending a NEW_CONNECTION_ID frame with an +# increased Retire Prior To field. The endpoint SHOULD continue to +# accept the previously issued connection IDs until they are retired by +# the peer. If the endpoint can no longer process the indicated +# connection IDs, it MAY close the connection. +# +# Upon receipt of an increased Retire Prior To field, the peer MUST +# stop using the corresponding connection IDs and retire them with +# RETIRE_CONNECTION_ID frames before adding the newly provided +# connection ID to the set of active connection IDs. This ordering +# allows an endpoint to replace all active connection IDs without the +# possibility of a peer having no available connection IDs and without +# exceeding the limit the peer sets in the active_connection_id_limit +# transport parameter; see Section 18.2. Failure to cease using the +# connection IDs when requested can result in connection failures, as +# the issuing endpoint might be unable to continue using the connection +# IDs with the active connection. +# +# An endpoint SHOULD limit the number of connection IDs it has retired +# locally for which RETIRE_CONNECTION_ID frames have not yet been +# acknowledged. An endpoint SHOULD allow for sending and tracking a +# number of RETIRE_CONNECTION_ID frames of at least twice the value of +# the active_connection_id_limit transport parameter. An endpoint MUST +# NOT forget a connection ID without retiring it, though it MAY choose +# to treat having connection IDs in need of retirement that exceed this +# limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. +# +# Endpoints SHOULD NOT issue updates of the Retire Prior To field +# before receiving RETIRE_CONNECTION_ID frames that retire all +# connection IDs indicated by the previous Retire Prior To value. + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD retire connection IDs when +they are no longer actively using either the local or destination +address for which the connection ID was used. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The endpoint SHOULD continue to +accept the previously issued connection IDs until they are retired by +the peer. +''' + +[[spec]] +level = "MAY" +quote = ''' +If the endpoint can no longer process the indicated +connection IDs, it MAY close the connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +Upon receipt of an increased Retire Prior To field, the peer MUST +stop using the corresponding connection IDs and retire them with +RETIRE_CONNECTION_ID frames before adding the newly provided +connection ID to the set of active connection IDs. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD limit the number of connection IDs it has retired +locally for which RETIRE_CONNECTION_ID frames have not yet been +acknowledged. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD allow for sending and tracking a +number of RETIRE_CONNECTION_ID frames of at least twice the value of +the active_connection_id_limit transport parameter. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST +NOT forget a connection ID without retiring it, though it MAY choose +to treat having connection IDs in need of retirement that exceed this +limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD NOT issue updates of the Retire Prior To field +before receiving RETIRE_CONNECTION_ID frames that retire all +connection IDs indicated by the previous Retire Prior To value. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml new file mode 100644 index 0000000000..2e8cb651a2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.1.toml @@ -0,0 +1,85 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.1" + +# Connection ID +# +# Each connection possesses a set of connection identifiers, or +# connection IDs, each of which can identify the connection. +# Connection IDs are independently selected by endpoints; each endpoint +# selects the connection IDs that its peer uses. +# +# The primary function of a connection ID is to ensure that changes in +# addressing at lower protocol layers (UDP, IP) do not cause packets +# for a QUIC connection to be delivered to the wrong endpoint. Each +# endpoint selects connection IDs using an implementation-specific (and +# perhaps deployment-specific) method that will allow packets with that +# connection ID to be routed back to the endpoint and to be identified +# by the endpoint upon receipt. +# +# Multiple connection IDs are used so that endpoints can send packets +# that cannot be identified by an observer as being for the same +# connection without cooperation from an endpoint; see Section 9.5. +# +# Connection IDs MUST NOT contain any information that can be used by +# an external observer (that is, one that does not cooperate with the +# issuer) to correlate them with other connection IDs for the same +# connection. As a trivial example, this means the same connection ID +# MUST NOT be issued more than once on the same connection. +# +# Packets with long headers include Source Connection ID and +# Destination Connection ID fields. These fields are used to set the +# connection IDs for new connections; see Section 7.2 for details. +# +# Packets with short headers (Section 17.3) only include the +# Destination Connection ID and omit the explicit length. The length +# of the Destination Connection ID field is expected to be known to +# endpoints. Endpoints using a load balancer that routes based on +# connection ID could agree with the load balancer on a fixed length +# for connection IDs or agree on an encoding scheme. A fixed portion +# could encode an explicit length, which allows the entire connection +# ID to vary in length and still be used by the load balancer. +# +# A Version Negotiation (Section 17.2.1) packet echoes the connection +# IDs selected by the client, both to ensure correct routing toward the +# client and to demonstrate that the packet is in response to a packet +# sent by the client. +# +# A zero-length connection ID can be used when a connection ID is not +# needed to route to the correct endpoint. However, multiplexing +# connections on the same local IP address and port while using zero- +# length connection IDs will cause failures in the presence of peer +# connection migration, NAT rebinding, and client port reuse. An +# endpoint MUST NOT use the same IP address and port for multiple +# concurrent connections with zero-length connection IDs, unless it is +# certain that those protocol features are not in use. +# +# When an endpoint uses a non-zero-length connection ID, it needs to +# ensure that the peer has a supply of connection IDs from which to +# choose for packets sent to the endpoint. These connection IDs are +# supplied by the endpoint using the NEW_CONNECTION_ID frame +# (Section 19.15). + +[[spec]] +level = "MUST" +quote = ''' +Connection IDs MUST NOT contain any information that can be used by +an external observer (that is, one that does not cooperate with the +issuer) to correlate them with other connection IDs for the same +connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +As a trivial example, this means the same connection ID +MUST NOT be issued more than once on the same connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +An +endpoint MUST NOT use the same IP address and port for multiple +concurrent connections with zero-length connection IDs, unless it is +certain that those protocol features are not in use. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.1.toml new file mode 100644 index 0000000000..c19086d71f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.1.toml @@ -0,0 +1,40 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2.1" + +# Client Packet Handling +# +# Valid packets sent to clients always include a Destination Connection +# ID that matches a value the client selects. Clients that choose to +# receive zero-length connection IDs can use the local address and port +# to identify a connection. Packets that do not match an existing +# connection -- based on Destination Connection ID or, if this value is +# zero length, local IP address and port -- are discarded. +# +# Due to packet reordering or loss, a client might receive packets for +# a connection that are encrypted with a key it has not yet computed. +# The client MAY drop these packets, or it MAY buffer them in +# anticipation of later packets that allow it to compute the key. +# +# If a client receives a packet that uses a different version than it +# initially selected, it MUST discard that packet. + +[[spec]] +level = "MAY" +quote = ''' +The client MAY drop these packets, or it MAY buffer them in +anticipation of later packets that allow it to compute the key. +''' + +[[spec]] +level = "MAY" +quote = ''' +The client MAY drop these packets, or it MAY buffer them in +anticipation of later packets that allow it to compute the key. +''' + +[[spec]] +level = "MUST" +quote = ''' +If a client receives a packet that uses a different version than it +initially selected, it MUST discard that packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml new file mode 100644 index 0000000000..3eda04e253 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.2.toml @@ -0,0 +1,100 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2.2" + +# Server Packet Handling +# +# If a server receives a packet that indicates an unsupported version +# and if the packet is large enough to initiate a new connection for +# any supported version, the server SHOULD send a Version Negotiation +# packet as described in Section 6.1. A server MAY limit the number of +# packets to which it responds with a Version Negotiation packet. +# Servers MUST drop smaller packets that specify unsupported versions. +# +# The first packet for an unsupported version can use different +# semantics and encodings for any version-specific field. In +# particular, different packet protection keys might be used for +# different versions. Servers that do not support a particular version +# are unlikely to be able to decrypt the payload of the packet or +# properly interpret the result. Servers SHOULD respond with a Version +# Negotiation packet, provided that the datagram is sufficiently long. +# +# Packets with a supported version, or no Version field, are matched to +# a connection using the connection ID or -- for packets with zero- +# length connection IDs -- the local address and port. These packets +# are processed using the selected connection; otherwise, the server +# continues as described below. +# +# If the packet is an Initial packet fully conforming with the +# specification, the server proceeds with the handshake (Section 7). +# This commits the server to the version that the client selected. +# +# If a server refuses to accept a new connection, it SHOULD send an +# Initial packet containing a CONNECTION_CLOSE frame with error code +# CONNECTION_REFUSED. +# +# If the packet is a 0-RTT packet, the server MAY buffer a limited +# number of these packets in anticipation of a late-arriving Initial +# packet. Clients are not able to send Handshake packets prior to +# receiving a server response, so servers SHOULD ignore any such +# packets. +# +# Servers MUST drop incoming packets under all other circumstances. + +[[spec]] +level = "SHOULD" +quote = ''' +If a server receives a packet that indicates an unsupported version +and if the packet is large enough to initiate a new connection for +any supported version, the server SHOULD send a Version Negotiation +packet as described in Section 6.1. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY limit the number of +packets to which it responds with a Version Negotiation packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +Servers MUST drop smaller packets that specify unsupported versions. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Servers SHOULD respond with a Version +Negotiation packet, provided that the datagram is sufficiently long. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If a server refuses to accept a new connection, it SHOULD send an +Initial packet containing a CONNECTION_CLOSE frame with error code +CONNECTION_REFUSED. +''' + +[[spec]] +level = "MAY" +quote = ''' +If the packet is a 0-RTT packet, the server MAY buffer a limited +number of these packets in anticipation of a late-arriving Initial +packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Clients are not able to send Handshake packets prior to +receiving a server response, so servers SHOULD ignore any such +packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +Servers MUST drop incoming packets under all other circumstances. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.3.toml new file mode 100644 index 0000000000..e5b8fc7257 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.3.toml @@ -0,0 +1,47 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2.3" + +# Considerations for Simple Load Balancers +# +# A server deployment could load-balance among servers using only +# source and destination IP addresses and ports. Changes to the +# client's IP address or port could result in packets being forwarded +# to the wrong server. Such a server deployment could use one of the +# following methods for connection continuity when a client's address +# changes. +# +# * Servers could use an out-of-band mechanism to forward packets to +# the correct server based on connection ID. +# +# * If servers can use a dedicated server IP address or port, other +# than the one that the client initially connects to, they could use +# the preferred_address transport parameter to request that clients +# move connections to that dedicated address. Note that clients +# could choose not to use the preferred address. +# +# A server in a deployment that does not implement a solution to +# maintain connection continuity when the client address changes SHOULD +# indicate that migration is not supported by using the +# disable_active_migration transport parameter. The +# disable_active_migration transport parameter does not prohibit +# connection migration after a client has acted on a preferred_address +# transport parameter. +# +# Server deployments that use this simple form of load balancing MUST +# avoid the creation of a stateless reset oracle; see Section 21.11. + +[[spec]] +level = "SHOULD" +quote = ''' +A server in a deployment that does not implement a solution to +maintain connection continuity when the client address changes SHOULD +indicate that migration is not supported by using the +disable_active_migration transport parameter. +''' + +[[spec]] +level = "MUST" +quote = ''' +Server deployments that use this simple form of load balancing MUST +avoid the creation of a stateless reset oracle; see Section 21.11. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.toml new file mode 100644 index 0000000000..7ca4e0ba3b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-5.2.toml @@ -0,0 +1,55 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2" + +# Matching Packets to Connections +# +# Incoming packets are classified on receipt. Packets can either be +# associated with an existing connection or -- for servers -- +# potentially create a new connection. +# +# Endpoints try to associate a packet with an existing connection. If +# the packet has a non-zero-length Destination Connection ID +# corresponding to an existing connection, QUIC processes that packet +# accordingly. Note that more than one connection ID can be associated +# with a connection; see Section 5.1. +# +# If the Destination Connection ID is zero length and the addressing +# information in the packet matches the addressing information the +# endpoint uses to identify a connection with a zero-length connection +# ID, QUIC processes the packet as part of that connection. An +# endpoint can use just destination IP and port or both source and +# destination addresses for identification, though this makes +# connections fragile as described in Section 5.1. +# +# Endpoints can send a Stateless Reset (Section 10.3) for any packets +# that cannot be attributed to an existing connection. A Stateless +# Reset allows a peer to more quickly identify when a connection +# becomes unusable. +# +# Packets that are matched to an existing connection are discarded if +# the packets are inconsistent with the state of that connection. For +# example, packets are discarded if they indicate a different protocol +# version than that of the connection or if the removal of packet +# protection is unsuccessful once the expected keys are available. +# +# Invalid packets that lack strong integrity protection, such as +# Initial, Retry, or Version Negotiation, MAY be discarded. An +# endpoint MUST generate a connection error if processing the contents +# of these packets prior to discovering an error, or fully revert any +# changes made during that processing. + +[[spec]] +level = "MAY" +quote = ''' +Invalid packets that lack strong integrity protection, such as +Initial, Retry, or Version Negotiation, MAY be discarded. +''' + +[[spec]] +level = "MUST" +quote = ''' +An +endpoint MUST generate a connection error if processing the contents +of these packets prior to discovering an error, or fully revert any +changes made during that processing. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.1.toml new file mode 100644 index 0000000000..15ec4361d8 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.1.toml @@ -0,0 +1,36 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-6.1" + +# Sending Version Negotiation Packets +# +# If the version selected by the client is not acceptable to the +# server, the server responds with a Version Negotiation packet; see +# Section 17.2.1. This includes a list of versions that the server +# will accept. An endpoint MUST NOT send a Version Negotiation packet +# in response to receiving a Version Negotiation packet. +# +# This system allows a server to process packets with unsupported +# versions without retaining state. Though either the Initial packet +# or the Version Negotiation packet that is sent in response could be +# lost, the client will send new packets until it successfully receives +# a response or it abandons the connection attempt. +# +# A server MAY limit the number of Version Negotiation packets it +# sends. For instance, a server that is able to recognize packets as +# 0-RTT might choose not to send Version Negotiation packets in +# response to 0-RTT packets with the expectation that it will +# eventually receive an Initial packet. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send a Version Negotiation packet +in response to receiving a Version Negotiation packet. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY limit the number of Version Negotiation packets it +sends. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml new file mode 100644 index 0000000000..e6b0f49788 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.2.toml @@ -0,0 +1,48 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-6.2" + +# Handling Version Negotiation Packets +# +# Version Negotiation packets are designed to allow for functionality +# to be defined in the future that allows QUIC to negotiate the version +# of QUIC to use for a connection. Future Standards Track +# specifications might change how implementations that support multiple +# versions of QUIC react to Version Negotiation packets received in +# response to an attempt to establish a connection using this version. +# +# A client that supports only this version of QUIC MUST abandon the +# current connection attempt if it receives a Version Negotiation +# packet, with the following two exceptions. A client MUST discard any +# Version Negotiation packet if it has received and successfully +# processed any other packet, including an earlier Version Negotiation +# packet. A client MUST discard a Version Negotiation packet that +# lists the QUIC version selected by the client. +# +# How to perform version negotiation is left as future work defined by +# future Standards Track specifications. In particular, that future +# work will ensure robustness against version downgrade attacks; see +# Section 21.12. + +[[spec]] +level = "MUST" +quote = ''' +A client that supports only this version of QUIC MUST abandon the +current connection attempt if it receives a Version Negotiation +packet, with the following two exceptions. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST discard any +Version Negotiation packet if it has received and successfully +processed any other packet, including an earlier Version Negotiation +packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST discard a Version Negotiation packet that +lists the QUIC version selected by the client. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.3.toml new file mode 100644 index 0000000000..06b58d5697 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.3.toml @@ -0,0 +1,31 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-6.3" + +# Using Reserved Versions +# +# For a server to use a new version in the future, clients need to +# correctly handle unsupported versions. Some version numbers +# (0x?a?a?a?a, as defined in Section 15) are reserved for inclusion in +# fields that contain version numbers. +# +# Endpoints MAY add reserved versions to any field where unknown or +# unsupported versions are ignored to test that a peer correctly +# ignores the value. For instance, an endpoint could include a +# reserved version in a Version Negotiation packet; see Section 17.2.1. +# Endpoints MAY send packets with a reserved version to test that a +# peer correctly discards the packet. + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY add reserved versions to any field where unknown or +unsupported versions are ignored to test that a peer correctly +ignores the value. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY send packets with a reserved version to test that a +peer correctly discards the packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.toml new file mode 100644 index 0000000000..15b7ab630e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-6.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-6" + +# Version Negotiation +# +# Version negotiation allows a server to indicate that it does not +# support the version the client used. A server sends a Version +# Negotiation packet in response to each packet that might initiate a +# new connection; see Section 5.2 for details. +# +# The size of the first packet sent by a client will determine whether +# a server sends a Version Negotiation packet. Clients that support +# multiple QUIC versions SHOULD ensure that the first UDP datagram they +# send is sized to the largest of the minimum datagram sizes from all +# versions they support, using PADDING frames (Section 19.1) as +# necessary. This ensures that the server responds if there is a +# mutually supported version. A server might not send a Version +# Negotiation packet if the datagram it receives is smaller than the +# minimum size specified in a different version; see Section 14.1. + +[[spec]] +level = "SHOULD" +quote = ''' +Clients that support +multiple QUIC versions SHOULD ensure that the first UDP datagram they +send is sized to the largest of the minimum datagram sizes from all +versions they support, using PADDING frames (Section 19.1) as +necessary. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml new file mode 100644 index 0000000000..e17fe2b9bf --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.2.toml @@ -0,0 +1,115 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.2" + +# Negotiating Connection IDs +# +# A connection ID is used to ensure consistent routing of packets, as +# described in Section 5.1. The long header contains two connection +# IDs: the Destination Connection ID is chosen by the recipient of the +# packet and is used to provide consistent routing; the Source +# Connection ID is used to set the Destination Connection ID used by +# the peer. +# +# During the handshake, packets with the long header (Section 17.2) are +# used to establish the connection IDs used by both endpoints. Each +# endpoint uses the Source Connection ID field to specify the +# connection ID that is used in the Destination Connection ID field of +# packets being sent to them. After processing the first Initial +# packet, each endpoint sets the Destination Connection ID field in +# subsequent packets it sends to the value of the Source Connection ID +# field that it received. +# +# When an Initial packet is sent by a client that has not previously +# received an Initial or Retry packet from the server, the client +# populates the Destination Connection ID field with an unpredictable +# value. This Destination Connection ID MUST be at least 8 bytes in +# length. Until a packet is received from the server, the client MUST +# use the same Destination Connection ID value on all packets in this +# connection. +# +# The Destination Connection ID field from the first Initial packet +# sent by a client is used to determine packet protection keys for +# Initial packets. These keys change after receiving a Retry packet; +# see Section 5.2 of [QUIC-TLS]. +# +# The client populates the Source Connection ID field with a value of +# its choosing and sets the Source Connection ID Length field to +# indicate the length. +# +# 0-RTT packets in the first flight use the same Destination Connection +# ID and Source Connection ID values as the client's first Initial +# packet. +# +# Upon first receiving an Initial or Retry packet from the server, the +# client uses the Source Connection ID supplied by the server as the +# Destination Connection ID for subsequent packets, including any 0-RTT +# packets. This means that a client might have to change the +# connection ID it sets in the Destination Connection ID field twice +# during connection establishment: once in response to a Retry packet +# and once in response to an Initial packet from the server. Once a +# client has received a valid Initial packet from the server, it MUST +# discard any subsequent packet it receives on that connection with a +# different Source Connection ID. +# +# A client MUST change the Destination Connection ID it uses for +# sending packets in response to only the first received Initial or +# Retry packet. A server MUST set the Destination Connection ID it +# uses for sending packets based on the first received Initial packet. +# Any further changes to the Destination Connection ID are only +# permitted if the values are taken from NEW_CONNECTION_ID frames; if +# subsequent Initial packets include a different Source Connection ID, +# they MUST be discarded. This avoids unpredictable outcomes that +# might otherwise result from stateless processing of multiple Initial +# packets with different Source Connection IDs. +# +# The Destination Connection ID that an endpoint sends can change over +# the lifetime of a connection, especially in response to connection +# migration (Section 9); see Section 5.1.1 for details. + +[[spec]] +level = "MUST" +quote = ''' +This Destination Connection ID MUST be at least 8 bytes in +length. +''' + +[[spec]] +level = "MUST" +quote = ''' +Until a packet is received from the server, the client MUST +use the same Destination Connection ID value on all packets in this +connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +Once a +client has received a valid Initial packet from the server, it MUST +discard any subsequent packet it receives on that connection with a +different Source Connection ID. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST change the Destination Connection ID it uses for +sending packets in response to only the first received Initial or +Retry packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST set the Destination Connection ID it +uses for sending packets based on the first received Initial packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +Any further changes to the Destination Connection ID are only +permitted if the values are taken from NEW_CONNECTION_ID frames; if +subsequent Initial packets include a different Source Connection ID, +they MUST be discarded. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml new file mode 100644 index 0000000000..826b664150 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.3.toml @@ -0,0 +1,130 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.3" + +# Authenticating Connection IDs +# +# The choice each endpoint makes about connection IDs during the +# handshake is authenticated by including all values in transport +# parameters; see Section 7.4. This ensures that all connection IDs +# used for the handshake are also authenticated by the cryptographic +# handshake. +# +# Each endpoint includes the value of the Source Connection ID field +# from the first Initial packet it sent in the +# initial_source_connection_id transport parameter; see Section 18.2. +# A server includes the Destination Connection ID field from the first +# Initial packet it received from the client in the +# original_destination_connection_id transport parameter; if the server +# sent a Retry packet, this refers to the first Initial packet received +# before sending the Retry packet. If it sends a Retry packet, a +# server also includes the Source Connection ID field from the Retry +# packet in the retry_source_connection_id transport parameter. +# +# The values provided by a peer for these transport parameters MUST +# match the values that an endpoint used in the Destination and Source +# Connection ID fields of Initial packets that it sent (and received, +# for servers). Endpoints MUST validate that received transport +# parameters match received connection ID values. Including connection +# ID values in transport parameters and verifying them ensures that an +# attacker cannot influence the choice of connection ID for a +# successful connection by injecting packets carrying attacker-chosen +# connection IDs during the handshake. +# +# An endpoint MUST treat the absence of the +# initial_source_connection_id transport parameter from either endpoint +# or the absence of the original_destination_connection_id transport +# parameter from the server as a connection error of type +# TRANSPORT_PARAMETER_ERROR. +# +# An endpoint MUST treat the following as a connection error of type +# TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: +# +# * absence of the retry_source_connection_id transport parameter from +# the server after receiving a Retry packet, +# +# * presence of the retry_source_connection_id transport parameter +# when no Retry packet was received, or +# +# * a mismatch between values received from a peer in these transport +# parameters and the value sent in the corresponding Destination or +# Source Connection ID fields of Initial packets. +# +# If a zero-length connection ID is selected, the corresponding +# transport parameter is included with a zero-length value. +# +# Figure 7 shows the connection IDs (with DCID=Destination Connection +# ID, SCID=Source Connection ID) that are used in a complete handshake. +# The exchange of Initial packets is shown, plus the later exchange of +# 1-RTT packets that includes the connection ID established during the +# handshake. +# +# Client Server +# +# Initial: DCID=S1, SCID=C1 -> +# <- Initial: DCID=C1, SCID=S3 +# ... +# 1-RTT: DCID=S3 -> +# <- 1-RTT: DCID=C1 +# +# Figure 7: Use of Connection IDs in a Handshake +# +# Figure 8 shows a similar handshake that includes a Retry packet. +# +# Client Server +# +# Initial: DCID=S1, SCID=C1 -> +# <- Retry: DCID=C1, SCID=S2 +# Initial: DCID=S2, SCID=C1 -> +# <- Initial: DCID=C1, SCID=S3 +# ... +# 1-RTT: DCID=S3 -> +# <- 1-RTT: DCID=C1 +# +# Figure 8: Use of Connection IDs in a Handshake with Retry +# +# In both cases (Figures 7 and 8), the client sets the value of the +# initial_source_connection_id transport parameter to "C1". +# +# When the handshake does not include a Retry (Figure 7), the server +# sets original_destination_connection_id to "S1" (note that this value +# is chosen by the client) and initial_source_connection_id to "S3". +# In this case, the server does not include a +# retry_source_connection_id transport parameter. +# +# When the handshake includes a Retry (Figure 8), the server sets +# original_destination_connection_id to "S1", +# retry_source_connection_id to "S2", and initial_source_connection_id +# to "S3". + +[[spec]] +level = "MUST" +quote = ''' +The values provided by a peer for these transport parameters MUST +match the values that an endpoint used in the Destination and Source +Connection ID fields of Initial packets that it sent (and received, +for servers). +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST validate that received transport +parameters match received connection ID values. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat the absence of the +initial_source_connection_id transport parameter from either endpoint +or the absence of the original_destination_connection_id transport +parameter from the server as a connection error of type +TRANSPORT_PARAMETER_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat the following as a connection error of type +TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml new file mode 100644 index 0000000000..246dc1d93a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.1.toml @@ -0,0 +1,192 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.4.1" + +# Values of Transport Parameters for 0-RTT +# +# Using 0-RTT depends on both client and server using protocol +# parameters that were negotiated from a previous connection. To +# enable 0-RTT, endpoints store the values of the server transport +# parameters with any session tickets it receives on the connection. +# Endpoints also store any information required by the application +# protocol or cryptographic handshake; see Section 4.6 of [QUIC-TLS]. +# The values of stored transport parameters are used when attempting +# 0-RTT using the session tickets. +# +# Remembered transport parameters apply to the new connection until the +# handshake completes and the client starts sending 1-RTT packets. +# Once the handshake completes, the client uses the transport +# parameters established in the handshake. Not all transport +# parameters are remembered, as some do not apply to future connections +# or they have no effect on the use of 0-RTT. +# +# The definition of a new transport parameter (Section 7.4.2) MUST +# specify whether storing the transport parameter for 0-RTT is +# mandatory, optional, or prohibited. A client need not store a +# transport parameter it cannot process. +# +# A client MUST NOT use remembered values for the following parameters: +# ack_delay_exponent, max_ack_delay, initial_source_connection_id, +# original_destination_connection_id, preferred_address, +# retry_source_connection_id, and stateless_reset_token. The client +# MUST use the server's new values in the handshake instead; if the +# server does not provide new values, the default values are used. +# +# A client that attempts to send 0-RTT data MUST remember all other +# transport parameters used by the server that it is able to process. +# The server can remember these transport parameters or can store an +# integrity-protected copy of the values in the ticket and recover the +# information when accepting 0-RTT data. A server uses the transport +# parameters in determining whether to accept 0-RTT data. +# +# If 0-RTT data is accepted by the server, the server MUST NOT reduce +# any limits or alter any values that might be violated by the client +# with its 0-RTT data. In particular, a server that accepts 0-RTT data +# MUST NOT set values for the following parameters (Section 18.2) that +# are smaller than the remembered values of the parameters. +# +# * active_connection_id_limit +# +# * initial_max_data +# +# * initial_max_stream_data_bidi_local +# +# * initial_max_stream_data_bidi_remote +# +# * initial_max_stream_data_uni +# +# * initial_max_streams_bidi +# +# * initial_max_streams_uni +# +# Omitting or setting a zero value for certain transport parameters can +# result in 0-RTT data being enabled but not usable. The applicable +# subset of transport parameters that permit the sending of application +# data SHOULD be set to non-zero values for 0-RTT. This includes +# initial_max_data and either (1) initial_max_streams_bidi and +# initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni +# and initial_max_stream_data_uni. +# +# A server might provide larger initial stream flow control limits for +# streams than the remembered values that a client applies when sending +# 0-RTT. Once the handshake completes, the client updates the flow +# control limits on all sending streams using the updated values of +# initial_max_stream_data_bidi_remote and initial_max_stream_data_uni. +# +# A server MAY store and recover the previously sent values of the +# max_idle_timeout, max_udp_payload_size, and disable_active_migration +# parameters and reject 0-RTT if it selects smaller values. Lowering +# the values of these parameters while also accepting 0-RTT data could +# degrade the performance of the connection. Specifically, lowering +# the max_udp_payload_size could result in dropped packets, leading to +# worse performance compared to rejecting 0-RTT data outright. +# +# A server MUST reject 0-RTT data if the restored values for transport +# parameters cannot be supported. +# +# When sending frames in 0-RTT packets, a client MUST only use +# remembered transport parameters; importantly, it MUST NOT use updated +# values that it learns from the server's updated transport parameters +# or from frames received in 1-RTT packets. Updated values of +# transport parameters from the handshake apply only to 1-RTT packets. +# For instance, flow control limits from remembered transport +# parameters apply to all 0-RTT packets even if those values are +# increased by the handshake or by frames sent in 1-RTT packets. A +# server MAY treat the use of updated transport parameters in 0-RTT as +# a connection error of type PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +The definition of a new transport parameter (Section 7.4.2) MUST +specify whether storing the transport parameter for 0-RTT is +mandatory, optional, or prohibited. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT use remembered values for the following parameters: +ack_delay_exponent, max_ack_delay, initial_source_connection_id, +original_destination_connection_id, preferred_address, +retry_source_connection_id, and stateless_reset_token. +''' + +[[spec]] +level = "MUST" +quote = ''' +The client +MUST use the server's new values in the handshake instead; if the +server does not provide new values, the default values are used. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client that attempts to send 0-RTT data MUST remember all other +transport parameters used by the server that it is able to process. +''' + +[[spec]] +level = "MUST" +quote = ''' +If 0-RTT data is accepted by the server, the server MUST NOT reduce +any limits or alter any values that might be violated by the client +with its 0-RTT data. +''' + +[[spec]] +level = "MUST" +quote = ''' +In particular, a server that accepts 0-RTT data +MUST NOT set values for the following parameters (Section 18.2) that +are smaller than the remembered values of the parameters. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The applicable +subset of transport parameters that permit the sending of application +data SHOULD be set to non-zero values for 0-RTT. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY store and recover the previously sent values of the +max_idle_timeout, max_udp_payload_size, and disable_active_migration +parameters and reject 0-RTT if it selects smaller values. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST reject 0-RTT data if the restored values for transport +parameters cannot be supported. +''' + +[[spec]] +level = "MUST" +quote = ''' +When sending frames in 0-RTT packets, a client MUST only use +remembered transport parameters; importantly, it MUST NOT use updated +values that it learns from the server's updated transport parameters +or from frames received in 1-RTT packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +When sending frames in 0-RTT packets, a client MUST only use +remembered transport parameters; importantly, it MUST NOT use updated +values that it learns from the server's updated transport parameters +or from frames received in 1-RTT packets. +''' + +[[spec]] +level = "MAY" +quote = ''' +A +server MAY treat the use of updated transport parameters in 0-RTT as +a connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.2.toml new file mode 100644 index 0000000000..b3e4dd4112 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.2.toml @@ -0,0 +1,30 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.4.2" + +# New Transport Parameters +# +# New transport parameters can be used to negotiate new protocol +# behavior. An endpoint MUST ignore transport parameters that it does +# not support. The absence of a transport parameter therefore disables +# any optional protocol feature that is negotiated using the parameter. +# As described in Section 18.1, some identifiers are reserved in order +# to exercise this requirement. +# +# A client that does not understand a transport parameter can discard +# it and attempt 0-RTT on subsequent connections. However, if the +# client adds support for a discarded transport parameter, it risks +# violating the constraints that the transport parameter establishes if +# it attempts 0-RTT. New transport parameters can avoid this problem +# by setting a default of the most conservative value. Clients can +# avoid this problem by remembering all parameters, even those not +# currently supported. +# +# New transport parameters can be registered according to the rules in +# Section 22.3. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST ignore transport parameters that it does +not support. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml new file mode 100644 index 0000000000..15355a24f7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.4.toml @@ -0,0 +1,68 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.4" + +# Transport Parameters +# +# During connection establishment, both endpoints make authenticated +# declarations of their transport parameters. Endpoints are required +# to comply with the restrictions that each parameter defines; the +# description of each parameter includes rules for its handling. +# +# Transport parameters are declarations that are made unilaterally by +# each endpoint. Each endpoint can choose values for transport +# parameters independent of the values chosen by its peer. +# +# The encoding of the transport parameters is detailed in Section 18. +# +# QUIC includes the encoded transport parameters in the cryptographic +# handshake. Once the handshake completes, the transport parameters +# declared by the peer are available. Each endpoint validates the +# values provided by its peer. +# +# Definitions for each of the defined transport parameters are included +# in Section 18.2. +# +# An endpoint MUST treat receipt of a transport parameter with an +# invalid value as a connection error of type +# TRANSPORT_PARAMETER_ERROR. +# +# An endpoint MUST NOT send a parameter more than once in a given +# transport parameters extension. An endpoint SHOULD treat receipt of +# duplicate transport parameters as a connection error of type +# TRANSPORT_PARAMETER_ERROR. +# +# Endpoints use transport parameters to authenticate the negotiation of +# connection IDs during the handshake; see Section 7.3. +# +# ALPN (see [ALPN]) allows clients to offer multiple application +# protocols during connection establishment. The transport parameters +# that a client includes during the handshake apply to all application +# protocols that the client offers. Application protocols can +# recommend values for transport parameters, such as the initial flow +# control limits. However, application protocols that set constraints +# on values for transport parameters could make it impossible for a +# client to offer multiple application protocols if these constraints +# conflict. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST treat receipt of a transport parameter with an +invalid value as a connection error of type +TRANSPORT_PARAMETER_ERROR. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send a parameter more than once in a given +transport parameters extension. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD treat receipt of +duplicate transport parameters as a connection error of type +TRANSPORT_PARAMETER_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml new file mode 100644 index 0000000000..3c0a212b0f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.5.toml @@ -0,0 +1,78 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.5" + +# Cryptographic Message Buffering +# +# Implementations need to maintain a buffer of CRYPTO data received out +# of order. Because there is no flow control of CRYPTO frames, an +# endpoint could potentially force its peer to buffer an unbounded +# amount of data. +# +# Implementations MUST support buffering at least 4096 bytes of data +# received in out-of-order CRYPTO frames. Endpoints MAY choose to +# allow more data to be buffered during the handshake. A larger limit +# during the handshake could allow for larger keys or credentials to be +# exchanged. An endpoint's buffer size does not need to remain +# constant during the life of the connection. +# +# Being unable to buffer CRYPTO frames during the handshake can lead to +# a connection failure. If an endpoint's buffer is exceeded during the +# handshake, it can expand its buffer temporarily to complete the +# handshake. If an endpoint does not expand its buffer, it MUST close +# the connection with a CRYPTO_BUFFER_EXCEEDED error code. +# +# Once the handshake completes, if an endpoint is unable to buffer all +# data in a CRYPTO frame, it MAY discard that CRYPTO frame and all +# CRYPTO frames received in the future, or it MAY close the connection +# with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing +# discarded CRYPTO frames MUST be acknowledged because the packet has +# been received and processed by the transport even though the CRYPTO +# frame was discarded. + +[[spec]] +level = "MUST" +quote = ''' +Implementations MUST support buffering at least 4096 bytes of data +received in out-of-order CRYPTO frames. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY choose to +allow more data to be buffered during the handshake. +''' + +[[spec]] +level = "MUST" +quote = ''' +If an endpoint does not expand its buffer, it MUST close +the connection with a CRYPTO_BUFFER_EXCEEDED error code. +''' + +[[spec]] +level = "MAY" +quote = ''' +Once the handshake completes, if an endpoint is unable to buffer all +data in a CRYPTO frame, it MAY discard that CRYPTO frame and all +CRYPTO frames received in the future, or it MAY close the connection +with a CRYPTO_BUFFER_EXCEEDED error code. +''' + +[[spec]] +level = "MAY" +quote = ''' +Once the handshake completes, if an endpoint is unable to buffer all +data in a CRYPTO frame, it MAY discard that CRYPTO frame and all +CRYPTO frames received in the future, or it MAY close the connection +with a CRYPTO_BUFFER_EXCEEDED error code. +''' + +[[spec]] +level = "MUST" +quote = ''' +Packets containing +discarded CRYPTO frames MUST be acknowledged because the packet has +been received and processed by the transport even though the CRYPTO +frame was discarded. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.toml new file mode 100644 index 0000000000..488b8c2f3f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-7.toml @@ -0,0 +1,85 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-7" + +# Cryptographic and Transport Handshake +# +# QUIC relies on a combined cryptographic and transport handshake to +# minimize connection establishment latency. QUIC uses the CRYPTO +# frame (Section 19.6) to transmit the cryptographic handshake. The +# version of QUIC defined in this document is identified as 0x00000001 +# and uses TLS as described in [QUIC-TLS]; a different QUIC version +# could indicate that a different cryptographic handshake protocol is +# in use. +# +# QUIC provides reliable, ordered delivery of the cryptographic +# handshake data. QUIC packet protection is used to encrypt as much of +# the handshake protocol as possible. The cryptographic handshake MUST +# provide the following properties: +# +# * authenticated key exchange, where +# +# - a server is always authenticated, +# +# - a client is optionally authenticated, +# +# - every connection produces distinct and unrelated keys, and +# +# - keying material is usable for packet protection for both 0-RTT +# and 1-RTT packets. +# +# * authenticated exchange of values for transport parameters of both +# endpoints, and confidentiality protection for server transport +# parameters (see Section 7.4). +# +# * authenticated negotiation of an application protocol (TLS uses +# Application-Layer Protocol Negotiation (ALPN) [ALPN] for this +# purpose). +# +# The CRYPTO frame can be sent in different packet number spaces +# (Section 12.3). The offsets used by CRYPTO frames to ensure ordered +# delivery of cryptographic handshake data start from zero in each +# packet number space. +# +# Figure 4 shows a simplified handshake and the exchange of packets and +# frames that are used to advance the handshake. Exchange of +# application data during the handshake is enabled where possible, +# shown with an asterisk ("*"). Once the handshake is complete, +# endpoints are able to exchange application data freely. +# +# Client Server +# +# Initial (CRYPTO) +# 0-RTT (*) ----------> +# Initial (CRYPTO) +# Handshake (CRYPTO) +# <---------- 1-RTT (*) +# Handshake (CRYPTO) +# 1-RTT (*) ----------> +# <---------- 1-RTT (HANDSHAKE_DONE) +# +# 1-RTT <=========> 1-RTT +# +# Figure 4: Simplified QUIC Handshake +# +# Endpoints can use packets sent during the handshake to test for +# Explicit Congestion Notification (ECN) support; see Section 13.4. An +# endpoint validates support for ECN by observing whether the ACK +# frames acknowledging the first packets it sends carry ECN counts, as +# described in Section 13.4.2. +# +# Endpoints MUST explicitly negotiate an application protocol. This +# avoids situations where there is a disagreement about the protocol +# that is in use. + +[[spec]] +level = "MUST" +quote = ''' +The cryptographic handshake MUST +provide the following properties: +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST explicitly negotiate an application protocol. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.1.toml new file mode 100644 index 0000000000..93c99c5fe7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.1.toml @@ -0,0 +1,17 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.1" + +# Token Construction +# +# A token sent in a NEW_TOKEN frame or a Retry packet MUST be +# constructed in a way that allows the server to identify how it was +# provided to a client. These tokens are carried in the same field but +# require different handling from servers. + +[[spec]] +level = "MUST" +quote = ''' +A token sent in a NEW_TOKEN frame or a Retry packet MUST be +constructed in a way that allows the server to identify how it was +provided to a client. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.2.toml new file mode 100644 index 0000000000..a12a4085da --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.2.toml @@ -0,0 +1,71 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.2" + +# Address Validation Using Retry Packets +# +# Upon receiving the client's Initial packet, the server can request +# address validation by sending a Retry packet (Section 17.2.5) +# containing a token. This token MUST be repeated by the client in all +# Initial packets it sends for that connection after it receives the +# Retry packet. +# +# In response to processing an Initial packet containing a token that +# was provided in a Retry packet, a server cannot send another Retry +# packet; it can only refuse the connection or permit it to proceed. +# +# As long as it is not possible for an attacker to generate a valid +# token for its own address (see Section 8.1.4) and the client is able +# to return that token, it proves to the server that it received the +# token. +# +# A server can also use a Retry packet to defer the state and +# processing costs of connection establishment. Requiring the server +# to provide a different connection ID, along with the +# original_destination_connection_id transport parameter defined in +# Section 18.2, forces the server to demonstrate that it, or an entity +# it cooperates with, received the original Initial packet from the +# client. Providing a different connection ID also grants a server +# some control over how subsequent packets are routed. This can be +# used to direct connections to a different server instance. +# +# If a server receives a client Initial that contains an invalid Retry +# token but is otherwise valid, it knows the client will not accept +# another Retry token. The server can discard such a packet and allow +# the client to time out to detect handshake failure, but that could +# impose a significant latency penalty on the client. Instead, the +# server SHOULD immediately close (Section 10.2) the connection with an +# INVALID_TOKEN error. Note that a server has not established any +# state for the connection at this point and so does not enter the +# closing period. +# +# A flow showing the use of a Retry packet is shown in Figure 9. +# +# Client Server +# +# Initial[0]: CRYPTO[CH] -> +# +# <- Retry+Token +# +# Initial+Token[1]: CRYPTO[CH] -> +# +# Initial[0]: CRYPTO[SH] ACK[1] +# Handshake[0]: CRYPTO[EE, CERT, CV, FIN] +# <- 1-RTT[0]: STREAM[1, "..."] +# +# Figure 9: Example Handshake with Retry + +[[spec]] +level = "MUST" +quote = ''' +This token MUST be repeated by the client in all +Initial packets it sends for that connection after it receives the +Retry packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Instead, the +server SHOULD immediately close (Section 10.2) the connection with an +INVALID_TOKEN error. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml new file mode 100644 index 0000000000..5ebd6bfa36 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.3.toml @@ -0,0 +1,241 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.3" + +# Address Validation for Future Connections +# +# A server MAY provide clients with an address validation token during +# one connection that can be used on a subsequent connection. Address +# validation is especially important with 0-RTT because a server +# potentially sends a significant amount of data to a client in +# response to 0-RTT data. +# +# The server uses the NEW_TOKEN frame (Section 19.7) to provide the +# client with an address validation token that can be used to validate +# future connections. In a future connection, the client includes this +# token in Initial packets to provide address validation. The client +# MUST include the token in all Initial packets it sends, unless a +# Retry replaces the token with a newer one. The client MUST NOT use +# the token provided in a Retry for future connections. Servers MAY +# discard any Initial packet that does not carry the expected token. +# +# Unlike the token that is created for a Retry packet, which is used +# immediately, the token sent in the NEW_TOKEN frame can be used after +# some period of time has passed. Thus, a token SHOULD have an +# expiration time, which could be either an explicit expiration time or +# an issued timestamp that can be used to dynamically calculate the +# expiration time. A server can store the expiration time or include +# it in an encrypted form in the token. +# +# A token issued with NEW_TOKEN MUST NOT include information that would +# allow values to be linked by an observer to the connection on which +# it was issued. For example, it cannot include the previous +# connection ID or addressing information, unless the values are +# encrypted. A server MUST ensure that every NEW_TOKEN frame it sends +# is unique across all clients, with the exception of those sent to +# repair losses of previously sent NEW_TOKEN frames. Information that +# allows the server to distinguish between tokens from Retry and +# NEW_TOKEN MAY be accessible to entities other than the server. +# +# It is unlikely that the client port number is the same on two +# different connections; validating the port is therefore unlikely to +# be successful. +# +# A token received in a NEW_TOKEN frame is applicable to any server +# that the connection is considered authoritative for (e.g., server +# names included in the certificate). When connecting to a server for +# which the client retains an applicable and unused token, it SHOULD +# include that token in the Token field of its Initial packet. +# Including a token might allow the server to validate the client +# address without an additional round trip. A client MUST NOT include +# a token that is not applicable to the server that it is connecting +# to, unless the client has the knowledge that the server that issued +# the token and the server the client is connecting to are jointly +# managing the tokens. A client MAY use a token from any previous +# connection to that server. +# +# A token allows a server to correlate activity between the connection +# where the token was issued and any connection where it is used. +# Clients that want to break continuity of identity with a server can +# discard tokens provided using the NEW_TOKEN frame. In comparison, a +# token obtained in a Retry packet MUST be used immediately during the +# connection attempt and cannot be used in subsequent connection +# attempts. +# +# A client SHOULD NOT reuse a token from a NEW_TOKEN frame for +# different connection attempts. Reusing a token allows connections to +# be linked by entities on the network path; see Section 9.5. +# +# Clients might receive multiple tokens on a single connection. Aside +# from preventing linkability, any token can be used in any connection +# attempt. Servers can send additional tokens to either enable address +# validation for multiple connection attempts or replace older tokens +# that might become invalid. For a client, this ambiguity means that +# sending the most recent unused token is most likely to be effective. +# Though saving and using older tokens have no negative consequences, +# clients can regard older tokens as being less likely to be useful to +# the server for address validation. +# +# When a server receives an Initial packet with an address validation +# token, it MUST attempt to validate the token, unless it has already +# completed address validation. If the token is invalid, then the +# server SHOULD proceed as if the client did not have a validated +# address, including potentially sending a Retry packet. Tokens +# provided with NEW_TOKEN frames and Retry packets can be distinguished +# by servers (see Section 8.1.1), and the latter can be validated more +# strictly. If the validation succeeds, the server SHOULD then allow +# the handshake to proceed. +# +# | Note: The rationale for treating the client as unvalidated +# | rather than discarding the packet is that the client might have +# | received the token in a previous connection using the NEW_TOKEN +# | frame, and if the server has lost state, it might be unable to +# | validate the token at all, leading to connection failure if the +# | packet is discarded. +# +# In a stateless design, a server can use encrypted and authenticated +# tokens to pass information to clients that the server can later +# recover and use to validate a client address. Tokens are not +# integrated into the cryptographic handshake, and so they are not +# authenticated. For instance, a client might be able to reuse a +# token. To avoid attacks that exploit this property, a server can +# limit its use of tokens to only the information needed to validate +# client addresses. +# +# Clients MAY use tokens obtained on one connection for any connection +# attempt using the same version. When selecting a token to use, +# clients do not need to consider other properties of the connection +# that is being attempted, including the choice of possible application +# protocols, session tickets, or other connection properties. + +[[spec]] +level = "MAY" +quote = ''' +A server MAY provide clients with an address validation token during +one connection that can be used on a subsequent connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +The client +MUST include the token in all Initial packets it sends, unless a +Retry replaces the token with a newer one. +''' + +[[spec]] +level = "MUST" +quote = ''' +The client MUST NOT use +the token provided in a Retry for future connections. +''' + +[[spec]] +level = "MAY" +quote = ''' +Servers MAY +discard any Initial packet that does not carry the expected token. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Thus, a token SHOULD have an +expiration time, which could be either an explicit expiration time or +an issued timestamp that can be used to dynamically calculate the +expiration time. +''' + +[[spec]] +level = "MUST" +quote = ''' +A token issued with NEW_TOKEN MUST NOT include information that would +allow values to be linked by an observer to the connection on which +it was issued. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST ensure that every NEW_TOKEN frame it sends +is unique across all clients, with the exception of those sent to +repair losses of previously sent NEW_TOKEN frames. +''' + +[[spec]] +level = "MAY" +quote = ''' +Information that +allows the server to distinguish between tokens from Retry and +NEW_TOKEN MAY be accessible to entities other than the server. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When connecting to a server for +which the client retains an applicable and unused token, it SHOULD +include that token in the Token field of its Initial packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT include +a token that is not applicable to the server that it is connecting +to, unless the client has the knowledge that the server that issued +the token and the server the client is connecting to are jointly +managing the tokens. +''' + +[[spec]] +level = "MAY" +quote = ''' +A client MAY use a token from any previous +connection to that server. +''' + +[[spec]] +level = "MUST" +quote = ''' +In comparison, a +token obtained in a Retry packet MUST be used immediately during the +connection attempt and cannot be used in subsequent connection +attempts. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A client SHOULD NOT reuse a token from a NEW_TOKEN frame for +different connection attempts. +''' + +[[spec]] +level = "MUST" +quote = ''' +When a server receives an Initial packet with an address validation +token, it MUST attempt to validate the token, unless it has already +completed address validation. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If the token is invalid, then the +server SHOULD proceed as if the client did not have a validated +address, including potentially sending a Retry packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If the validation succeeds, the server SHOULD then allow +the handshake to proceed. +''' + +[[spec]] +level = "MAY" +quote = ''' +Clients MAY use tokens obtained on one connection for any connection +attempt using the same version. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml new file mode 100644 index 0000000000..e845b72be8 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.4.toml @@ -0,0 +1,114 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.4" + +# Address Validation Token Integrity +# +# An address validation token MUST be difficult to guess. Including a +# random value with at least 128 bits of entropy in the token would be +# sufficient, but this depends on the server remembering the value it +# sends to clients. +# +# A token-based scheme allows the server to offload any state +# associated with validation to the client. For this design to work, +# the token MUST be covered by integrity protection against +# modification or falsification by clients. Without integrity +# protection, malicious clients could generate or guess values for +# tokens that would be accepted by the server. Only the server +# requires access to the integrity protection key for tokens. +# +# There is no need for a single well-defined format for the token +# because the server that generates the token also consumes it. Tokens +# sent in Retry packets SHOULD include information that allows the +# server to verify that the source IP address and port in client +# packets remain constant. +# +# Tokens sent in NEW_TOKEN frames MUST include information that allows +# the server to verify that the client IP address has not changed from +# when the token was issued. Servers can use tokens from NEW_TOKEN +# frames in deciding not to send a Retry packet, even if the client +# address has changed. If the client IP address has changed, the +# server MUST adhere to the anti-amplification limit; see Section 8. +# Note that in the presence of NAT, this requirement might be +# insufficient to protect other hosts that share the NAT from +# amplification attacks. +# +# Attackers could replay tokens to use servers as amplifiers in DDoS +# attacks. To protect against such attacks, servers MUST ensure that +# replay of tokens is prevented or limited. Servers SHOULD ensure that +# tokens sent in Retry packets are only accepted for a short time, as +# they are returned immediately by clients. Tokens that are provided +# in NEW_TOKEN frames (Section 19.7) need to be valid for longer but +# SHOULD NOT be accepted multiple times. Servers are encouraged to +# allow tokens to be used only once, if possible; tokens MAY include +# additional information about clients to further narrow applicability +# or reuse. + +[[spec]] +level = "MUST" +quote = ''' +An address validation token MUST be difficult to guess. +''' + +[[spec]] +level = "MUST" +quote = ''' +For this design to work, +the token MUST be covered by integrity protection against +modification or falsification by clients. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Tokens +sent in Retry packets SHOULD include information that allows the +server to verify that the source IP address and port in client +packets remain constant. +''' + +[[spec]] +level = "MUST" +quote = ''' +Tokens sent in NEW_TOKEN frames MUST include information that allows +the server to verify that the client IP address has not changed from +when the token was issued. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the client IP address has changed, the +server MUST adhere to the anti-amplification limit; see Section 8. +''' + +[[spec]] +level = "MUST" +quote = ''' +To protect against such attacks, servers MUST ensure that +replay of tokens is prevented or limited. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Servers SHOULD ensure that +tokens sent in Retry packets are only accepted for a short time, as +they are returned immediately by clients. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Tokens that are provided +in NEW_TOKEN frames (Section 19.7) need to be valid for longer but +SHOULD NOT be accepted multiple times. +''' + +[[spec]] +level = "MAY" +quote = ''' +Servers are encouraged to +allow tokens to be used only once, if possible; tokens MAY include +additional information about clients to further narrow applicability +or reuse. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml new file mode 100644 index 0000000000..862e4a563b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.1.toml @@ -0,0 +1,113 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1" + +# Address Validation during Connection Establishment +# +# Connection establishment implicitly provides address validation for +# both endpoints. In particular, receipt of a packet protected with +# Handshake keys confirms that the peer successfully processed an +# Initial packet. Once an endpoint has successfully processed a +# Handshake packet from the peer, it can consider the peer address to +# have been validated. +# +# Additionally, an endpoint MAY consider the peer address validated if +# the peer uses a connection ID chosen by the endpoint and the +# connection ID contains at least 64 bits of entropy. +# +# For the client, the value of the Destination Connection ID field in +# its first Initial packet allows it to validate the server address as +# a part of successfully processing any packet. Initial packets from +# the server are protected with keys that are derived from this value +# (see Section 5.2 of [QUIC-TLS]). Alternatively, the value is echoed +# by the server in Version Negotiation packets (Section 6) or included +# in the Integrity Tag in Retry packets (Section 5.8 of [QUIC-TLS]). +# +# Prior to validating the client address, servers MUST NOT send more +# than three times as many bytes as the number of bytes they have +# received. This limits the magnitude of any amplification attack that +# can be mounted using spoofed source addresses. For the purposes of +# avoiding amplification prior to address validation, servers MUST +# count all of the payload bytes received in datagrams that are +# uniquely attributed to a single connection. This includes datagrams +# that contain packets that are successfully processed and datagrams +# that contain packets that are all discarded. +# +# Clients MUST ensure that UDP datagrams containing Initial packets +# have UDP payloads of at least 1200 bytes, adding PADDING frames as +# necessary. A client that sends padded datagrams allows the server to +# send more data prior to completing address validation. +# +# Loss of an Initial or Handshake packet from the server can cause a +# deadlock if the client does not send additional Initial or Handshake +# packets. A deadlock could occur when the server reaches its anti- +# amplification limit and the client has received acknowledgments for +# all the data it has sent. In this case, when the client has no +# reason to send additional packets, the server will be unable to send +# more data because it has not validated the client's address. To +# prevent this deadlock, clients MUST send a packet on a Probe Timeout +# (PTO); see Section 6.2 of [QUIC-RECOVERY]. Specifically, the client +# MUST send an Initial packet in a UDP datagram that contains at least +# 1200 bytes if it does not have Handshake keys, and otherwise send a +# Handshake packet. +# +# A server might wish to validate the client address before starting +# the cryptographic handshake. QUIC uses a token in the Initial packet +# to provide address validation prior to completing the handshake. +# This token is delivered to the client during connection establishment +# with a Retry packet (see Section 8.1.2) or in a previous connection +# using the NEW_TOKEN frame (see Section 8.1.3). +# +# In addition to sending limits imposed prior to address validation, +# servers are also constrained in what they can send by the limits set +# by the congestion controller. Clients are only constrained by the +# congestion controller. + +[[spec]] +level = "MAY" +quote = ''' +Additionally, an endpoint MAY consider the peer address validated if +the peer uses a connection ID chosen by the endpoint and the +connection ID contains at least 64 bits of entropy. +''' + +[[spec]] +level = "MUST" +quote = ''' +Prior to validating the client address, servers MUST NOT send more +than three times as many bytes as the number of bytes they have +received. +''' + +[[spec]] +level = "MUST" +quote = ''' +For the purposes of +avoiding amplification prior to address validation, servers MUST +count all of the payload bytes received in datagrams that are +uniquely attributed to a single connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +Clients MUST ensure that UDP datagrams containing Initial packets +have UDP payloads of at least 1200 bytes, adding PADDING frames as +necessary. +''' + +[[spec]] +level = "MUST" +quote = ''' +To +prevent this deadlock, clients MUST send a packet on a Probe Timeout +(PTO); see Section 6.2 of [QUIC-RECOVERY]. +''' + +[[spec]] +level = "MUST" +quote = ''' +Specifically, the client +MUST send an Initial packet in a UDP datagram that contains at least +1200 bytes if it does not have Handshake keys, and otherwise send a +Handshake packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml new file mode 100644 index 0000000000..37ac1a7162 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.1.toml @@ -0,0 +1,96 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.1" + +# Initiating Path Validation +# +# To initiate path validation, an endpoint sends a PATH_CHALLENGE frame +# containing an unpredictable payload on the path to be validated. +# +# An endpoint MAY send multiple PATH_CHALLENGE frames to guard against +# packet loss. However, an endpoint SHOULD NOT send multiple +# PATH_CHALLENGE frames in a single packet. +# +# An endpoint SHOULD NOT probe a new path with packets containing a +# PATH_CHALLENGE frame more frequently than it would send an Initial +# packet. This ensures that connection migration is no more load on a +# new path than establishing a new connection. +# +# The endpoint MUST use unpredictable data in every PATH_CHALLENGE +# frame so that it can associate the peer's response with the +# corresponding PATH_CHALLENGE. +# +# An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame +# to at least the smallest allowed maximum datagram size of 1200 bytes, +# unless the anti-amplification limit for the path does not permit +# sending a datagram of this size. Sending UDP datagrams of this size +# ensures that the network path from the endpoint to the peer can be +# used for QUIC; see Section 14. +# +# When an endpoint is unable to expand the datagram size to 1200 bytes +# due to the anti-amplification limit, the path MTU will not be +# validated. To ensure that the path MTU is large enough, the endpoint +# MUST perform a second path validation by sending a PATH_CHALLENGE +# frame in a datagram of at least 1200 bytes. This additional +# validation can be performed after a PATH_RESPONSE is successfully +# received or when enough bytes have been received on the path that +# sending the larger datagram will not result in exceeding the anti- +# amplification limit. +# +# Unlike other cases where datagrams are expanded, endpoints MUST NOT +# discard datagrams that appear to be too small when they contain +# PATH_CHALLENGE or PATH_RESPONSE. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY send multiple PATH_CHALLENGE frames to guard against +packet loss. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +However, an endpoint SHOULD NOT send multiple +PATH_CHALLENGE frames in a single packet. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD NOT probe a new path with packets containing a +PATH_CHALLENGE frame more frequently than it would send an Initial +packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +The endpoint MUST use unpredictable data in every PATH_CHALLENGE +frame so that it can associate the peer's response with the +corresponding PATH_CHALLENGE. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame +to at least the smallest allowed maximum datagram size of 1200 bytes, +unless the anti-amplification limit for the path does not permit +sending a datagram of this size. +''' + +[[spec]] +level = "MUST" +quote = ''' +To ensure that the path MTU is large enough, the endpoint +MUST perform a second path validation by sending a PATH_CHALLENGE +frame in a datagram of at least 1200 bytes. +''' + +[[spec]] +level = "MUST" +quote = ''' +Unlike other cases where datagrams are expanded, endpoints MUST NOT +discard datagrams that appear to be too small when they contain +PATH_CHALLENGE or PATH_RESPONSE. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml new file mode 100644 index 0000000000..a6ae09b6d7 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.2.toml @@ -0,0 +1,83 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.2" + +# Path Validation Responses +# +# On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by +# echoing the data contained in the PATH_CHALLENGE frame in a +# PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a +# packet containing a PATH_RESPONSE frame unless constrained by +# congestion control. +# +# A PATH_RESPONSE frame MUST be sent on the network path where the +# PATH_CHALLENGE frame was received. This ensures that path validation +# by a peer only succeeds if the path is functional in both directions. +# This requirement MUST NOT be enforced by the endpoint that initiates +# path validation, as that would enable an attack on migration; see +# Section 9.3.3. +# +# An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame +# to at least the smallest allowed maximum datagram size of 1200 bytes. +# This verifies that the path is able to carry datagrams of this size +# in both directions. However, an endpoint MUST NOT expand the +# datagram containing the PATH_RESPONSE if the resulting data exceeds +# the anti-amplification limit. This is expected to only occur if the +# received PATH_CHALLENGE was not sent in an expanded datagram. +# +# An endpoint MUST NOT send more than one PATH_RESPONSE frame in +# response to one PATH_CHALLENGE frame; see Section 13.3. The peer is +# expected to send more PATH_CHALLENGE frames as necessary to evoke +# additional PATH_RESPONSE frames. + +[[spec]] +level = "MUST" +quote = ''' +On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by +echoing the data contained in the PATH_CHALLENGE frame in a +PATH_RESPONSE frame. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT delay transmission of a +packet containing a PATH_RESPONSE frame unless constrained by +congestion control. +''' + +[[spec]] +level = "MUST" +quote = ''' +A PATH_RESPONSE frame MUST be sent on the network path where the +PATH_CHALLENGE frame was received. +''' + +[[spec]] +level = "MUST" +quote = ''' +This requirement MUST NOT be enforced by the endpoint that initiates +path validation, as that would enable an attack on migration; see +Section 9.3.3. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame +to at least the smallest allowed maximum datagram size of 1200 bytes. +''' + +[[spec]] +level = "MUST" +quote = ''' +However, an endpoint MUST NOT expand the +datagram containing the PATH_RESPONSE if the resulting data exceeds +the anti-amplification limit. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send more than one PATH_RESPONSE frame in +response to one PATH_CHALLENGE frame; see Section 13.3. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.3.toml new file mode 100644 index 0000000000..418f952251 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.3.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.3" + +# Successful Path Validation +# +# Path validation succeeds when a PATH_RESPONSE frame is received that +# contains the data that was sent in a previous PATH_CHALLENGE frame. +# A PATH_RESPONSE frame received on any network path validates the path +# on which the PATH_CHALLENGE was sent. +# +# If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not +# expanded to at least 1200 bytes and if the response to it validates +# the peer address, the path is validated but not the path MTU. As a +# result, the endpoint can now send more than three times the amount of +# data that has been received. However, the endpoint MUST initiate +# another path validation with an expanded datagram to verify that the +# path supports the required MTU. +# +# Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE +# frame is not adequate validation, since the acknowledgment can be +# spoofed by a malicious peer. + +[[spec]] +level = "MUST" +quote = ''' +However, the endpoint MUST initiate +another path validation with an expanded datagram to verify that the +path supports the required MTU. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml new file mode 100644 index 0000000000..6ab51d86c5 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.4.toml @@ -0,0 +1,60 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.4" + +# Failed Path Validation +# +# Path validation only fails when the endpoint attempting to validate +# the path abandons its attempt to validate the path. +# +# Endpoints SHOULD abandon path validation based on a timer. When +# setting this timer, implementations are cautioned that the new path +# could have a longer round-trip time than the original. A value of +# three times the larger of the current PTO or the PTO for the new path +# (using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED. +# +# This timeout allows for multiple PTOs to expire prior to failing path +# validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE +# frame does not cause path validation failure. +# +# Note that the endpoint might receive packets containing other frames +# on the new path, but a PATH_RESPONSE frame with appropriate data is +# required for path validation to succeed. +# +# When an endpoint abandons path validation, it determines that the +# path is unusable. This does not necessarily imply a failure of the +# connection -- endpoints can continue sending packets over other paths +# as appropriate. If no paths are available, an endpoint can wait for +# a new path to become available or close the connection. An endpoint +# that has no valid network path to its peer MAY signal this using the +# NO_VIABLE_PATH connection error, noting that this is only possible if +# the network path exists but does not support the required MTU +# (Section 14). +# +# A path validation might be abandoned for other reasons besides +# failure. Primarily, this happens if a connection migration to a new +# path is initiated while a path validation on the old path is in +# progress. + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD abandon path validation based on a timer. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A value of +three times the larger of the current PTO or the PTO for the new path +(using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint +that has no valid network path to its peer MAY signal this using the +NO_VIABLE_PATH connection error, noting that this is only possible if +the network path exists but does not support the required MTU +(Section 14). +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.toml new file mode 100644 index 0000000000..06b24f3bc2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.2.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2" + +# Path Validation +# +# Path validation is used by both peers during connection migration +# (see Section 9) to verify reachability after a change of address. In +# path validation, endpoints test reachability between a specific local +# address and a specific peer address, where an address is the 2-tuple +# of IP address and port. +# +# Path validation tests that packets sent on a path to a peer are +# received by that peer. Path validation is used to ensure that +# packets received from a migrating peer do not carry a spoofed source +# address. +# +# Path validation does not validate that a peer can send in the return +# direction. Acknowledgments cannot be used for return path validation +# because they contain insufficient entropy and might be spoofed. +# Endpoints independently determine reachability on each direction of a +# path, and therefore return reachability can only be established by +# the peer. +# +# Path validation can be used at any time by either endpoint. For +# instance, an endpoint might check that a peer is still in possession +# of its address after a period of quiescence. +# +# Path validation is not designed as a NAT traversal mechanism. Though +# the mechanism described here might be effective for the creation of +# NAT bindings that support NAT traversal, the expectation is that one +# endpoint is able to receive packets without first having sent a +# packet on that path. Effective NAT traversal needs additional +# synchronization mechanisms that are not provided here. +# +# An endpoint MAY include other frames with the PATH_CHALLENGE and +# PATH_RESPONSE frames used for path validation. In particular, an +# endpoint can include PADDING frames with a PATH_CHALLENGE frame for +# Path Maximum Transmission Unit Discovery (PMTUD); see Section 14.2.1. +# An endpoint can also include its own PATH_CHALLENGE frame when +# sending a PATH_RESPONSE frame. +# +# An endpoint uses a new connection ID for probes sent from a new local +# address; see Section 9.5. When probing a new path, an endpoint can +# ensure that its peer has an unused connection ID available for +# responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in +# the same packet, if the peer's active_connection_id_limit permits, +# ensures that an unused connection ID will be available to the peer +# when sending a response. +# +# An endpoint can choose to simultaneously probe multiple paths. The +# number of simultaneous paths used for probes is limited by the number +# of extra connection IDs its peer has previously supplied, since each +# new local address used for a probe requires a previously unused +# connection ID. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY include other frames with the PATH_CHALLENGE and +PATH_RESPONSE frames used for path validation. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.toml new file mode 100644 index 0000000000..0511f30e3e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-8.toml @@ -0,0 +1,31 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-8" + +# Address Validation +# +# Address validation ensures that an endpoint cannot be used for a +# traffic amplification attack. In such an attack, a packet is sent to +# a server with spoofed source address information that identifies a +# victim. If a server generates more or larger packets in response to +# that packet, the attacker can use the server to send more data toward +# the victim than it would be able to send on its own. +# +# The primary defense against amplification attacks is verifying that a +# peer is able to receive packets at the transport address that it +# claims. Therefore, after receiving packets from an address that is +# not yet validated, an endpoint MUST limit the amount of data it sends +# to the unvalidated address to three times the amount of data received +# from that address. This limit on the size of responses is known as +# the anti-amplification limit. +# +# Address validation is performed both during connection establishment +# (see Section 8.1) and during connection migration (see Section 8.2). + +[[spec]] +level = "MUST" +quote = ''' +Therefore, after receiving packets from an address that is +not yet validated, an endpoint MUST limit the amount of data it sends +to the unvalidated address to three times the amount of data received +from that address. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.1.toml new file mode 100644 index 0000000000..278163b4d6 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.1.toml @@ -0,0 +1,24 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.1" + +# Probing a New Path +# +# An endpoint MAY probe for peer reachability from a new local address +# using path validation (Section 8.2) prior to migrating the connection +# to the new local address. Failure of path validation simply means +# that the new path is not usable for this connection. Failure to +# validate a path does not cause the connection to end unless there are +# no valid alternative paths available. +# +# PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames +# are "probing frames", and all other frames are "non-probing frames". +# A packet containing only probing frames is a "probing packet", and a +# packet containing any other frame is a "non-probing packet". + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY probe for peer reachability from a new local address +using path validation (Section 8.2) prior to migrating the connection +to the new local address. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.2.toml new file mode 100644 index 0000000000..20bd793eaa --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.2.toml @@ -0,0 +1,33 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.2" + +# Initiating Connection Migration +# +# An endpoint can migrate a connection to a new local address by +# sending packets containing non-probing frames from that address. +# +# Each endpoint validates its peer's address during connection +# establishment. Therefore, a migrating endpoint can send to its peer +# knowing that the peer is willing to receive at the peer's current +# address. Thus, an endpoint can migrate to a new local address +# without first validating the peer's address. +# +# To establish reachability on the new path, an endpoint initiates path +# validation (Section 8.2) on the new path. An endpoint MAY defer path +# validation until after a peer sends the next non-probing frame to its +# new address. +# +# When migrating, the new path might not support the endpoint's current +# sending rate. Therefore, the endpoint resets its congestion +# controller and RTT estimate, as described in Section 9.4. +# +# The new path might not have the same ECN capability. Therefore, the +# endpoint validates ECN capability as described in Section 13.4. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY defer path +validation until after a peer sends the next non-probing frame to its +new address. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml new file mode 100644 index 0000000000..ba8cb914d2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.2.toml @@ -0,0 +1,52 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.3.2" + +# On-Path Address Spoofing +# +# An on-path attacker could cause a spurious connection migration by +# copying and forwarding a packet with a spoofed address such that it +# arrives before the original packet. The packet with the spoofed +# address will be seen to come from a migrating connection, and the +# original packet will be seen as a duplicate and dropped. After a +# spurious migration, validation of the source address will fail +# because the entity at the source address does not have the necessary +# cryptographic keys to read or respond to the PATH_CHALLENGE frame +# that is sent to it even if it wanted to. +# +# To protect the connection from failing due to such a spurious +# migration, an endpoint MUST revert to using the last validated peer +# address when validation of a new peer address fails. Additionally, +# receipt of packets with higher packet numbers from the legitimate +# peer address will trigger another connection migration. This will +# cause the validation of the address of the spurious migration to be +# abandoned, thus containing migrations initiated by the attacker +# injecting a single packet. +# +# If an endpoint has no state about the last validated peer address, it +# MUST close the connection silently by discarding all connection +# state. This results in new packets on the connection being handled +# generically. For instance, an endpoint MAY send a Stateless Reset in +# response to any further incoming packets. + +[[spec]] +level = "MUST" +quote = ''' +To protect the connection from failing due to such a spurious +migration, an endpoint MUST revert to using the last validated peer +address when validation of a new peer address fails. +''' + +[[spec]] +level = "MUST" +quote = ''' +If an endpoint has no state about the last validated peer address, it +MUST close the connection silently by discarding all connection +state. +''' + +[[spec]] +level = "MAY" +quote = ''' +For instance, an endpoint MAY send a Stateless Reset in +response to any further incoming packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.3.toml new file mode 100644 index 0000000000..92b5afe661 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.3.toml @@ -0,0 +1,63 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.3.3" + +# Off-Path Packet Forwarding +# +# An off-path attacker that can observe packets might forward copies of +# genuine packets to endpoints. If the copied packet arrives before +# the genuine packet, this will appear as a NAT rebinding. Any genuine +# packet will be discarded as a duplicate. If the attacker is able to +# continue forwarding packets, it might be able to cause migration to a +# path via the attacker. This places the attacker on-path, giving it +# the ability to observe or drop all subsequent packets. +# +# This style of attack relies on the attacker using a path that has +# approximately the same characteristics as the direct path between +# endpoints. The attack is more reliable if relatively few packets are +# sent or if packet loss coincides with the attempted attack. +# +# A non-probing packet received on the original path that increases the +# maximum received packet number will cause the endpoint to move back +# to that path. Eliciting packets on this path increases the +# likelihood that the attack is unsuccessful. Therefore, mitigation of +# this attack relies on triggering the exchange of packets. +# +# In response to an apparent migration, endpoints MUST validate the +# previously active path using a PATH_CHALLENGE frame. This induces +# the sending of new packets on that path. If the path is no longer +# viable, the validation attempt will time out and fail; if the path is +# viable but no longer desired, the validation will succeed but only +# results in probing packets being sent on the path. +# +# An endpoint that receives a PATH_CHALLENGE on an active path SHOULD +# send a non-probing packet in response. If the non-probing packet +# arrives before any copy made by an attacker, this results in the +# connection being migrated back to the original path. Any subsequent +# migration to another path restarts this entire process. +# +# This defense is imperfect, but this is not considered a serious +# problem. If the path via the attack is reliably faster than the +# original path despite multiple attempts to use that original path, it +# is not possible to distinguish between an attack and an improvement +# in routing. +# +# An endpoint could also use heuristics to improve detection of this +# style of attack. For instance, NAT rebinding is improbable if +# packets were recently received on the old path; similarly, rebinding +# is rare on IPv6 paths. Endpoints can also look for duplicated +# packets. Conversely, a change in connection ID is more likely to +# indicate an intentional migration rather than an attack. + +[[spec]] +level = "MUST" +quote = ''' +In response to an apparent migration, endpoints MUST validate the +previously active path using a PATH_CHALLENGE frame. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint that receives a PATH_CHALLENGE on an active path SHOULD +send a non-probing packet in response. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml new file mode 100644 index 0000000000..af6f469d39 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.3.toml @@ -0,0 +1,77 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.3" + +# Responding to Connection Migration +# +# Receiving a packet from a new peer address containing a non-probing +# frame indicates that the peer has migrated to that address. +# +# If the recipient permits the migration, it MUST send subsequent +# packets to the new peer address and MUST initiate path validation +# (Section 8.2) to verify the peer's ownership of the address if +# validation is not already underway. If the recipient has no unused +# connection IDs from the peer, it will not be able to send anything on +# the new path until the peer provides one; see Section 9.5. +# +# An endpoint only changes the address to which it sends packets in +# response to the highest-numbered non-probing packet. This ensures +# that an endpoint does not send packets to an old peer address in the +# case that it receives reordered packets. +# +# An endpoint MAY send data to an unvalidated peer address, but it MUST +# protect against potential attacks as described in Sections 9.3.1 and +# 9.3.2. An endpoint MAY skip validation of a peer address if that +# address has been seen recently. In particular, if an endpoint +# returns to a previously validated path after detecting some form of +# spurious migration, skipping address validation and restoring loss +# detection and congestion state can reduce the performance impact of +# the attack. +# +# After changing the address to which it sends non-probing packets, an +# endpoint can abandon any path validation for other addresses. +# +# Receiving a packet from a new peer address could be the result of a +# NAT rebinding at the peer. +# +# After verifying a new client address, the server SHOULD send new +# address validation tokens (Section 8) to the client. + +[[spec]] +level = "MUST" +quote = ''' +If the recipient permits the migration, it MUST send subsequent +packets to the new peer address and MUST initiate path validation +(Section 8.2) to verify the peer's ownership of the address if +validation is not already underway. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the recipient permits the migration, it MUST send subsequent +packets to the new peer address and MUST initiate path validation +(Section 8.2) to verify the peer's ownership of the address if +validation is not already underway. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MAY send data to an unvalidated peer address, but it MUST +protect against potential attacks as described in Sections 9.3.1 and +9.3.2. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY skip validation of a peer address if that +address has been seen recently. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +After verifying a new client address, the server SHOULD send new +address validation tokens (Section 8) to the client. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml new file mode 100644 index 0000000000..062d59eec1 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.4.toml @@ -0,0 +1,78 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.4" + +# Loss Detection and Congestion Control +# +# The capacity available on the new path might not be the same as the +# old path. Packets sent on the old path MUST NOT contribute to +# congestion control or RTT estimation for the new path. +# +# On confirming a peer's ownership of its new address, an endpoint MUST +# immediately reset the congestion controller and round-trip time +# estimator for the new path to initial values (see Appendices A.3 and +# B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address +# is its port number. Because port-only changes are commonly the +# result of NAT rebinding or other middlebox activity, the endpoint MAY +# instead retain its congestion control state and round-trip estimate +# in those cases instead of reverting to initial values. In cases +# where congestion control state retained from an old path is used on a +# new path with substantially different characteristics, a sender could +# transmit too aggressively until the congestion controller and the RTT +# estimator have adapted. Generally, implementations are advised to be +# cautious when using previous values on a new path. +# +# There could be apparent reordering at the receiver when an endpoint +# sends data and probes from/to multiple addresses during the migration +# period, since the two resulting paths could have different round-trip +# times. A receiver of packets on multiple paths will still send ACK +# frames covering all received packets. +# +# While multiple paths might be used during connection migration, a +# single congestion control context and a single loss recovery context +# (as described in [QUIC-RECOVERY]) could be adequate. For instance, +# an endpoint might delay switching to a new congestion control context +# until it is confirmed that an old path is no longer needed (such as +# the case described in Section 9.3.3). +# +# A sender can make exceptions for probe packets so that their loss +# detection is independent and does not unduly cause the congestion +# controller to reduce its sending rate. An endpoint might set a +# separate timer when a PATH_CHALLENGE is sent, which is canceled if +# the corresponding PATH_RESPONSE is received. If the timer fires +# before the PATH_RESPONSE is received, the endpoint might send a new +# PATH_CHALLENGE and restart the timer for a longer period of time. +# This timer SHOULD be set as described in Section 6.2.1 of +# [QUIC-RECOVERY] and MUST NOT be more aggressive. + +[[spec]] +level = "MUST" +quote = ''' +Packets sent on the old path MUST NOT contribute to +congestion control or RTT estimation for the new path. +''' + +[[spec]] +level = "MUST" +quote = ''' +On confirming a peer's ownership of its new address, an endpoint MUST +immediately reset the congestion controller and round-trip time +estimator for the new path to initial values (see Appendices A.3 and +B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address +is its port number. +''' + +[[spec]] +level = "MAY" +quote = ''' +Because port-only changes are commonly the +result of NAT rebinding or other middlebox activity, the endpoint MAY +instead retain its congestion control state and round-trip estimate +in those cases instead of reverting to initial values. +''' + +[[spec]] +level = "MUST" +quote = ''' +This timer SHOULD be set as described in Section 6.2.1 of +[QUIC-RECOVERY] and MUST NOT be more aggressive. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml new file mode 100644 index 0000000000..5ddd07f336 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.5.toml @@ -0,0 +1,133 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.5" + +# Privacy Implications of Connection Migration +# +# Using a stable connection ID on multiple network paths would allow a +# passive observer to correlate activity between those paths. An +# endpoint that moves between networks might not wish to have their +# activity correlated by any entity other than their peer, so different +# connection IDs are used when sending from different local addresses, +# as discussed in Section 5.1. For this to be effective, endpoints +# need to ensure that connection IDs they provide cannot be linked by +# any other entity. +# +# At any time, endpoints MAY change the Destination Connection ID they +# transmit with to a value that has not been used on another path. +# +# An endpoint MUST NOT reuse a connection ID when sending from more +# than one local address -- for example, when initiating connection +# migration as described in Section 9.2 or when probing a new network +# path as described in Section 9.1. +# +# Similarly, an endpoint MUST NOT reuse a connection ID when sending to +# more than one destination address. Due to network changes outside +# the control of its peer, an endpoint might receive packets from a new +# source address with the same Destination Connection ID field value, +# in which case it MAY continue to use the current connection ID with +# the new remote address while still sending from the same local +# address. +# +# These requirements regarding connection ID reuse apply only to the +# sending of packets, as unintentional changes in path without a change +# in connection ID are possible. For example, after a period of +# network inactivity, NAT rebinding might cause packets to be sent on a +# new path when the client resumes sending. An endpoint responds to +# such an event as described in Section 9.3. +# +# Using different connection IDs for packets sent in both directions on +# each new network path eliminates the use of the connection ID for +# linking packets from the same connection across different network +# paths. Header protection ensures that packet numbers cannot be used +# to correlate activity. This does not prevent other properties of +# packets, such as timing and size, from being used to correlate +# activity. +# +# An endpoint SHOULD NOT initiate migration with a peer that has +# requested a zero-length connection ID, because traffic over the new +# path might be trivially linkable to traffic over the old one. If the +# server is able to associate packets with a zero-length connection ID +# to the right connection, it means that the server is using other +# information to demultiplex packets. For example, a server might +# provide a unique address to every client -- for instance, using HTTP +# alternative services [ALTSVC]. Information that might allow correct +# routing of packets across multiple network paths will also allow +# activity on those paths to be linked by entities other than the peer. +# +# A client might wish to reduce linkability by switching to a new +# connection ID, source UDP port, or IP address (see [RFC8981]) when +# sending traffic after a period of inactivity. Changing the address +# from which it sends packets at the same time might cause the server +# to detect a connection migration. This ensures that the mechanisms +# that support migration are exercised even for clients that do not +# experience NAT rebindings or genuine migrations. Changing address +# can cause a peer to reset its congestion control state (see +# Section 9.4), so addresses SHOULD only be changed infrequently. +# +# An endpoint that exhausts available connection IDs cannot probe new +# paths or initiate migration, nor can it respond to probes or attempts +# by its peer to migrate. To ensure that migration is possible and +# packets sent on different paths cannot be correlated, endpoints +# SHOULD provide new connection IDs before peers migrate; see +# Section 5.1.1. If a peer might have exhausted available connection +# IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in +# all packets sent on a new network path. + +[[spec]] +level = "MAY" +quote = ''' +At any time, endpoints MAY change the Destination Connection ID they +transmit with to a value that has not been used on another path. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT reuse a connection ID when sending from more +than one local address -- for example, when initiating connection +migration as described in Section 9.2 or when probing a new network +path as described in Section 9.1. +''' + +[[spec]] +level = "MUST" +quote = ''' +Similarly, an endpoint MUST NOT reuse a connection ID when sending to +more than one destination address. +''' + +[[spec]] +level = "MAY" +quote = ''' +Due to network changes outside +the control of its peer, an endpoint might receive packets from a new +source address with the same Destination Connection ID field value, +in which case it MAY continue to use the current connection ID with +the new remote address while still sending from the same local +address. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD NOT initiate migration with a peer that has +requested a zero-length connection ID, because traffic over the new +path might be trivially linkable to traffic over the old one. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Changing address +can cause a peer to reset its congestion control state (see +Section 9.4), so addresses SHOULD only be changed infrequently. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +To ensure that migration is possible and +packets sent on different paths cannot be correlated, endpoints +SHOULD provide new connection IDs before peers migrate; see +Section 5.1.1. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml new file mode 100644 index 0000000000..fb508e55c5 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.1.toml @@ -0,0 +1,55 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6.1" + +# Communicating a Preferred Address +# +# A server conveys a preferred address by including the +# preferred_address transport parameter in the TLS handshake. +# +# Servers MAY communicate a preferred address of each address family +# (IPv4 and IPv6) to allow clients to pick the one most suited to their +# network attachment. +# +# Once the handshake is confirmed, the client SHOULD select one of the +# two addresses provided by the server and initiate path validation +# (see Section 8.2). A client constructs packets using any previously +# unused active connection ID, taken from either the preferred_address +# transport parameter or a NEW_CONNECTION_ID frame. +# +# As soon as path validation succeeds, the client SHOULD begin sending +# all future packets to the new server address using the new connection +# ID and discontinue use of the old server address. If path validation +# fails, the client MUST continue sending all future packets to the +# server's original IP address. + +[[spec]] +level = "MAY" +quote = ''' +Servers MAY communicate a preferred address of each address family +(IPv4 and IPv6) to allow clients to pick the one most suited to their +network attachment. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Once the handshake is confirmed, the client SHOULD select one of the +two addresses provided by the server and initiate path validation +(see Section 8.2). +''' + +[[spec]] +level = "SHOULD" +quote = ''' +As soon as path validation succeeds, the client SHOULD begin sending +all future packets to the new server address using the new connection +ID and discontinue use of the old server address. +''' + +[[spec]] +level = "MUST" +quote = ''' +If path validation +fails, the client MUST continue sending all future packets to the +server's original IP address. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml new file mode 100644 index 0000000000..03b82f2acc --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.2.toml @@ -0,0 +1,77 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6.2" + +# Migration to a Preferred Address +# +# A client that migrates to a preferred address MUST validate the +# address it chooses before migrating; see Section 21.5.3. +# +# A server might receive a packet addressed to its preferred IP address +# at any time after it accepts a connection. If this packet contains a +# PATH_CHALLENGE frame, the server sends a packet containing a +# PATH_RESPONSE frame as per Section 8.2. The server MUST send non- +# probing packets from its original address until it receives a non- +# probing packet from the client at its preferred address and until the +# server has validated the new path. +# +# The server MUST probe on the path toward the client from its +# preferred address. This helps to guard against spurious migration +# initiated by an attacker. +# +# Once the server has completed its path validation and has received a +# non-probing packet with a new largest packet number on its preferred +# address, the server begins sending non-probing packets to the client +# exclusively from its preferred IP address. The server SHOULD drop +# newer packets for this connection that are received on the old IP +# address. The server MAY continue to process delayed packets that are +# received on the old IP address. +# +# The addresses that a server provides in the preferred_address +# transport parameter are only valid for the connection in which they +# are provided. A client MUST NOT use these for other connections, +# including connections that are resumed from the current connection. + +[[spec]] +level = "MUST" +quote = ''' +A client that migrates to a preferred address MUST validate the +address it chooses before migrating; see Section 21.5.3. +''' + +[[spec]] +level = "MUST" +quote = ''' +The server MUST send non- +probing packets from its original address until it receives a non- +probing packet from the client at its preferred address and until the +server has validated the new path. +''' + +[[spec]] +level = "MUST" +quote = ''' +The server MUST probe on the path toward the client from its +preferred address. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The server SHOULD drop +newer packets for this connection that are received on the old IP +address. +''' + +[[spec]] +level = "MAY" +quote = ''' +The server MAY continue to process delayed packets that are +received on the old IP address. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT use these for other connections, +including connections that are resumed from the current connection. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml new file mode 100644 index 0000000000..992cadda5f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.3.toml @@ -0,0 +1,95 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6.3" + +# Interaction of Client Migration and Preferred Address +# +# A client might need to perform a connection migration before it has +# migrated to the server's preferred address. In this case, the client +# SHOULD perform path validation to both the original and preferred +# server address from the client's new address concurrently. +# +# If path validation of the server's preferred address succeeds, the +# client MUST abandon validation of the original address and migrate to +# using the server's preferred address. If path validation of the +# server's preferred address fails but validation of the server's +# original address succeeds, the client MAY migrate to its new address +# and continue sending to the server's original address. +# +# If packets received at the server's preferred address have a +# different source address than observed from the client during the +# handshake, the server MUST protect against potential attacks as +# described in Sections 9.3.1 and 9.3.2. In addition to intentional +# simultaneous migration, this might also occur because the client's +# access network used a different NAT binding for the server's +# preferred address. +# +# Servers SHOULD initiate path validation to the client's new address +# upon receiving a probe packet from a different address; see +# Section 8. +# +# A client that migrates to a new address SHOULD use a preferred +# address from the same address family for the server. +# +# The connection ID provided in the preferred_address transport +# parameter is not specific to the addresses that are provided. This +# connection ID is provided to ensure that the client has a connection +# ID available for migration, but the client MAY use this connection ID +# on any path. + +[[spec]] +level = "SHOULD" +quote = ''' +In this case, the client +SHOULD perform path validation to both the original and preferred +server address from the client's new address concurrently. +''' + +[[spec]] +level = "MUST" +quote = ''' +If path validation of the server's preferred address succeeds, the +client MUST abandon validation of the original address and migrate to +using the server's preferred address. +''' + +[[spec]] +level = "MAY" +quote = ''' +If path validation of the +server's preferred address fails but validation of the server's +original address succeeds, the client MAY migrate to its new address +and continue sending to the server's original address. +''' + +[[spec]] +level = "MUST" +quote = ''' +If packets received at the server's preferred address have a +different source address than observed from the client during the +handshake, the server MUST protect against potential attacks as +described in Sections 9.3.1 and 9.3.2. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Servers SHOULD initiate path validation to the client's new address +upon receiving a probe packet from a different address; see +Section 8. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A client that migrates to a new address SHOULD use a preferred +address from the same address family for the server. +''' + +[[spec]] +level = "MAY" +quote = ''' +This +connection ID is provided to ensure that the client has a connection +ID available for migration, but the client MAY use this connection ID +on any path. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.toml new file mode 100644 index 0000000000..600cae1503 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.6.toml @@ -0,0 +1,27 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6" + +# Server's Preferred Address +# +# QUIC allows servers to accept connections on one IP address and +# attempt to transfer these connections to a more preferred address +# shortly after the handshake. This is particularly useful when +# clients initially connect to an address shared by multiple servers +# but would prefer to use a unicast address to ensure connection +# stability. This section describes the protocol for migrating a +# connection to a preferred server address. +# +# Migrating a connection to a new server address mid-connection is not +# supported by the version of QUIC specified in this document. If a +# client receives packets from a new server address when the client has +# not initiated a migration to that address, the client SHOULD discard +# these packets. + +[[spec]] +level = "SHOULD" +quote = ''' +If a +client receives packets from a new server address when the client has +not initiated a migration to that address, the client SHOULD discard +these packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.7.toml new file mode 100644 index 0000000000..1199acf608 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.7.toml @@ -0,0 +1,36 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.7" + +# Use of IPv6 Flow Label and Migration +# +# Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label +# in compliance with [RFC6437], unless the local API does not allow +# setting IPv6 flow labels. +# +# The flow label generation MUST be designed to minimize the chances of +# linkability with a previously used flow label, as a stable flow label +# would enable correlating activity on multiple paths; see Section 9.5. +# +# [RFC6437] suggests deriving values using a pseudorandom function to +# generate flow labels. Including the Destination Connection ID field +# in addition to source and destination addresses when generating flow +# labels ensures that changes are synchronized with changes in other +# observable identifiers. A cryptographic hash function that combines +# these inputs with a local secret is one way this might be +# implemented. + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label +in compliance with [RFC6437], unless the local API does not allow +setting IPv6 flow labels. +''' + +[[spec]] +level = "MUST" +quote = ''' +The flow label generation MUST be designed to minimize the chances of +linkability with a previously used flow label, as a stable flow label +would enable correlating activity on multiple paths; see Section 9.5. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml new file mode 100644 index 0000000000..8e80a6b522 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9000/section-9.toml @@ -0,0 +1,104 @@ +target = "https://www.rfc-editor.org/rfc/rfc9000#section-9" + +# Connection Migration +# +# The use of a connection ID allows connections to survive changes to +# endpoint addresses (IP address and port), such as those caused by an +# endpoint migrating to a new network. This section describes the +# process by which an endpoint migrates to a new address. +# +# The design of QUIC relies on endpoints retaining a stable address for +# the duration of the handshake. An endpoint MUST NOT initiate +# connection migration before the handshake is confirmed, as defined in +# Section 4.1.2 of [QUIC-TLS]. +# +# If the peer sent the disable_active_migration transport parameter, an +# endpoint also MUST NOT send packets (including probing packets; see +# Section 9.1) from a different local address to the address the peer +# used during the handshake, unless the endpoint has acted on a +# preferred_address transport parameter from the peer. If the peer +# violates this requirement, the endpoint MUST either drop the incoming +# packets on that path without generating a Stateless Reset or proceed +# with path validation and allow the peer to migrate. Generating a +# Stateless Reset or closing the connection would allow third parties +# in the network to cause connections to close by spoofing or otherwise +# manipulating observed traffic. +# +# Not all changes of peer address are intentional, or active, +# migrations. The peer could experience NAT rebinding: a change of +# address due to a middlebox, usually a NAT, allocating a new outgoing +# port or even a new outgoing IP address for a flow. An endpoint MUST +# perform path validation (Section 8.2) if it detects any change to a +# peer's address, unless it has previously validated that address. +# +# When an endpoint has no validated path on which to send packets, it +# MAY discard connection state. An endpoint capable of connection +# migration MAY wait for a new path to become available before +# discarding connection state. +# +# This document limits migration of connections to new client +# addresses, except as described in Section 9.6. Clients are +# responsible for initiating all migrations. Servers do not send non- +# probing packets (see Section 9.1) toward a client address until they +# see a non-probing packet from that address. If a client receives +# packets from an unknown server address, the client MUST discard these +# packets. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT initiate +connection migration before the handshake is confirmed, as defined in +Section 4.1.2 of [QUIC-TLS]. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the peer sent the disable_active_migration transport parameter, an +endpoint also MUST NOT send packets (including probing packets; see +Section 9.1) from a different local address to the address the peer +used during the handshake, unless the endpoint has acted on a +preferred_address transport parameter from the peer. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the peer +violates this requirement, the endpoint MUST either drop the incoming +packets on that path without generating a Stateless Reset or proceed +with path validation and allow the peer to migrate. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST +perform path validation (Section 8.2) if it detects any change to a +peer's address, unless it has previously validated that address. +''' + +[[spec]] +level = "MAY" +quote = ''' +When an endpoint has no validated path on which to send packets, it +MAY discard connection state. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint capable of connection +migration MAY wait for a new path to become available before +discarding connection state. +''' + +[[spec]] +level = "MUST" +quote = ''' +If a client receives +packets from an unknown server address, the client MUST discard these +packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.2.toml new file mode 100644 index 0000000000..8ea0c9a269 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.2.toml @@ -0,0 +1,31 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.2" + +# Handshake Confirmed +# +# In this document, the TLS handshake is considered confirmed at the +# server when the handshake completes. The server MUST send a +# HANDSHAKE_DONE frame as soon as the handshake is complete. At the +# client, the handshake is considered confirmed when a HANDSHAKE_DONE +# frame is received. +# +# Additionally, a client MAY consider the handshake to be confirmed +# when it receives an acknowledgment for a 1-RTT packet. This can be +# implemented by recording the lowest packet number sent with 1-RTT +# keys and comparing it to the Largest Acknowledged field in any +# received 1-RTT ACK frame: once the latter is greater than or equal to +# the former, the handshake is confirmed. + +[[spec]] +level = "MUST" +quote = ''' +The server MUST send a +HANDSHAKE_DONE frame as soon as the handshake is complete. +''' + +[[spec]] +level = "MAY" +quote = ''' +Additionally, a client MAY consider the handshake to be confirmed +when it receives an acknowledgment for a 1-RTT packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml new file mode 100644 index 0000000000..ccaed768cf --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.3.toml @@ -0,0 +1,123 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.3" + +# Sending and Receiving Handshake Messages +# +# In order to drive the handshake, TLS depends on being able to send +# and receive handshake messages. There are two basic functions on +# this interface: one where QUIC requests handshake messages and one +# where QUIC provides bytes that comprise handshake messages. +# +# Before starting the handshake, QUIC provides TLS with the transport +# parameters (see Section 8.2) that it wishes to carry. +# +# A QUIC client starts TLS by requesting TLS handshake bytes from TLS. +# The client acquires handshake bytes before sending its first packet. +# A QUIC server starts the process by providing TLS with the client's +# handshake bytes. +# +# At any time, the TLS stack at an endpoint will have a current sending +# encryption level and a receiving encryption level. TLS encryption +# levels determine the QUIC packet type and keys that are used for +# protecting data. +# +# Each encryption level is associated with a different sequence of +# bytes, which is reliably transmitted to the peer in CRYPTO frames. +# When TLS provides handshake bytes to be sent, they are appended to +# the handshake bytes for the current encryption level. The encryption +# level then determines the type of packet that the resulting CRYPTO +# frame is carried in; see Table 1. +# +# Four encryption levels are used, producing keys for Initial, 0-RTT, +# Handshake, and 1-RTT packets. CRYPTO frames are carried in just +# three of these levels, omitting the 0-RTT level. These four levels +# correspond to three packet number spaces: Initial and Handshake +# encrypted packets use their own separate spaces; 0-RTT and 1-RTT +# packets use the application data packet number space. +# +# QUIC takes the unprotected content of TLS handshake records as the +# content of CRYPTO frames. TLS record protection is not used by QUIC. +# QUIC assembles CRYPTO frames into QUIC packets, which are protected +# using QUIC packet protection. +# +# QUIC CRYPTO frames only carry TLS handshake messages. TLS alerts are +# turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8. TLS +# application data and other content types cannot be carried by QUIC at +# any encryption level; it is an error if they are received from the +# TLS stack. +# +# When an endpoint receives a QUIC packet containing a CRYPTO frame +# from the network, it proceeds as follows: +# +# * If the packet uses the current TLS receiving encryption level, +# sequence the data into the input flow as usual. As with STREAM +# frames, the offset is used to find the proper location in the data +# sequence. If the result of this process is that new data is +# available, then it is delivered to TLS in order. +# +# * If the packet is from a previously installed encryption level, it +# MUST NOT contain data that extends past the end of previously +# received data in that flow. Implementations MUST treat any +# violations of this requirement as a connection error of type +# PROTOCOL_VIOLATION. +# +# * If the packet is from a new encryption level, it is saved for +# later processing by TLS. Once TLS moves to receiving from this +# encryption level, saved data can be provided to TLS. When TLS +# provides keys for a higher encryption level, if there is data from +# a previous encryption level that TLS has not consumed, this MUST +# be treated as a connection error of type PROTOCOL_VIOLATION. +# +# Each time that TLS is provided with new data, new handshake bytes are +# requested from TLS. TLS might not provide any bytes if the handshake +# messages it has received are incomplete or it has no data to send. +# +# The content of CRYPTO frames might either be processed incrementally +# by TLS or buffered until complete messages or flights are available. +# TLS is responsible for buffering handshake bytes that have arrived in +# order. QUIC is responsible for buffering handshake bytes that arrive +# out of order or for encryption levels that are not yet ready. QUIC +# does not provide any means of flow control for CRYPTO frames; see +# Section 7.5 of [QUIC-TRANSPORT]. +# +# Once the TLS handshake is complete, this is indicated to QUIC along +# with any final handshake bytes that TLS needs to send. At this +# stage, the transport parameters that the peer advertised during the +# handshake are authenticated; see Section 8.2. +# +# Once the handshake is complete, TLS becomes passive. TLS can still +# receive data from its peer and respond in kind, but it will not need +# to send more data unless specifically requested -- either by an +# application or QUIC. One reason to send data is that the server +# might wish to provide additional or updated session tickets to a +# client. +# +# When the handshake is complete, QUIC only needs to provide TLS with +# any data that arrives in CRYPTO streams. In the same manner that is +# used during the handshake, new data is requested from TLS after +# providing received data. + +[[spec]] +level = "MUST" +quote = ''' +* If the packet is from a previously installed encryption level, it +MUST NOT contain data that extends past the end of previously +received data in that flow. +''' + +[[spec]] +level = "MUST" +quote = ''' +Implementations MUST treat any +violations of this requirement as a connection error of type +PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +When TLS +provides keys for a higher encryption level, if there is data from +a previous encryption level that TLS has not consumed, this MUST +be treated as a connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.4.toml new file mode 100644 index 0000000000..d940714f0c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.1.4.toml @@ -0,0 +1,84 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.4" + +# Encryption Level Changes +# +# As keys at a given encryption level become available to TLS, TLS +# indicates to QUIC that reading or writing keys at that encryption +# level are available. +# +# The availability of new keys is always a result of providing inputs +# to TLS. TLS only provides new keys after being initialized (by a +# client) or when provided with new handshake data. +# +# However, a TLS implementation could perform some of its processing +# asynchronously. In particular, the process of validating a +# certificate can take some time. While waiting for TLS processing to +# complete, an endpoint SHOULD buffer received packets if they might be +# processed using keys that are not yet available. These packets can +# be processed once keys are provided by TLS. An endpoint SHOULD +# continue to respond to packets that can be processed during this +# time. +# +# After processing inputs, TLS might produce handshake bytes, keys for +# new encryption levels, or both. +# +# TLS provides QUIC with three items as a new encryption level becomes +# available: +# +# * A secret +# +# * An Authenticated Encryption with Associated Data (AEAD) function +# +# * A Key Derivation Function (KDF) +# +# These values are based on the values that TLS negotiates and are used +# by QUIC to generate packet and header protection keys; see Section 5 +# and Section 5.4. +# +# If 0-RTT is possible, it is ready after the client sends a TLS +# ClientHello message or the server receives that message. After +# providing a QUIC client with the first handshake bytes, the TLS stack +# might signal the change to 0-RTT keys. On the server, after +# receiving handshake bytes that contain a ClientHello message, a TLS +# server might signal that 0-RTT keys are available. +# +# Although TLS only uses one encryption level at a time, QUIC may use +# more than one level. For instance, after sending its Finished +# message (using a CRYPTO frame at the Handshake encryption level) an +# endpoint can send STREAM data (in 1-RTT encryption). If the Finished +# message is lost, the endpoint uses the Handshake encryption level to +# retransmit the lost message. Reordering or loss of packets can mean +# that QUIC will need to handle packets at multiple encryption levels. +# During the handshake, this means potentially handling packets at +# higher and lower encryption levels than the current encryption level +# used by TLS. +# +# In particular, server implementations need to be able to read packets +# at the Handshake encryption level at the same time as the 0-RTT +# encryption level. A client could interleave ACK frames that are +# protected with Handshake keys with 0-RTT data, and the server needs +# to process those acknowledgments in order to detect lost Handshake +# packets. +# +# QUIC also needs access to keys that might not ordinarily be available +# to a TLS implementation. For instance, a client might need to +# acknowledge Handshake packets before it is ready to send CRYPTO +# frames at that encryption level. TLS therefore needs to provide keys +# to QUIC before it might produce them for its own use. + +[[spec]] +level = "SHOULD" +quote = ''' +While waiting for TLS processing to +complete, an endpoint SHOULD buffer received packets if they might be +processed using keys that are not yet available. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD +continue to respond to packets that can be processed during this +time. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.2.toml new file mode 100644 index 0000000000..8419a39c14 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.2.toml @@ -0,0 +1,30 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.2" + +# TLS Version +# +# This document describes how TLS 1.3 [TLS13] is used with QUIC. +# +# In practice, the TLS handshake will negotiate a version of TLS to +# use. This could result in a version of TLS newer than 1.3 being +# negotiated if both endpoints support that version. This is +# acceptable provided that the features of TLS 1.3 that are used by +# QUIC are supported by the newer version. +# +# Clients MUST NOT offer TLS versions older than 1.3. A badly +# configured TLS implementation could negotiate TLS 1.2 or another +# older version of TLS. An endpoint MUST terminate the connection if a +# version of TLS older than 1.3 is negotiated. + +[[spec]] +level = "MUST" +quote = ''' +Clients MUST NOT offer TLS versions older than 1.3. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST terminate the connection if a +version of TLS older than 1.3 is negotiated. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.3.toml new file mode 100644 index 0000000000..d39d01c056 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.3.toml @@ -0,0 +1,53 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.3" + +# ClientHello Size +# +# The first Initial packet from a client contains the start or all of +# its first cryptographic handshake message, which for TLS is the +# ClientHello. Servers might need to parse the entire ClientHello +# (e.g., to access extensions such as Server Name Identification (SNI) +# or Application-Layer Protocol Negotiation (ALPN)) in order to decide +# whether to accept the new incoming QUIC connection. If the +# ClientHello spans multiple Initial packets, such servers would need +# to buffer the first received fragments, which could consume excessive +# resources if the client's address has not yet been validated. To +# avoid this, servers MAY use the Retry feature (see Section 8.1 of +# [QUIC-TRANSPORT]) to only buffer partial ClientHello messages from +# clients with a validated address. +# +# QUIC packet and framing add at least 36 bytes of overhead to the +# ClientHello message. That overhead increases if the client chooses a +# Source Connection ID field longer than zero bytes. Overheads also do +# not include the token or a Destination Connection ID longer than 8 +# bytes, both of which might be required if a server sends a Retry +# packet. +# +# A typical TLS ClientHello can easily fit into a 1200-byte packet. +# However, in addition to the overheads added by QUIC, there are +# several variables that could cause this limit to be exceeded. Large +# session tickets, multiple or large key shares, and long lists of +# supported ciphers, signature algorithms, versions, QUIC transport +# parameters, and other negotiable parameters and extensions could +# cause this message to grow. +# +# For servers, in addition to connection IDs and tokens, the size of +# TLS session tickets can have an effect on a client's ability to +# connect efficiently. Minimizing the size of these values increases +# the probability that clients can use them and still fit their entire +# ClientHello message in their first Initial packet. +# +# The TLS implementation does not need to ensure that the ClientHello +# is large enough to meet QUIC's requirements for datagrams that carry +# Initial packets; see Section 14.1 of [QUIC-TRANSPORT]. QUIC +# implementations use PADDING frames or packet coalescing to ensure +# that datagrams are large enough. + +[[spec]] +level = "MAY" +quote = ''' +To +avoid this, servers MAY use the Retry feature (see Section 8.1 of +[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from +clients with a validated address. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml new file mode 100644 index 0000000000..51f35dc2dd --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.4.toml @@ -0,0 +1,86 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.4" + +# Peer Authentication +# +# The requirements for authentication depend on the application +# protocol that is in use. TLS provides server authentication and +# permits the server to request client authentication. +# +# A client MUST authenticate the identity of the server. This +# typically involves verification that the identity of the server is +# included in a certificate and that the certificate is issued by a +# trusted entity (see for example [RFC2818]). +# +# | Note: Where servers provide certificates for authentication, +# | the size of the certificate chain can consume a large number of +# | bytes. Controlling the size of certificate chains is critical +# | to performance in QUIC as servers are limited to sending 3 +# | bytes for every byte received prior to validating the client +# | address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a +# | certificate chain can be managed by limiting the number of +# | names or extensions; using keys with small public key +# | representations, like ECDSA; or by using certificate +# | compression [COMPRESS]. +# +# A server MAY request that the client authenticate during the +# handshake. A server MAY refuse a connection if the client is unable +# to authenticate when requested. The requirements for client +# authentication vary based on application protocol and deployment. +# +# A server MUST NOT use post-handshake client authentication (as +# defined in Section 4.6.2 of [TLS13]) because the multiplexing offered +# by QUIC prevents clients from correlating the certificate request +# with the application-level event that triggered it (see +# [HTTP2-TLS13]). More specifically, servers MUST NOT send post- +# handshake TLS CertificateRequest messages, and clients MUST treat +# receipt of such messages as a connection error of type +# PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +A client MUST authenticate the identity of the server. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY request that the client authenticate during the +handshake. +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY refuse a connection if the client is unable +to authenticate when requested. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST NOT use post-handshake client authentication (as +defined in Section 4.6.2 of [TLS13]) because the multiplexing offered +by QUIC prevents clients from correlating the certificate request +with the application-level event that triggered it (see +[HTTP2-TLS13]). +''' + +[[spec]] +level = "MUST" +quote = ''' +More specifically, servers MUST NOT send post- +handshake TLS CertificateRequest messages, and clients MUST treat +receipt of such messages as a connection error of type +PROTOCOL_VIOLATION. +''' + +[[spec]] +level = "MUST" +quote = ''' +More specifically, servers MUST NOT send post- +handshake TLS CertificateRequest messages, and clients MUST treat +receipt of such messages as a connection error of type +PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.5.toml new file mode 100644 index 0000000000..fd8109499a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.5.toml @@ -0,0 +1,37 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.5" + +# Session Resumption +# +# QUIC can use the session resumption feature of TLS 1.3. It does this +# by carrying NewSessionTicket messages in CRYPTO frames after the +# handshake is complete. Session resumption can be used to provide +# 0-RTT and can also be used when 0-RTT is disabled. +# +# Endpoints that use session resumption might need to remember some +# information about the current connection when creating a resumed +# connection. TLS requires that some information be retained; see +# Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state +# being retained when resuming a connection unless 0-RTT is also used; +# see Section 7.4.1 of [QUIC-TRANSPORT] and Section 4.6.1. Application +# protocols could depend on state that is retained between resumed +# connections. +# +# Clients can store any state required for resumption along with the +# session ticket. Servers can use the session ticket to help carry +# state. +# +# Session resumption allows servers to link activity on the original +# connection with the resumed connection, which might be a privacy +# issue for clients. Clients can choose not to enable resumption to +# avoid creating this correlation. Clients SHOULD NOT reuse tickets as +# that allows entities other than the server to correlate connections; +# see Appendix C.4 of [TLS13]. + +[[spec]] +level = "SHOULD" +quote = ''' +Clients SHOULD NOT reuse tickets as +that allows entities other than the server to correlate connections; +see Appendix C.4 of [TLS13]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.1.toml new file mode 100644 index 0000000000..2695227a9d --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.1.toml @@ -0,0 +1,47 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.6.1" + +# Enabling 0-RTT +# +# The TLS early_data extension in the NewSessionTicket message is +# defined to convey (in the max_early_data_size parameter) the amount +# of TLS 0-RTT data the server is willing to accept. QUIC does not use +# TLS early data. QUIC uses 0-RTT packets to carry early data. +# Accordingly, the max_early_data_size parameter is repurposed to hold +# a sentinel value 0xffffffff to indicate that the server is willing to +# accept QUIC 0-RTT data. To indicate that the server does not accept +# 0-RTT data, the early_data extension is omitted from the +# NewSessionTicket. The amount of data that the client can send in +# QUIC 0-RTT is controlled by the initial_max_data transport parameter +# supplied by the server. +# +# Servers MUST NOT send the early_data extension with a +# max_early_data_size field set to any value other than 0xffffffff. A +# client MUST treat receipt of a NewSessionTicket that contains an +# early_data extension with any other value as a connection error of +# type PROTOCOL_VIOLATION. +# +# A client that wishes to send 0-RTT packets uses the early_data +# extension in the ClientHello message of a subsequent handshake; see +# Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT +# packets. +# +# A client that attempts 0-RTT might also provide an address validation +# token if the server has sent a NEW_TOKEN frame; see Section 8.1 of +# [QUIC-TRANSPORT]. + +[[spec]] +level = "MUST" +quote = ''' +Servers MUST NOT send the early_data extension with a +max_early_data_size field set to any value other than 0xffffffff. +''' + +[[spec]] +level = "MUST" +quote = ''' +A +client MUST treat receipt of a NewSessionTicket that contains an +early_data extension with any other value as a connection error of +type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml new file mode 100644 index 0000000000..fb77454b90 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.6.2.toml @@ -0,0 +1,55 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.6.2" + +# Accepting and Rejecting 0-RTT +# +# A server accepts 0-RTT by sending an early_data extension in the +# EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then +# processes and acknowledges the 0-RTT packets that it receives. +# +# A server rejects 0-RTT by sending the EncryptedExtensions without an +# early_data extension. A server will always reject 0-RTT if it sends +# a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT +# process any 0-RTT packets, even if it could. When 0-RTT was +# rejected, a client SHOULD treat receipt of an acknowledgment for a +# 0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it +# is able to detect the condition. +# +# When 0-RTT is rejected, all connection characteristics that the +# client assumed might be incorrect. This includes the choice of +# application protocol, transport parameters, and any application +# configuration. The client therefore MUST reset the state of all +# streams, including application state bound to those streams. +# +# A client MAY reattempt 0-RTT if it receives a Retry or Version +# Negotiation packet. These packets do not signify rejection of 0-RTT. + +[[spec]] +level = "MUST" +quote = ''' +When rejecting 0-RTT, a server MUST NOT +process any 0-RTT packets, even if it could. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When 0-RTT was +rejected, a client SHOULD treat receipt of an acknowledgment for a +0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it +is able to detect the condition. +''' + +[[spec]] +level = "MUST" +quote = ''' +The client therefore MUST reset the state of all +streams, including application state bound to those streams. +''' + +[[spec]] +level = "MAY" +quote = ''' +A client MAY reattempt 0-RTT if it receives a Retry or Version +Negotiation packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.7.toml new file mode 100644 index 0000000000..e14487fe62 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.7.toml @@ -0,0 +1,21 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.7" + +# HelloRetryRequest +# +# The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be +# used to request that a client provide new information, such as a key +# share, or to validate some characteristic of the client. From the +# perspective of QUIC, HelloRetryRequest is not differentiated from +# other cryptographic handshake messages that are carried in Initial +# packets. Although it is in principle possible to use this feature +# for address verification, QUIC implementations SHOULD instead use the +# Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. + +[[spec]] +level = "SHOULD" +quote = ''' +Although it is in principle possible to use this feature +for address verification, QUIC implementations SHOULD instead use the +Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.8.toml new file mode 100644 index 0000000000..153412c4e2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.8.toml @@ -0,0 +1,42 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.8" + +# TLS Errors +# +# If TLS experiences an error, it generates an appropriate alert as +# defined in Section 6 of [TLS13]. +# +# A TLS alert is converted into a QUIC connection error. The +# AlertDescription value is added to 0x0100 to produce a QUIC error +# code from the range reserved for CRYPTO_ERROR; see Section 20.1 of +# [QUIC-TRANSPORT]. The resulting value is sent in a QUIC +# CONNECTION_CLOSE frame of type 0x1c. +# +# QUIC is only able to convey an alert level of "fatal". In TLS 1.3, +# the only existing uses for the "warning" level are to signal +# connection close; see Section 6.1 of [TLS13]. As QUIC provides +# alternative mechanisms for connection termination and the TLS +# connection is only closed if an error is encountered, a QUIC endpoint +# MUST treat any alert from TLS as if it were at the "fatal" level. +# +# QUIC permits the use of a generic code in place of a specific error +# code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this +# includes replacing any alert with a generic alert, such as +# handshake_failure (0x0128 in QUIC). Endpoints MAY use a generic +# error code to avoid possibly exposing confidential information. + +[[spec]] +level = "MUST" +quote = ''' +As QUIC provides +alternative mechanisms for connection termination and the TLS +connection is only closed if an error is encountered, a QUIC endpoint +MUST treat any alert from TLS as if it were at the "fatal" level. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY use a generic +error code to avoid possibly exposing confidential information. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.1.toml new file mode 100644 index 0000000000..2a563258b2 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.1.toml @@ -0,0 +1,44 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9.1" + +# Discarding Initial Keys +# +# Packets protected with Initial secrets (Section 5.2) are not +# authenticated, meaning that an attacker could spoof packets with the +# intent to disrupt a connection. To limit these attacks, Initial +# packet protection keys are discarded more aggressively than other +# keys. +# +# The successful use of Handshake packets indicates that no more +# Initial packets need to be exchanged, as these keys can only be +# produced after receiving all CRYPTO frames from Initial packets. +# Thus, a client MUST discard Initial keys when it first sends a +# Handshake packet and a server MUST discard Initial keys when it first +# successfully processes a Handshake packet. Endpoints MUST NOT send +# Initial packets after this point. +# +# This results in abandoning loss recovery state for the Initial +# encryption level and ignoring any outstanding Initial packets. + +[[spec]] +level = "MUST" +quote = ''' +Thus, a client MUST discard Initial keys when it first sends a +Handshake packet and a server MUST discard Initial keys when it first +successfully processes a Handshake packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +Thus, a client MUST discard Initial keys when it first sends a +Handshake packet and a server MUST discard Initial keys when it first +successfully processes a Handshake packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST NOT send +Initial packets after this point. +''' + diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.2.toml similarity index 60% rename from specs/www.rfc-editor.org/rfc/rfc9001/4.9.2.toml rename to .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.2.toml index c77c4cccfa..e5ceb5cb88 100644 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.2.toml @@ -1,9 +1,9 @@ target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9.2" -# 4.9.2. Discarding Handshake Keys +# Discarding Handshake Keys # -# An endpoint MUST discard its Handshake keys when the TLS handshake is -# confirmed (Section 4.1.2). +# An endpoint MUST discard its Handshake keys when the TLS handshake is +# confirmed (Section 4.1.2). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml new file mode 100644 index 0000000000..17b1ad2631 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.3.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9.3" + +# Discarding 0-RTT Keys +# +# 0-RTT and 1-RTT packets share the same packet number space, and +# clients do not send 0-RTT packets after sending a 1-RTT packet +# (Section 5.6). +# +# Therefore, a client SHOULD discard 0-RTT keys as soon as it installs +# 1-RTT keys as they have no use after that moment. +# +# Additionally, a server MAY discard 0-RTT keys as soon as it receives +# a 1-RTT packet. However, due to packet reordering, a 0-RTT packet +# could arrive after a 1-RTT packet. Servers MAY temporarily retain +# 0-RTT keys to allow decrypting reordered packets without requiring +# their contents to be retransmitted with 1-RTT keys. After receiving +# a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; +# the RECOMMENDED time period is three times the Probe Timeout (PTO, +# see [QUIC-RECOVERY]). A server MAY discard 0-RTT keys earlier if it +# determines that it has received all 0-RTT packets, which can be done +# by keeping track of missing packet numbers. + +[[spec]] +level = "SHOULD" +quote = ''' +Therefore, a client SHOULD discard 0-RTT keys as soon as it installs +1-RTT keys as they have no use after that moment. +''' + +[[spec]] +level = "MAY" +quote = ''' +Additionally, a server MAY discard 0-RTT keys as soon as it receives +a 1-RTT packet. +''' + +[[spec]] +level = "MAY" +quote = ''' +Servers MAY temporarily retain +0-RTT keys to allow decrypting reordered packets without requiring +their contents to be retransmitted with 1-RTT keys. +''' + +[[spec]] +level = "MUST" +quote = ''' +After receiving +a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; +the RECOMMENDED time period is three times the Probe Timeout (PTO, +see [QUIC-RECOVERY]). +''' + +[[spec]] +level = "MAY" +quote = ''' +A server MAY discard 0-RTT keys earlier if it +determines that it has received all 0-RTT packets, which can be done +by keeping track of missing packet numbers. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml new file mode 100644 index 0000000000..05854253d4 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.9.toml @@ -0,0 +1,53 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9" + +# Discarding Unused Keys +# +# After QUIC has completed a move to a new encryption level, packet +# protection keys for previous encryption levels can be discarded. +# This occurs several times during the handshake, as well as when keys +# are updated; see Section 6. +# +# Packet protection keys are not discarded immediately when new keys +# are available. If packets from a lower encryption level contain +# CRYPTO frames, frames that retransmit that data MUST be sent at the +# same encryption level. Similarly, an endpoint generates +# acknowledgments for packets at the same encryption level as the +# packet being acknowledged. Thus, it is possible that keys for a +# lower encryption level are needed for a short time after keys for a +# newer encryption level are available. +# +# An endpoint cannot discard keys for a given encryption level unless +# it has received all the cryptographic handshake messages from its +# peer at that encryption level and its peer has done the same. +# Different methods for determining this are provided for Initial keys +# (Section 4.9.1) and Handshake keys (Section 4.9.2). These methods do +# not prevent packets from being received or sent at that encryption +# level because a peer might not have received all the acknowledgments +# necessary. +# +# Though an endpoint might retain older keys, new data MUST be sent at +# the highest currently available encryption level. Only ACK frames +# and retransmissions of data in CRYPTO frames are sent at a previous +# encryption level. These packets MAY also include PADDING frames. + +[[spec]] +level = "MUST" +quote = ''' +If packets from a lower encryption level contain +CRYPTO frames, frames that retransmit that data MUST be sent at the +same encryption level. +''' + +[[spec]] +level = "MUST" +quote = ''' +Though an endpoint might retain older keys, new data MUST be sent at +the highest currently available encryption level. +''' + +[[spec]] +level = "MAY" +quote = ''' +These packets MAY also include PADDING frames. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.toml new file mode 100644 index 0000000000..6f375d277b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-4.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-4" + +# Carrying TLS Messages +# +# QUIC carries TLS handshake data in CRYPTO frames, each of which +# consists of a contiguous block of handshake data identified by an +# offset and length. Those frames are packaged into QUIC packets and +# encrypted under the current encryption level. As with TLS over TCP, +# once TLS handshake data has been delivered to QUIC, it is QUIC's +# responsibility to deliver it reliably. Each chunk of data that is +# produced by TLS is associated with the set of keys that TLS is +# currently using. If QUIC needs to retransmit that data, it MUST use +# the same keys even if TLS has already updated to newer keys. +# +# Each encryption level corresponds to a packet number space. The +# packet number space that is used determines the semantics of frames. +# Some frames are prohibited in different packet number spaces; see +# Section 12.5 of [QUIC-TRANSPORT]. +# +# Because packets could be reordered on the wire, QUIC uses the packet +# type to indicate which keys were used to protect a given packet, as +# shown in Table 1. When packets of different types need to be sent, +# endpoints SHOULD use coalesced packets to send them in the same UDP +# datagram. +# +# +=====================+=================+==================+ +# | Packet Type | Encryption Keys | PN Space | +# +=====================+=================+==================+ +# | Initial | Initial secrets | Initial | +# +=====================+-----------------+------------------+ +# | 0-RTT Protected | 0-RTT | Application data | +# +=====================+-----------------+------------------+ +# | Handshake | Handshake | Handshake | +# +=====================+-----------------+------------------+ +# | Retry | Retry | N/A | +# +=====================+-----------------+------------------+ +# | Version Negotiation | N/A | N/A | +# +=====================+-----------------+------------------+ +# | Short Header | 1-RTT | Application data | +# +=====================+-----------------+------------------+ +# +# Table 1: Encryption Keys by Packet Type +# +# Section 17 of [QUIC-TRANSPORT] shows how packets at the various +# encryption levels fit into the handshake process. + +[[spec]] +level = "MUST" +quote = ''' +If QUIC needs to retransmit that data, it MUST use +the same keys even if TLS has already updated to newer keys. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When packets of different types need to be sent, +endpoints SHOULD use coalesced packets to send them in the same UDP +datagram. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.1.toml new file mode 100644 index 0000000000..9913e1fc85 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.1.toml @@ -0,0 +1,49 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.1" + +# Packet Protection Keys +# +# QUIC derives packet protection keys in the same way that TLS derives +# record protection keys. +# +# Each encryption level has separate secret values for protection of +# packets sent in each direction. These traffic secrets are derived by +# TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all +# encryption levels except the Initial encryption level. The secrets +# for the Initial encryption level are computed based on the client's +# initial Destination Connection ID, as described in Section 5.2. +# +# The keys used for packet protection are computed from the TLS secrets +# using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label +# function described in Section 7.1 of [TLS13] is used with the hash +# function from the negotiated cipher suite. All uses of HKDF-Expand- +# Label in QUIC use a zero-length Context. +# +# Note that labels, which are described using strings, are encoded as +# bytes using ASCII [ASCII] without quotes or any trailing NUL byte. +# +# Other versions of TLS MUST provide a similar function in order to be +# used with QUIC. +# +# The current encryption level secret and the label "quic key" are +# input to the KDF to produce the AEAD key; the label "quic iv" is used +# to derive the Initialization Vector (IV); see Section 5.3. The +# header protection key uses the "quic hp" label; see Section 5.4. +# Using these labels provides key separation between QUIC and TLS; see +# Section 9.6. +# +# Both "quic key" and "quic hp" are used to produce keys, so the Length +# provided to HKDF-Expand-Label along with these labels is determined +# by the size of keys in the AEAD or header protection algorithm. The +# Length provided with "quic iv" is the minimum length of the AEAD +# nonce or 8 bytes if that is larger; see [AEAD]. +# +# The KDF used for initial secrets is always the HKDF-Expand-Label +# function from TLS 1.3; see Section 5.2. + +[[spec]] +level = "MUST" +quote = ''' +Other versions of TLS MUST provide a similar function in order to be +used with QUIC. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.2.toml new file mode 100644 index 0000000000..a9cc058165 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.2.toml @@ -0,0 +1,80 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.2" + +# Initial Secrets +# +# Initial packets apply the packet protection process, but use a secret +# derived from the Destination Connection ID field from the client's +# first Initial packet. +# +# This secret is determined by using HKDF-Extract (see Section 2.2 of +# [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and +# the input keying material (IKM) of the Destination Connection ID +# field. This produces an intermediate pseudorandom key (PRK) that is +# used to derive two separate secrets for sending and receiving. +# +# The secret used by clients to construct Initial packets uses the PRK +# and the label "client in" as input to the HKDF-Expand-Label function +# from TLS [TLS13] to produce a 32-byte secret. Packets constructed by +# the server use the same process with the label "server in". The hash +# function for HKDF when deriving initial secrets and keys is SHA-256 +# [SHA]. +# +# This process in pseudocode is: +# +# initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a +# initial_secret = HKDF-Extract(initial_salt, +# client_dst_connection_id) +# +# client_initial_secret = HKDF-Expand-Label(initial_secret, +# "client in", "", +# Hash.length) +# server_initial_secret = HKDF-Expand-Label(initial_secret, +# "server in", "", +# Hash.length) +# +# The connection ID used with HKDF-Expand-Label is the Destination +# Connection ID in the Initial packet sent by the client. This will be +# a randomly selected value unless the client creates the Initial +# packet after receiving a Retry packet, where the Destination +# Connection ID is selected by the server. +# +# Future versions of QUIC SHOULD generate a new salt value, thus +# ensuring that the keys are different for each version of QUIC. This +# prevents a middlebox that recognizes only one version of QUIC from +# seeing or modifying the contents of packets from future versions. +# +# The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for +# Initial packets even where the TLS versions offered do not include +# TLS 1.3. +# +# The secrets used for constructing subsequent Initial packets change +# when a server sends a Retry packet to use the connection ID value +# selected by the server. The secrets do not change when a client +# changes the Destination Connection ID it uses in response to an +# Initial packet from the server. +# +# | Note: The Destination Connection ID field could be any length +# | up to 20 bytes, including zero length if the server sends a +# | Retry packet with a zero-length Source Connection ID field. +# | After a Retry, the Initial keys provide the client no assurance +# | that the server received its packet, so the client has to rely +# | on the exchange that included the Retry packet to validate the +# | server address; see Section 8.1 of [QUIC-TRANSPORT]. +# +# Appendix A contains sample Initial packets. + +[[spec]] +level = "SHOULD" +quote = ''' +Future versions of QUIC SHOULD generate a new salt value, thus +ensuring that the keys are different for each version of QUIC. +''' + +[[spec]] +level = "MUST" +quote = ''' +The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for +Initial packets even where the TLS versions offered do not include +TLS 1.3. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml new file mode 100644 index 0000000000..735c3fdb72 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.3.toml @@ -0,0 +1,74 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.3" + +# AEAD Usage +# +# The Authenticated Encryption with Associated Data (AEAD) function +# (see [AEAD]) used for QUIC packet protection is the AEAD that is +# negotiated for use with the TLS connection. For example, if TLS is +# using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM +# function is used. +# +# QUIC can use any of the cipher suites defined in [TLS13] with the +# exception of TLS_AES_128_CCM_8_SHA256. A cipher suite MUST NOT be +# negotiated unless a header protection scheme is defined for the +# cipher suite. This document defines a header protection scheme for +# all cipher suites defined in [TLS13] aside from +# TLS_AES_128_CCM_8_SHA256. These cipher suites have a 16-byte +# authentication tag and produce an output 16 bytes larger than their +# input. +# +# An endpoint MUST NOT reject a ClientHello that offers a cipher suite +# that it does not support, or it would be impossible to deploy a new +# cipher suite. This also applies to TLS_AES_128_CCM_8_SHA256. +# +# When constructing packets, the AEAD function is applied prior to +# applying header protection; see Section 5.4. The unprotected packet +# header is part of the associated data (A). When processing packets, +# an endpoint first removes the header protection. +# +# The key and IV for the packet are computed as described in +# Section 5.1. The nonce, N, is formed by combining the packet +# protection IV with the packet number. The 62 bits of the +# reconstructed QUIC packet number in network byte order are left- +# padded with zeros to the size of the IV. The exclusive OR of the +# padded packet number and the IV forms the AEAD nonce. +# +# The associated data, A, for the AEAD is the contents of the QUIC +# header, starting from the first byte of either the short or long +# header, up to and including the unprotected packet number. +# +# The input plaintext, P, for the AEAD is the payload of the QUIC +# packet, as described in [QUIC-TRANSPORT]. +# +# The output ciphertext, C, of the AEAD is transmitted in place of P. +# +# Some AEAD functions have limits for how many packets can be encrypted +# under the same key and IV; see Section 6.6. This might be lower than +# the packet number limit. An endpoint MUST initiate a key update +# (Section 6) prior to exceeding any limit set for the AEAD that is in +# use. + +[[spec]] +level = "MUST" +quote = ''' +A cipher suite MUST NOT be +negotiated unless a header protection scheme is defined for the +cipher suite. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT reject a ClientHello that offers a cipher suite +that it does not support, or it would be impossible to deploy a new +cipher suite. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST initiate a key update +(Section 6) prior to exceeding any limit set for the AEAD that is in +use. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.1.toml new file mode 100644 index 0000000000..bc0e91f028 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.1.toml @@ -0,0 +1,95 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.4.1" + +# Header Protection Application +# +# Header protection is applied after packet protection is applied (see +# Section 5.3). The ciphertext of the packet is sampled and used as +# input to an encryption algorithm. The algorithm used depends on the +# negotiated AEAD. +# +# The output of this algorithm is a 5-byte mask that is applied to the +# protected header fields using exclusive OR. The least significant +# bits of the first byte of the packet are masked by the least +# significant bits of the first mask byte, and the packet number is +# masked with the remaining bytes. Any unused bytes of mask that might +# result from a shorter packet number encoding are unused. +# +# Figure 6 shows a sample algorithm for applying header protection. +# Removing header protection only differs in the order in which the +# packet number length (pn_length) is determined (here "^" is used to +# represent exclusive OR). +# +# mask = header_protection(hp_key, sample) +# +# pn_length = (packet[0] & 0x03) + 1 +# if (packet[0] & 0x80) == 0x80: +# # Long header: 4 bits masked +# packet[0] ^= mask[0] & 0x0f +# else: +# # Short header: 5 bits masked +# packet[0] ^= mask[0] & 0x1f +# +# # pn_offset is the start of the Packet Number field. +# packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] +# +# Figure 6: Header Protection Pseudocode +# +# Specific header protection functions are defined based on the +# selected cipher suite; see Section 5.4.3 and Section 5.4.4. +# +# Figure 7 shows an example long header packet (Initial) and a short +# header packet (1-RTT). Figure 7 shows the fields in each header that +# are covered by header protection and the portion of the protected +# packet payload that is sampled. +# +# Initial Packet { +# Header Form (1) = 1, +# Fixed Bit (1) = 1, +# Long Packet Type (2) = 0, +# Reserved Bits (2), # Protected +# Packet Number Length (2), # Protected +# Version (32), +# DCID Len (8), +# Destination Connection ID (0..160), +# SCID Len (8), +# Source Connection ID (0..160), +# Token Length (i), +# Token (..), +# Length (i), +# Packet Number (8..32), # Protected +# Protected Payload (0..24), # Skipped Part +# Protected Payload (128), # Sampled Part +# Protected Payload (..) # Remainder +# } +# +# 1-RTT Packet { +# Header Form (1) = 0, +# Fixed Bit (1) = 1, +# Spin Bit (1), +# Reserved Bits (2), # Protected +# Key Phase (1), # Protected +# Packet Number Length (2), # Protected +# Destination Connection ID (0..160), +# Packet Number (8..32), # Protected +# Protected Payload (0..24), # Skipped Part +# Protected Payload (128), # Sampled Part +# Protected Payload (..), # Remainder +# } +# +# Figure 7: Header Protection and Ciphertext Sample +# +# Before a TLS cipher suite can be used with QUIC, a header protection +# algorithm MUST be specified for the AEAD used with that cipher suite. +# This document defines algorithms for AEAD_AES_128_GCM, +# AEAD_AES_128_CCM, AEAD_AES_256_GCM (all these AES AEADs are defined +# in [AEAD]), and AEAD_CHACHA20_POLY1305 (defined in [CHACHA]). Prior +# to TLS selecting a cipher suite, AES header protection is used +# (Section 5.4.3), matching the AEAD_AES_128_GCM packet protection. + +[[spec]] +level = "MUST" +quote = ''' +Before a TLS cipher suite can be used with QUIC, a header protection +algorithm MUST be specified for the AEAD used with that cipher suite. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.2.toml new file mode 100644 index 0000000000..16a2f3a973 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.4.2.toml @@ -0,0 +1,65 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.4.2" + +# Header Protection Sample +# +# The header protection algorithm uses both the header protection key +# and a sample of the ciphertext from the packet Payload field. +# +# The same number of bytes are always sampled, but an allowance needs +# to be made for the removal of protection by a receiving endpoint, +# which will not know the length of the Packet Number field. The +# sample of ciphertext is taken starting from an offset of 4 bytes +# after the start of the Packet Number field. That is, in sampling +# packet ciphertext for header protection, the Packet Number field is +# assumed to be 4 bytes long (its maximum possible encoded length). +# +# An endpoint MUST discard packets that are not long enough to contain +# a complete sample. +# +# To ensure that sufficient data is available for sampling, packets are +# padded so that the combined lengths of the encoded packet number and +# protected payload is at least 4 bytes longer than the sample required +# for header protection. The cipher suites defined in [TLS13] -- other +# than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme +# is not defined in this document -- have 16-byte expansions and +# 16-byte header protection samples. This results in needing at least +# 3 bytes of frames in the unprotected payload if the packet number is +# encoded on a single byte, or 2 bytes of frames for a 2-byte packet +# number encoding. +# +# The sampled ciphertext can be determined by the following pseudocode: +# +# # pn_offset is the start of the Packet Number field. +# sample_offset = pn_offset + 4 +# +# sample = packet[sample_offset..sample_offset+sample_length] +# +# Where the packet number offset of a short header packet can be +# calculated as: +# +# pn_offset = 1 + len(connection_id) +# +# And the packet number offset of a long header packet can be +# calculated as: +# +# pn_offset = 7 + len(destination_connection_id) + +# len(source_connection_id) + +# len(payload_length) +# if packet_type == Initial: +# pn_offset += len(token_length) + +# len(token) +# +# For example, for a packet with a short header, an 8-byte connection +# ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to +# 28 inclusive (using zero-based indexing). +# +# Multiple QUIC packets might be included in the same UDP datagram. +# Each packet is handled separately. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST discard packets that are not long enough to contain +a complete sample. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.5.toml new file mode 100644 index 0000000000..074c1fe274 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.5.toml @@ -0,0 +1,35 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.5" + +# Receiving Protected Packets +# +# Once an endpoint successfully receives a packet with a given packet +# number, it MUST discard all packets in the same packet number space +# with higher packet numbers if they cannot be successfully unprotected +# with either the same key, or -- if there is a key update -- a +# subsequent packet protection key; see Section 6. Similarly, a packet +# that appears to trigger a key update but cannot be unprotected +# successfully MUST be discarded. +# +# Failure to unprotect a packet does not necessarily indicate the +# existence of a protocol error in a peer or an attack. The truncated +# packet number encoding used in QUIC can cause packet numbers to be +# decoded incorrectly if they are delayed significantly. + +[[spec]] +level = "MUST" +quote = ''' +Once an endpoint successfully receives a packet with a given packet +number, it MUST discard all packets in the same packet number space +with higher packet numbers if they cannot be successfully unprotected +with either the same key, or -- if there is a key update -- a +subsequent packet protection key; see Section 6. +''' + +[[spec]] +level = "MUST" +quote = ''' +Similarly, a packet +that appears to trigger a key update but cannot be unprotected +successfully MUST be discarded. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml new file mode 100644 index 0000000000..58ea91c9b1 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.6.toml @@ -0,0 +1,117 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.6" + +# Use of 0-RTT Keys +# +# If 0-RTT keys are available (see Section 4.6.1), the lack of replay +# protection means that restrictions on their use are necessary to +# avoid replay attacks on the protocol. +# +# Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM, +# STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for +# use with 0-RTT as they carry application data. Application data that +# is received in 0-RTT could cause an application at the server to +# process the data multiple times rather than just once. Additional +# actions taken by a server as a result of processing replayed +# application data could have unwanted consequences. A client +# therefore MUST NOT use 0-RTT for application data unless specifically +# requested by the application that is in use. +# +# An application protocol that uses QUIC MUST include a profile that +# defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to +# carry QUIC frames that do not carry application data. For example, a +# profile for HTTP is described in [HTTP-REPLAY] and used for HTTP/3; +# see Section 10.9 of [QUIC-HTTP]. +# +# Though replaying packets might result in additional connection +# attempts, the effect of processing replayed frames that do not carry +# application data is limited to changing the state of the affected +# connection. A TLS handshake cannot be successfully completed using +# replayed packets. +# +# A client MAY wish to apply additional restrictions on what data it +# sends prior to the completion of the TLS handshake. +# +# A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys, +# except that it cannot send certain frames with 0-RTT keys; see +# Section 12.5 of [QUIC-TRANSPORT]. +# +# A client that receives an indication that its 0-RTT data has been +# accepted by a server can send 0-RTT data until it receives all of the +# server's handshake messages. A client SHOULD stop sending 0-RTT data +# if it receives an indication that 0-RTT data has been rejected. +# +# A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT +# keys to protect acknowledgments of 0-RTT packets. A client MUST NOT +# attempt to decrypt 0-RTT packets it receives and instead MUST discard +# them. +# +# Once a client has installed 1-RTT keys, it MUST NOT send any more +# 0-RTT packets. +# +# | Note: 0-RTT data can be acknowledged by the server as it +# | receives it, but any packets containing acknowledgments of +# | 0-RTT data cannot have packet protection removed by the client +# | until the TLS handshake is complete. The 1-RTT keys necessary +# | to remove packet protection cannot be derived until the client +# | receives all server handshake messages. + +[[spec]] +level = "MUST" +quote = ''' +A client +therefore MUST NOT use 0-RTT for application data unless specifically +requested by the application that is in use. +''' + +[[spec]] +level = "MUST" +quote = ''' +An application protocol that uses QUIC MUST include a profile that +defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to +carry QUIC frames that do not carry application data. +''' + +[[spec]] +level = "MAY" +quote = ''' +A client MAY wish to apply additional restrictions on what data it +sends prior to the completion of the TLS handshake. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A client SHOULD stop sending 0-RTT data +if it receives an indication that 0-RTT data has been rejected. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT +keys to protect acknowledgments of 0-RTT packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT +attempt to decrypt 0-RTT packets it receives and instead MUST discard +them. +''' + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT +attempt to decrypt 0-RTT packets it receives and instead MUST discard +them. +''' + +[[spec]] +level = "MUST" +quote = ''' +Once a client has installed 1-RTT keys, it MUST NOT send any more +0-RTT packets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml new file mode 100644 index 0000000000..33679ebd73 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-5.7.toml @@ -0,0 +1,95 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.7" + +# Receiving Out-of-Order Protected Packets +# +# Due to reordering and loss, protected packets might be received by an +# endpoint before the final TLS handshake messages are received. A +# client will be unable to decrypt 1-RTT packets from the server, +# whereas a server will be able to decrypt 1-RTT packets from the +# client. Endpoints in either role MUST NOT decrypt 1-RTT packets from +# their peer prior to completing the handshake. +# +# Even though 1-RTT keys are available to a server after receiving the +# first handshake messages from a client, it is missing assurances on +# the client state: +# +# * The client is not authenticated, unless the server has chosen to +# use a pre-shared key and validated the client's pre-shared key +# binder; see Section 4.2.11 of [TLS13]. +# +# * The client has not demonstrated liveness, unless the server has +# validated the client's address with a Retry packet or other means; +# see Section 8.1 of [QUIC-TRANSPORT]. +# +# * Any received 0-RTT data that the server responds to might be due +# to a replay attack. +# +# Therefore, the server's use of 1-RTT keys before the handshake is +# complete is limited to sending data. A server MUST NOT process +# incoming 1-RTT protected packets before the TLS handshake is +# complete. Because sending acknowledgments indicates that all frames +# in a packet have been processed, a server cannot send acknowledgments +# for 1-RTT packets until the TLS handshake is complete. Received +# packets protected with 1-RTT keys MAY be stored and later decrypted +# and used once the handshake is complete. +# +# | Note: TLS implementations might provide all 1-RTT secrets prior +# | to handshake completion. Even where QUIC implementations have +# | 1-RTT read keys, those keys are not to be used prior to +# | completing the handshake. +# +# The requirement for the server to wait for the client Finished +# message creates a dependency on that message being delivered. A +# client can avoid the potential for head-of-line blocking that this +# implies by sending its 1-RTT packets coalesced with a Handshake +# packet containing a copy of the CRYPTO frame that carries the +# Finished message, until one of the Handshake packets is acknowledged. +# This enables immediate server processing for those packets. +# +# A server could receive packets protected with 0-RTT keys prior to +# receiving a TLS ClientHello. The server MAY retain these packets for +# later decryption in anticipation of receiving a ClientHello. +# +# A client generally receives 1-RTT keys at the same time as the +# handshake completes. Even if it has 1-RTT secrets, a client MUST NOT +# process incoming 1-RTT protected packets before the TLS handshake is +# complete. + +[[spec]] +level = "MUST" +quote = ''' +Endpoints in either role MUST NOT decrypt 1-RTT packets from +their peer prior to completing the handshake. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST NOT process +incoming 1-RTT protected packets before the TLS handshake is +complete. +''' + +[[spec]] +level = "MAY" +quote = ''' +Received +packets protected with 1-RTT keys MAY be stored and later decrypted +and used once the handshake is complete. +''' + +[[spec]] +level = "MAY" +quote = ''' +The server MAY retain these packets for +later decryption in anticipation of receiving a ClientHello. +''' + +[[spec]] +level = "MUST" +quote = ''' +Even if it has 1-RTT secrets, a client MUST NOT +process incoming 1-RTT protected packets before the TLS handshake is +complete. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml new file mode 100644 index 0000000000..baa58a067e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.1.toml @@ -0,0 +1,78 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.1" + +# Initiating a Key Update +# +# Endpoints maintain separate read and write secrets for packet +# protection. An endpoint initiates a key update by updating its +# packet protection write secret and using that to protect new packets. +# The endpoint creates a new write secret from the existing write +# secret as performed in Section 7.2 of [TLS13]. This uses the KDF +# function provided by TLS with a label of "quic ku". The +# corresponding key and IV are created from that secret as defined in +# Section 5.1. The header protection key is not updated. +# +# For example, to update write keys with TLS 1.3, HKDF-Expand-Label is +# used as: +# +# secret_ = HKDF-Expand-Label(secret_, "quic ku", +# "", Hash.length) +# +# The endpoint toggles the value of the Key Phase bit and uses the +# updated key and IV to protect all subsequent packets. +# +# An endpoint MUST NOT initiate a key update prior to having confirmed +# the handshake (Section 4.1.2). An endpoint MUST NOT initiate a +# subsequent key update unless it has received an acknowledgment for a +# packet that was sent protected with keys from the current key phase. +# This ensures that keys are available to both peers before another key +# update can be initiated. This can be implemented by tracking the +# lowest packet number sent with each key phase and the highest +# acknowledged packet number in the 1-RTT space: once the latter is +# higher than or equal to the former, another key update can be +# initiated. +# +# | Note: Keys of packets other than the 1-RTT packets are never +# | updated; their keys are derived solely from the TLS handshake +# | state. +# +# The endpoint that initiates a key update also updates the keys that +# it uses for receiving packets. These keys will be needed to process +# packets the peer sends after updating. +# +# An endpoint MUST retain old keys until it has successfully +# unprotected a packet sent using the new keys. An endpoint SHOULD +# retain old keys for some time after unprotecting a packet sent using +# the new keys. Discarding old keys too early can cause delayed +# packets to be discarded. Discarding packets will be interpreted as +# packet loss by the peer and could adversely affect performance. + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT initiate a key update prior to having confirmed +the handshake (Section 4.1.2). +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT initiate a +subsequent key update unless it has received an acknowledgment for a +packet that was sent protected with keys from the current key phase. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST retain old keys until it has successfully +unprotected a packet sent using the new keys. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD +retain old keys for some time after unprotecting a packet sent using +the new keys. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml new file mode 100644 index 0000000000..9a48c5ec70 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.2.toml @@ -0,0 +1,72 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.2" + +# Responding to a Key Update +# +# A peer is permitted to initiate a key update after receiving an +# acknowledgment of a packet in the current key phase. An endpoint +# detects a key update when processing a packet with a key phase that +# differs from the value used to protect the last packet it sent. To +# process this packet, the endpoint uses the next packet protection key +# and IV. See Section 6.3 for considerations about generating these +# keys. +# +# If a packet is successfully processed using the next key and IV, then +# the peer has initiated a key update. The endpoint MUST update its +# send keys to the corresponding key phase in response, as described in +# Section 6.1. Sending keys MUST be updated before sending an +# acknowledgment for the packet that was received with updated keys. +# By acknowledging the packet that triggered the key update in a packet +# protected with the updated keys, the endpoint signals that the key +# update is complete. +# +# An endpoint can defer sending the packet or acknowledgment according +# to its normal packet sending behavior; it is not necessary to +# immediately generate a packet in response to a key update. The next +# packet sent by the endpoint will use the updated keys. The next +# packet that contains an acknowledgment will cause the key update to +# be completed. If an endpoint detects a second update before it has +# sent any packets with updated keys containing an acknowledgment for +# the packet that initiated the key update, it indicates that its peer +# has updated keys twice without awaiting confirmation. An endpoint +# MAY treat such consecutive key updates as a connection error of type +# KEY_UPDATE_ERROR. +# +# An endpoint that receives an acknowledgment that is carried in a +# packet protected with old keys where any acknowledged packet was +# protected with newer keys MAY treat that as a connection error of +# type KEY_UPDATE_ERROR. This indicates that a peer has received and +# acknowledged a packet that initiates a key update, but has not +# updated keys in response. + +[[spec]] +level = "MUST" +quote = ''' +The endpoint MUST update its +send keys to the corresponding key phase in response, as described in +Section 6.1. +''' + +[[spec]] +level = "MUST" +quote = ''' +Sending keys MUST be updated before sending an +acknowledgment for the packet that was received with updated keys. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint +MAY treat such consecutive key updates as a connection error of type +KEY_UPDATE_ERROR. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint that receives an acknowledgment that is carried in a +packet protected with old keys where any acknowledged packet was +protected with newer keys MAY treat that as a connection error of +type KEY_UPDATE_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml new file mode 100644 index 0000000000..c0c50f43d8 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.3.toml @@ -0,0 +1,76 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.3" + +# Timing of Receive Key Generation +# +# Endpoints responding to an apparent key update MUST NOT generate a +# timing side-channel signal that might indicate that the Key Phase bit +# was invalid (see Section 9.5). Endpoints can use randomized packet +# protection keys in place of discarded keys when key updates are not +# yet permitted. Using randomized keys ensures that attempting to +# remove packet protection does not result in timing variations, and +# results in packets with an invalid Key Phase bit being rejected. +# +# The process of creating new packet protection keys for receiving +# packets could reveal that a key update has occurred. An endpoint MAY +# generate new keys as part of packet processing, but this creates a +# timing signal that could be used by an attacker to learn when key +# updates happen and thus leak the value of the Key Phase bit. +# +# Endpoints are generally expected to have current and next receive +# packet protection keys available. For a short period after a key +# update completes, up to the PTO, endpoints MAY defer generation of +# the next set of receive packet protection keys. This allows +# endpoints to retain only two sets of receive keys; see Section 6.5. +# +# Once generated, the next set of packet protection keys SHOULD be +# retained, even if the packet that was received was subsequently +# discarded. Packets containing apparent key updates are easy to +# forge, and while the process of key update does not require +# significant effort, triggering this process could be used by an +# attacker for DoS. +# +# For this reason, endpoints MUST be able to retain two sets of packet +# protection keys for receiving packets: the current and the next. +# Retaining the previous keys in addition to these might improve +# performance, but this is not essential. + +[[spec]] +level = "MUST" +quote = ''' +Endpoints responding to an apparent key update MUST NOT generate a +timing side-channel signal that might indicate that the Key Phase bit +was invalid (see Section 9.5). +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY +generate new keys as part of packet processing, but this creates a +timing signal that could be used by an attacker to learn when key +updates happen and thus leak the value of the Key Phase bit. +''' + +[[spec]] +level = "MAY" +quote = ''' +For a short period after a key +update completes, up to the PTO, endpoints MAY defer generation of +the next set of receive packet protection keys. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Once generated, the next set of packet protection keys SHOULD be +retained, even if the packet that was received was subsequently +discarded. +''' + +[[spec]] +level = "MUST" +quote = ''' +For this reason, endpoints MUST be able to retain two sets of packet +protection keys for receiving packets: the current and the next. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.4.toml new file mode 100644 index 0000000000..f86f508659 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.4.toml @@ -0,0 +1,30 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.4" + +# Sending with Updated Keys +# +# An endpoint never sends packets that are protected with old keys. +# Only the current keys are used. Keys used for protecting packets can +# be discarded immediately after switching to newer keys. +# +# Packets with higher packet numbers MUST be protected with either the +# same or newer packet protection keys than packets with lower packet +# numbers. An endpoint that successfully removes protection with old +# keys when newer keys were used for packets with lower packet numbers +# MUST treat this as a connection error of type KEY_UPDATE_ERROR. + +[[spec]] +level = "MUST" +quote = ''' +Packets with higher packet numbers MUST be protected with either the +same or newer packet protection keys than packets with lower packet +numbers. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint that successfully removes protection with old +keys when newer keys were used for packets with lower packet numbers +MUST treat this as a connection error of type KEY_UPDATE_ERROR. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml new file mode 100644 index 0000000000..311db611cb --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.5.toml @@ -0,0 +1,91 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.5" + +# Receiving with Different Keys +# +# For receiving packets during a key update, packets protected with +# older keys might arrive if they were delayed by the network. +# Retaining old packet protection keys allows these packets to be +# successfully processed. +# +# As packets protected with keys from the next key phase use the same +# Key Phase value as those protected with keys from the previous key +# phase, it is necessary to distinguish between the two if packets +# protected with old keys are to be processed. This can be done using +# packet numbers. A recovered packet number that is lower than any +# packet number from the current key phase uses the previous packet +# protection keys; a recovered packet number that is higher than any +# packet number from the current key phase requires the use of the next +# packet protection keys. +# +# Some care is necessary to ensure that any process for selecting +# between previous, current, and next packet protection keys does not +# expose a timing side channel that might reveal which keys were used +# to remove packet protection. See Section 9.5 for more information. +# +# Alternatively, endpoints can retain only two sets of packet +# protection keys, swapping previous for next after enough time has +# passed to allow for reordering in the network. In this case, the Key +# Phase bit alone can be used to select keys. +# +# An endpoint MAY allow a period of approximately the Probe Timeout +# (PTO; see [QUIC-RECOVERY]) after promoting the next set of receive +# keys to be current before it creates the subsequent set of packet +# protection keys. These updated keys MAY replace the previous keys at +# that time. With the caveat that PTO is a subjective measure -- that +# is, a peer could have a different view of the RTT -- this time is +# expected to be long enough that any reordered packets would be +# declared lost by a peer even if they were acknowledged and short +# enough to allow a peer to initiate further key updates. +# +# Endpoints need to allow for the possibility that a peer might not be +# able to decrypt packets that initiate a key update during the period +# when the peer retains old keys. Endpoints SHOULD wait three times +# the PTO before initiating a key update after receiving an +# acknowledgment that confirms that the previous key update was +# received. Failing to allow sufficient time could lead to packets +# being discarded. +# +# An endpoint SHOULD retain old read keys for no more than three times +# the PTO after having received a packet protected using the new keys. +# After this period, old read keys and their corresponding secrets +# SHOULD be discarded. + +[[spec]] +level = "MAY" +quote = ''' +An endpoint MAY allow a period of approximately the Probe Timeout +(PTO; see [QUIC-RECOVERY]) after promoting the next set of receive +keys to be current before it creates the subsequent set of packet +protection keys. +''' + +[[spec]] +level = "MAY" +quote = ''' +These updated keys MAY replace the previous keys at +that time. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD wait three times +the PTO before initiating a key update after receiving an +acknowledgment that confirms that the previous key update was +received. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD retain old read keys for no more than three times +the PTO after having received a packet protected using the new keys. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +After this period, old read keys and their corresponding secrets +SHOULD be discarded. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml new file mode 100644 index 0000000000..44668b8179 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.6.toml @@ -0,0 +1,164 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.6" + +# Limits on AEAD Usage +# +# This document sets usage limits for AEAD algorithms to ensure that +# overuse does not give an adversary a disproportionate advantage in +# attacking the confidentiality and integrity of communications when +# using QUIC. +# +# The usage limits defined in TLS 1.3 exist for protection against +# attacks on confidentiality and apply to successful applications of +# AEAD protection. The integrity protections in authenticated +# encryption also depend on limiting the number of attempts to forge +# packets. TLS achieves this by closing connections after any record +# fails an authentication check. In comparison, QUIC ignores any +# packet that cannot be authenticated, allowing multiple forgery +# attempts. +# +# QUIC accounts for AEAD confidentiality and integrity limits +# separately. The confidentiality limit applies to the number of +# packets encrypted with a given key. The integrity limit applies to +# the number of packets decrypted within a given connection. Details +# on enforcing these limits for each AEAD algorithm follow below. +# +# Endpoints MUST count the number of encrypted packets for each set of +# keys. If the total number of encrypted packets with the same key +# exceeds the confidentiality limit for the selected AEAD, the endpoint +# MUST stop using those keys. Endpoints MUST initiate a key update +# before sending more protected packets than the confidentiality limit +# for the selected AEAD permits. If a key update is not possible or +# integrity limits are reached, the endpoint MUST stop using the +# connection and only send stateless resets in response to receiving +# packets. It is RECOMMENDED that endpoints immediately close the +# connection with a connection error of type AEAD_LIMIT_REACHED before +# reaching a state where key updates are not possible. +# +# For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit +# is 2^23 encrypted packets; see Appendix B.1. For +# AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the +# number of possible packets (2^62) and so can be disregarded. For +# AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted +# packets; see Appendix B.2. Applying a limit reduces the probability +# that an attacker can distinguish the AEAD in use from a random +# permutation; see [AEBounds], [ROBUST], and [GCM-MU]. +# +# In addition to counting packets sent, endpoints MUST count the number +# of received packets that fail authentication during the lifetime of a +# connection. If the total number of received packets that fail +# authentication within the connection, across all keys, exceeds the +# integrity limit for the selected AEAD, the endpoint MUST immediately +# close the connection with a connection error of type +# AEAD_LIMIT_REACHED and not process any more packets. +# +# For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is +# 2^52 invalid packets; see Appendix B.1. For AEAD_CHACHA20_POLY1305, +# the integrity limit is 2^36 invalid packets; see [AEBounds]. For +# AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see +# Appendix B.2. Applying this limit reduces the probability that an +# attacker can successfully forge a packet; see [AEBounds], [ROBUST], +# and [GCM-MU]. +# +# Endpoints that limit the size of packets MAY use higher +# confidentiality and integrity limits; see Appendix B for details. +# +# Future analyses and specifications MAY relax confidentiality or +# integrity limits for an AEAD. +# +# Any TLS cipher suite that is specified for use with QUIC MUST define +# limits on the use of the associated AEAD function that preserves +# margins for confidentiality and integrity. That is, limits MUST be +# specified for the number of packets that can be authenticated and for +# the number of packets that can fail authentication. Providing a +# reference to any analysis upon which values are based -- and any +# assumptions used in that analysis -- allows limits to be adapted to +# varying usage conditions. + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST count the number of encrypted packets for each set of +keys. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the total number of encrypted packets with the same key +exceeds the confidentiality limit for the selected AEAD, the endpoint +MUST stop using those keys. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST initiate a key update +before sending more protected packets than the confidentiality limit +for the selected AEAD permits. +''' + +[[spec]] +level = "MUST" +quote = ''' +If a key update is not possible or +integrity limits are reached, the endpoint MUST stop using the +connection and only send stateless resets in response to receiving +packets. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +It is RECOMMENDED that endpoints immediately close the +connection with a connection error of type AEAD_LIMIT_REACHED before +reaching a state where key updates are not possible. +''' + +[[spec]] +level = "MUST" +quote = ''' +In addition to counting packets sent, endpoints MUST count the number +of received packets that fail authentication during the lifetime of a +connection. +''' + +[[spec]] +level = "MUST" +quote = ''' +If the total number of received packets that fail +authentication within the connection, across all keys, exceeds the +integrity limit for the selected AEAD, the endpoint MUST immediately +close the connection with a connection error of type +AEAD_LIMIT_REACHED and not process any more packets. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints that limit the size of packets MAY use higher +confidentiality and integrity limits; see Appendix B for details. +''' + +[[spec]] +level = "MAY" +quote = ''' +Future analyses and specifications MAY relax confidentiality or +integrity limits for an AEAD. +''' + +[[spec]] +level = "MUST" +quote = ''' +Any TLS cipher suite that is specified for use with QUIC MUST define +limits on the use of the associated AEAD function that preserves +margins for confidentiality and integrity. +''' + +[[spec]] +level = "MUST" +quote = ''' +That is, limits MUST be +specified for the number of packets that can be authenticated and for +the number of packets that can fail authentication. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml new file mode 100644 index 0000000000..786983f33c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-6.toml @@ -0,0 +1,77 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-6" + +# Key Update +# +# Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY +# initiate a key update. +# +# The Key Phase bit indicates which packet protection keys are used to +# protect the packet. The Key Phase bit is initially set to 0 for the +# first set of 1-RTT packets and toggled to signal each subsequent key +# update. +# +# The Key Phase bit allows a recipient to detect a change in keying +# material without needing to receive the first packet that triggered +# the change. An endpoint that notices a changed Key Phase bit updates +# keys and decrypts the packet that contains the changed value. +# +# Initiating a key update results in both endpoints updating keys. +# This differs from TLS where endpoints can update keys independently. +# +# This mechanism replaces the key update mechanism of TLS, which relies +# on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints +# MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the +# receipt of a TLS KeyUpdate message as a connection error of type +# 0x010a, equivalent to a fatal TLS alert of unexpected_message; see +# Section 4.8. +# +# Figure 9 shows a key update process, where the initial set of keys +# used (identified with @M) are replaced by updated keys (identified +# with @N). The value of the Key Phase bit is indicated in brackets +# []. +# +# Initiating Peer Responding Peer +# +# @M [0] QUIC Packets +# +# ... Update to @N +# @N [1] QUIC Packets +# --------> +# Update to @N ... +# QUIC Packets [1] @N +# <-------- +# QUIC Packets [1] @N +# containing ACK +# <-------- +# ... Key Update Permitted +# +# @N [1] QUIC Packets +# containing ACK for @N packets +# --------> +# Key Update Permitted ... +# +# Figure 9: Key Update + +[[spec]] +level = "MAY" +quote = ''' +Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY +initiate a key update. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints +MUST NOT send a TLS KeyUpdate message. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST treat the +receipt of a TLS KeyUpdate message as a connection error of type +0x010a, equivalent to a fatal TLS alert of unexpected_message; see +Section 4.8. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-7.toml new file mode 100644 index 0000000000..56d290c615 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-7.toml @@ -0,0 +1,33 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-7" + +# Security of Initial Messages +# +# Initial packets are not protected with a secret key, so they are +# subject to potential tampering by an attacker. QUIC provides +# protection against attackers that cannot read packets but does not +# attempt to provide additional protection against attacks where the +# attacker can observe and inject packets. Some forms of tampering -- +# such as modifying the TLS messages themselves -- are detectable, but +# some -- such as modifying ACKs -- are not. +# +# For example, an attacker could inject a packet containing an ACK +# frame to make it appear that a packet had not been received or to +# create a false impression of the state of the connection (e.g., by +# modifying the ACK Delay). Note that such a packet could cause a +# legitimate packet to be dropped as a duplicate. Implementations +# SHOULD use caution in relying on any data that is contained in +# Initial packets that is not otherwise authenticated. +# +# It is also possible for the attacker to tamper with data that is +# carried in Handshake packets, but because that sort of tampering +# requires modifying TLS handshake messages, any such tampering will +# cause the TLS handshake to fail. + +[[spec]] +level = "SHOULD" +quote = ''' +Implementations +SHOULD use caution in relying on any data that is contained in +Initial packets that is not otherwise authenticated. +''' + diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/8.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml similarity index 51% rename from specs/www.rfc-editor.org/rfc/rfc9001/8.1.toml rename to .duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml index 6aec5d62cf..028b682f85 100644 --- a/specs/www.rfc-editor.org/rfc/rfc9001/8.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.1.toml @@ -1,28 +1,28 @@ target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.1" -# 8.1. Protocol Negotiation +# Protocol Negotiation # -# QUIC requires that the cryptographic handshake provide authenticated -# protocol negotiation. TLS uses Application-Layer Protocol -# Negotiation [ALPN] to select an application protocol. Unless another -# mechanism is used for agreeing on an application protocol, endpoints -# MUST use ALPN for this purpose. +# QUIC requires that the cryptographic handshake provide authenticated +# protocol negotiation. TLS uses Application-Layer Protocol +# Negotiation [ALPN] to select an application protocol. Unless another +# mechanism is used for agreeing on an application protocol, endpoints +# MUST use ALPN for this purpose. # -# When using ALPN, endpoints MUST immediately close a connection (see -# Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS -# alert (QUIC error code 0x0178; see Section 4.8) if an application -# protocol is not negotiated. While [ALPN] only specifies that servers -# use this alert, QUIC clients MUST use error 0x0178 to terminate a -# connection when ALPN negotiation fails. +# When using ALPN, endpoints MUST immediately close a connection (see +# Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS +# alert (QUIC error code 0x0178; see Section 4.8) if an application +# protocol is not negotiated. While [ALPN] only specifies that servers +# use this alert, QUIC clients MUST use error 0x0178 to terminate a +# connection when ALPN negotiation fails. # -# An application protocol MAY restrict the QUIC versions that it can -# operate over. Servers MUST select an application protocol compatible -# with the QUIC version that the client has selected. The server MUST -# treat the inability to select a compatible application protocol as a -# connection error of type 0x0178 (no_application_protocol). -# Similarly, a client MUST treat the selection of an incompatible -# application protocol by a server as a connection error of type -# 0x0178. +# An application protocol MAY restrict the QUIC versions that it can +# operate over. Servers MUST select an application protocol compatible +# with the QUIC version that the client has selected. The server MUST +# treat the inability to select a compatible application protocol as a +# connection error of type 0x0178 (no_application_protocol). +# Similarly, a client MUST treat the selection of an incompatible +# application protocol by a server as a connection error of type +# 0x0178. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml new file mode 100644 index 0000000000..b8db0d43ed --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.2.toml @@ -0,0 +1,81 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.2" + +# QUIC Transport Parameters Extension +# +# QUIC transport parameters are carried in a TLS extension. Different +# versions of QUIC might define a different method for negotiating +# transport configuration. +# +# Including transport parameters in the TLS handshake provides +# integrity protection for these values. +# +# enum { +# quic_transport_parameters(0x39), (65535) +# } ExtensionType; +# +# The extension_data field of the quic_transport_parameters extension +# contains a value that is defined by the version of QUIC that is in +# use. +# +# The quic_transport_parameters extension is carried in the ClientHello +# and the EncryptedExtensions messages during the handshake. Endpoints +# MUST send the quic_transport_parameters extension; endpoints that +# receive ClientHello or EncryptedExtensions messages without the +# quic_transport_parameters extension MUST close the connection with an +# error of type 0x016d (equivalent to a fatal TLS missing_extension +# alert, see Section 4.8). +# +# Transport parameters become available prior to the completion of the +# handshake. A server might use these values earlier than handshake +# completion. However, the value of transport parameters is not +# authenticated until the handshake completes, so any use of these +# parameters cannot depend on their authenticity. Any tampering with +# transport parameters will cause the handshake to fail. +# +# Endpoints MUST NOT send this extension in a TLS connection that does +# not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A +# fatal unsupported_extension alert MUST be sent by an implementation +# that supports this extension if the extension is received when the +# transport is not QUIC. +# +# Negotiating the quic_transport_parameters extension causes the +# EndOfEarlyData to be removed; see Section 8.3. + +[[spec]] +level = "MUST" +quote = ''' +Endpoints +MUST send the quic_transport_parameters extension; endpoints that +receive ClientHello or EncryptedExtensions messages without the +quic_transport_parameters extension MUST close the connection with an +error of type 0x016d (equivalent to a fatal TLS missing_extension +alert, see Section 4.8). +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints +MUST send the quic_transport_parameters extension; endpoints that +receive ClientHello or EncryptedExtensions messages without the +quic_transport_parameters extension MUST close the connection with an +error of type 0x016d (equivalent to a fatal TLS missing_extension +alert, see Section 4.8). +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST NOT send this extension in a TLS connection that does +not use QUIC (such as the use of TLS with TCP defined in [TLS13]). +''' + +[[spec]] +level = "MUST" +quote = ''' +A +fatal unsupported_extension alert MUST be sent by an implementation +that supports this extension if the extension is received when the +transport is not QUIC. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.3.toml new file mode 100644 index 0000000000..396d17db0b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.3.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.3" + +# Removing the EndOfEarlyData Message +# +# The TLS EndOfEarlyData message is not used with QUIC. QUIC does not +# rely on this message to mark the end of 0-RTT data or to signal the +# change to Handshake keys. +# +# Clients MUST NOT send the EndOfEarlyData message. A server MUST +# treat receipt of a CRYPTO frame in a 0-RTT packet as a connection +# error of type PROTOCOL_VIOLATION. +# +# As a result, EndOfEarlyData does not appear in the TLS handshake +# transcript. + +[[spec]] +level = "MUST" +quote = ''' +Clients MUST NOT send the EndOfEarlyData message. +''' + +[[spec]] +level = "MUST" +quote = ''' +A server MUST +treat receipt of a CRYPTO frame in a 0-RTT packet as a connection +error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.4.toml new file mode 100644 index 0000000000..7d0b149a99 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-8.4.toml @@ -0,0 +1,33 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.4" + +# Prohibit TLS Middlebox Compatibility Mode +# +# Appendix D.4 of [TLS13] describes an alteration to the TLS 1.3 +# handshake as a workaround for bugs in some middleboxes. The TLS 1.3 +# middlebox compatibility mode involves setting the legacy_session_id +# field to a 32-byte value in the ClientHello and ServerHello, then +# sending a change_cipher_spec record. Both field and record carry no +# semantic content and are ignored. +# +# This mode has no use in QUIC as it only applies to middleboxes that +# interfere with TLS over TCP. QUIC also provides no means to carry a +# change_cipher_spec record. A client MUST NOT request the use of the +# TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a +# TLS ClientHello with a non-empty legacy_session_id field as a +# connection error of type PROTOCOL_VIOLATION. + +[[spec]] +level = "MUST" +quote = ''' +A client MUST NOT request the use of the +TLS 1.3 compatibility mode. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A server SHOULD treat the receipt of a +TLS ClientHello with a non-empty legacy_session_id field as a +connection error of type PROTOCOL_VIOLATION. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml new file mode 100644 index 0000000000..209e425ed3 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.2.toml @@ -0,0 +1,99 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.2" + +# Replay Attacks with 0-RTT +# +# As described in Section 8 of [TLS13], use of TLS early data comes +# with an exposure to replay attack. The use of 0-RTT in QUIC is +# similarly vulnerable to replay attack. +# +# Endpoints MUST implement and use the replay protections described in +# [TLS13], however it is recognized that these protections are +# imperfect. Therefore, additional consideration of the risk of replay +# is needed. +# +# QUIC is not vulnerable to replay attack, except via the application +# protocol information it might carry. The management of QUIC protocol +# state based on the frame types defined in [QUIC-TRANSPORT] is not +# vulnerable to replay. Processing of QUIC frames is idempotent and +# cannot result in invalid connection states if frames are replayed, +# reordered, or lost. QUIC connections do not produce effects that +# last beyond the lifetime of the connection, except for those produced +# by the application protocol that QUIC serves. +# +# TLS session tickets and address validation tokens are used to carry +# QUIC configuration information between connections, specifically, to +# enable a server to efficiently recover state that is used in +# connection establishment and address validation. These MUST NOT be +# used to communicate application semantics between endpoints; clients +# MUST treat them as opaque values. The potential for reuse of these +# tokens means that they require stronger protections against replay. +# +# A server that accepts 0-RTT on a connection incurs a higher cost than +# accepting a connection without 0-RTT. This includes higher +# processing and computation costs. Servers need to consider the +# probability of replay and all associated costs when accepting 0-RTT. +# +# Ultimately, the responsibility for managing the risks of replay +# attacks with 0-RTT lies with an application protocol. An application +# protocol that uses QUIC MUST describe how the protocol uses 0-RTT and +# the measures that are employed to protect against replay attack. An +# analysis of replay risk needs to consider all QUIC protocol features +# that carry application semantics. +# +# Disabling 0-RTT entirely is the most effective defense against replay +# attack. +# +# QUIC extensions MUST either describe how replay attacks affect their +# operation or prohibit the use of the extension in 0-RTT. Application +# protocols MUST either prohibit the use of extensions that carry +# application semantics in 0-RTT or provide replay mitigation +# strategies. + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST implement and use the replay protections described in +[TLS13], however it is recognized that these protections are +imperfect. +''' + +[[spec]] +level = "MUST" +quote = ''' +These MUST NOT be +used to communicate application semantics between endpoints; clients +MUST treat them as opaque values. +''' + +[[spec]] +level = "MUST" +quote = ''' +These MUST NOT be +used to communicate application semantics between endpoints; clients +MUST treat them as opaque values. +''' + +[[spec]] +level = "MUST" +quote = ''' +An application +protocol that uses QUIC MUST describe how the protocol uses 0-RTT and +the measures that are employed to protect against replay attack. +''' + +[[spec]] +level = "MUST" +quote = ''' +QUIC extensions MUST either describe how replay attacks affect their +operation or prohibit the use of the extension in 0-RTT. +''' + +[[spec]] +level = "MUST" +quote = ''' +Application +protocols MUST either prohibit the use of extensions that carry +application semantics in 0-RTT or provide replay mitigation +strategies. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.3.toml new file mode 100644 index 0000000000..902e6e8a86 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.3.toml @@ -0,0 +1,24 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.3" + +# Packet Reflection Attack Mitigation +# +# A small ClientHello that results in a large block of handshake +# messages from a server can be used in packet reflection attacks to +# amplify the traffic generated by an attacker. +# +# QUIC includes three defenses against this attack. First, the packet +# containing a ClientHello MUST be padded to a minimum size. Second, +# if responding to an unverified source address, the server is +# forbidden to send more than three times as many bytes as the number +# of bytes it has received (see Section 8.1 of [QUIC-TRANSPORT]). +# Finally, because acknowledgments of Handshake packets are +# authenticated, a blind attacker cannot forge them. Put together, +# these defenses limit the level of amplification. + +[[spec]] +level = "MUST" +quote = ''' +First, the packet +containing a ClientHello MUST be padded to a minimum size. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.4.toml new file mode 100644 index 0000000000..92c7513546 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.4.toml @@ -0,0 +1,46 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.4" + +# Header Protection Analysis +# +# [NAN] analyzes authenticated encryption algorithms that provide nonce +# privacy, referred to as "Hide Nonce" (HN) transforms. The general +# header protection construction in this document is one of those +# algorithms (HN1). Header protection is applied after the packet +# protection AEAD, sampling a set of bytes ("sample") from the AEAD +# output and encrypting the header field using a pseudorandom function +# (PRF) as follows: +# +# protected_field = field XOR PRF(hp_key, sample) +# +# The header protection variants in this document use a pseudorandom +# permutation (PRP) in place of a generic PRF. However, since all PRPs +# are also PRFs [IMC], these variants do not deviate from the HN1 +# construction. +# +# As "hp_key" is distinct from the packet protection key, it follows +# that header protection achieves AE2 security as defined in [NAN] and +# therefore guarantees privacy of "field", the protected packet header. +# Future header protection variants based on this construction MUST use +# a PRF to ensure equivalent security guarantees. +# +# Use of the same key and ciphertext sample more than once risks +# compromising header protection. Protecting two different headers +# with the same key and ciphertext sample reveals the exclusive OR of +# the protected fields. Assuming that the AEAD acts as a PRF, if L +# bits are sampled, the odds of two ciphertext samples being identical +# approach 2^(-L/2), that is, the birthday bound. For the algorithms +# described in this document, that probability is one in 2^64. +# +# To prevent an attacker from modifying packet headers, the header is +# transitively authenticated using packet protection; the entire packet +# header is part of the authenticated additional data. Protected +# fields that are falsified or modified can only be detected once the +# packet protection is removed. + +[[spec]] +level = "MUST" +quote = ''' +Future header protection variants based on this construction MUST use +a PRF to ensure equivalent security guarantees. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml new file mode 100644 index 0000000000..59a54b6650 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.5.toml @@ -0,0 +1,62 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.5" + +# Header Protection Timing Side Channels +# +# An attacker could guess values for packet numbers or Key Phase and +# have an endpoint confirm guesses through timing side channels. +# Similarly, guesses for the packet number length can be tried and +# exposed. If the recipient of a packet discards packets with +# duplicate packet numbers without attempting to remove packet +# protection, they could reveal through timing side channels that the +# packet number matches a received packet. For authentication to be +# free from side channels, the entire process of header protection +# removal, packet number recovery, and packet protection removal MUST +# be applied together without timing and other side channels. +# +# For the sending of packets, construction and protection of packet +# payloads and packet numbers MUST be free from side channels that +# would reveal the packet number or its encoded size. +# +# During a key update, the time taken to generate new keys could reveal +# through timing side channels that a key update has occurred. +# Alternatively, where an attacker injects packets, this side channel +# could reveal the value of the Key Phase on injected packets. After +# receiving a key update, an endpoint SHOULD generate and save the next +# set of receive packet protection keys, as described in Section 6.3. +# By generating new keys before a key update is received, receipt of +# packets will not create timing signals that leak the value of the Key +# Phase. +# +# This depends on not doing this key generation during packet +# processing, and it can require that endpoints maintain three sets of +# packet protection keys for receiving: for the previous key phase, for +# the current key phase, and for the next key phase. Endpoints can +# instead choose to defer generation of the next receive packet +# protection keys until they discard old keys so that only two sets of +# receive keys need to be retained at any point in time. + +[[spec]] +level = "MUST" +quote = ''' +For authentication to be +free from side channels, the entire process of header protection +removal, packet number recovery, and packet protection removal MUST +be applied together without timing and other side channels. +''' + +[[spec]] +level = "MUST" +quote = ''' +For the sending of packets, construction and protection of packet +payloads and packet numbers MUST be free from side channels that +would reveal the packet number or its encoded size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +After +receiving a key update, an endpoint SHOULD generate and save the next +set of receive packet protection keys, as described in Section 6.3. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.6.toml new file mode 100644 index 0000000000..4ed09e2b23 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9001/section-9.6.toml @@ -0,0 +1,40 @@ +target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.6" + +# Key Diversity +# +# In using TLS, the central key schedule of TLS is used. As a result +# of the TLS handshake messages being integrated into the calculation +# of secrets, the inclusion of the QUIC transport parameters extension +# ensures that the handshake and 1-RTT keys are not the same as those +# that might be produced by a server running TLS over TCP. To avoid +# the possibility of cross-protocol key synchronization, additional +# measures are provided to improve key separation. +# +# The QUIC packet protection keys and IVs are derived using a different +# label than the equivalent keys in TLS. +# +# To preserve this separation, a new version of QUIC SHOULD define new +# labels for key derivation for packet protection key and IV, plus the +# header protection keys. This version of QUIC uses the string "quic". +# Other versions can use a version-specific label in place of that +# string. +# +# The initial secrets use a key that is specific to the negotiated QUIC +# version. New QUIC versions SHOULD define a new salt value used in +# calculating initial secrets. + +[[spec]] +level = "SHOULD" +quote = ''' +To preserve this separation, a new version of QUIC SHOULD define new +labels for key derivation for packet protection key and IV, plus the +header protection keys. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +New QUIC versions SHOULD define a new salt value used in +calculating initial secrets. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.1.toml new file mode 100644 index 0000000000..8c45c60ab9 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.1.toml @@ -0,0 +1,56 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-5.1" + +# Generating RTT Samples +# +# An endpoint generates an RTT sample on receiving an ACK frame that +# meets the following two conditions: +# +# * the largest acknowledged packet number is newly acknowledged, and +# +# * at least one of the newly acknowledged packets was ack-eliciting. +# +# The RTT sample, latest_rtt, is generated as the time elapsed since +# the largest acknowledged packet was sent: +# +# latest_rtt = ack_time - send_time_of_largest_acked +# +# An RTT sample is generated using only the largest acknowledged packet +# in the received ACK frame. This is because a peer reports +# acknowledgment delays for only the largest acknowledged packet in an +# ACK frame. While the reported acknowledgment delay is not used by +# the RTT sample measurement, it is used to adjust the RTT sample in +# subsequent computations of smoothed_rtt and rttvar (Section 5.3). +# +# To avoid generating multiple RTT samples for a single packet, an ACK +# frame SHOULD NOT be used to update RTT estimates if it does not newly +# acknowledge the largest acknowledged packet. +# +# An RTT sample MUST NOT be generated on receiving an ACK frame that +# does not newly acknowledge at least one ack-eliciting packet. A peer +# usually does not send an ACK frame when only non-ack-eliciting +# packets are received. Therefore, an ACK frame that contains +# acknowledgments for only non-ack-eliciting packets could include an +# arbitrarily large ACK Delay value. Ignoring such ACK frames avoids +# complications in subsequent smoothed_rtt and rttvar computations. +# +# A sender might generate multiple RTT samples per RTT when multiple +# ACK frames are received within an RTT. As suggested in [RFC6298], +# doing so might result in inadequate history in smoothed_rtt and +# rttvar. Ensuring that RTT estimates retain sufficient history is an +# open research question. + +[[spec]] +level = "SHOULD" +quote = ''' +To avoid generating multiple RTT samples for a single packet, an ACK +frame SHOULD NOT be used to update RTT estimates if it does not newly +acknowledge the largest acknowledged packet. +''' + +[[spec]] +level = "MUST" +quote = ''' +An RTT sample MUST NOT be generated on receiving an ACK frame that +does not newly acknowledge at least one ack-eliciting packet. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml new file mode 100644 index 0000000000..321a880e67 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.2.toml @@ -0,0 +1,73 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-5.2" + +# Estimating min_rtt +# +# min_rtt is the sender's estimate of the minimum RTT observed for a +# given network path over a period of time. In this document, min_rtt +# is used by loss detection to reject implausibly small RTT samples. +# +# min_rtt MUST be set to the latest_rtt on the first RTT sample. +# min_rtt MUST be set to the lesser of min_rtt and latest_rtt +# (Section 5.1) on all other samples. +# +# An endpoint uses only locally observed times in computing the min_rtt +# and does not adjust for acknowledgment delays reported by the peer. +# Doing so allows the endpoint to set a lower bound for the +# smoothed_rtt based entirely on what it observes (see Section 5.3) and +# limits potential underestimation due to erroneously reported delays +# by the peer. +# +# The RTT for a network path may change over time. If a path's actual +# RTT decreases, the min_rtt will adapt immediately on the first low +# sample. If the path's actual RTT increases, however, the min_rtt +# will not adapt to it, allowing future RTT samples that are smaller +# than the new RTT to be included in smoothed_rtt. +# +# Endpoints SHOULD set the min_rtt to the newest RTT sample after +# persistent congestion is established. This avoids repeatedly +# declaring persistent congestion when the RTT increases. This also +# allows a connection to reset its estimate of min_rtt and smoothed_rtt +# after a disruptive network event; see Section 5.3. +# +# Endpoints MAY reestablish the min_rtt at other times in the +# connection, such as when traffic volume is low and an acknowledgment +# is received with a low acknowledgment delay. Implementations SHOULD +# NOT refresh the min_rtt value too often since the actual minimum RTT +# of the path is not frequently observable. + +[[spec]] +level = "MUST" +quote = ''' +min_rtt MUST be set to the latest_rtt on the first RTT sample. +''' + +[[spec]] +level = "MUST" +quote = ''' +min_rtt MUST be set to the lesser of min_rtt and latest_rtt +(Section 5.1) on all other samples. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD set the min_rtt to the newest RTT sample after +persistent congestion is established. +''' + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY reestablish the min_rtt at other times in the +connection, such as when traffic volume is low and an acknowledgment +is received with a low acknowledgment delay. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Implementations SHOULD +NOT refresh the min_rtt value too often since the actual minimum RTT +of the path is not frequently observable. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml new file mode 100644 index 0000000000..47df5e7cdd --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-5.3.toml @@ -0,0 +1,157 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-5.3" + +# Estimating smoothed_rtt and rttvar +# +# smoothed_rtt is an exponentially weighted moving average of an +# endpoint's RTT samples, and rttvar estimates the variation in the RTT +# samples using a mean variation. +# +# The calculation of smoothed_rtt uses RTT samples after adjusting them +# for acknowledgment delays. These delays are decoded from the ACK +# Delay field of ACK frames as described in Section 19.3 of +# [QUIC-TRANSPORT]. +# +# The peer might report acknowledgment delays that are larger than the +# peer's max_ack_delay during the handshake (Section 13.2.1 of +# [QUIC-TRANSPORT]). To account for this, the endpoint SHOULD ignore +# max_ack_delay until the handshake is confirmed, as defined in +# Section 4.1.2 of [QUIC-TLS]. When they occur, these large +# acknowledgment delays are likely to be non-repeating and limited to +# the handshake. The endpoint can therefore use them without limiting +# them to the max_ack_delay, avoiding unnecessary inflation of the RTT +# estimate. +# +# Note that a large acknowledgment delay can result in a substantially +# inflated smoothed_rtt if there is an error either in the peer's +# reporting of the acknowledgment delay or in the endpoint's min_rtt +# estimate. Therefore, prior to handshake confirmation, an endpoint +# MAY ignore RTT samples if adjusting the RTT sample for acknowledgment +# delay causes the sample to be less than the min_rtt. +# +# After the handshake is confirmed, any acknowledgment delays reported +# by the peer that are greater than the peer's max_ack_delay are +# attributed to unintentional but potentially repeating delays, such as +# scheduler latency at the peer or loss of previous acknowledgments. +# Excess delays could also be due to a noncompliant receiver. +# Therefore, these extra delays are considered effectively part of path +# delay and incorporated into the RTT estimate. +# +# Therefore, when adjusting an RTT sample using peer-reported +# acknowledgment delays, an endpoint: +# +# * MAY ignore the acknowledgment delay for Initial packets, since +# these acknowledgments are not delayed by the peer (Section 13.2.1 +# of [QUIC-TRANSPORT]); +# +# * SHOULD ignore the peer's max_ack_delay until the handshake is +# confirmed; +# +# * MUST use the lesser of the acknowledgment delay and the peer's +# max_ack_delay after the handshake is confirmed; and +# +# * MUST NOT subtract the acknowledgment delay from the RTT sample if +# the resulting value is smaller than the min_rtt. This limits the +# underestimation of the smoothed_rtt due to a misreporting peer. +# +# Additionally, an endpoint might postpone the processing of +# acknowledgments when the corresponding decryption keys are not +# immediately available. For example, a client might receive an +# acknowledgment for a 0-RTT packet that it cannot decrypt because +# 1-RTT packet protection keys are not yet available to it. In such +# cases, an endpoint SHOULD subtract such local delays from its RTT +# sample until the handshake is confirmed. +# +# Similar to [RFC6298], smoothed_rtt and rttvar are computed as +# follows. +# +# An endpoint initializes the RTT estimator during connection +# establishment and when the estimator is reset during connection +# migration; see Section 9.4 of [QUIC-TRANSPORT]. Before any RTT +# samples are available for a new path or when the estimator is reset, +# the estimator is initialized using the initial RTT; see +# Section 6.2.2. +# +# smoothed_rtt and rttvar are initialized as follows, where kInitialRtt +# contains the initial RTT value: +# +# smoothed_rtt = kInitialRtt +# rttvar = kInitialRtt / 2 +# +# RTT samples for the network path are recorded in latest_rtt; see +# Section 5.1. On the first RTT sample after initialization, the +# estimator is reset using that sample. This ensures that the +# estimator retains no history of past samples. Packets sent on other +# paths do not contribute RTT samples to the current path, as described +# in Section 9.4 of [QUIC-TRANSPORT]. +# +# On the first RTT sample after initialization, smoothed_rtt and rttvar +# are set as follows: +# +# smoothed_rtt = latest_rtt +# rttvar = latest_rtt / 2 +# +# On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: +# +# ack_delay = decoded acknowledgment delay from ACK frame +# if (handshake confirmed): +# ack_delay = min(ack_delay, max_ack_delay) +# adjusted_rtt = latest_rtt +# if (latest_rtt >= min_rtt + ack_delay): +# adjusted_rtt = latest_rtt - ack_delay +# smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt +# rttvar_sample = abs(smoothed_rtt - adjusted_rtt) +# rttvar = 3/4 * rttvar + 1/4 * rttvar_sample + +[[spec]] +level = "SHOULD" +quote = ''' +To account for this, the endpoint SHOULD ignore +max_ack_delay until the handshake is confirmed, as defined in +Section 4.1.2 of [QUIC-TLS]. +''' + +[[spec]] +level = "MAY" +quote = ''' +Therefore, prior to handshake confirmation, an endpoint +MAY ignore RTT samples if adjusting the RTT sample for acknowledgment +delay causes the sample to be less than the min_rtt. +''' + +[[spec]] +level = "MAY" +quote = ''' +* MAY ignore the acknowledgment delay for Initial packets, since +these acknowledgments are not delayed by the peer (Section 13.2.1 +of [QUIC-TRANSPORT]); +''' + +[[spec]] +level = "SHOULD" +quote = ''' +* SHOULD ignore the peer's max_ack_delay until the handshake is +confirmed; +''' + +[[spec]] +level = "MUST" +quote = ''' +* MUST use the lesser of the acknowledgment delay and the peer's +max_ack_delay after the handshake is confirmed; and +''' + +[[spec]] +level = "MUST" +quote = ''' +* MUST NOT subtract the acknowledgment delay from the RTT sample if +the resulting value is smaller than the min_rtt. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In such +cases, an endpoint SHOULD subtract such local delays from its RTT +sample until the handshake is confirmed. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.1.toml new file mode 100644 index 0000000000..cf1d07baaa --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.1.toml @@ -0,0 +1,35 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.1.1" + +# Packet Threshold +# +# The RECOMMENDED initial value for the packet reordering threshold +# (kPacketThreshold) is 3, based on best practices for TCP loss +# detection [RFC5681] [RFC6675]. In order to remain similar to TCP, +# implementations SHOULD NOT use a packet threshold less than 3; see +# [RFC5681]. +# +# Some networks may exhibit higher degrees of packet reordering, +# causing a sender to detect spurious losses. Additionally, packet +# reordering could be more common with QUIC than TCP because network +# elements that could observe and reorder TCP packets cannot do that +# for QUIC and also because QUIC packet numbers are encrypted. +# Algorithms that increase the reordering threshold after spuriously +# detecting losses, such as RACK [RFC8985], have proven to be useful in +# TCP and are expected to be at least as useful in QUIC. + +[[spec]] +level = "SHOULD" +quote = ''' +The RECOMMENDED initial value for the packet reordering threshold +(kPacketThreshold) is 3, based on best practices for TCP loss +detection [RFC5681] [RFC6675]. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In order to remain similar to TCP, +implementations SHOULD NOT use a packet threshold less than 3; see +[RFC5681]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml new file mode 100644 index 0000000000..370d5b6126 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.2.toml @@ -0,0 +1,86 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.1.2" + +# Time Threshold +# +# Once a later packet within the same packet number space has been +# acknowledged, an endpoint SHOULD declare an earlier packet lost if it +# was sent a threshold amount of time in the past. To avoid declaring +# packets as lost too early, this time threshold MUST be set to at +# least the local timer granularity, as indicated by the kGranularity +# constant. The time threshold is: +# +# max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity) +# +# If packets sent prior to the largest acknowledged packet cannot yet +# be declared lost, then a timer SHOULD be set for the remaining time. +# +# Using max(smoothed_rtt, latest_rtt) protects from the two following +# cases: +# +# * the latest RTT sample is lower than the smoothed RTT, perhaps due +# to reordering where the acknowledgment encountered a shorter path; +# +# * the latest RTT sample is higher than the smoothed RTT, perhaps due +# to a sustained increase in the actual RTT, but the smoothed RTT +# has not yet caught up. +# +# The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT +# multiplier, is 9/8. The RECOMMENDED value of the timer granularity +# (kGranularity) is 1 millisecond. +# +# | Note: TCP's RACK [RFC8985] specifies a slightly larger +# | threshold, equivalent to 5/4, for a similar purpose. +# | Experience with QUIC shows that 9/8 works well. +# +# Implementations MAY experiment with absolute thresholds, thresholds +# from previous connections, adaptive thresholds, or the including of +# RTT variation. Smaller thresholds reduce reordering resilience and +# increase spurious retransmissions, and larger thresholds increase +# loss detection delay. + +[[spec]] +level = "SHOULD" +quote = ''' +Once a later packet within the same packet number space has been +acknowledged, an endpoint SHOULD declare an earlier packet lost if it +was sent a threshold amount of time in the past. +''' + +[[spec]] +level = "MUST" +quote = ''' +To avoid declaring +packets as lost too early, this time threshold MUST be set to at +least the local timer granularity, as indicated by the kGranularity +constant. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If packets sent prior to the largest acknowledged packet cannot yet +be declared lost, then a timer SHOULD be set for the remaining time. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT +multiplier, is 9/8. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The RECOMMENDED value of the timer granularity +(kGranularity) is 1 millisecond. +''' + +[[spec]] +level = "MAY" +quote = ''' +Implementations MAY experiment with absolute thresholds, thresholds +from previous connections, adaptive thresholds, or the including of +RTT variation. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.toml new file mode 100644 index 0000000000..1899e2b27b --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.1.toml @@ -0,0 +1,41 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.1" + +# Acknowledgment-Based Detection +# +# Acknowledgment-based loss detection implements the spirit of TCP's +# Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward +# Acknowledgment [FACK], SACK loss recovery [RFC6675], and RACK-TLP +# [RFC8985]. This section provides an overview of how these algorithms +# are implemented in QUIC. +# +# A packet is declared lost if it meets all of the following +# conditions: +# +# * The packet is unacknowledged, in flight, and was sent prior to an +# acknowledged packet. +# +# * The packet was sent kPacketThreshold packets before an +# acknowledged packet (Section 6.1.1), or it was sent long enough in +# the past (Section 6.1.2). +# +# The acknowledgment indicates that a packet sent later was delivered, +# and the packet and time thresholds provide some tolerance for packet +# reordering. +# +# Spuriously declaring packets as lost leads to unnecessary +# retransmissions and may result in degraded performance due to the +# actions of the congestion controller upon detecting loss. +# Implementations can detect spurious retransmissions and increase the +# packet or time reordering threshold to reduce future spurious +# retransmissions and loss events. Implementations with adaptive time +# thresholds MAY choose to start with smaller initial reordering +# thresholds to minimize recovery latency. + +[[spec]] +level = "MAY" +quote = ''' +Implementations with adaptive time +thresholds MAY choose to start with smaller initial reordering +thresholds to minimize recovery latency. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml new file mode 100644 index 0000000000..c48496da86 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.1.toml @@ -0,0 +1,116 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.1" + +# Computing PTO +# +# When an ack-eliciting packet is transmitted, the sender schedules a +# timer for the PTO period as follows: +# +# PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay +# +# The PTO period is the amount of time that a sender ought to wait for +# an acknowledgment of a sent packet. This time period includes the +# estimated network RTT (smoothed_rtt), the variation in the estimate +# (4*rttvar), and max_ack_delay, to account for the maximum time by +# which a receiver might delay sending an acknowledgment. +# +# When the PTO is armed for Initial or Handshake packet number spaces, +# the max_ack_delay in the PTO period computation is set to 0, since +# the peer is expected to not delay these packets intentionally; see +# Section 13.2.1 of [QUIC-TRANSPORT]. +# +# The PTO period MUST be at least kGranularity to avoid the timer +# expiring immediately. +# +# When ack-eliciting packets in multiple packet number spaces are in +# flight, the timer MUST be set to the earlier value of the Initial and +# Handshake packet number spaces. +# +# An endpoint MUST NOT set its PTO timer for the Application Data +# packet number space until the handshake is confirmed. Doing so +# prevents the endpoint from retransmitting information in packets when +# either the peer does not yet have the keys to process them or the +# endpoint does not yet have the keys to process their acknowledgments. +# For example, this can happen when a client sends 0-RTT packets to the +# server; it does so without knowing whether the server will be able to +# decrypt them. Similarly, this can happen when a server sends 1-RTT +# packets before confirming that the client has verified the server's +# certificate and can therefore read these 1-RTT packets. +# +# A sender SHOULD restart its PTO timer every time an ack-eliciting +# packet is sent or acknowledged, or when Initial or Handshake keys are +# discarded (Section 4.9 of [QUIC-TLS]). This ensures the PTO is +# always set based on the latest estimate of the RTT and for the +# correct packet across packet number spaces. +# +# When a PTO timer expires, the PTO backoff MUST be increased, +# resulting in the PTO period being set to twice its current value. +# The PTO backoff factor is reset when an acknowledgment is received, +# except in the following case. A server might take longer to respond +# to packets during the handshake than otherwise. To protect such a +# server from repeated client probes, the PTO backoff is not reset at a +# client that is not yet certain that the server has finished +# validating the client's address. That is, a client does not reset +# the PTO backoff factor on receiving acknowledgments in Initial +# packets. +# +# This exponential reduction in the sender's rate is important because +# consecutive PTOs might be caused by loss of packets or +# acknowledgments due to severe congestion. Even when there are ack- +# eliciting packets in flight in multiple packet number spaces, the +# exponential increase in PTO occurs across all spaces to prevent +# excess load on the network. For example, a timeout in the Initial +# packet number space doubles the length of the timeout in the +# Handshake packet number space. +# +# The total length of time over which consecutive PTOs expire is +# limited by the idle timeout. +# +# The PTO timer MUST NOT be set if a timer is set for time threshold +# loss detection; see Section 6.1.2. A timer that is set for time +# threshold loss detection will expire earlier than the PTO timer in +# most cases and is less likely to spuriously retransmit data. + +[[spec]] +level = "MUST" +quote = ''' +The PTO period MUST be at least kGranularity to avoid the timer +expiring immediately. +''' + +[[spec]] +level = "MUST" +quote = ''' +When ack-eliciting packets in multiple packet number spaces are in +flight, the timer MUST be set to the earlier value of the Initial and +Handshake packet number spaces. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT set its PTO timer for the Application Data +packet number space until the handshake is confirmed. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD restart its PTO timer every time an ack-eliciting +packet is sent or acknowledged, or when Initial or Handshake keys are +discarded (Section 4.9 of [QUIC-TLS]). +''' + +[[spec]] +level = "MUST" +quote = ''' +When a PTO timer expires, the PTO backoff MUST be increased, +resulting in the PTO period being set to twice its current value. +''' + +[[spec]] +level = "MUST" +quote = ''' +The PTO timer MUST NOT be set if a timer is set for time threshold +loss detection; see Section 6.1.2. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml new file mode 100644 index 0000000000..41aa85aa24 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.1.toml @@ -0,0 +1,68 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.2.1" + +# Before Address Validation +# +# Until the server has validated the client's address on the path, the +# amount of data it can send is limited to three times the amount of +# data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. If +# no additional data can be sent, the server's PTO timer MUST NOT be +# armed until datagrams have been received from the client because +# packets sent on PTO count against the anti-amplification limit. +# +# When the server receives a datagram from the client, the +# amplification limit is increased and the server resets the PTO timer. +# If the PTO timer is then set to a time in the past, it is executed +# immediately. Doing so avoids sending new 1-RTT packets prior to +# packets critical to the completion of the handshake. In particular, +# this can happen when 0-RTT is accepted but the server fails to +# validate the client's address. +# +# Since the server could be blocked until more datagrams are received +# from the client, it is the client's responsibility to send packets to +# unblock the server until it is certain that the server has finished +# its address validation (see Section 8 of [QUIC-TRANSPORT]). That is, +# the client MUST set the PTO timer if the client has not received an +# acknowledgment for any of its Handshake packets and the handshake is +# not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no +# packets in flight. When the PTO fires, the client MUST send a +# Handshake packet if it has Handshake keys, otherwise it MUST send an +# Initial packet in a UDP datagram with a payload of at least 1200 +# bytes. + +[[spec]] +level = "MUST" +quote = ''' +If +no additional data can be sent, the server's PTO timer MUST NOT be +armed until datagrams have been received from the client because +packets sent on PTO count against the anti-amplification limit. +''' + +[[spec]] +level = "MUST" +quote = ''' +That is, +the client MUST set the PTO timer if the client has not received an +acknowledgment for any of its Handshake packets and the handshake is +not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no +packets in flight. +''' + +[[spec]] +level = "MUST" +quote = ''' +When the PTO fires, the client MUST send a +Handshake packet if it has Handshake keys, otherwise it MUST send an +Initial packet in a UDP datagram with a payload of at least 1200 +bytes. +''' + +[[spec]] +level = "MUST" +quote = ''' +When the PTO fires, the client MUST send a +Handshake packet if it has Handshake keys, otherwise it MUST send an +Initial packet in a UDP datagram with a payload of at least 1200 +bytes. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml new file mode 100644 index 0000000000..dadad9c713 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.2.toml @@ -0,0 +1,58 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.2" + +# Handshakes and New Paths +# +# Resumed connections over the same network MAY use the previous +# connection's final smoothed RTT value as the resumed connection's +# initial RTT. When no previous RTT is available, the initial RTT +# SHOULD be set to 333 milliseconds. This results in handshakes +# starting with a PTO of 1 second, as recommended for TCP's initial +# RTO; see Section 2 of [RFC6298]. +# +# A connection MAY use the delay between sending a PATH_CHALLENGE and +# receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in +# Appendix A.2) for a new path, but the delay SHOULD NOT be considered +# an RTT sample. +# +# When the Initial keys and Handshake keys are discarded (see +# Section 6.4), any Initial packets and Handshake packets can no longer +# be acknowledged, so they are removed from bytes in flight. When +# Initial or Handshake keys are discarded, the PTO and loss detection +# timers MUST be reset, because discarding keys indicates forward +# progress and the loss detection timer might have been set for a now- +# discarded packet number space. + +[[spec]] +level = "MAY" +quote = ''' +Resumed connections over the same network MAY use the previous +connection's final smoothed RTT value as the resumed connection's +initial RTT. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When no previous RTT is available, the initial RTT +SHOULD be set to 333 milliseconds. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A connection MAY use the delay between sending a PATH_CHALLENGE and +receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in +Appendix A.2) for a new path, but the delay SHOULD NOT be considered +an RTT sample. +''' + +[[spec]] +level = "MUST" +quote = ''' +When +Initial or Handshake keys are discarded, the PTO and loss detection +timers MUST be reset, because discarding keys indicates forward +progress and the loss detection timer might have been set for a now- +discarded packet number space. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.3.toml new file mode 100644 index 0000000000..3d01d9952a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.3.toml @@ -0,0 +1,37 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.3" + +# Speeding up Handshake Completion +# +# When a server receives an Initial packet containing duplicate CRYPTO +# data, it can assume the client did not receive all of the server's +# CRYPTO data sent in Initial packets, or the client's estimated RTT is +# too small. When a client receives Handshake or 1-RTT packets prior +# to obtaining Handshake keys, it may assume some or all of the +# server's Initial packets were lost. +# +# To speed up handshake completion under these conditions, an endpoint +# MAY, for a limited number of times per connection, send a packet +# containing unacknowledged CRYPTO data earlier than the PTO expiry, +# subject to the address validation limits in Section 8.1 of +# [QUIC-TRANSPORT]. Doing so at most once for each connection is +# adequate to quickly recover from a single packet loss. An endpoint +# that always retransmits packets in response to receiving packets that +# it cannot process risks creating an infinite exchange of packets. +# +# Endpoints can also use coalesced packets (see Section 12.2 of +# [QUIC-TRANSPORT]) to ensure that each datagram elicits at least one +# acknowledgment. For example, a client can coalesce an Initial packet +# containing PING and PADDING frames with a 0-RTT data packet, and a +# server can coalesce an Initial packet containing a PING frame with +# one or more packets in its first flight. + +[[spec]] +level = "MAY" +quote = ''' +To speed up handshake completion under these conditions, an endpoint +MAY, for a limited number of times per connection, send a packet +containing unacknowledged CRYPTO data earlier than the PTO expiry, +subject to the address validation limits in Section 8.1 of +[QUIC-TRANSPORT]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml new file mode 100644 index 0000000000..778f7fa903 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.4.toml @@ -0,0 +1,124 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.4" + +# Sending Probe Packets +# +# When a PTO timer expires, a sender MUST send at least one ack- +# eliciting packet in the packet number space as a probe. An endpoint +# MAY send up to two full-sized datagrams containing ack-eliciting +# packets to avoid an expensive consecutive PTO expiration due to a +# single lost datagram or to transmit data from multiple packet number +# spaces. All probe packets sent on a PTO MUST be ack-eliciting. +# +# In addition to sending data in the packet number space for which the +# timer expired, the sender SHOULD send ack-eliciting packets from +# other packet number spaces with in-flight data, coalescing packets if +# possible. This is particularly valuable when the server has both +# Initial and Handshake data in flight or when the client has both +# Handshake and Application Data in flight because the peer might only +# have receive keys for one of the two packet number spaces. +# +# If the sender wants to elicit a faster acknowledgment on PTO, it can +# skip a packet number to eliminate the acknowledgment delay. +# +# An endpoint SHOULD include new data in packets that are sent on PTO +# expiration. Previously sent data MAY be sent if no new data can be +# sent. Implementations MAY use alternative strategies for determining +# the content of probe packets, including sending new or retransmitted +# data based on the application's priorities. +# +# It is possible the sender has no new or previously sent data to send. +# As an example, consider the following sequence of events: new +# application data is sent in a STREAM frame, deemed lost, then +# retransmitted in a new packet, and then the original transmission is +# acknowledged. When there is no data to send, the sender SHOULD send +# a PING or other ack-eliciting frame in a single packet, rearming the +# PTO timer. +# +# Alternatively, instead of sending an ack-eliciting packet, the sender +# MAY mark any packets still in flight as lost. Doing so avoids +# sending an additional packet but increases the risk that loss is +# declared too aggressively, resulting in an unnecessary rate reduction +# by the congestion controller. +# +# Consecutive PTO periods increase exponentially, and as a result, +# connection recovery latency increases exponentially as packets +# continue to be dropped in the network. Sending two packets on PTO +# expiration increases resilience to packet drops, thus reducing the +# probability of consecutive PTO events. +# +# When the PTO timer expires multiple times and new data cannot be +# sent, implementations must choose between sending the same payload +# every time or sending different payloads. Sending the same payload +# may be simpler and ensures the highest priority frames arrive first. +# Sending different payloads each time reduces the chances of spurious +# retransmission. + +[[spec]] +level = "MUST" +quote = ''' +When a PTO timer expires, a sender MUST send at least one ack- +eliciting packet in the packet number space as a probe. +''' + +[[spec]] +level = "MAY" +quote = ''' +An endpoint +MAY send up to two full-sized datagrams containing ack-eliciting +packets to avoid an expensive consecutive PTO expiration due to a +single lost datagram or to transmit data from multiple packet number +spaces. +''' + +[[spec]] +level = "MUST" +quote = ''' +All probe packets sent on a PTO MUST be ack-eliciting. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +In addition to sending data in the packet number space for which the +timer expired, the sender SHOULD send ack-eliciting packets from +other packet number spaces with in-flight data, coalescing packets if +possible. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +An endpoint SHOULD include new data in packets that are sent on PTO +expiration. +''' + +[[spec]] +level = "MAY" +quote = ''' +Previously sent data MAY be sent if no new data can be +sent. +''' + +[[spec]] +level = "MAY" +quote = ''' +Implementations MAY use alternative strategies for determining +the content of probe packets, including sending new or retransmitted +data based on the application's priorities. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +When there is no data to send, the sender SHOULD send +a PING or other ack-eliciting frame in a single packet, rearming the +PTO timer. +''' + +[[spec]] +level = "MAY" +quote = ''' +Alternatively, instead of sending an ack-eliciting packet, the sender +MAY mark any packets still in flight as lost. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.toml new file mode 100644 index 0000000000..1fb819f2c1 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.2.toml @@ -0,0 +1,31 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2" + +# Probe Timeout +# +# A Probe Timeout (PTO) triggers the sending of one or two probe +# datagrams when ack-eliciting packets are not acknowledged within the +# expected period of time or the server may not have validated the +# client's address. A PTO enables a connection to recover from loss of +# tail packets or acknowledgments. +# +# As with loss detection, the PTO is per packet number space. That is, +# a PTO value is computed per packet number space. +# +# A PTO timer expiration event does not indicate packet loss and MUST +# NOT cause prior unacknowledged packets to be marked as lost. When an +# acknowledgment is received that newly acknowledges packets, loss +# detection proceeds as dictated by the packet and time threshold +# mechanisms; see Section 6.1. +# +# The PTO algorithm used in QUIC implements the reliability functions +# of Tail Loss Probe [RFC8985], RTO [RFC5681], and F-RTO algorithms for +# TCP [RFC5682]. The timeout computation is based on TCP's RTO period +# [RFC6298]. + +[[spec]] +level = "MUST" +quote = ''' +A PTO timer expiration event does not indicate packet loss and MUST +NOT cause prior unacknowledged packets to be marked as lost. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.3.toml new file mode 100644 index 0000000000..06e574f95d --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.3.toml @@ -0,0 +1,36 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.3" + +# Handling Retry Packets +# +# A Retry packet causes a client to send another Initial packet, +# effectively restarting the connection process. A Retry packet +# indicates that the Initial packet was received but not processed. A +# Retry packet cannot be treated as an acknowledgment because it does +# not indicate that a packet was processed or specify the packet +# number. +# +# Clients that receive a Retry packet reset congestion control and loss +# recovery state, including resetting any pending timers. Other +# connection state, in particular cryptographic handshake messages, is +# retained; see Section 17.2.5 of [QUIC-TRANSPORT]. +# +# The client MAY compute an RTT estimate to the server as the time +# period from when the first Initial packet was sent to when a Retry or +# a Version Negotiation packet is received. The client MAY use this +# value in place of its default for the initial RTT estimate. + +[[spec]] +level = "MAY" +quote = ''' +The client MAY compute an RTT estimate to the server as the time +period from when the first Initial packet was sent to when a Retry or +a Version Negotiation packet is received. +''' + +[[spec]] +level = "MAY" +quote = ''' +The client MAY use this +value in place of its default for the initial RTT estimate. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.4.toml new file mode 100644 index 0000000000..bf065a331f --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-6.4.toml @@ -0,0 +1,45 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.4" + +# Discarding Keys and Packet State +# +# When Initial and Handshake packet protection keys are discarded (see +# Section 4.9 of [QUIC-TLS]), all packets that were sent with those +# keys can no longer be acknowledged because their acknowledgments +# cannot be processed. The sender MUST discard all recovery state +# associated with those packets and MUST remove them from the count of +# bytes in flight. +# +# Endpoints stop sending and receiving Initial packets once they start +# exchanging Handshake packets; see Section 17.2.2.1 of +# [QUIC-TRANSPORT]. At this point, recovery state for all in-flight +# Initial packets is discarded. +# +# When 0-RTT is rejected, recovery state for all in-flight 0-RTT +# packets is discarded. +# +# If a server accepts 0-RTT, but does not buffer 0-RTT packets that +# arrive before Initial packets, early 0-RTT packets will be declared +# lost, but that is expected to be infrequent. +# +# It is expected that keys are discarded at some time after the packets +# encrypted with them are either acknowledged or declared lost. +# However, Initial and Handshake secrets are discarded as soon as +# Handshake and 1-RTT keys are proven to be available to both client +# and server; see Section 4.9.1 of [QUIC-TLS]. + +[[spec]] +level = "MUST" +quote = ''' +The sender MUST discard all recovery state +associated with those packets and MUST remove them from the count of +bytes in flight. +''' + +[[spec]] +level = "MUST" +quote = ''' +The sender MUST discard all recovery state +associated with those packets and MUST remove them from the count of +bytes in flight. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml new file mode 100644 index 0000000000..cf2e7431dc --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.2.toml @@ -0,0 +1,61 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.2" + +# Initial and Minimum Congestion Window +# +# QUIC begins every connection in slow start with the congestion window +# set to an initial value. Endpoints SHOULD use an initial congestion +# window of ten times the maximum datagram size (max_datagram_size), +# while limiting the window to the larger of 14,720 bytes or twice the +# maximum datagram size. This follows the analysis and recommendations +# in [RFC6928], increasing the byte limit to account for the smaller +# 8-byte overhead of UDP compared to the 20-byte overhead for TCP. +# +# If the maximum datagram size changes during the connection, the +# initial congestion window SHOULD be recalculated with the new size. +# If the maximum datagram size is decreased in order to complete the +# handshake, the congestion window SHOULD be set to the new initial +# congestion window. +# +# Prior to validating the client's address, the server can be further +# limited by the anti-amplification limit as specified in Section 8.1 +# of [QUIC-TRANSPORT]. Though the anti-amplification limit can prevent +# the congestion window from being fully utilized and therefore slow +# down the increase in congestion window, it does not directly affect +# the congestion window. +# +# The minimum congestion window is the smallest value the congestion +# window can attain in response to loss, an increase in the peer- +# reported ECN-CE count, or persistent congestion. The RECOMMENDED +# value is 2 * max_datagram_size. + +[[spec]] +level = "SHOULD" +quote = ''' +Endpoints SHOULD use an initial congestion +window of ten times the maximum datagram size (max_datagram_size), +while limiting the window to the larger of 14,720 bytes or twice the +maximum datagram size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If the maximum datagram size changes during the connection, the +initial congestion window SHOULD be recalculated with the new size. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +If the maximum datagram size is decreased in order to complete the +handshake, the congestion window SHOULD be set to the new initial +congestion window. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The RECOMMENDED +value is 2 * max_datagram_size. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.1.toml new file mode 100644 index 0000000000..6838d46b19 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.1.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.3.1" + +# Slow Start +# +# A NewReno sender is in slow start any time the congestion window is +# below the slow start threshold. A sender begins in slow start +# because the slow start threshold is initialized to an infinite value. +# +# While a sender is in slow start, the congestion window increases by +# the number of bytes acknowledged when each acknowledgment is +# processed. This results in exponential growth of the congestion +# window. +# +# The sender MUST exit slow start and enter a recovery period when a +# packet is lost or when the ECN-CE count reported by its peer +# increases. +# +# A sender reenters slow start any time the congestion window is less +# than the slow start threshold, which only occurs after persistent +# congestion is declared. + +[[spec]] +level = "MUST" +quote = ''' +The sender MUST exit slow start and enter a recovery period when a +packet is lost or when the ECN-CE count reported by its peer +increases. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml new file mode 100644 index 0000000000..01d4ef54a3 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.2.toml @@ -0,0 +1,57 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.3.2" + +# Recovery +# +# A NewReno sender enters a recovery period when it detects the loss of +# a packet or when the ECN-CE count reported by its peer increases. A +# sender that is already in a recovery period stays in it and does not +# reenter it. +# +# On entering a recovery period, a sender MUST set the slow start +# threshold to half the value of the congestion window when loss is +# detected. The congestion window MUST be set to the reduced value of +# the slow start threshold before exiting the recovery period. +# +# Implementations MAY reduce the congestion window immediately upon +# entering a recovery period or use other mechanisms, such as +# Proportional Rate Reduction [PRR], to reduce the congestion window +# more gradually. If the congestion window is reduced immediately, a +# single packet can be sent prior to reduction. This speeds up loss +# recovery if the data in the lost packet is retransmitted and is +# similar to TCP as described in Section 5 of [RFC6675]. +# +# The recovery period aims to limit congestion window reduction to once +# per round trip. Therefore, during a recovery period, the congestion +# window does not change in response to new losses or increases in the +# ECN-CE count. +# +# A recovery period ends and the sender enters congestion avoidance +# when a packet sent during the recovery period is acknowledged. This +# is slightly different from TCP's definition of recovery, which ends +# when the lost segment that started recovery is acknowledged +# [RFC5681]. + +[[spec]] +level = "MUST" +quote = ''' +On entering a recovery period, a sender MUST set the slow start +threshold to half the value of the congestion window when loss is +detected. +''' + +[[spec]] +level = "MUST" +quote = ''' +The congestion window MUST be set to the reduced value of +the slow start threshold before exiting the recovery period. +''' + +[[spec]] +level = "MAY" +quote = ''' +Implementations MAY reduce the congestion window immediately upon +entering a recovery period or use other mechanisms, such as +Proportional Rate Reduction [PRR], to reduce the congestion window +more gradually. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.3.toml new file mode 100644 index 0000000000..103bcb77f5 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.3.3.toml @@ -0,0 +1,26 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.3.3" + +# Congestion Avoidance +# +# A NewReno sender is in congestion avoidance any time the congestion +# window is at or above the slow start threshold and not in a recovery +# period. +# +# A sender in congestion avoidance uses an Additive Increase +# Multiplicative Decrease (AIMD) approach that MUST limit the increase +# to the congestion window to at most one maximum datagram size for +# each congestion window that is acknowledged. +# +# The sender exits congestion avoidance and enters a recovery period +# when a packet is lost or when the ECN-CE count reported by its peer +# increases. + +[[spec]] +level = "MUST" +quote = ''' +A sender in congestion avoidance uses an Additive Increase +Multiplicative Decrease (AIMD) approach that MUST limit the increase +to the congestion window to at most one maximum datagram size for +each congestion window that is acknowledged. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.4.toml new file mode 100644 index 0000000000..13e770a82a --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.4.toml @@ -0,0 +1,29 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.4" + +# Ignoring Loss of Undecryptable Packets +# +# During the handshake, some packet protection keys might not be +# available when a packet arrives, and the receiver can choose to drop +# the packet. In particular, Handshake and 0-RTT packets cannot be +# processed until the Initial packets arrive, and 1-RTT packets cannot +# be processed until the handshake completes. Endpoints MAY ignore the +# loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived +# before the peer had packet protection keys to process those packets. +# Endpoints MUST NOT ignore the loss of packets that were sent after +# the earliest acknowledged packet in a given packet number space. + +[[spec]] +level = "MAY" +quote = ''' +Endpoints MAY ignore the +loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived +before the peer had packet protection keys to process those packets. +''' + +[[spec]] +level = "MUST" +quote = ''' +Endpoints MUST NOT ignore the loss of packets that were sent after +the earliest acknowledged packet in a given packet number space. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.5.toml new file mode 100644 index 0000000000..dfef83298e --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.5.toml @@ -0,0 +1,27 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.5" + +# Probe Timeout +# +# Probe packets MUST NOT be blocked by the congestion controller. A +# sender MUST however count these packets as being additionally in +# flight, since these packets add network load without establishing +# packet loss. Note that sending probe packets might cause the +# sender's bytes in flight to exceed the congestion window until an +# acknowledgment is received that establishes loss or delivery of +# packets. + +[[spec]] +level = "MUST" +quote = ''' +Probe packets MUST NOT be blocked by the congestion controller. +''' + +[[spec]] +level = "MUST" +quote = ''' +A +sender MUST however count these packets as being additionally in +flight, since these packets add network load without establishing +packet loss. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.1.toml new file mode 100644 index 0000000000..3b70844e2c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.1.toml @@ -0,0 +1,45 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.6.1" + +# Duration +# +# The persistent congestion duration is computed as follows: +# +# (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) * +# kPersistentCongestionThreshold +# +# Unlike the PTO computation in Section 6.2, this duration includes the +# max_ack_delay irrespective of the packet number spaces in which +# losses are established. +# +# This duration allows a sender to send as many packets before +# establishing persistent congestion, including some in response to PTO +# expiration, as TCP does with Tail Loss Probes [RFC8985] and an RTO +# [RFC5681]. +# +# Larger values of kPersistentCongestionThreshold cause the sender to +# become less responsive to persistent congestion in the network, which +# can result in aggressive sending into a congested network. Too small +# a value can result in a sender declaring persistent congestion +# unnecessarily, resulting in reduced throughput for the sender. +# +# The RECOMMENDED value for kPersistentCongestionThreshold is 3, which +# results in behavior that is approximately equivalent to a TCP sender +# declaring an RTO after two TLPs. +# +# This design does not use consecutive PTO events to establish +# persistent congestion, since application patterns impact PTO +# expiration. For example, a sender that sends small amounts of data +# with silence periods between them restarts the PTO timer every time +# it sends, potentially preventing the PTO timer from expiring for a +# long period of time, even when no acknowledgments are being received. +# The use of a duration enables a sender to establish persistent +# congestion without depending on PTO expiration. + +[[spec]] +level = "SHOULD" +quote = ''' +The RECOMMENDED value for kPersistentCongestionThreshold is 3, which +results in behavior that is approximately equivalent to a TCP sender +declaring an RTO after two TLPs. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml new file mode 100644 index 0000000000..877e6a3903 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.6.2.toml @@ -0,0 +1,82 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.6.2" + +# Establishing Persistent Congestion +# +# A sender establishes persistent congestion after the receipt of an +# acknowledgment if two packets that are ack-eliciting are declared +# lost, and: +# +# * across all packet number spaces, none of the packets sent between +# the send times of these two packets are acknowledged; +# +# * the duration between the send times of these two packets exceeds +# the persistent congestion duration (Section 7.6.1); and +# +# * a prior RTT sample existed when these two packets were sent. +# +# These two packets MUST be ack-eliciting, since a receiver is required +# to acknowledge only ack-eliciting packets within its maximum +# acknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT]. +# +# The persistent congestion period SHOULD NOT start until there is at +# least one RTT sample. Before the first RTT sample, a sender arms its +# PTO timer based on the initial RTT (Section 6.2.2), which could be +# substantially larger than the actual RTT. Requiring a prior RTT +# sample prevents a sender from establishing persistent congestion with +# potentially too few probes. +# +# Since network congestion is not affected by packet number spaces, +# persistent congestion SHOULD consider packets sent across packet +# number spaces. A sender that does not have state for all packet +# number spaces or an implementation that cannot compare send times +# across packet number spaces MAY use state for just the packet number +# space that was acknowledged. This might result in erroneously +# declaring persistent congestion, but it will not lead to a failure to +# detect persistent congestion. +# +# When persistent congestion is declared, the sender's congestion +# window MUST be reduced to the minimum congestion window +# (kMinimumWindow), similar to a TCP sender's response on an RTO +# [RFC5681]. + +[[spec]] +level = "MUST" +quote = ''' +These two packets MUST be ack-eliciting, since a receiver is required +to acknowledge only ack-eliciting packets within its maximum +acknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT]. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +The persistent congestion period SHOULD NOT start until there is at +least one RTT sample. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Since network congestion is not affected by packet number spaces, +persistent congestion SHOULD consider packets sent across packet +number spaces. +''' + +[[spec]] +level = "MAY" +quote = ''' +A sender that does not have state for all packet +number spaces or an implementation that cannot compare send times +across packet number spaces MAY use state for just the packet number +space that was acknowledged. +''' + +[[spec]] +level = "MUST" +quote = ''' +When persistent congestion is declared, the sender's congestion +window MUST be reduced to the minimum congestion window +(kMinimumWindow), similar to a TCP sender's response on an RTO +[RFC5681]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml new file mode 100644 index 0000000000..27079d986c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.7.toml @@ -0,0 +1,84 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.7" + +# Pacing +# +# A sender SHOULD pace sending of all in-flight packets based on input +# from the congestion controller. +# +# Sending multiple packets into the network without any delay between +# them creates a packet burst that might cause short-term congestion +# and losses. Senders MUST either use pacing or limit such bursts. +# Senders SHOULD limit bursts to the initial congestion window; see +# Section 7.2. A sender with knowledge that the network path to the +# receiver can absorb larger bursts MAY use a higher limit. +# +# An implementation should take care to architect its congestion +# controller to work well with a pacer. For instance, a pacer might +# wrap the congestion controller and control the availability of the +# congestion window, or a pacer might pace out packets handed to it by +# the congestion controller. +# +# Timely delivery of ACK frames is important for efficient loss +# recovery. To avoid delaying their delivery to the peer, packets +# containing only ACK frames SHOULD therefore not be paced. +# +# Endpoints can implement pacing as they choose. A perfectly paced +# sender spreads packets exactly evenly over time. For a window-based +# congestion controller, such as the one in this document, that rate +# can be computed by averaging the congestion window over the RTT. +# Expressed as a rate in units of bytes per time, where +# congestion_window is in bytes: +# +# rate = N * congestion_window / smoothed_rtt +# +# Or expressed as an inter-packet interval in units of time: +# +# interval = ( smoothed_rtt * packet_size / congestion_window ) / N +# +# Using a value for "N" that is small, but at least 1 (for example, +# 1.25) ensures that variations in RTT do not result in +# underutilization of the congestion window. +# +# Practical considerations, such as packetization, scheduling delays, +# and computational efficiency, can cause a sender to deviate from this +# rate over time periods that are much shorter than an RTT. +# +# One possible implementation strategy for pacing uses a leaky bucket +# algorithm, where the capacity of the "bucket" is limited to the +# maximum burst size and the rate the "bucket" fills is determined by +# the above function. + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD pace sending of all in-flight packets based on input +from the congestion controller. +''' + +[[spec]] +level = "MUST" +quote = ''' +Senders MUST either use pacing or limit such bursts. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +Senders SHOULD limit bursts to the initial congestion window; see +Section 7.2. +''' + +[[spec]] +level = "MAY" +quote = ''' +A sender with knowledge that the network path to the +receiver can absorb larger bursts MAY use a higher limit. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +To avoid delaying their delivery to the peer, packets +containing only ACK frames SHOULD therefore not be paced. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml new file mode 100644 index 0000000000..8fb75eca10 --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.8.toml @@ -0,0 +1,41 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.8" + +# Underutilizing the Congestion Window +# +# When bytes in flight is smaller than the congestion window and +# sending is not pacing limited, the congestion window is +# underutilized. This can happen due to insufficient application data +# or flow control limits. When this occurs, the congestion window +# SHOULD NOT be increased in either slow start or congestion avoidance. +# +# A sender that paces packets (see Section 7.7) might delay sending +# packets and not fully utilize the congestion window due to this +# delay. A sender SHOULD NOT consider itself application limited if it +# would have fully utilized the congestion window without pacing delay. +# +# A sender MAY implement alternative mechanisms to update its +# congestion window after periods of underutilization, such as those +# proposed for TCP in [RFC7661]. + +[[spec]] +level = "SHOULD" +quote = ''' +When this occurs, the congestion window +SHOULD NOT be increased in either slow start or congestion avoidance. +''' + +[[spec]] +level = "SHOULD" +quote = ''' +A sender SHOULD NOT consider itself application limited if it +would have fully utilized the congestion window without pacing delay. +''' + +[[spec]] +level = "MAY" +quote = ''' +A sender MAY implement alternative mechanisms to update its +congestion window after periods of underutilization, such as those +proposed for TCP in [RFC7661]. +''' + diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml new file mode 100644 index 0000000000..d13dcca72c --- /dev/null +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc9002/section-7.toml @@ -0,0 +1,62 @@ +target = "https://www.rfc-editor.org/rfc/rfc9002#section-7" + +# Congestion Control +# +# This document specifies a sender-side congestion controller for QUIC +# similar to TCP NewReno [RFC6582]. +# +# The signals QUIC provides for congestion control are generic and are +# designed to support different sender-side algorithms. A sender can +# unilaterally choose a different algorithm to use, such as CUBIC +# [RFC8312]. +# +# If a sender uses a different controller than that specified in this +# document, the chosen controller MUST conform to the congestion +# control guidelines specified in Section 3.1 of [RFC8085]. +# +# Similar to TCP, packets containing only ACK frames do not count +# toward bytes in flight and are not congestion controlled. Unlike +# TCP, QUIC can detect the loss of these packets and MAY use that +# information to adjust the congestion controller or the rate of ACK- +# only packets being sent, but this document does not describe a +# mechanism for doing so. +# +# The congestion controller is per path, so packets sent on other paths +# do not alter the current path's congestion controller, as described +# in Section 9.4 of [QUIC-TRANSPORT]. +# +# The algorithm in this document specifies and uses the controller's +# congestion window in bytes. +# +# An endpoint MUST NOT send a packet if it would cause bytes_in_flight +# (see Appendix B.2) to be larger than the congestion window, unless +# the packet is sent on a PTO timer expiration (see Section 6.2) or +# when entering recovery (see Section 7.3.2). + +[[spec]] +level = "MUST" +quote = ''' +If a sender uses a different controller than that specified in this +document, the chosen controller MUST conform to the congestion +control guidelines specified in Section 3.1 of [RFC8085]. +''' + +[[spec]] +level = "MAY" +quote = ''' +Unlike +TCP, QUIC can detect the loss of these packets and MAY use that +information to adjust the congestion controller or the rate of ACK- +only packets being sent, but this document does not describe a +mechanism for doing so. +''' + +[[spec]] +level = "MUST" +quote = ''' +An endpoint MUST NOT send a packet if it would cause bytes_in_flight +(see Appendix B.2) to be larger than the congestion window, unless +the packet is sent on a PTO timer expiration (see Section 6.2) or +when entering recovery (see Section 7.3.2). +''' + diff --git a/specs/tools.ietf.org/id/draft-banks-quic-performance-00.txt b/.duvet/specifications/tools.ietf.org/id/draft-banks-quic-performance-00.txt similarity index 100% rename from specs/tools.ietf.org/id/draft-banks-quic-performance-00.txt rename to .duvet/specifications/tools.ietf.org/id/draft-banks-quic-performance-00.txt diff --git a/specs/tools.ietf.org/id/draft-cardwell-iccrg-bbr-congestion-control-02.txt b/.duvet/specifications/tools.ietf.org/id/draft-cardwell-iccrg-bbr-congestion-control-02.txt similarity index 100% rename from specs/tools.ietf.org/id/draft-cardwell-iccrg-bbr-congestion-control-02.txt rename to .duvet/specifications/tools.ietf.org/id/draft-cardwell-iccrg-bbr-congestion-control-02.txt diff --git a/specs/tools.ietf.org/id/draft-cheng-iccrg-delivery-rate-estimation-02.txt b/.duvet/specifications/tools.ietf.org/id/draft-cheng-iccrg-delivery-rate-estimation-02.txt similarity index 100% rename from specs/tools.ietf.org/id/draft-cheng-iccrg-delivery-rate-estimation-02.txt rename to .duvet/specifications/tools.ietf.org/id/draft-cheng-iccrg-delivery-rate-estimation-02.txt diff --git a/specs/tools.ietf.org/id/draft-eggert-tcpm-rfc8312bis-01.txt b/.duvet/specifications/tools.ietf.org/id/draft-eggert-tcpm-rfc8312bis-01.txt similarity index 100% rename from specs/tools.ietf.org/id/draft-eggert-tcpm-rfc8312bis-01.txt rename to .duvet/specifications/tools.ietf.org/id/draft-eggert-tcpm-rfc8312bis-01.txt diff --git a/specs/tools.ietf.org/id/draft-ietf-tcpm-hystartplusplus-04.txt b/.duvet/specifications/tools.ietf.org/id/draft-ietf-tcpm-hystartplusplus-04.txt similarity index 100% rename from specs/tools.ietf.org/id/draft-ietf-tcpm-hystartplusplus-04.txt rename to .duvet/specifications/tools.ietf.org/id/draft-ietf-tcpm-hystartplusplus-04.txt diff --git a/specs/tools.ietf.org/id/draft-marx-qlog-event-definitions-quic-h3-02.txt b/.duvet/specifications/tools.ietf.org/id/draft-marx-qlog-event-definitions-quic-h3-02.txt similarity index 100% rename from specs/tools.ietf.org/id/draft-marx-qlog-event-definitions-quic-h3-02.txt rename to .duvet/specifications/tools.ietf.org/id/draft-marx-qlog-event-definitions-quic-h3-02.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc1071.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc1071.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc1071.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc1071.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc1112.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc1112.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc1112.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc1112.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc1918.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc1918.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc1918.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc1918.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc2373.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc2373.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc2373.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc2373.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc2460.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc2460.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc2460.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc2460.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc2544.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc2544.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc2544.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc2544.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc3168.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc3168.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc3168.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc3168.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc3849.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc3849.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc3849.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc3849.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc3927.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc3927.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc3927.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc3927.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc4193.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc4193.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc4193.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc4193.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc4291.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc4291.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc4291.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc4291.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc4303.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc4303.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc4303.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc4303.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc5156.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc5156.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc5156.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc5156.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc5180.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc5180.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc5180.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc5180.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc5246.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc5246.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc5246.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc5246.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc5737.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc5737.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc5737.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc5737.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc6052.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc6052.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc6052.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc6052.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc6335.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc6335.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc6335.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc6335.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc6598.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc6598.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc6598.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc6598.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc6666.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc6666.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc6666.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc6666.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc6676.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc6676.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc6676.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc6676.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc6890.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc6890.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc6890.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc6890.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc7301.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc7301.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc7301.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc7301.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc7723.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc7723.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc7723.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc7723.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc791.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc791.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc791.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc791.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc8155.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc8155.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc8155.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc8155.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc8200.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc8200.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc8200.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc8200.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc8312.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc8312.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc8312.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc8312.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc8446.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc8446.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc8446.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc8446.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc8899.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc8899.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc8899.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc8899.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc9000.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc9000.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc9000.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc9000.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc9001.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc9001.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc9001.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc9001.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc9002.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc9002.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc9002.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc9002.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc919.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc919.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc919.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc919.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc9221.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc9221.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc9221.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc9221.txt diff --git a/specs/www.rfc-editor.org/rfc/rfc9308.txt b/.duvet/specifications/www.rfc-editor.org/rfc/rfc9308.txt similarity index 100% rename from specs/www.rfc-editor.org/rfc/rfc9308.txt rename to .duvet/specifications/www.rfc-editor.org/rfc/rfc9308.txt diff --git a/specs/todos/recovery/5.2.toml b/.duvet/todos/recovery/5.2.toml similarity index 100% rename from specs/todos/recovery/5.2.toml rename to .duvet/todos/recovery/5.2.toml diff --git a/specs/todos/recovery/5.3.toml b/.duvet/todos/recovery/5.3.toml similarity index 100% rename from specs/todos/recovery/5.3.toml rename to .duvet/todos/recovery/5.3.toml diff --git a/specs/todos/recovery/6.1.2.toml b/.duvet/todos/recovery/6.1.2.toml similarity index 100% rename from specs/todos/recovery/6.1.2.toml rename to .duvet/todos/recovery/6.1.2.toml diff --git a/specs/todos/recovery/6.1.toml b/.duvet/todos/recovery/6.1.toml similarity index 100% rename from specs/todos/recovery/6.1.toml rename to .duvet/todos/recovery/6.1.toml diff --git a/specs/todos/recovery/6.2.2.toml b/.duvet/todos/recovery/6.2.2.toml similarity index 100% rename from specs/todos/recovery/6.2.2.toml rename to .duvet/todos/recovery/6.2.2.toml diff --git a/specs/todos/recovery/6.2.3.toml b/.duvet/todos/recovery/6.2.3.toml similarity index 100% rename from specs/todos/recovery/6.2.3.toml rename to .duvet/todos/recovery/6.2.3.toml diff --git a/specs/todos/recovery/6.2.4.toml b/.duvet/todos/recovery/6.2.4.toml similarity index 100% rename from specs/todos/recovery/6.2.4.toml rename to .duvet/todos/recovery/6.2.4.toml diff --git a/specs/todos/recovery/7.4.toml b/.duvet/todos/recovery/7.4.toml similarity index 100% rename from specs/todos/recovery/7.4.toml rename to .duvet/todos/recovery/7.4.toml diff --git a/specs/todos/recovery/7.7.toml b/.duvet/todos/recovery/7.7.toml similarity index 100% rename from specs/todos/recovery/7.7.toml rename to .duvet/todos/recovery/7.7.toml diff --git a/specs/todos/recovery/7.8.toml b/.duvet/todos/recovery/7.8.toml similarity index 100% rename from specs/todos/recovery/7.8.toml rename to .duvet/todos/recovery/7.8.toml diff --git a/specs/todos/recovery/7.toml b/.duvet/todos/recovery/7.toml similarity index 100% rename from specs/todos/recovery/7.toml rename to .duvet/todos/recovery/7.toml diff --git a/specs/todos/rfc8899/3.toml b/.duvet/todos/rfc8899/3.toml similarity index 100% rename from specs/todos/rfc8899/3.toml rename to .duvet/todos/rfc8899/3.toml diff --git a/specs/todos/rfc8899/4.3.toml b/.duvet/todos/rfc8899/4.3.toml similarity index 100% rename from specs/todos/rfc8899/4.3.toml rename to .duvet/todos/rfc8899/4.3.toml diff --git a/specs/todos/rfc8899/4.6.1.toml b/.duvet/todos/rfc8899/4.6.1.toml similarity index 100% rename from specs/todos/rfc8899/4.6.1.toml rename to .duvet/todos/rfc8899/4.6.1.toml diff --git a/specs/todos/rfc8899/4.6.2.toml b/.duvet/todos/rfc8899/4.6.2.toml similarity index 100% rename from specs/todos/rfc8899/4.6.2.toml rename to .duvet/todos/rfc8899/4.6.2.toml diff --git a/specs/todos/rfc8899/8.toml b/.duvet/todos/rfc8899/8.toml similarity index 100% rename from specs/todos/rfc8899/8.toml rename to .duvet/todos/rfc8899/8.toml diff --git a/specs/todos/tls/4.1.4.toml b/.duvet/todos/tls/4.1.4.toml similarity index 100% rename from specs/todos/tls/4.1.4.toml rename to .duvet/todos/tls/4.1.4.toml diff --git a/specs/todos/tls/4.6.1.toml b/.duvet/todos/tls/4.6.1.toml similarity index 100% rename from specs/todos/tls/4.6.1.toml rename to .duvet/todos/tls/4.6.1.toml diff --git a/specs/todos/tls/4.6.2.toml b/.duvet/todos/tls/4.6.2.toml similarity index 100% rename from specs/todos/tls/4.6.2.toml rename to .duvet/todos/tls/4.6.2.toml diff --git a/specs/todos/tls/4.9.3.toml b/.duvet/todos/tls/4.9.3.toml similarity index 100% rename from specs/todos/tls/4.9.3.toml rename to .duvet/todos/tls/4.9.3.toml diff --git a/specs/todos/tls/5.3.toml b/.duvet/todos/tls/5.3.toml similarity index 100% rename from specs/todos/tls/5.3.toml rename to .duvet/todos/tls/5.3.toml diff --git a/specs/todos/tls/5.5.toml b/.duvet/todos/tls/5.5.toml similarity index 100% rename from specs/todos/tls/5.5.toml rename to .duvet/todos/tls/5.5.toml diff --git a/specs/todos/tls/6.1.toml b/.duvet/todos/tls/6.1.toml similarity index 100% rename from specs/todos/tls/6.1.toml rename to .duvet/todos/tls/6.1.toml diff --git a/specs/todos/tls/6.2.toml b/.duvet/todos/tls/6.2.toml similarity index 100% rename from specs/todos/tls/6.2.toml rename to .duvet/todos/tls/6.2.toml diff --git a/specs/todos/tls/6.3.toml b/.duvet/todos/tls/6.3.toml similarity index 100% rename from specs/todos/tls/6.3.toml rename to .duvet/todos/tls/6.3.toml diff --git a/specs/todos/tls/6.5.toml b/.duvet/todos/tls/6.5.toml similarity index 100% rename from specs/todos/tls/6.5.toml rename to .duvet/todos/tls/6.5.toml diff --git a/specs/todos/tls/6.6.toml b/.duvet/todos/tls/6.6.toml similarity index 100% rename from specs/todos/tls/6.6.toml rename to .duvet/todos/tls/6.6.toml diff --git a/specs/todos/tls/6.toml b/.duvet/todos/tls/6.toml similarity index 100% rename from specs/todos/tls/6.toml rename to .duvet/todos/tls/6.toml diff --git a/specs/todos/tls/7.toml b/.duvet/todos/tls/7.toml similarity index 100% rename from specs/todos/tls/7.toml rename to .duvet/todos/tls/7.toml diff --git a/specs/todos/tls/8.1.toml b/.duvet/todos/tls/8.1.toml similarity index 100% rename from specs/todos/tls/8.1.toml rename to .duvet/todos/tls/8.1.toml diff --git a/specs/todos/tls/8.3.toml b/.duvet/todos/tls/8.3.toml similarity index 100% rename from specs/todos/tls/8.3.toml rename to .duvet/todos/tls/8.3.toml diff --git a/specs/todos/tls/9.2.toml b/.duvet/todos/tls/9.2.toml similarity index 100% rename from specs/todos/tls/9.2.toml rename to .duvet/todos/tls/9.2.toml diff --git a/specs/todos/tls/9.5.toml b/.duvet/todos/tls/9.5.toml similarity index 100% rename from specs/todos/tls/9.5.toml rename to .duvet/todos/tls/9.5.toml diff --git a/specs/todos/transport/10.3.toml b/.duvet/todos/transport/10.3.toml similarity index 100% rename from specs/todos/transport/10.3.toml rename to .duvet/todos/transport/10.3.toml diff --git a/specs/todos/transport/14.2.1.toml b/.duvet/todos/transport/14.2.1.toml similarity index 100% rename from specs/todos/transport/14.2.1.toml rename to .duvet/todos/transport/14.2.1.toml diff --git a/specs/todos/transport/17.2.toml b/.duvet/todos/transport/17.2.toml similarity index 100% rename from specs/todos/transport/17.2.toml rename to .duvet/todos/transport/17.2.toml diff --git a/specs/todos/transport/17.4.toml b/.duvet/todos/transport/17.4.toml similarity index 100% rename from specs/todos/transport/17.4.toml rename to .duvet/todos/transport/17.4.toml diff --git a/specs/todos/transport/19.7.toml b/.duvet/todos/transport/19.7.toml similarity index 100% rename from specs/todos/transport/19.7.toml rename to .duvet/todos/transport/19.7.toml diff --git a/specs/todos/transport/2.3.toml b/.duvet/todos/transport/2.3.toml similarity index 100% rename from specs/todos/transport/2.3.toml rename to .duvet/todos/transport/2.3.toml diff --git a/specs/todos/transport/5.1.2.toml b/.duvet/todos/transport/5.1.2.toml similarity index 100% rename from specs/todos/transport/5.1.2.toml rename to .duvet/todos/transport/5.1.2.toml diff --git a/specs/todos/transport/6.toml b/.duvet/todos/transport/6.toml similarity index 100% rename from specs/todos/transport/6.toml rename to .duvet/todos/transport/6.toml diff --git a/specs/todos/transport/7.2.toml b/.duvet/todos/transport/7.2.toml similarity index 100% rename from specs/todos/transport/7.2.toml rename to .duvet/todos/transport/7.2.toml diff --git a/specs/todos/transport/7.4.1.toml b/.duvet/todos/transport/7.4.1.toml similarity index 100% rename from specs/todos/transport/7.4.1.toml rename to .duvet/todos/transport/7.4.1.toml diff --git a/specs/todos/transport/8.1.toml b/.duvet/todos/transport/8.1.toml similarity index 100% rename from specs/todos/transport/8.1.toml rename to .duvet/todos/transport/8.1.toml diff --git a/specs/todos/transport/8.2.toml b/.duvet/todos/transport/8.2.toml similarity index 100% rename from specs/todos/transport/8.2.toml rename to .duvet/todos/transport/8.2.toml diff --git a/scripts/compliance b/scripts/compliance index 288e72111d..78f82e02bf 100755 --- a/scripts/compliance +++ b/scripts/compliance @@ -10,16 +10,6 @@ if ! command -v duvet &> /dev/null; then cargo install duvet fi -duvet \ - report \ - --spec-pattern 'specs/**/*.toml' \ - --source-pattern 'quic/**/*.rs' \ - --workspace \ - --exclude duvet \ - --require-tests false \ - --blob-link "https://github.com/aws/s2n-quic/blob/$BLOB" \ - --issue-link 'https://github.com/aws/s2n-quic/issues' \ - --no-cargo \ - --html target/compliance/report.html +duvet report echo "compliance report available in 'target/compliance/report.html'" diff --git a/specs/www.rfc-editor.org/rfc/rfc768.txt b/specs/www.rfc-editor.org/rfc/rfc768.txt deleted file mode 100644 index cbd850e061..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc768.txt +++ /dev/null @@ -1,174 +0,0 @@ - - -RFC 768 J. Postel - ISI - 28 August 1980 - - - - User Datagram Protocol - ---------------------- - -Introduction ------------- - -This User Datagram Protocol (UDP) is defined to make available a -datagram mode of packet-switched computer communication in the -environment of an interconnected set of computer networks. This -protocol assumes that the Internet Protocol (IP) [1] is used as the -underlying protocol. - -This protocol provides a procedure for application programs to send -messages to other programs with a minimum of protocol mechanism. The -protocol is transaction oriented, and delivery and duplicate protection -are not guaranteed. Applications requiring ordered reliable delivery of -streams of data should use the Transmission Control Protocol (TCP) [2]. - -Format ------- - - - 0 7 8 15 16 23 24 31 - +--------+--------+--------+--------+ - | Source | Destination | - | Port | Port | - +--------+--------+--------+--------+ - | | | - | Length | Checksum | - +--------+--------+--------+--------+ - | - | data octets ... - +---------------- ... - - User Datagram Header Format - -Fields ------- - -Source Port is an optional field, when meaningful, it indicates the port -of the sending process, and may be assumed to be the port to which a -reply should be addressed in the absence of any other information. If -not used, a value of zero is inserted. - - - - - -Postel [page 1] - - - 28 Aug 1980 -User Datagram Protocol RFC 768 -Fields - - - -Destination Port has a meaning within the context of a particular -internet destination address. - -Length is the length in octets of this user datagram including this -header and the data. (This means the minimum value of the length is -eight.) - -Checksum is the 16-bit one's complement of the one's complement sum of a -pseudo header of information from the IP header, the UDP header, and the -data, padded with zero octets at the end (if necessary) to make a -multiple of two octets. - -The pseudo header conceptually prefixed to the UDP header contains the -source address, the destination address, the protocol, and the UDP -length. This information gives protection against misrouted datagrams. -This checksum procedure is the same as is used in TCP. - - 0 7 8 15 16 23 24 31 - +--------+--------+--------+--------+ - | source address | - +--------+--------+--------+--------+ - | destination address | - +--------+--------+--------+--------+ - | zero |protocol| UDP length | - +--------+--------+--------+--------+ - -If the computed checksum is zero, it is transmitted as all ones (the -equivalent in one's complement arithmetic). An all zero transmitted -checksum value means that the transmitter generated no checksum (for -debugging or for higher level protocols that don't care). - -User Interface --------------- - -A user interface should allow - - the creation of new receive ports, - - receive operations on the receive ports that return the data octets - and an indication of source port and source address, - - and an operation that allows a datagram to be sent, specifying the - data, source and destination ports and addresses to be sent. - - - - - - -[page 2] Postel - - -28 Aug 1980 -RFC 768 User Datagram Protocol - IP Interface - - - -IP Interface -------------- - -The UDP module must be able to determine the source and destination -internet addresses and the protocol field from the internet header. One -possible UDP/IP interface would return the whole internet datagram -including all of the internet header in response to a receive operation. -Such an interface would also allow the UDP to pass a full internet -datagram complete with header to the IP to send. The IP would verify -certain fields for consistency and compute the internet header checksum. - -Protocol Application --------------------- - -The major uses of this protocol is the Internet Name Server [3], and the -Trivial File Transfer [4]. - -Protocol Number ---------------- - -This is protocol 17 (21 octal) when used in the Internet Protocol. -Other protocol numbers are listed in [5]. - -References ----------- - -[1] Postel, J., "Internet Protocol," RFC 760, USC/Information - Sciences Institute, January 1980. - -[2] Postel, J., "Transmission Control Protocol," RFC 761, - USC/Information Sciences Institute, January 1980. - -[3] Postel, J., "Internet Name Server," USC/Information Sciences - Institute, IEN 116, August 1979. - -[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of - Technology, IEN 133, January 1980. - -[5] Postel, J., "Assigned Numbers," USC/Information Sciences - Institute, RFC 762, January 1980. - - - - - - - - - -Postel [page 3] - \ No newline at end of file diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/4.2.toml b/specs/www.rfc-editor.org/rfc/rfc8312/4.2.toml deleted file mode 100644 index 1a3026a05b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/4.2.toml +++ /dev/null @@ -1,43 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.2" - -# 4.2. TCP-Friendly Region -# -# Standard TCP performs well in certain types of networks, for example, -# under short RTT and small bandwidth (or small BDP) networks. In -# these networks, we use the TCP-friendly region to ensure that CUBIC -# achieves at least the same throughput as Standard TCP. -# -# The TCP-friendly region is designed according to the analysis -# described in [FHP00]. The analysis studies the performance of an -# Additive Increase and Multiplicative Decrease (AIMD) algorithm with -# an additive factor of alpha_aimd (segments per RTT) and a -# multiplicative factor of beta_aimd, denoted by AIMD(alpha_aimd, -# beta_aimd). Specifically, the average congestion window size of -# AIMD(alpha_aimd, beta_aimd) can be calculated using Eq. 3. The -# analysis shows that AIMD(alpha_aimd, beta_aimd) with -# alpha_aimd=3*(1-beta_aimd)/(1+beta_aimd) achieves the same average -# window size as Standard TCP that uses AIMD(1, 0.5). -# -# AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / -# (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) -# -# Based on the above analysis, CUBIC uses Eq. 4 to estimate the window -# size W_est of AIMD(alpha_aimd, beta_aimd) with -# alpha_aimd=3*(1-beta_cubic)/(1+beta_cubic) and beta_aimd=beta_cubic, -# which achieves the same average window size as Standard TCP. When -# receiving an ACK in congestion avoidance (cwnd could be greater than -# -# or less than W_max), CUBIC checks whether W_cubic(t) is less than -# W_est(t). If so, CUBIC is in the TCP-friendly region and cwnd SHOULD -# be set to W_est(t) at each reception of an ACK. -# -# W_est(t) = W_max*beta_cubic + -# [3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT) (Eq. 4) - -[[spec]] -level = "SHOULD" -quote = ''' -If so, CUBIC is in the TCP-friendly region and cwnd SHOULD -be set to W_est(t) at each reception of an ACK. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/4.3.toml b/specs/www.rfc-editor.org/rfc/rfc8312/4.3.toml deleted file mode 100644 index c1e696a4b2..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/4.3.toml +++ /dev/null @@ -1,18 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.3" - -# 4.3. Concave Region -# -# When receiving an ACK in congestion avoidance, if CUBIC is not in the -# TCP-friendly region and cwnd is less than W_max, then CUBIC is in the -# concave region. In this region, cwnd MUST be incremented by -# (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where -# W_cubic(t+RTT) is calculated using Eq. 1. - -[[spec]] -level = "MUST" -quote = ''' -In this region, cwnd MUST be incremented by -(W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where -W_cubic(t+RTT) is calculated using Eq. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/4.4.toml b/specs/www.rfc-editor.org/rfc/rfc8312/4.4.toml deleted file mode 100644 index f983ae4959..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/4.4.toml +++ /dev/null @@ -1,28 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.4" - -# 4.4. Convex Region -# -# When receiving an ACK in congestion avoidance, if CUBIC is not in the -# TCP-friendly region and cwnd is larger than or equal to W_max, then -# CUBIC is in the convex region. The convex region indicates that the -# network conditions might have been perturbed since the last -# congestion event, possibly implying more available bandwidth after -# some flow departures. Since the Internet is highly asynchronous, -# some amount of perturbation is always possible without causing a -# major change in available bandwidth. In this region, CUBIC is being -# very careful by very slowly increasing its window size. The convex -# profile ensures that the window increases very slowly at the -# beginning and gradually increases its increase rate. We also call -# this region the "maximum probing phase" since CUBIC is searching for -# a new W_max. In this region, cwnd MUST be incremented by -# (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where -# W_cubic(t+RTT) is calculated using Eq. 1. - -[[spec]] -level = "MUST" -quote = ''' -In this region, cwnd MUST be incremented by -(W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where -W_cubic(t+RTT) is calculated using Eq. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/4.5.toml b/specs/www.rfc-editor.org/rfc/rfc8312/4.5.toml deleted file mode 100644 index 139b9f4308..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/4.5.toml +++ /dev/null @@ -1,27 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.5" - -# 4.5. Multiplicative Decrease -# -# When a packet loss is detected by duplicate ACKs or a network -# congestion is detected by ECN-Echo ACKs, CUBIC updates its W_max, -# cwnd, and ssthresh as follows. Parameter beta_cubic SHOULD be set to -# 0.7. -# -# W_max = cwnd; // save window size before reduction -# ssthresh = cwnd * beta_cubic; // new slow-start threshold -# ssthresh = max(ssthresh, 2); // threshold is at least 2 MSS -# cwnd = cwnd * beta_cubic; // window reduction -# -# A side effect of setting beta_cubic to a value bigger than 0.5 is -# slower convergence. We believe that while a more adaptive setting of -# beta_cubic could result in faster convergence, it will make the -# analysis of CUBIC much harder. This adaptive adjustment of -# beta_cubic is an item for the next version of CUBIC. - -[[spec]] -level = "SHOULD" -quote = ''' -Parameter beta_cubic SHOULD be set to -0.7. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/4.6.toml b/specs/www.rfc-editor.org/rfc/rfc8312/4.6.toml deleted file mode 100644 index 77932ef8b7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/4.6.toml +++ /dev/null @@ -1,54 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.6" - -# 4.6. Fast Convergence -# -# To improve the convergence speed of CUBIC, we add a heuristic in -# CUBIC. When a new flow joins the network, existing flows in the -# network need to give up some of their bandwidth to allow the new flow -# some room for growth if the existing flows have been using all the -# bandwidth of the network. To speed up this bandwidth release by -# existing flows, the following mechanism called "fast convergence" -# SHOULD be implemented. -# -# With fast convergence, when a congestion event occurs, before the -# window reduction of the congestion window, a flow remembers the last -# value of W_max before it updates W_max for the current congestion -# event. Let us call the last value of W_max to be W_last_max. -# -# if (W_max < W_last_max){ // should we make room for others -# W_last_max = W_max; // remember the last W_max -# W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max -# } else { -# W_last_max = W_max // remember the last W_max -# } -# -# At a congestion event, if the current value of W_max is less than -# W_last_max, this indicates that the saturation point experienced by -# this flow is getting reduced because of the change in available -# bandwidth. Then we allow this flow to release more bandwidth by -# reducing W_max further. This action effectively lengthens the time -# for this flow to increase its congestion window because the reduced -# W_max forces the flow to have the plateau earlier. This allows more -# time for the new flow to catch up to its congestion window size. -# -# The fast convergence is designed for network environments with -# multiple CUBIC flows. In network environments with only a single -# CUBIC flow and without any other traffic, the fast convergence SHOULD -# be disabled. - -[[spec]] -level = "SHOULD" -quote = ''' -To speed up this bandwidth release by -existing flows, the following mechanism called "fast convergence" -SHOULD be implemented. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In network environments with only a single -CUBIC flow and without any other traffic, the fast convergence SHOULD -be disabled. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/4.8.toml b/specs/www.rfc-editor.org/rfc/rfc8312/4.8.toml deleted file mode 100644 index ccd0553f5e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/4.8.toml +++ /dev/null @@ -1,34 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-4.8" - -# 4.8. Slow Start -# -# CUBIC MUST employ a slow-start algorithm, when the cwnd is no more -# than ssthresh. Among the slow-start algorithms, CUBIC MAY choose the -# standard TCP slow start [RFC5681] in general networks, or the limited -# slow start [RFC3742] or hybrid slow start [HR08] for fast and long- -# distance networks. -# -# In the case when CUBIC runs the hybrid slow start [HR08], it may exit -# the first slow start without incurring any packet loss and thus W_max -# is undefined. In this special case, CUBIC switches to congestion -# avoidance and increases its congestion window size using Eq. 1, where -# t is the elapsed time since the beginning of the current congestion -# avoidance, K is set to 0, and W_max is set to the congestion window -# size at the beginning of the current congestion avoidance. - -[[spec]] -level = "MUST" -quote = ''' -CUBIC MUST employ a slow-start algorithm, when the cwnd is no more -than ssthresh. -''' - -[[spec]] -level = "MAY" -quote = ''' -Among the slow-start algorithms, CUBIC MAY choose the -standard TCP slow start [RFC5681] in general networks, or the limited -slow start [RFC3742] or hybrid slow start [HR08] for fast and long- -distance networks. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/5.1.toml b/specs/www.rfc-editor.org/rfc/rfc8312/5.1.toml deleted file mode 100644 index 280447f9ad..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/5.1.toml +++ /dev/null @@ -1,90 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-5.1" - -# 5.1. Fairness to Standard TCP -# -# In environments where Standard TCP is able to make reasonable use of -# the available bandwidth, CUBIC does not significantly change this -# state. -# -# Standard TCP performs well in the following two types of networks: -# -# 1. networks with a small bandwidth-delay product (BDP) -# -# 2. networks with a short RTTs, but not necessarily a small BDP -# -# CUBIC is designed to behave very similarly to Standard TCP in the -# above two types of networks. The following two tables show the -# average window sizes of Standard TCP, HSTCP, and CUBIC. The average -# window sizes of Standard TCP and HSTCP are from [RFC3649]. The -# average window size of CUBIC is calculated using Eq. 6 and the CUBIC -# TCP-friendly region for three different values of C. -# -# +--------+----------+-----------+------------+-----------+----------+ -# | Loss | Average | Average | CUBIC | CUBIC | CUBIC | -# | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | -# +--------+----------+-----------+------------+-----------+----------+ -# | 10^-2 | 12 | 12 | 12 | 12 | 12 | -# | 10^-3 | 38 | 38 | 38 | 38 | 59 | -# | 10^-4 | 120 | 263 | 120 | 187 | 333 | -# | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | -# | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | -# | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | -# | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | -# +--------+----------+-----------+------------+-----------+----------+ -# -# Table 1 -# -# Table 1 describes the response function of Standard TCP, HSTCP, and -# CUBIC in networks with RTT = 0.1 seconds. The average window size is -# in MSS-sized segments. -# -# +--------+-----------+-----------+------------+-----------+---------+ -# | Loss | Average | Average | CUBIC | CUBIC | CUBIC | -# | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | -# +--------+-----------+-----------+------------+-----------+---------+ -# | 10^-2 | 12 | 12 | 12 | 12 | 12 | -# | 10^-3 | 38 | 38 | 38 | 38 | 38 | -# | 10^-4 | 120 | 263 | 120 | 120 | 120 | -# | 10^-5 | 379 | 1795 | 379 | 379 | 379 | -# | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | -# | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | -# | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | -# +--------+-----------+-----------+------------+-----------+---------+ -# -# Table 2 -# -# Table 2 describes the response function of Standard TCP, HSTCP, and -# CUBIC in networks with RTT = 0.01 seconds. The average window size -# is in MSS-sized segments. -# -# Both tables show that CUBIC with any of these three C values is more -# friendly to TCP than HSTCP, especially in networks with a short RTT -# where TCP performs reasonably well. For example, in a network with -# RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 -# packets. If the packet size is 1500 bytes, then TCP can achieve an -# average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 -# achieves exactly the same rate as Standard TCP, whereas HSTCP is -# about ten times more aggressive than Standard TCP. -# -# We can see that C determines the aggressiveness of CUBIC in competing -# with other congestion control algorithms for bandwidth. CUBIC is -# more friendly to Standard TCP, if the value of C is lower. However, -# we do not recommend setting C to a very low value like 0.04, since -# CUBIC with a low C cannot efficiently use the bandwidth in long RTT -# and high-bandwidth networks. Based on these observations and our -# experiments, we find C=0.4 gives a good balance between TCP- -# friendliness and aggressiveness of window increase. Therefore, C -# SHOULD be set to 0.4. With C set to 0.4, Eq. 6 is reduced to: -# -# AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) -# -# Eq. 7 is then used in the next subsection to show the scalability of -# CUBIC. - -[[spec]] -level = "SHOULD" -quote = ''' -Therefore, C -SHOULD be set to 0.4. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8312/5.8.toml b/specs/www.rfc-editor.org/rfc/rfc8312/5.8.toml deleted file mode 100644 index 40f23ff9e1..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8312/5.8.toml +++ /dev/null @@ -1,19 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8312#section-5.8" - -# 5.8. Behavior for Application-Limited Flows -# -# CUBIC does not raise its congestion window size if the flow is -# currently limited by the application instead of the congestion -# window. In case of long periods when cwnd has not been updated due -# to the application rate limit, such as idle periods, t in Eq. 1 MUST -# NOT include these periods; otherwise, W_cubic(t) might be very high -# after restarting from these periods. - -[[spec]] -level = "MUST" -quote = ''' -1 MUST -NOT include these periods; otherwise, W_cubic(t) might be very high -after restarting from these periods. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/1.3.toml b/specs/www.rfc-editor.org/rfc/rfc8899/1.3.toml deleted file mode 100644 index 64b993c62d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/1.3.toml +++ /dev/null @@ -1,68 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-1.3" - -# 1.3. Path MTU Discovery for Datagram Services -# -# Section 5 of this document presents a set of algorithms for datagram -# protocols to discover the largest size of unfragmented datagram that -# can be sent over a network path. The method relies upon features of -# the PL described in Section 3 and applies to transport protocols -# operating over IPv4 and IPv6. It does not require cooperation from -# the lower layers, although it can utilize PTB messages when these -# received messages are made available to the PL. -# -# The message size guidelines in Section 3.2 of the UDP Usage -# Guidelines [BCP145] state that "an application SHOULD either use the -# Path MTU information provided by the IP layer or implement Path MTU -# Discovery (PMTUD)" but do not provide a mechanism for discovering the -# largest size of unfragmented datagram that can be used on a network -# path. The present document updates RFC 8085 to specify this method -# in place of PLPMTUD [RFC4821] and provides a mechanism for sharing -# the discovered largest size as the MPS (see Section 4.4). -# -# Section 10.2 of [RFC4821] recommended a PLPMTUD probing method for -# the Stream Control Transport Protocol (SCTP). SCTP utilizes probe -# packets consisting of a minimal-sized HEARTBEAT chunk bundled with a -# PAD chunk as defined in [RFC4820]. However, RFC 4821 did not provide -# a complete specification. The present document replaces that -# description by providing a complete specification. -# -# The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires -# implementations to support Classical PMTUD and states that a DCCP -# sender "MUST maintain the MPS allowed for each active DCCP session". -# It also defines the current congestion control MPS (CCMPS) supported -# by a network path. This recommends use of PMTUD and suggests use of -# control packets (DCCP-Sync) as path probe packets because they do not -# risk application data loss. The method defined in this specification -# can be used with DCCP. -# -# Section 4 and Section 5 define the protocol mechanisms and -# specification for Datagram Packetization Layer Path MTU Discovery -# (DPLPMTUD). -# -# Section 6 specifies the method for datagram transports and provides -# information to enable the implementation of PLPMTUD with other -# datagram transports and applications that use datagram transports. -# -# Section 6 also provides recommendations for SCTP endpoints, updating -# [RFC4960], [RFC6951], and [RFC8261] to use the method specified in -# this document instead of the method in [RFC4821]. - -[[spec]] -level = "SHOULD" -quote = ''' -The message size guidelines in Section 3.2 of the UDP Usage -Guidelines [BCP145] state that "an application SHOULD either use the -Path MTU information provided by the IP layer or implement Path MTU -Discovery (PMTUD)" but do not provide a mechanism for discovering the -largest size of unfragmented datagram that can be used on a network -path. -''' - -[[spec]] -level = "MUST" -quote = ''' -The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires -implementations to support Classical PMTUD and states that a DCCP -sender "MUST maintain the MPS allowed for each active DCCP session". -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/2.toml deleted file mode 100644 index 179c52cae9..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/2.toml +++ /dev/null @@ -1,157 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-2" - -# 2. Terminology -# -# 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. -# -# The following terminology is defined. Relevant terms are directly -# copied from [RFC4821], and the definitions in [RFC1122] apply. -# -# Acknowledged PL: A PL that includes a mechanism that can confirm -# successful delivery of datagrams to the remote PL endpoint (e.g., -# SCTP). Typically, the PL receiver returns acknowledgments -# corresponding to the received datagrams, which can be utilized to -# detect black-holing of packets (c.f., Unacknowledged PL). -# -# Actual PMTU: The actual PMTU is the PMTU of a network path between a -# sender PL and a destination PL, which the DPLPMTUD algorithm seeks -# to determine. -# -# Black Hole: A black hole is encountered when a sender is unaware -# that packets are not being delivered to the destination endpoint. -# Two types of black hole are relevant to DPLPMTUD: -# -# * Packets encounter a packet black hole when packets are not -# delivered to the destination endpoint (e.g., when the sender -# transmits packets of a particular size with a previously known -# effective PMTU, and they are discarded by the network). -# -# * An ICMP black hole is encountered when the sender is unaware -# that packets are not delivered to the destination endpoint -# because PTB messages are not received by the originating PL -# sender. -# -# Classical Path MTU Discovery: Classical PMTUD is a process described -# in [RFC1191] and [RFC8201] in which nodes rely on PTB messages to -# learn the largest size of unfragmented packet that can be used -# across a network path. -# -# Datagram: A datagram is a transport-layer protocol data unit, -# transmitted in the payload of an IP packet. -# -# DPLPMTUD: Datagram Packetization Layer Path MTU Discovery -# (DPLPMTUD), PLPMTUD performed using a datagram transport protocol. -# -# Effective PMTU: The effective PMTU is the current estimated value -# for PMTU that is used by a PMTUD. This is equivalent to the -# PLPMTU derived by PLPMTUD plus the size of any headers added below -# the PL, including the IP layer headers. -# -# EMTU_S: The effective MTU for sending (EMTU_S) is defined in -# [RFC1122] as "the maximum IP datagram size that may be sent, for a -# particular combination of IP source and destination addresses...". -# -# EMTU_R: The effective MTU for receiving (EMTU_R) is designated in -# [RFC1122] as "the largest datagram size that can be reassembled". -# -# Link: A link is a communication facility or medium over which nodes -# can communicate at the link layer, i.e., a layer below the IP -# layer. Examples are Ethernet LANs and Internet (or higher) layer -# tunnels. -# -# Link MTU: The link Maximum Transmission Unit (MTU) is the size in -# bytes of the largest IP packet, including the IP header and -# payload, that can be transmitted over a link. Note that this -# could more properly be called the IP MTU, to be consistent with -# how other standards organizations use the acronym. This includes -# the IP header but excludes link layer headers and other framing -# that is not part of IP or the IP payload. Other standards -# organizations generally define the link MTU to include the link -# layer headers. This specification continues the requirement in -# [RFC4821] that states, "All links MUST enforce their MTU: links -# that might non-deterministically deliver packets that are larger -# than their rated MTU MUST consistently discard such packets." -# -# MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that -# DPLPMTUD will attempt to use (see the constants defined in -# Section 5.1.2). -# -# MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that -# DPLPMTUD will attempt to use (see the constants defined in -# Section 5.1.2). -# -# MPS: The Maximum Packet Size (MPS) is the largest size of -# application data block that can be sent across a network path by a -# PL using a single datagram (see Section 4.4). -# -# MSL: The Maximum Segment Lifetime (MSL) is the maximum delay a -# packet is expected to experience across a path, taken as 2 minutes -# [BCP145]. -# -# Packet: A packet is the IP header(s) and any extension headers/ -# options plus the IP payload. -# -# Packetization Layer (PL): The PL is a layer of the network stack -# that places data into packets and performs transport protocol -# functions. Examples of a PL include TCP, SCTP, SCTP over UDP, -# SCTP over DTLS, or QUIC. -# -# Path: The path is the set of links and routers traversed by a packet -# between a source node and a destination node by a particular flow. -# -# Path MTU (PMTU): The Path MTU (PMTU) is the minimum of the link MTU -# of all the links forming a network path between a source node and -# a destination node, as used by PMTUD. -# -# PTB: In this document, the term PTB message is applied to both IPv4 -# ICMP Unreachable messages (Type 3) that carry the error -# Fragmentation Needed (Type 3, Code 4) [RFC0792] and ICMPv6 Packet -# Too Big messages (Type 2) [RFC4443]. -# -# PTB_SIZE: The PTB_SIZE is a value reported in a validated PTB -# message that indicates next-hop link MTU of a router along the -# path. -# -# PL_PTB_SIZE: The size reported in a validated PTB message, reduced -# by the size of all headers added by layers below the PL. -# -# PLPMTU: The Packetization Layer PMTU is an estimate of the largest -# size of PL datagram that can be sent by a path, controlled by -# PLPMTUD. -# -# PLPMTUD: Packetization Layer Path MTU Discovery (PLPMTUD), the -# method described in this document for datagram PLs, which is an -# extension to Classical PMTU Discovery. -# -# Probe packet: A probe packet is a datagram sent with a purposely -# chosen size (typically the current PLPMTU or larger) to detect if -# packets of this size can be successfully sent end-to-end across -# the network path. -# -# Unacknowledged PL: A PL that does not itself provide a mechanism to -# confirm delivery of datagrams to the remote PL endpoint (e.g., -# UDP), and therefore requires DPLPMTUD to provide a mechanism to -# detect black-holing of packets (c.f., Acknowledged PL). - -[[spec]] -level = "MUST" -quote = ''' -This specification continues the requirement in -[RFC4821] that states, "All links MUST enforce their MTU: links -that might non-deterministically deliver packets that are larger -than their rated MTU MUST consistently discard such packets." -''' - -[[spec]] -level = "MUST" -quote = ''' -This specification continues the requirement in -[RFC4821] that states, "All links MUST enforce their MTU: links -that might non-deterministically deliver packets that are larger -than their rated MTU MUST consistently discard such packets." -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/3.toml b/specs/www.rfc-editor.org/rfc/rfc8899/3.toml deleted file mode 100644 index 0b2dc5e716..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/3.toml +++ /dev/null @@ -1,389 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-3" - -# 3. Features Required to Provide Datagram PLPMTUD -# -# The principles expressed in [RFC4821] apply to the use of the -# technique with any PL. TCP PLPMTUD has been defined using standard -# TCP protocol mechanisms. Unlike TCP, a datagram PL requires -# additional mechanisms and considerations to implement PLPMTUD. -# -# The requirements for datagram PLPMTUD are: -# -# 1. Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by -# DPLPMTUD. A PL MUST NOT send a datagram (other than a probe -# packet) with a size at the PL that is larger than the current -# PLPMTU. -# -# 2. Probe packets: The network interface below the PL is REQUIRED to -# provide a way to transmit a probe packet that is larger than the -# PLPMTU. In IPv4, a probe packet MUST be sent with the Don't -# Fragment (DF) bit set in the IP header and without network layer -# endpoint fragmentation. In IPv6, a probe packet is always sent -# without source fragmentation (as specified in Section 5.4 of -# [RFC8201]). -# -# 3. Reception feedback: The destination PL endpoint is REQUIRED to -# provide a feedback method that indicates to the DPLPMTUD sender -# when a probe packet has been received by the destination PL -# endpoint. Section 6 provides examples of how a PL can provide -# this acknowledgment of received probe packets. -# -# 4. Probe loss recovery: It is RECOMMENDED to use probe packets that -# do not carry any user data that would require retransmission if -# lost. Most datagram transports permit this. If a probe packet -# contains user data requiring retransmission in case of loss, the -# PL (or layers above) is REQUIRED to arrange any retransmission -# and/or repair of any resulting loss. The PL is REQUIRED to be -# robust in the case where probe packets are lost due to other -# reasons (including link transmission error, congestion). -# -# 5. PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize -# information about the maximum size of packet that can be -# transmitted by the sender on the local link (e.g., the local link -# MTU). A PL sender MAY utilize similar information about the -# maximum size of network-layer packet that a receiver can accept -# when this is supplied (note this could be less than EMTU_R). -# This avoids implementations trying to send probe packets that -# cannot be transferred by the local link. Too high of a value -# could reduce the efficiency of the search algorithm. Some -# applications also have a maximum transport protocol data unit -# (PDU) size, in which case there is no benefit from probing for a -# size larger than this (unless a transport allows multiplexing -# multiple applications' PDUs into the same datagram). -# -# 6. Processing PTB messages: A DPLPMTUD sender MAY optionally utilize -# PTB messages received from the network layer to help identify -# when a network path does not support the current size of probe -# packet. Any received PTB message MUST be validated before it is -# used to update the PLPMTU discovery information [RFC8201]. This -# validation confirms that the PTB message was sent in response to -# a packet originated by the sender and needs to be performed -# before the PLPMTU discovery method reacts to the PTB message. A -# PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but -# could trigger a probe to test for a larger PLPMTU. A valid -# PTB_SIZE is converted to a PL_PTB_SIZE before it is to be used in -# the DPLPMTUD state machine. A PL_PTB_SIZE that is greater than -# that currently probed SHOULD be ignored. (This PTB message ought -# to be discarded without further processing but could be utilized -# as an input that enables a resilience mode). -# -# 7. Probing and congestion control: A PL MAY use a congestion -# controller to decide when to send a probe packet. If -# transmission of probe packets is limited by the congestion -# controller, this could result in transmission of probe packets -# being delayed or suspended during congestion. When the -# transmission of probe packets is not controlled by the congestion -# controller, the interval between probe packets MUST be at least -# one RTT. Loss of a probe packet SHOULD NOT be treated as an -# indication of congestion and SHOULD NOT trigger a congestion -# control reaction [RFC4821] because this could result in -# unnecessary reduction of the sending rate. An update to the -# PLPMTU (or MPS) MUST NOT increase the congestion window measured -# in bytes [RFC4821]. Therefore, an increase in the packet size -# does not cause an increase in the data rate in bytes per second. -# A PL that maintains the congestion window in terms of a limit to -# the number of outstanding fixed-size packets SHOULD adapt this -# limit to compensate for the size of the actual packets. The -# transmission of probe packets can interact with the operation of -# a PL that performs burst mitigation or pacing, and the PL could -# need transmission of probe packets to be regulated by these -# methods. -# -# 8. Probing and flow control: Flow control at the PL concerns the -# end-to-end flow of data using the PL service. Flow control -# SHOULD NOT apply to DPLPMTU when probe packets use a design that -# does not carry user data to the remote application. -# -# 9. Shared PLPMTU state: The PMTU value calculated from the PLPMTU -# MAY also be stored with the corresponding entry associated with -# the destination in the IP layer cache and used by other PL -# instances. The specification of PLPMTUD [RFC4821] states, "If -# PLPMTUD updates the MTU for a particular path, all Packetization -# Layer sessions that share the path representation (as described -# in Section 5.2) SHOULD be notified to make use of the new MTU". -# Such methods MUST be robust to the wide variety of underlying -# network forwarding behaviors. Section 5.2 of [RFC8201] provides -# guidance on the caching of PMTU information and also the relation -# to IPv6 flow labels. -# -# In addition, the following principles are stated for design of a -# DPLPMTUD method: -# -# * A PL MAY be designed to segment data blocks larger than the MPS -# into multiple datagrams. However, not all datagram PLs support -# segmentation of data blocks. It is RECOMMENDED that methods avoid -# forcing an application to use an arbitrary small MPS for -# transmission while the method is searching for the currently -# supported PLPMTU. A reduced MPS can adversely impact the -# performance of an application. -# -# * To assist applications in choosing a suitable data block size, the -# PL is RECOMMENDED to provide a primitive that returns the MPS -# derived from the PLPMTU to the higher layer using the PL. The -# value of the MPS can change following a change in the path or loss -# of probe packets. -# -# * Path validation: It is RECOMMENDED that methods are robust to path -# changes that could have occurred since the path characteristics -# were last confirmed and to the possibility of inconsistent path -# information being received. -# -# * Datagram reordering: A method is REQUIRED to be robust to the -# possibility that a flow encounters reordering or that the traffic -# (including probe packets) is divided over more than one network -# path. -# -# * Datagram delay and duplication: The feedback mechanism is REQUIRED -# to be robust to the possibility that packets could be -# significantly delayed or duplicated along a network path. -# -# * When to probe: It is RECOMMENDED that methods determine whether -# the path has changed since it last measured the path. This can -# help determine when to probe the path again. - -[[spec]] -level = "MUST" -quote = ''' -A PL MUST NOT send a datagram (other than a probe -packet) with a size at the PL that is larger than the current -PLPMTU. -''' - -[[spec]] -level = "MUST" -quote = ''' -Probe packets: The network interface below the PL is REQUIRED to -provide a way to transmit a probe packet that is larger than the -PLPMTU. -''' - -[[spec]] -level = "MUST" -quote = ''' -In IPv4, a probe packet MUST be sent with the Don't -Fragment (DF) bit set in the IP header and without network layer -endpoint fragmentation. -''' - -[[spec]] -level = "MUST" -quote = ''' -Reception feedback: The destination PL endpoint is REQUIRED to -provide a feedback method that indicates to the DPLPMTUD sender -when a probe packet has been received by the destination PL -endpoint. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Probe loss recovery: It is RECOMMENDED to use probe packets that -do not carry any user data that would require retransmission if -lost. -''' - -[[spec]] -level = "MUST" -quote = ''' -If a probe packet -contains user data requiring retransmission in case of loss, the -PL (or layers above) is REQUIRED to arrange any retransmission -and/or repair of any resulting loss. -''' - -[[spec]] -level = "MUST" -quote = ''' -The PL is REQUIRED to be -robust in the case where probe packets are lost due to other -reasons (including link transmission error, congestion). -''' - -[[spec]] -level = "SHOULD" -quote = ''' -PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize -information about the maximum size of packet that can be -transmitted by the sender on the local link (e.g., the local link -MTU). -''' - -[[spec]] -level = "MAY" -quote = ''' -A PL sender MAY utilize similar information about the -maximum size of network-layer packet that a receiver can accept -when this is supplied (note this could be less than EMTU_R). -''' - -[[spec]] -level = "MAY" -quote = ''' -Processing PTB messages: A DPLPMTUD sender MAY optionally utilize -PTB messages received from the network layer to help identify -when a network path does not support the current size of probe -packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -Any received PTB message MUST be validated before it is -used to update the PLPMTU discovery information [RFC8201]. -''' - -[[spec]] -level = "MUST" -quote = ''' -A -PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but -could trigger a probe to test for a larger PLPMTU. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A PL_PTB_SIZE that is greater than -that currently probed SHOULD be ignored. -''' - -[[spec]] -level = "MAY" -quote = ''' -Probing and congestion control: A PL MAY use a congestion -controller to decide when to send a probe packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -When the -transmission of probe packets is not controlled by the congestion -controller, the interval between probe packets MUST be at least -one RTT. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Loss of a probe packet SHOULD NOT be treated as an -indication of congestion and SHOULD NOT trigger a congestion -control reaction [RFC4821] because this could result in -unnecessary reduction of the sending rate. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Loss of a probe packet SHOULD NOT be treated as an -indication of congestion and SHOULD NOT trigger a congestion -control reaction [RFC4821] because this could result in -unnecessary reduction of the sending rate. -''' - -[[spec]] -level = "MUST" -quote = ''' -An update to the -PLPMTU (or MPS) MUST NOT increase the congestion window measured -in bytes [RFC4821]. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A PL that maintains the congestion window in terms of a limit to -the number of outstanding fixed-size packets SHOULD adapt this -limit to compensate for the size of the actual packets. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Flow control -SHOULD NOT apply to DPLPMTU when probe packets use a design that -does not carry user data to the remote application. -''' - -[[spec]] -level = "MAY" -quote = ''' -Shared PLPMTU state: The PMTU value calculated from the PLPMTU -MAY also be stored with the corresponding entry associated with -the destination in the IP layer cache and used by other PL -instances. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The specification of PLPMTUD [RFC4821] states, "If -PLPMTUD updates the MTU for a particular path, all Packetization -Layer sessions that share the path representation (as described -in Section 5.2) SHOULD be notified to make use of the new MTU". -''' - -[[spec]] -level = "MUST" -quote = ''' -Such methods MUST be robust to the wide variety of underlying -network forwarding behaviors. -''' - -[[spec]] -level = "MAY" -quote = ''' -* A PL MAY be designed to segment data blocks larger than the MPS -into multiple datagrams. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -It is RECOMMENDED that methods avoid -forcing an application to use an arbitrary small MPS for -transmission while the method is searching for the currently -supported PLPMTU. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -* To assist applications in choosing a suitable data block size, the -PL is RECOMMENDED to provide a primitive that returns the MPS -derived from the PLPMTU to the higher layer using the PL. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -* Path validation: It is RECOMMENDED that methods are robust to path -changes that could have occurred since the path characteristics -were last confirmed and to the possibility of inconsistent path -information being received. -''' - -[[spec]] -level = "MUST" -quote = ''' -* Datagram reordering: A method is REQUIRED to be robust to the -possibility that a flow encounters reordering or that the traffic -(including probe packets) is divided over more than one network -path. -''' - -[[spec]] -level = "MUST" -quote = ''' -* Datagram delay and duplication: The feedback mechanism is REQUIRED -to be robust to the possibility that packets could be -significantly delayed or duplicated along a network path. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -* When to probe: It is RECOMMENDED that methods determine whether -the path has changed since it last measured the path. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.1.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.1.toml deleted file mode 100644 index 951937e423..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.1.toml +++ /dev/null @@ -1,87 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.1" - -# 4.1. PLPMTU Probe Packets -# -# The DPLPMTUD method relies upon the PL sender being able to generate -# probe packets with a specific size. TCP is able to generate these -# probe packets by choosing to appropriately segment data being sent -# [RFC4821]. In contrast, a datagram PL that constructs a probe packet -# has to either request an application to send a data block that is -# larger than that generated by an application, or to utilize padding -# functions to extend a datagram beyond the size of the application -# data block. Protocols that permit exchange of control messages -# (without an application data block) can generate a probe packet by -# extending a control message with padding data. The total size of a -# probe packet includes all headers and padding added to the payload -# data being sent (e.g., including protocol option fields, security- -# related fields such as an Authenticated Encryption with Associated -# Data (AEAD) tag, and TLS record layer padding). -# -# A receiver is REQUIRED to be able to distinguish an in-band data -# block from any added padding. This is needed to ensure that any -# added padding is not passed on to an application at the receiver. -# -# This results in three possible ways that a sender can create a probe -# packet: -# -# Probing using padding data: A probe packet that contains only -# control information together with any padding, which is needed to -# inflate to the size of the probe packet. Since these probe -# packets do not carry an application-supplied data block, they do -# not typically require retransmission, although they do still -# consume network capacity and incur endpoint processing. -# -# Probing using application data and padding data: A probe packet that -# contains a data block supplied by an application that is combined -# with padding to inflate the length of the datagram to the size of -# the probe packet. -# -# Probing using application data: A probe packet that contains a data -# block supplied by an application that matches the size of the -# probe packet. This method requests the application to issue a -# data block of the desired probe size. -# -# A PL that uses a probe packet carrying application data and that -# needs protection from the loss of this probe packet could perform -# transport-layer retransmission/repair of the data block (e.g., by -# retransmitting after loss is detected or by duplicating the data -# block in a datagram without the padding data). This retransmitted -# data block might possibly need to be sent using a smaller PLPMTU, -# which could force the PL to use a smaller packet size to traverse the -# end-to-end path. (This could utilize endpoint network-layer -# fragmentation or a PL that can resegment the data block into multiple -# datagrams). -# -# DPLPMTUD MAY choose to use only one of these methods to simplify the -# implementation. -# -# Probe messages sent by a PL MUST contain enough information to -# uniquely identify the probe within the Maximum Segment Lifetime -# (e.g., including a unique identifier from the PL or the DPLPMTUD -# implementation), while being robust to reordering and replay of probe -# response and PTB messages. - -[[spec]] -level = "MUST" -quote = ''' -A receiver is REQUIRED to be able to distinguish an in-band data -block from any added padding. -''' - -[[spec]] -level = "MAY" -quote = ''' -DPLPMTUD MAY choose to use only one of these methods to simplify the -implementation. -''' - -[[spec]] -level = "MUST" -quote = ''' -Probe messages sent by a PL MUST contain enough information to -uniquely identify the probe within the Maximum Segment Lifetime -(e.g., including a unique identifier from the PL or the DPLPMTUD -implementation), while being robust to reordering and replay of probe -response and PTB messages. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.2.toml deleted file mode 100644 index fe2c3a4968..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.2.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.2" - -# 4.2. Confirmation of Probed Packet Size -# -# The PL needs a method to determine (confirm) when probe packets have -# been successfully received end-to-end across a network path. -# -# Transport protocols can include end-to-end methods that detect and -# report reception of specific datagrams that they send (e.g., DCCP, -# SCTP, and QUIC provide keep-alive/heartbeat features). When -# supported, this mechanism MAY also be used by DPLPMTUD to acknowledge -# reception of a probe packet. -# -# A PL that does not acknowledge data reception (e.g., UDP and UDP- -# Lite) is unable itself to detect when the packets that it sends are -# discarded because their size is greater than the actual PMTU. These -# PLs need to rely on an application protocol to detect this loss. -# -# Section 6 specifies this function for a set of IETF-specified -# protocols. - -[[spec]] -level = "MAY" -quote = ''' -When -supported, this mechanism MAY also be used by DPLPMTUD to acknowledge -reception of a probe packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.3.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.3.toml deleted file mode 100644 index f4684c472a..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.3.toml +++ /dev/null @@ -1,69 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.3" - -# 4.3. Black Hole Detection and Reducing the PLPMTU -# -# The description that follows uses the set of constants defined in -# Section 5.1.2 and variables defined in Section 5.1.3. -# -# Black hole detection is triggered by an indication that the network -# path could be unable to support the current PLPMTU size. -# -# There are three indicators that can be used to detect black holes: -# -# * A validated PTB message can be received that indicates a -# PL_PTB_SIZE less than the current PLPMTU. A DPLPMTUD method MUST -# NOT rely solely on this method. -# -# * A PL can use the DPLPMTUD probing mechanism to periodically -# generate probe packets of the size of the current PLPMTU (e.g., -# using the CONFIRMATION_TIMER, Section 5.1.1). A timer tracks -# whether acknowledgments are received. Successive loss of probes -# is an indication that the current path no longer supports the -# PLPMTU (e.g., when the number of probe packets sent without -# receiving an acknowledgment, PROBE_COUNT, becomes greater than -# MAX_PROBES). -# -# * A PL can utilize an event that indicates the network path no -# longer sustains the sender's PLPMTU size. This could use a -# mechanism implemented within the PL to detect excessive loss of -# data sent with a specific packet size and then conclude that this -# excessive loss could be a result of an invalid PLPMTU (as in -# PLPMTUD for TCP [RFC4821]). -# -# The three methods can result in different transmission patterns for -# packet probes and are expected to result in different responsiveness -# following a change in the actual PMTU. -# -# A PL MAY inhibit sending probe packets when no application data has -# been sent since the previous probe packet. A PL that resumes sending -# user data MAY continue PLPMTU discovery for each path. This allows -# it to use an up-to-date PLPMTU. However, this could result in -# additional packets being sent. -# -# When the method detects that the current PLPMTU is not supported, -# DPLPMTUD sets a lower PLPMTU and a lower MPS. The PL then confirms -# that the new PLPMTU can be successfully used across the path. A -# probe packet could need to be smaller than the size of the data block -# generated by the application. - -[[spec]] -level = "MUST" -quote = ''' -A DPLPMTUD method MUST -NOT rely solely on this method. -''' - -[[spec]] -level = "MAY" -quote = ''' -A PL MAY inhibit sending probe packets when no application data has -been sent since the previous probe packet. -''' - -[[spec]] -level = "MAY" -quote = ''' -A PL that resumes sending -user data MAY continue PLPMTU discovery for each path. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.4.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.4.toml deleted file mode 100644 index 094abe1c3d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.4.toml +++ /dev/null @@ -1,72 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.4" - -# 4.4. The Maximum Packet Size (MPS) -# -# The result of probing determines a usable PLPMTU, which is used to -# set the MPS used by the application. The MPS is smaller than the -# PLPMTU because it is reduced by the size of PL headers (including the -# overhead of security-related fields such as an AEAD tag and TLS -# record layer padding). The relationship between the MPS and the -# PLPMTUD is illustrated in Figure 1. -# -# Any additional -# headers .--- MPS -----. -# | | | -# v v v -# +------------------------------+ -# | IP | ** | PL | protocol data | -# +------------------------------+ -# -# <----- PLPMTU -----> -# <---------- PMTU --------------> -# -# Figure 1: Relationship between MPS and PLPMTU -# -# A PL is unable to send a packet (other than a probe packet) with a -# size larger than the current PLPMTU at the network layer. To avoid -# this, a PL MAY be designed to segment data blocks larger than the MPS -# into multiple datagrams. -# -# DPLPMTUD seeks to avoid IP fragmentation. An attempt to send a data -# block larger than the MPS will therefore fail if a PL is unable to -# segment data. To determine the largest data block that can be sent, -# a PL SHOULD provide applications with a primitive that returns the -# MPS, derived from the current PLPMTU. -# -# If DPLPMTUD results in a change to the MPS, the application needs to -# adapt to the new MPS. A particular case can arise when packets have -# been sent with a size less than the MPS and the PLPMTU was -# subsequently reduced. If these packets are lost, the PL MAY segment -# the data using the new MPS. If a PL is unable to resegment a -# previously sent datagram (e.g., [RFC4960]), then the sender either -# discards the datagram or could perform retransmission using network- -# layer fragmentation to form multiple IP packets not larger than the -# PLPMTU. For IPv4, the use of endpoint fragmentation by the sender is -# preferred over clearing the DF bit in the IPv4 header. Operational -# experience reveals that IP fragmentation can reduce the reliability -# of Internet communication [RFC8900], which may reduce the probability -# of successful retransmission. - -[[spec]] -level = "MAY" -quote = ''' -To avoid -this, a PL MAY be designed to segment data blocks larger than the MPS -into multiple datagrams. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -To determine the largest data block that can be sent, -a PL SHOULD provide applications with a primitive that returns the -MPS, derived from the current PLPMTU. -''' - -[[spec]] -level = "MAY" -quote = ''' -If these packets are lost, the PL MAY segment -the data using the new MPS. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.5.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.5.toml deleted file mode 100644 index 0b79e00b7c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.5.toml +++ /dev/null @@ -1,20 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.5" - -# 4.5. Disabling the Effect of PMTUD -# -# A PL implementing this specification MUST suspend network layer -# processing of outgoing packets that enforces a PMTU -# [RFC1191][RFC8201] for each flow utilizing DPLPMTUD and instead use -# DPLPMTUD to control the size of packets that are sent by a flow. -# This removes the need for the network layer to drop or to fragment -# sent packets that have a size greater than the PMTU. - -[[spec]] -level = "MUST" -quote = ''' -A PL implementing this specification MUST suspend network layer -processing of outgoing packets that enforces a PMTU -[RFC1191][RFC8201] for each flow utilizing DPLPMTUD and instead use -DPLPMTUD to control the size of packets that are sent by a flow. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.6.1.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.6.1.toml deleted file mode 100644 index 72e0b9467e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.6.1.toml +++ /dev/null @@ -1,81 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.6.1" - -# 4.6.1. Validation of PTB Messages -# -# This section specifies utilization and validation of PTB messages. -# -# * A simple implementation MAY ignore received PTB messages, and in -# this case, the PLPMTU is not updated when a PTB message is -# received. -# -# * A PL that supports PTB messages MUST validate these messages -# before they are further processed. -# -# A PL that receives a PTB message from a router or middlebox performs -# ICMP validation (see Section 4 of [RFC8201] and Section 5.2 of -# [BCP145]). Because DPLPMTUD operates at the PL, the PL needs to -# check that each received PTB message is received in response to a -# packet transmitted by the endpoint PL performing DPLPMTUD. -# -# The PL MUST check the protocol information in the quoted packet -# carried in an ICMP PTB message payload to validate the message -# originated from the sending node. This validation includes -# determining that the combination of the IP addresses, the protocol, -# the source port, and destination port match those returned in the -# quoted packet -- this is also necessary for the PTB message to be -# passed to the corresponding PL. -# -# The validation SHOULD utilize information that is not simple for an -# off-path attacker to determine [BCP145]. For example, it could check -# the value of a protocol header field known only to the two PL -# endpoints. A datagram application that uses well-known source and -# destination ports ought to also rely on other information to complete -# this validation. -# -# These checks are intended to provide protection from packets that -# originate from a node that is not on the network path. A PTB message -# that does not complete the validation MUST NOT be further utilized by -# the DPLPMTUD method, as discussed in the Security Considerations -# section (Section 8). -# -# Section 4.6.2 describes this processing of PTB messages. - -[[spec]] -level = "MAY" -quote = ''' -* A simple implementation MAY ignore received PTB messages, and in -this case, the PLPMTU is not updated when a PTB message is -received. -''' - -[[spec]] -level = "MUST" -quote = ''' -* A PL that supports PTB messages MUST validate these messages -before they are further processed. -''' - -[[spec]] -level = "MUST" -quote = ''' -The PL MUST check the protocol information in the quoted packet -carried in an ICMP PTB message payload to validate the message -originated from the sending node. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The validation SHOULD utilize information that is not simple for an -off-path attacker to determine [BCP145]. -''' - -[[spec]] -level = "MUST" -quote = ''' -A PTB message -that does not complete the validation MUST NOT be further utilized by -the DPLPMTUD method, as discussed in the Security Considerations -section (Section 8). -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/4.6.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/4.6.2.toml deleted file mode 100644 index 24a9e0e757..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/4.6.2.toml +++ /dev/null @@ -1,111 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-4.6.2" - -# 4.6.2. Use of PTB Messages -# -# PTB messages that have been validated MAY be utilized by the DPLPMTUD -# algorithm but MUST NOT be used directly to set the PLPMTU. -# -# Before using the size reported in the PTB message, it must first be -# converted to a PL_PTB_SIZE. The PL_PTB_SIZE is smaller than the -# PTB_SIZE because it is reduced by headers below the PL, including any -# IP options or extensions added to the PL packet. -# -# A method that utilizes these PTB messages can improve the speed at -# which the algorithm detects an appropriate PLPMTU by triggering an -# immediate probe for the PL_PTB_SIZE (resulting in a network-layer -# packet of size PTB_SIZE), compared to one that relies solely on -# probing using a timer-based search algorithm. -# -# A set of checks are intended to provide protection from a router that -# reports an unexpected PTB_SIZE. The PL also needs to check that the -# indicated PL_PTB_SIZE is less than the size used by probe packets and -# at least the minimum size accepted. -# -# This section provides a summary of how PTB messages can be utilized, -# using the set of constants defined in Section 5.1.2. This processing -# depends on the PL_PTB_SIZE and the current value of a set of -# variables: -# -# PL_PTB_SIZE < MIN_PLPMTU -# * Invalid PL_PTB_SIZE, see Section 4.6.1. -# -# * PTB message ought to be discarded without further processing -# (i.e., PLPMTU is not modified). -# -# * The information could be utilized as an input that triggers the -# enabling of a resilience mode (see Section 5.3.3). -# -# MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU -# * A robust PL MAY enter an error state (see Section 5.2) for an -# IPv4 path when the PL_PTB_SIZE reported in the PTB message is -# larger than or equal to 68 bytes [RFC0791] and when this is -# less than the BASE_PLPMTU. -# -# * A robust PL MAY enter an error state (see Section 5.2) for an -# IPv6 path when the PL_PTB_SIZE reported in the PTB message is -# larger than or equal to 1280 bytes [RFC8200] and when this is -# less than the BASE_PLPMTU. -# -# BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU -# * This could be an indication of a black hole. The PLPMTU SHOULD -# be set to BASE_PLPMTU (the PLPMTU is reduced to the BASE_PLPMTU -# to avoid unnecessary packet loss when a black hole is -# encountered). -# -# * The PL ought to start a search to quickly discover the new -# PLPMTU. The PL_PTB_SIZE reported in the PTB message can be -# used to initialize a search algorithm. -# -# PLPMTU < PL_PTB_SIZE < PROBED_SIZE -# * The PLPMTU continues to be valid, but the size of a packet used -# to search (PROBED_SIZE) was larger than the actual PMTU. -# -# * The PLPMTU is not updated. -# -# * The PL can use the reported PL_PTB_SIZE from the PTB message as -# the next search point when it resumes the search algorithm. -# -# PL_PTB_SIZE >= PROBED_SIZE -# * Inconsistent network signal. -# -# * PTB message ought to be discarded without further processing -# (i.e., PLPMTU is not modified). -# -# * The information could be utilized as an input to trigger the -# enabling of a resilience mode. - -[[spec]] -level = "MUST" -quote = ''' -PTB messages that have been validated MAY be utilized by the DPLPMTUD -algorithm but MUST NOT be used directly to set the PLPMTU. -''' - -[[spec]] -level = "MAY" -quote = ''' -MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU -* A robust PL MAY enter an error state (see Section 5.2) for an -IPv4 path when the PL_PTB_SIZE reported in the PTB message is -larger than or equal to 68 bytes [RFC0791] and when this is -less than the BASE_PLPMTU. -''' - -[[spec]] -level = "MAY" -quote = ''' -* A robust PL MAY enter an error state (see Section 5.2) for an -IPv6 path when the PL_PTB_SIZE reported in the PTB message is -larger than or equal to 1280 bytes [RFC8200] and when this is -less than the BASE_PLPMTU. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The PLPMTU SHOULD -be set to BASE_PLPMTU (the PLPMTU is reduced to the BASE_PLPMTU -to avoid unnecessary packet loss when a black hole is -encountered). -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/5.1.1.toml b/specs/www.rfc-editor.org/rfc/rfc8899/5.1.1.toml deleted file mode 100644 index 8f5fccaaeb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/5.1.1.toml +++ /dev/null @@ -1,71 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.1.1" - -# 5.1.1. Timers -# -# The method utilizes up to three timers: -# -# PROBE_TIMER: The PROBE_TIMER is configured to expire after a period -# longer than the maximum time to receive an acknowledgment to a -# probe packet. This value MUST NOT be smaller than 1 second and -# SHOULD be larger than 15 seconds. Guidance on the selection of -# the timer value is provided in Section 3.1.1 of the UDP Usage -# Guidelines [BCP145]. -# -# PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period a -# sender will continue to use the current PLPMTU, after which it -# reenters the Search Phase. This timer has a period of 600 -# seconds, as recommended by PLPMTUD [RFC4821]. -# -# DPLPMTUD MAY inhibit sending probe packets when no application -# data has been sent since the previous probe packet. A PL -# preferring to use an up-to-date PMTU once user data is sent again -# can choose to continue PMTU discovery for each path. However, -# this will result in sending additional packets. -# -# CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST -# NOT be used. For other PLs, the CONFIRMATION_TIMER is configured -# to the period a PL sender waits before confirming the current -# PLPMTU is still supported. This is less than the PMTU_RAISE_TIMER -# and used to decrease the PLPMTU (e.g., when a black hole is -# encountered). Confirmation needs to be frequent enough when data -# is flowing that the sending PL does not black hole extensive -# amounts of traffic. Guidance on selection of the timer value are -# provided in Section 3.1.1 of the UDP Usage Guidelines [BCP145]. -# -# DPLPMTUD MAY inhibit sending probe packets when no application -# data has been sent since the previous probe packet. A PL -# preferring to use an up-to-date PMTU once user data is sent again, -# can choose to continue PMTU discovery for each path. However, -# this could result in sending additional packets. -# -# DPLPMTUD specifies various timers; however, an implementation could -# choose to realize these timer functions using a single timer. - -[[spec]] -level = "MUST" -quote = ''' -This value MUST NOT be smaller than 1 second and -SHOULD be larger than 15 seconds. -''' - -[[spec]] -level = "MAY" -quote = ''' -DPLPMTUD MAY inhibit sending probe packets when no application -data has been sent since the previous probe packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST -NOT be used. -''' - -[[spec]] -level = "MAY" -quote = ''' -DPLPMTUD MAY inhibit sending probe packets when no application -data has been sent since the previous probe packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/5.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/5.1.2.toml deleted file mode 100644 index 40d6b3ccb7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/5.1.2.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.1.2" - -# 5.1.2. Constants -# -# The following constants are defined: -# -# MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT -# counter (see Section 5.1.3). MAX_PROBES represents the limit for -# the number of consecutive probe attempts of any size. Search -# algorithms benefit from a MAX_PROBES value greater than 1 because -# this can provide robustness to isolated packet loss. The default -# value of MAX_PROBES is 3. -# -# MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that -# DPLPMTUD will attempt to use. An endpoint could need to configure -# the MIN_PLPMTU to provide space for extension headers and other -# encapsulations at layers below the PL. This value can be -# interface and path dependent. For IPv6, this size is greater than -# or equal to the size at the PL that results in an 1280-byte IPv6 -# packet, as specified in [RFC8200]. For IPv4, this size is greater -# than or equal to the size at the PL that results in an 68-byte -# IPv4 packet. Note: An IPv4 router is required to be able to -# forward a datagram of 68 bytes without further fragmentation. -# This is the combined size of an IPv4 header and the minimum -# fragment size of 8 bytes. In addition, receivers are required to -# be able to reassemble fragmented datagrams at least up to 576 -# bytes, as stated in Section 3.3.3 of [RFC1122]. -# -# MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU. This has -# to be less than or equal to the maximum size of the PL packet that -# can be sent on the outgoing interface (constrained by the local -# interface MTU). When known, this also ought to be less than the -# maximum size of PL packet that can be received by the remote -# endpoint (constrained by EMTU_R). It can be limited by the design -# or configuration of the PL being used. An application, or PL, MAY -# choose a smaller MAX_PLPMTU when there is no need to send packets -# larger than a specific size. -# -# BASE_PLPMTU: The BASE_PLPMTU is a configured size expected to work -# for most paths. The size is equal to or larger than the -# MIN_PLPMTU and smaller than the MAX_PLPMTU. For most PLs, a -# suitable BASE_PLPMTU will be larger than 1200 bytes. When using -# IPv4, there is no currently equivalent size specified, and a -# default BASE_PLPMTU of 1200 bytes is RECOMMENDED. - -[[spec]] -level = "MAY" -quote = ''' -An application, or PL, MAY -choose a smaller MAX_PLPMTU when there is no need to send packets -larger than a specific size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When using -IPv4, there is no currently equivalent size specified, and a -default BASE_PLPMTU of 1200 bytes is RECOMMENDED. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/5.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/5.2.toml deleted file mode 100644 index 033447cad1..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/5.2.toml +++ /dev/null @@ -1,139 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.2" - -# 5.2. State Machine -# -# A state machine for DPLPMTUD is depicted in Figure 5. If multipath -# or multihoming is supported, a state machine is needed for each path. -# -# Note: Not all changes are shown to simplify the diagram. -# -# | | -# | Start | PL indicates loss -# | | of connectivity -# v v -# +---------------+ +---------------+ -# | DISABLED | | ERROR | -# +---------------+ PROBE_TIMER expiry: +---------------+ -# | PL indicates PROBE_COUNT = MAX_PROBES or ^ | -# | connectivity PTB: PL_PTB_SIZE < BASE_PLPMTU | | -# +--------------------+ +------------------+ | -# | | | -# v | BASE_PLPMTU Probe | -# +---------------+ acked | -# | BASE |--------------------->+ -# +---------------+ | -# ^ | ^ ^ | -# Black hole detected | | | | Black hole detected | -# +--------------------+ | | +--------------------+ | -# | +----+ | | -# | PROBE_TIMER expiry: | | -# | PROBE_COUNT < MAX_PROBES | | -# | | | -# | PMTU_RAISE_TIMER expiry | | -# | +-----------------------------------------+ | | -# | | | | | -# | | v | v -# +---------------+ +---------------+ -# |SEARCH_COMPLETE| | SEARCHING | -# +---------------+ +---------------+ -# | ^ ^ | | ^ -# | | | | | | -# | | +-----------------------------------------+ | | -# | | MAX_PLPMTU Probe acked or | | -# | | PROBE_TIMER expiry: PROBE_COUNT = MAX_PROBES or | | -# +----+ PTB: PL_PTB_SIZE = PLPMTU +----+ -# CONFIRMATION_TIMER expiry: PROBE_TIMER expiry: -# PROBE_COUNT < MAX_PROBES or PROBE_COUNT < MAX_PROBES or -# PLPMTU Probe acked Probe acked or PTB: -# PLPMTU < PL_PTB_SIZE < PROBED_SIZE -# -# Figure 5: State Machine for Datagram PLPMTUD -# -# The following states are defined: -# -# DISABLED: The DISABLED state is the initial state before probing has -# started. It is also entered from any other state, when the PL -# indicates loss of connectivity. This state is left once the PL -# indicates connectivity to the remote PL. When transitioning to -# the BASE state, a probe packet of size BASE_PLPMTU can be sent -# immediately. -# -# BASE: The BASE state is used to confirm that the BASE_PLPMTU size is -# supported by the network path and is designed to allow an -# application to continue working when there are transient -# reductions in the actual PMTU. It also seeks to avoid long -# periods when a sender searching for a larger PLPMTU is unaware -# that packets are not being delivered due to a packet or ICMP black -# hole. -# -# On entry, the PROBED_SIZE is set to the BASE_PLPMTU size, and the -# PROBE_COUNT is set to zero. -# -# Each time a probe packet is sent, the PROBE_TIMER is started. The -# state is exited when the probe packet is acknowledged, and the PL -# sender enters the SEARCHING state. -# -# The state is also left when the PROBE_COUNT reaches MAX_PROBES or -# a received PTB message is validated. This causes the PL sender to -# enter the ERROR state. -# -# SEARCHING: The SEARCHING state is the main probing state. This -# state is entered when probing for the BASE_PLPMTU completes. -# -# Each time a probe packet is acknowledged, the PROBE_COUNT is set -# to zero, the PLPMTU is set to the PROBED_SIZE, and then the -# PROBED_SIZE is increased using the search algorithm (as described -# in Section 5.3). -# -# When a probe packet is sent and not acknowledged within the period -# of the PROBE_TIMER, the PROBE_COUNT is incremented, and a new -# probe packet is transmitted. -# -# The state is exited to enter SEARCH_COMPLETE when the PROBE_COUNT -# reaches MAX_PROBES, a validated PTB is received that corresponds -# to the last successfully probed size (PL_PTB_SIZE = PLPMTU), or a -# probe of size MAX_PLPMTU is acknowledged (PLPMTU = MAX_PLPMTU). -# -# When a black hole is detected in the SEARCHING state, this causes -# the PL sender to enter the BASE state. -# -# SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates that a search -# has completed. This is the normal maintenance state, where the PL -# is not probing to update the PLPMTU. DPLPMTUD remains in this -# state until either the PMTU_RAISE_TIMER expires or a black hole is -# detected. -# -# When DPLPMTUD uses an unacknowledged PL and is in the -# SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets -# the PROBE_COUNT and schedules a probe packet with the size of the -# PLPMTU. If MAX_PROBES successive PLPMTUD-sized probes fail to be -# acknowledged, the method enters the BASE state. When used with an -# acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to -# generate PLPMTU probes in this state. -# -# ERROR: The ERROR state represents the case where either the network -# path is not known to support a PLPMTU of at least the BASE_PLPMTU -# size or when there is contradictory information about the network -# path that would otherwise result in excessive variation in the MPS -# signaled to the higher layer. The state implements a method to -# mitigate oscillation in the state-event engine. It signals a -# conservative value of the MPS to the higher layer by the PL. The -# state is exited when packet probes no longer detect the error. -# The PL sender then enters the SEARCHING state. -# -# Implementations are permitted to enable endpoint fragmentation if -# the DPLPMTUD is unable to validate MIN_PLPMTU within PROBE_COUNT -# probes. If DPLPMTUD is unable to validate MIN_PLPMTU, the -# implementation will transition to the DISABLED state. -# -# Note: MIN_PLPMTU could be identical to BASE_PLPMTU, simplifying -# the actions in this state. - -[[spec]] -level = "SHOULD" -quote = ''' -When used with an -acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to -generate PLPMTU probes in this state. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/5.3.1.toml b/specs/www.rfc-editor.org/rfc/rfc8899/5.3.1.toml deleted file mode 100644 index 5c5bbe16f4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/5.3.1.toml +++ /dev/null @@ -1,45 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.3.1" - -# 5.3.1. Probing for a Larger PLPMTU -# -# Implementations use a search algorithm across the search range to -# determine whether a larger PLPMTU can be supported across a network -# path. -# -# The method discovers the search range by confirming the minimum -# PLPMTU and then using the probe method to select a PROBED_SIZE less -# than or equal to MAX_PLPMTU. MAX_PLPMTU is the minimum of the local -# MTU and EMTU_R (when this is learned from the remote endpoint). The -# MAX_PLPMTU MAY be reduced by an application that sets a maximum to -# the size of datagrams it will send. -# -# The PROBE_COUNT is initialized to zero when the first probe with a -# size greater than or equal to PLPMTU is sent. Each probe packet -# successfully sent to the remote peer is confirmed by acknowledgment -# at the PL (see Section 4.1). -# -# Each time a probe packet is sent to the destination, the PROBE_TIMER -# is started. The timer is canceled when the PL receives -# acknowledgment that the probe packet has been successfully sent -# across the path (Section 4.1). This confirms that the PROBED_SIZE is -# supported, and the PROBED_SIZE value is then assigned to the PLPMTU. -# The search algorithm can continue to send subsequent probe packets of -# an increasing size. -# -# If the timer expires before a probe packet is acknowledged, the probe -# has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER -# expires, the PROBE_COUNT is incremented, the PROBE_TIMER is -# reinitialized, and a new probe of the same size or any other size -# (determined by the search algorithm) can be sent. The maximum number -# of consecutive failed probes is configured (MAX_PROBES). If the -# value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and -# the PL sender enters the SEARCH_COMPLETE state. - -[[spec]] -level = "MAY" -quote = ''' -The -MAX_PLPMTU MAY be reduced by an application that sets a maximum to -the size of datagrams it will send. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/5.3.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/5.3.2.toml deleted file mode 100644 index 7bca2679fe..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/5.3.2.toml +++ /dev/null @@ -1,24 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-5.3.2" - -# 5.3.2. Selection of Probe Sizes -# -# The search algorithm determines a minimum useful gain in PLPMTU. It -# would not be constructive for a PL sender to attempt to probe for all -# sizes. This would incur unnecessary load on the path. -# Implementations SHOULD select the set of probe packet sizes to -# maximize the gain in PLPMTU from each search step. -# -# Implementations could optimize the search procedure by selecting step -# sizes from a table of common PMTU sizes. When selecting the -# appropriate next size to search, an implementer ought to also -# consider that there can be common sizes of MPS that applications seek -# to use, and there could be common sizes of MTU used within the -# network. - -[[spec]] -level = "SHOULD" -quote = ''' -Implementations SHOULD select the set of probe packet sizes to -maximize the gain in PLPMTU from each search step. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/5.toml b/specs/www.rfc-editor.org/rfc/rfc8899/5.toml deleted file mode 100644 index af74d6683f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/5.toml +++ /dev/null @@ -1,59 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-5" - -# 5. Datagram Packetization Layer PMTUD -# -# This section specifies Datagram PLPMTUD (DPLPMTUD). The method can -# be introduced at various points (as indicated with * in Figure 2) in -# the IP protocol stack to discover the PLPMTU so that an application -# can utilize an appropriate MPS for the current network path. -# -# DPLPMTUD SHOULD only be performed at one layer between a pair of -# endpoints. Therefore, an upper PL or application should avoid using -# DPLPMTUD when this is already enabled in a lower layer. A PL MUST -# adjust the MPS indicated by DPLPMTUD to account for any additional -# overhead introduced by the PL. -# -# +----------------------+ -# | Application* | -# +-----+------------+---+ -# | | -# +---+--+ +--+--+ -# | QUIC*| |SCTP*| -# +---+--+ +-+-+-+ -# | | | -# +---+ +----+ | -# | | | -# +-+--+-+ | -# | UDP | | -# +---+--+ | -# | | -# +-----------+-------+--+ -# | Network Interface | -# +----------------------+ -# -# Figure 2: Examples Where DPLPMTUD Can Be Implemented -# -# The central idea of DPLPMTUD is probing by a sender. Probe packets -# are sent to find the maximum size of user message that can be -# completely transferred across the network path from the sender to the -# destination. -# -# The following sections identify the components needed for -# implementation, provide an overview of the phases of operation, and -# specify the state machine and search algorithm. - -[[spec]] -level = "SHOULD" -quote = ''' -DPLPMTUD SHOULD only be performed at one layer between a pair of -endpoints. -''' - -[[spec]] -level = "MUST" -quote = ''' -A PL MUST -adjust the MPS indicated by DPLPMTUD to account for any additional -overhead introduced by the PL. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.1.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.1.1.toml deleted file mode 100644 index f66708ae73..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.1.toml +++ /dev/null @@ -1,20 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1.1" - -# 6.1.1. Application Request -# -# An application needs an application-layer protocol mechanism (such as -# a message acknowledgment method) that solicits a response from a -# destination endpoint. The method SHOULD allow the sender to check -# the value returned in the response to provide additional protection -# from off-path insertion of data [BCP145]. Suitable methods include a -# parameter known only to the two endpoints, such as a session ID or -# initialized sequence number. - -[[spec]] -level = "SHOULD" -quote = ''' -The method SHOULD allow the sender to check -the value returned in the response to provide additional protection -from off-path insertion of data [BCP145]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.6.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.1.6.toml deleted file mode 100644 index 660c6a52cc..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.6.toml +++ /dev/null @@ -1,28 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1.6" - -# 6.1.6. Handling of PTB Messages -# -# An application that is able and wishes to receive PTB messages MUST -# perform ICMP validation as specified in Section 5.2 of [BCP145]. -# This requires that the application checks each received PTB message -# to validate that it was is received in response to transmitted -# traffic and that the reported PL_PTB_SIZE is less than the current -# probed size (see Section 4.6.2). A validated PTB message MAY be used -# as input to the DPLPMTUD algorithm but MUST NOT be used directly to -# set the PLPMTU. - -[[spec]] -level = "MUST" -quote = ''' -An application that is able and wishes to receive PTB messages MUST -perform ICMP validation as specified in Section 5.2 of [BCP145]. -''' - -[[spec]] -level = "MUST" -quote = ''' -A validated PTB message MAY be used -as input to the DPLPMTUD algorithm but MUST NOT be used directly to -set the PLPMTU. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.1.toml deleted file mode 100644 index 1d03f8589e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.1.toml +++ /dev/null @@ -1,32 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.1" - -# 6.1. Application Support for DPLPMTUD with UDP or UDP-Lite -# -# The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do -# not define a method in the RFC series that supports PLPMTUD. In -# particular, the UDP transport does not provide the transport features -# needed to implement datagram PLPMTUD. -# -# The DPLPMTUD method can be implemented as a part of an application -# built directly or indirectly on UDP or UDP-Lite but relies on higher- -# layer protocol features to implement the method [BCP145]. -# -# Some primitives used by DPLPMTUD might not be available via the -# Datagram API (e.g., the ability to access the PLPMTU from the IP- -# layer cache or to interpret received PTB messages). -# -# In addition, it is recommended that PMTU discovery is not performed -# by multiple protocol layers. An application SHOULD avoid using -# DPLPMTUD when the underlying transport system provides this -# capability. A common method for managing the PLPMTU has benefits, -# both in the ability to share state between different processes and in -# opportunities to coordinate probing for different PL instances. - -[[spec]] -level = "SHOULD" -quote = ''' -An application SHOULD avoid using -DPLPMTUD when the underlying transport system provides this -capability. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.4.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.4.toml deleted file mode 100644 index 9daf83a6fd..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.1.4.toml +++ /dev/null @@ -1,30 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.1.4" - -# 6.2.1.4. PTB Message Handling by SCTP -# -# Normal ICMP validation MUST be performed as specified in Appendix C -# of [RFC4960]. This requires that the first 8 bytes of the SCTP -# common header are quoted in the payload of the PTB message, which can -# be the case for ICMPv4 and is normally the case for ICMPv6. -# -# When a PTB message has been validated, the PL_PTB_SIZE calculated -# from the PTB_SIZE reported in the PTB message SHOULD be used with the -# DPLPMTUD algorithm, provided that the reported PL_PTB_SIZE is less -# than the current probe size (see Section 4.6). - -[[spec]] -level = "MUST" -quote = ''' -Normal ICMP validation MUST be performed as specified in Appendix C -of [RFC4960]. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When a PTB message has been validated, the PL_PTB_SIZE calculated -from the PTB_SIZE reported in the PTB message SHOULD be used with the -DPLPMTUD algorithm, provided that the reported PL_PTB_SIZE is less -than the current probe size (see Section 4.6). -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.4.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.4.toml deleted file mode 100644 index 0f83536df1..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.4.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.2.4" - -# 6.2.2.4. Handling of PTB Messages by SCTP/UDP -# -# ICMP validation MUST be performed for PTB messages as specified in -# Appendix C of [RFC4960]. This requires that the first 8 bytes of the -# SCTP common header are contained in the PTB message, which can be the -# case for ICMPv4 (but note the UDP header also consumes a part of the -# quoted packet header) and is normally the case for ICMPv6. When the -# validation is completed, the PL_PTB_SIZE calculated from the PTB_SIZE -# in the PTB message SHOULD be used with the DPLPMTUD providing that -# the reported PL_PTB_SIZE is less than the current probe size. - -[[spec]] -level = "MUST" -quote = ''' -ICMP validation MUST be performed for PTB messages as specified in -Appendix C of [RFC4960]. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When the -validation is completed, the PL_PTB_SIZE calculated from the PTB_SIZE -in the PTB message SHOULD be used with the DPLPMTUD providing that -the reported PL_PTB_SIZE is less than the current probe size. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.toml deleted file mode 100644 index 96276e15e7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.2.toml +++ /dev/null @@ -1,21 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2.2" - -# 6.2.2. DPLPMTUD for SCTP/UDP -# -# The UDP encapsulation of SCTP is specified in [RFC6951]. -# -# This specification updates the reference to RFC 4821 in Section 5.6 -# of RFC 6951 to refer to this document (RFC 8899). RFC 6951 is -# updated by the addition of the following sentence at the end of -# Section 5.6: -# -# | The RECOMMENDED method for determining the MTU of the path is -# | specified in RFC 8899. - -[[spec]] -level = "SHOULD" -quote = ''' -| The RECOMMENDED method for determining the MTU of the path is -| specified in RFC 8899. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.toml b/specs/www.rfc-editor.org/rfc/rfc8899/6.2.toml deleted file mode 100644 index ea99ffc106..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/6.2.toml +++ /dev/null @@ -1,42 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-6.2" - -# 6.2. DPLPMTUD for SCTP -# -# Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing -# method for SCTP, and Section 7.3 of [RFC4960] recommends an endpoint -# apply the techniques in RFC 4821 on a per-destination-address basis. -# The specification for DPLPMTUD continues the practice of using the PL -# to discover the PMTU but updates RFC4960 with a recommendation to use -# the method specified in this document: The RECOMMENDED method for -# generating probes is to add a chunk consisting only of padding to an -# SCTP message. The PAD chunk defined in [RFC4820] SHOULD be attached -# to a minimum-length HEARTBEAT (HB) chunk to build a probe packet. -# This enables probing without affecting the transfer of user messages -# and without being limited by congestion control or flow control. -# This is preferred to using DATA chunks (with padding as required) as -# path probes. -# -# Section 6.9 of [RFC4960] describes dividing the user messages into -# DATA chunks sent by the PL when using SCTP. This notes that once an -# SCTP message has been sent, it cannot be resegmented. [RFC4960] -# describes the method for retransmitting DATA chunks when the MPS has -# been reduced, and Section 6.9 of [RFC4960] describes use of IP -# fragmentation for this case. This is unchanged by this document. - -[[spec]] -level = "SHOULD" -quote = ''' -The specification for DPLPMTUD continues the practice of using the PL -to discover the PMTU but updates RFC4960 with a recommendation to use -the method specified in this document: The RECOMMENDED method for -generating probes is to add a chunk consisting only of padding to an -SCTP message. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The PAD chunk defined in [RFC4820] SHOULD be attached -to a minimum-length HEARTBEAT (HB) chunk to build a probe packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc8899/8.toml b/specs/www.rfc-editor.org/rfc/rfc8899/8.toml deleted file mode 100644 index a701f1f766..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc8899/8.toml +++ /dev/null @@ -1,110 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc8899#section-8" - -# 8. Security Considerations -# -# The security considerations for the use of UDP and SCTP are provided -# in the referenced RFCs. -# -# To avoid excessive load, the interval between individual probe -# packets MUST be at least one RTT, and the interval between rounds of -# probing is determined by the PMTU_RAISE_TIMER. -# -# A PL sender needs to ensure that the method used to confirm reception -# of probe packets protects from off-path attackers injecting packets -# into the path. This protection is provided in IETF-defined protocols -# (e.g., TCP, SCTP) using a randomly initialized sequence number. A -# description of one way to do this when using UDP is provided in -# Section 5.1 of [BCP145]). -# -# There are cases where ICMP Packet Too Big (PTB) messages are not -# delivered due to policy, configuration, or equipment design (see -# Section 1.1). This method therefore does not rely upon PTB messages -# being received but is able to utilize these when they are received by -# the sender. PTB messages could potentially be used to cause a node -# to inappropriately reduce the PLPMTU. A node supporting DPLPMTUD -# MUST therefore appropriately validate the payload of PTB messages to -# ensure these are received in response to transmitted traffic (i.e., a -# reported error condition that corresponds to a datagram actually sent -# by the path layer, see Section 4.6.1). -# -# An on-path attacker able to create a PTB message could forge PTB -# messages that include a valid quoted IP packet. Such an attack could -# be used to drive down the PLPMTU. An on-path device could similarly -# force a reduction of the PLPMTU by implementing a policy that drops -# packets larger than a configured size. There are two ways this -# method can be mitigated against such attacks: first, by ensuring that -# a PL sender never reduces the PLPMTU below the base size solely in -# response to receiving a PTB message. This is achieved by first -# entering the BASE state when such a message is received. Second, the -# design does not require processing of PTB messages; a PL sender could -# therefore suspend processing of PTB messages (e.g., in a robustness -# mode after detecting that subsequent probes actually confirm that a -# size larger than the PTB_SIZE is supported by a path). -# -# Parsing the quoted packet inside a PTB message can introduce -# additional per-packet processing at the PL sender. This processing -# SHOULD be limited to avoid a denial-of-service attack when arbitrary -# headers are included. Rate-limiting the processing could result in -# PTB messages not being received by a PL; however, the DPLPMTUD method -# is robust to such loss. -# -# The successful processing of an ICMP message can trigger a probe when -# the reported PTB size is valid, but this does not directly update the -# PLPMTU for the path. This prevents a message attempting to black -# hole data by indicating a size larger than supported by the path. -# -# It is possible that the information about a path is not stable. This -# could be a result of forwarding across more than one path that has a -# different actual PMTU or a single path presents a varying PMTU. The -# design of a PLPMTUD implementation SHOULD consider how to mitigate -# the effects of varying path information. One possible mitigation is -# to provide robustness (see Section 5.4) in the method that avoids -# oscillation in the MPS. -# -# DPLPMTUD methods can introduce padding data to inflate the length of -# the datagram to the total size required for a probe packet. The -# total size of a probe packet includes all headers and padding added -# to the payload data being sent (e.g., including security-related -# fields such as an AEAD tag and TLS record layer padding). The value -# of the padding data does not influence the DPLPMTUD search algorithm, -# and therefore needs to be set consistent with the policy of the PL. -# -# If a PL can make use of cryptographic confidentiality or data- -# integrity mechanisms, then the design ought to avoid adding anything -# (e.g., padding) to DPLPMTUD probe packets that is not also protected -# by those cryptographic mechanisms. - -[[spec]] -level = "MUST" -quote = ''' -To avoid excessive load, the interval between individual probe -packets MUST be at least one RTT, and the interval between rounds of -probing is determined by the PMTU_RAISE_TIMER. -''' - -[[spec]] -level = "MUST" -quote = ''' -A node supporting DPLPMTUD -MUST therefore appropriately validate the payload of PTB messages to -ensure these are received in response to transmitted traffic (i.e., a -reported error condition that corresponds to a datagram actually sent -by the path layer, see Section 4.6.1). -''' - -[[spec]] -level = "SHOULD" -quote = ''' -This processing -SHOULD be limited to avoid a denial-of-service attack when arbitrary -headers are included. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The -design of a PLPMTUD implementation SHOULD consider how to mitigate -the effects of varying path information. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.1.2.toml deleted file mode 100644 index 1ba0c94876..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.1.2.toml +++ /dev/null @@ -1,39 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.1.2" - -# 10.1.2. Deferring Idle Timeout -# -# An endpoint might need to send ack-eliciting packets to avoid an idle -# timeout if it is expecting response data but does not have or is -# unable to send application data. -# -# An implementation of QUIC might provide applications with an option -# to defer an idle timeout. This facility could be used when the -# application wishes to avoid losing state that has been associated -# with an open connection but does not expect to exchange application -# data for some time. With this option, an endpoint could send a PING -# frame (Section 19.2) periodically, which will cause the peer to -# restart its idle timeout period. Sending a packet containing a PING -# frame restarts the idle timeout for this endpoint also if this is the -# first ack-eliciting packet sent since receiving a packet. Sending a -# PING frame causes the peer to respond with an acknowledgment, which -# also restarts the idle timeout for the endpoint. -# -# Application protocols that use QUIC SHOULD provide guidance on when -# deferring an idle timeout is appropriate. Unnecessary sending of -# PING frames could have a detrimental effect on performance. -# -# A connection will time out if no packets are sent or received for a -# period longer than the time negotiated using the max_idle_timeout -# transport parameter; see Section 10. However, state in middleboxes -# might time out earlier than that. Though REQ-5 in [RFC4787] -# recommends a 2-minute timeout interval, experience shows that sending -# packets every 30 seconds is necessary to prevent the majority of -# middleboxes from losing state for UDP flows [GATEWAY]. - -[[spec]] -level = "SHOULD" -quote = ''' -Application protocols that use QUIC SHOULD provide guidance on when -deferring an idle timeout is appropriate. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.1.toml deleted file mode 100644 index 999fa78f8d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.1.toml +++ /dev/null @@ -1,38 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.1" - -# 10.1. Idle Timeout -# -# If a max_idle_timeout is specified by either endpoint in its -# transport parameters (Section 18.2), the connection is silently -# closed and its state is discarded when it remains idle for longer -# than the minimum of the max_idle_timeout value advertised by both -# endpoints. -# -# Each endpoint advertises a max_idle_timeout, but the effective value -# at an endpoint is computed as the minimum of the two advertised -# values (or the sole advertised value, if only one endpoint advertises -# a non-zero value). By announcing a max_idle_timeout, an endpoint -# commits to initiating an immediate close (Section 10.2) if it -# abandons the connection prior to the effective value. -# -# An endpoint restarts its idle timer when a packet from its peer is -# received and processed successfully. An endpoint also restarts its -# idle timer when sending an ack-eliciting packet if no other ack- -# eliciting packets have been sent since last receiving and processing -# a packet. Restarting this timer when sending a packet ensures that -# connections are not closed after new activity is initiated. -# -# To avoid excessively small idle timeout periods, endpoints MUST -# increase the idle timeout period to be at least three times the -# current Probe Timeout (PTO). This allows for multiple PTOs to -# expire, and therefore multiple probes to be sent and lost, prior to -# idle timeout. - -[[spec]] -level = "MUST" -quote = ''' -To avoid excessively small idle timeout periods, endpoints MUST -increase the idle timeout period to be at least three times the -current Probe Timeout (PTO). -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.2.1.toml deleted file mode 100644 index 31f0db3540..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.1.toml +++ /dev/null @@ -1,114 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2.1" - -# 10.2.1. Closing Connection State -# -# An endpoint enters the closing state after initiating an immediate -# close. -# -# In the closing state, an endpoint retains only enough information to -# generate a packet containing a CONNECTION_CLOSE frame and to identify -# packets as belonging to the connection. An endpoint in the closing -# state sends a packet containing a CONNECTION_CLOSE frame in response -# to any incoming packet that it attributes to the connection. -# -# An endpoint SHOULD limit the rate at which it generates packets in -# the closing state. For instance, an endpoint could wait for a -# progressively increasing number of received packets or amount of time -# before responding to received packets. -# -# An endpoint's selected connection ID and the QUIC version are -# sufficient information to identify packets for a closing connection; -# the endpoint MAY discard all other connection state. An endpoint -# that is closing is not required to process any received frame. An -# endpoint MAY retain packet protection keys for incoming packets to -# allow it to read and process a CONNECTION_CLOSE frame. -# -# An endpoint MAY drop packet protection keys when entering the closing -# state and send a packet containing a CONNECTION_CLOSE frame in -# response to any UDP datagram that is received. However, an endpoint -# that discards packet protection keys cannot identify and discard -# invalid packets. To avoid being used for an amplification attack, -# such endpoints MUST limit the cumulative size of packets it sends to -# three times the cumulative size of the packets that are received and -# attributed to the connection. To minimize the state that an endpoint -# maintains for a closing connection, endpoints MAY send the exact same -# packet in response to any received packet. -# -# | Note: Allowing retransmission of a closing packet is an -# | exception to the requirement that a new packet number be used -# | for each packet; see Section 12.3. Sending new packet numbers -# | is primarily of advantage to loss recovery and congestion -# | control, which are not expected to be relevant for a closed -# | connection. Retransmitting the final packet requires less -# | state. -# -# While in the closing state, an endpoint could receive packets from a -# new source address, possibly indicating a connection migration; see -# Section 9. An endpoint in the closing state MUST either discard -# packets received from an unvalidated address or limit the cumulative -# size of packets it sends to an unvalidated address to three times the -# size of packets it receives from that address. -# -# An endpoint is not expected to handle key updates when it is closing -# (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint -# from moving from the closing state to the draining state, as the -# endpoint will not be able to process subsequently received packets, -# but it otherwise has no impact. - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD limit the rate at which it generates packets in -the closing state. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint's selected connection ID and the QUIC version are -sufficient information to identify packets for a closing connection; -the endpoint MAY discard all other connection state. -''' - -[[spec]] -level = "MAY" -quote = ''' -An -endpoint MAY retain packet protection keys for incoming packets to -allow it to read and process a CONNECTION_CLOSE frame. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY drop packet protection keys when entering the closing -state and send a packet containing a CONNECTION_CLOSE frame in -response to any UDP datagram that is received. -''' - -[[spec]] -level = "MUST" -quote = ''' -To avoid being used for an amplification attack, -such endpoints MUST limit the cumulative size of packets it sends to -three times the cumulative size of the packets that are received and -attributed to the connection. -''' - -[[spec]] -level = "MAY" -quote = ''' -To minimize the state that an endpoint -maintains for a closing connection, endpoints MAY send the exact same -packet in response to any received packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint in the closing state MUST either discard -packets received from an unvalidated address or limit the cumulative -size of packets it sends to an unvalidated address to three times the -size of packets it receives from that address. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.2.2.toml deleted file mode 100644 index 98d4f6ed67..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.2.toml +++ /dev/null @@ -1,55 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2.2" - -# 10.2.2. Draining Connection State -# -# The draining state is entered once an endpoint receives a -# CONNECTION_CLOSE frame, which indicates that its peer is closing or -# draining. While otherwise identical to the closing state, an -# endpoint in the draining state MUST NOT send any packets. Retaining -# packet protection keys is unnecessary once a connection is in the -# draining state. -# -# An endpoint that receives a CONNECTION_CLOSE frame MAY send a single -# packet containing a CONNECTION_CLOSE frame before entering the -# draining state, using a NO_ERROR code if appropriate. An endpoint -# MUST NOT send further packets. Doing so could result in a constant -# exchange of CONNECTION_CLOSE frames until one of the endpoints exits -# the closing state. -# -# An endpoint MAY enter the draining state from the closing state if it -# receives a CONNECTION_CLOSE frame, which indicates that the peer is -# also closing or draining. In this case, the draining state ends when -# the closing state would have ended. In other words, the endpoint -# uses the same end time but ceases transmission of any packets on this -# connection. - -[[spec]] -level = "MUST" -quote = ''' -While otherwise identical to the closing state, an -endpoint in the draining state MUST NOT send any packets. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint that receives a CONNECTION_CLOSE frame MAY send a single -packet containing a CONNECTION_CLOSE frame before entering the -draining state, using a NO_ERROR code if appropriate. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint -MUST NOT send further packets. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY enter the draining state from the closing state if it -receives a CONNECTION_CLOSE frame, which indicates that the peer is -also closing or draining. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.2.3.toml deleted file mode 100644 index b815c9958d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.3.toml +++ /dev/null @@ -1,131 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2.3" - -# 10.2.3. Immediate Close during the Handshake -# -# When sending a CONNECTION_CLOSE frame, the goal is to ensure that the -# peer will process the frame. Generally, this means sending the frame -# in a packet with the highest level of packet protection to avoid the -# packet being discarded. After the handshake is confirmed (see -# Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any -# CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to -# confirming the handshake, it is possible that more advanced packet -# protection keys are not available to the peer, so another -# CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower -# packet protection level. More specifically: -# -# * A client will always know whether the server has Handshake keys -# (see Section 17.2.2.1), but it is possible that a server does not -# know whether the client has Handshake keys. Under these -# circumstances, a server SHOULD send a CONNECTION_CLOSE frame in -# both Handshake and Initial packets to ensure that at least one of -# them is processable by the client. -# -# * A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet -# cannot be assured that the server has accepted 0-RTT. Sending a -# CONNECTION_CLOSE frame in an Initial packet makes it more likely -# that the server can receive the close signal, even if the -# application error code might not be received. -# -# * Prior to confirming the handshake, a peer might be unable to -# process 1-RTT packets, so an endpoint SHOULD send a -# CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A -# server SHOULD also send a CONNECTION_CLOSE frame in an Initial -# packet. -# -# Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake -# packet could expose application state or be used to alter application -# state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a -# CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or -# Handshake packets. Otherwise, information about the application -# state might be revealed. Endpoints MUST clear the value of the -# Reason Phrase field and SHOULD use the APPLICATION_ERROR code when -# converting to a CONNECTION_CLOSE of type 0x1c. -# -# CONNECTION_CLOSE frames sent in multiple packet types can be -# coalesced into a single UDP datagram; see Section 12.2. -# -# An endpoint can send a CONNECTION_CLOSE frame in an Initial packet. -# This might be in response to unauthenticated information received in -# Initial or Handshake packets. Such an immediate close might expose -# legitimate connections to a denial of service. QUIC does not include -# defensive measures for on-path attacks during the handshake; see -# Section 21.2. However, at the cost of reducing feedback about errors -# for legitimate peers, some forms of denial of service can be made -# more difficult for an attacker if endpoints discard illegal packets -# rather than terminating a connection with CONNECTION_CLOSE. For this -# reason, endpoints MAY discard packets rather than immediately close -# if errors are detected in packets that lack authentication. -# -# An endpoint that has not established state, such as a server that -# detects an error in an Initial packet, does not enter the closing -# state. An endpoint that has no state for the connection does not -# enter a closing or draining period on sending a CONNECTION_CLOSE -# frame. - -[[spec]] -level = "MUST" -quote = ''' -After the handshake is confirmed (see -Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any -CONNECTION_CLOSE frames in a 1-RTT packet. -''' - -[[spec]] -level = "MAY" -quote = ''' -However, prior to -confirming the handshake, it is possible that more advanced packet -protection keys are not available to the peer, so another -CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower -packet protection level. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Under these -circumstances, a server SHOULD send a CONNECTION_CLOSE frame in -both Handshake and Initial packets to ensure that at least one of -them is processable by the client. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -* Prior to confirming the handshake, a peer might be unable to -process 1-RTT packets, so an endpoint SHOULD send a -CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A -server SHOULD also send a CONNECTION_CLOSE frame in an Initial -packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -A CONNECTION_CLOSE of type 0x1d MUST be replaced by a -CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or -Handshake packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST clear the value of the -Reason Phrase field and SHOULD use the APPLICATION_ERROR code when -converting to a CONNECTION_CLOSE of type 0x1c. -''' - -[[spec]] -level = "MAY" -quote = ''' -For this -reason, endpoints MAY discard packets rather than immediately close -if errors are detected in packets that lack authentication. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.2.toml deleted file mode 100644 index 9d470f9dea..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.2.toml +++ /dev/null @@ -1,85 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.2" - -# 10.2. Immediate Close -# -# An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to -# terminate the connection immediately. A CONNECTION_CLOSE frame -# causes all streams to immediately become closed; open streams can be -# assumed to be implicitly reset. -# -# After sending a CONNECTION_CLOSE frame, an endpoint immediately -# enters the closing state; see Section 10.2.1. After receiving a -# CONNECTION_CLOSE frame, endpoints enter the draining state; see -# Section 10.2.2. -# -# Violations of the protocol lead to an immediate close. -# -# An immediate close can be used after an application protocol has -# arranged to close a connection. This might be after the application -# protocol negotiates a graceful shutdown. The application protocol -# can exchange messages that are needed for both application endpoints -# to agree that the connection can be closed, after which the -# application requests that QUIC close the connection. When QUIC -# consequently closes the connection, a CONNECTION_CLOSE frame with an -# application-supplied error code will be used to signal closure to the -# peer. -# -# The closing and draining connection states exist to ensure that -# connections close cleanly and that delayed or reordered packets are -# properly discarded. These states SHOULD persist for at least three -# times the current PTO interval as defined in [QUIC-RECOVERY]. -# -# Disposing of connection state prior to exiting the closing or -# draining state could result in an endpoint generating a Stateless -# Reset unnecessarily when it receives a late-arriving packet. -# Endpoints that have some alternative means to ensure that late- -# arriving packets do not induce a response, such as those that are -# able to close the UDP socket, MAY end these states earlier to allow -# for faster resource recovery. Servers that retain an open socket for -# accepting new connections SHOULD NOT end the closing or draining -# state early. -# -# Once its closing or draining state ends, an endpoint SHOULD discard -# all connection state. The endpoint MAY send a Stateless Reset in -# response to any further incoming packets belonging to this -# connection. - -[[spec]] -level = "SHOULD" -quote = ''' -These states SHOULD persist for at least three -times the current PTO interval as defined in [QUIC-RECOVERY]. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints that have some alternative means to ensure that late- -arriving packets do not induce a response, such as those that are -able to close the UDP socket, MAY end these states earlier to allow -for faster resource recovery. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Servers that retain an open socket for -accepting new connections SHOULD NOT end the closing or draining -state early. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Once its closing or draining state ends, an endpoint SHOULD discard -all connection state. -''' - -[[spec]] -level = "MAY" -quote = ''' -The endpoint MAY send a Stateless Reset in -response to any further incoming packets belonging to this -connection. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.3.1.toml deleted file mode 100644 index 752a41013e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.1.toml +++ /dev/null @@ -1,82 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.1" - -# 10.3.1. Detecting a Stateless Reset -# -# An endpoint detects a potential Stateless Reset using the trailing 16 -# bytes of the UDP datagram. An endpoint remembers all stateless reset -# tokens associated with the connection IDs and remote addresses for -# datagrams it has recently sent. This includes Stateless Reset Token -# field values from NEW_CONNECTION_ID frames and the server's transport -# parameters but excludes stateless reset tokens associated with -# connection IDs that are either unused or retired. The endpoint -# identifies a received datagram as a Stateless Reset by comparing the -# last 16 bytes of the datagram with all stateless reset tokens -# associated with the remote address on which the datagram was -# received. -# -# This comparison can be performed for every inbound datagram. -# Endpoints MAY skip this check if any packet from a datagram is -# successfully processed. However, the comparison MUST be performed -# when the first packet in an incoming datagram either cannot be -# associated with a connection or cannot be decrypted. -# -# An endpoint MUST NOT check for any stateless reset tokens associated -# with connection IDs it has not used or for connection IDs that have -# been retired. -# -# When comparing a datagram to stateless reset token values, endpoints -# MUST perform the comparison without leaking information about the -# value of the token. For example, performing this comparison in -# constant time protects the value of individual stateless reset tokens -# from information leakage through timing side channels. Another -# approach would be to store and compare the transformed values of -# stateless reset tokens instead of the raw token values, where the -# transformation is defined as a cryptographically secure pseudorandom -# function using a secret key (e.g., block cipher, Hashed Message -# Authentication Code (HMAC) [RFC2104]). An endpoint is not expected -# to protect information about whether a packet was successfully -# decrypted or the number of valid stateless reset tokens. -# -# If the last 16 bytes of the datagram are identical in value to a -# stateless reset token, the endpoint MUST enter the draining period -# and not send any further packets on this connection. - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY skip this check if any packet from a datagram is -successfully processed. -''' - -[[spec]] -level = "MUST" -quote = ''' -However, the comparison MUST be performed -when the first packet in an incoming datagram either cannot be -associated with a connection or cannot be decrypted. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT check for any stateless reset tokens associated -with connection IDs it has not used or for connection IDs that have -been retired. -''' - -[[spec]] -level = "MUST" -quote = ''' -When comparing a datagram to stateless reset token values, endpoints -MUST perform the comparison without leaking information about the -value of the token. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the last 16 bytes of the datagram are identical in value to a -stateless reset token, the endpoint MUST enter the draining period -and not send any further packets on this connection. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.3.2.toml deleted file mode 100644 index 1468f36ef9..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.2.toml +++ /dev/null @@ -1,98 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.2" - -# 10.3.2. Calculating a Stateless Reset Token -# -# The stateless reset token MUST be difficult to guess. In order to -# create a stateless reset token, an endpoint could randomly generate -# [RANDOM] a secret for every connection that it creates. However, -# this presents a coordination problem when there are multiple -# instances in a cluster or a storage problem for an endpoint that -# might lose state. Stateless reset specifically exists to handle the -# case where state is lost, so this approach is suboptimal. -# -# A single static key can be used across all connections to the same -# endpoint by generating the proof using a pseudorandom function that -# takes a static key and the connection ID chosen by the endpoint (see -# Section 5.1) as input. An endpoint could use HMAC [RFC2104] (for -# example, HMAC(static_key, connection_id)) or the HMAC-based Key -# Derivation Function (HKDF) [RFC5869] (for example, using the static -# key as input keying material, with the connection ID as salt). The -# output of this function is truncated to 16 bytes to produce the -# stateless reset token for that connection. -# -# An endpoint that loses state can use the same method to generate a -# valid stateless reset token. The connection ID comes from the packet -# that the endpoint receives. -# -# This design relies on the peer always sending a connection ID in its -# packets so that the endpoint can use the connection ID from a packet -# to reset the connection. An endpoint that uses this design MUST -# either use the same connection ID length for all connections or -# encode the length of the connection ID such that it can be recovered -# without state. In addition, it cannot provide a zero-length -# connection ID. -# -# Revealing the stateless reset token allows any entity to terminate -# the connection, so a value can only be used once. This method for -# choosing the stateless reset token means that the combination of -# connection ID and static key MUST NOT be used for another connection. -# A denial-of-service attack is possible if the same connection ID is -# used by instances that share a static key or if an attacker can cause -# a packet to be routed to an instance that has no state but the same -# static key; see Section 21.11. A connection ID from a connection -# that is reset by revealing the stateless reset token MUST NOT be -# reused for new connections at nodes that share a static key. -# -# The same stateless reset token MUST NOT be used for multiple -# connection IDs. Endpoints are not required to compare new values -# against all previous values, but a duplicate value MAY be treated as -# a connection error of type PROTOCOL_VIOLATION. -# -# Note that Stateless Resets do not have any cryptographic protection. - -[[spec]] -level = "MUST" -quote = ''' -The stateless reset token MUST be difficult to guess. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that uses this design MUST -either use the same connection ID length for all connections or -encode the length of the connection ID such that it can be recovered -without state. -''' - -[[spec]] -level = "MUST" -quote = ''' -This method for -choosing the stateless reset token means that the combination of -connection ID and static key MUST NOT be used for another connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -A connection ID from a connection -that is reset by revealing the stateless reset token MUST NOT be -reused for new connections at nodes that share a static key. -''' - -[[spec]] -level = "MUST" -quote = ''' -The same stateless reset token MUST NOT be used for multiple -connection IDs. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints are not required to compare new values -against all previous values, but a duplicate value MAY be treated as -a connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.3.3.toml deleted file mode 100644 index ea6b7b53e3..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.3.toml +++ /dev/null @@ -1,37 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.3" - -# 10.3.3. Looping -# -# The design of a Stateless Reset is such that without knowing the -# stateless reset token it is indistinguishable from a valid packet. -# For instance, if a server sends a Stateless Reset to another server, -# it might receive another Stateless Reset in response, which could -# lead to an infinite exchange. -# -# An endpoint MUST ensure that every Stateless Reset that it sends is -# smaller than the packet that triggered it, unless it maintains state -# sufficient to prevent looping. In the event of a loop, this results -# in packets eventually being too small to trigger a response. -# -# An endpoint can remember the number of Stateless Resets that it has -# sent and stop generating new Stateless Resets once a limit is -# reached. Using separate limits for different remote addresses will -# ensure that Stateless Resets can be used to close connections when -# other peers or connections have exhausted limits. -# -# A Stateless Reset that is smaller than 41 bytes might be identifiable -# as a Stateless Reset by an observer, depending upon the length of the -# peer's connection IDs. Conversely, not sending a Stateless Reset in -# response to a small packet might result in Stateless Resets not being -# useful in detecting cases of broken connections where only very small -# packets are sent; such failures might only be detected by other -# means, such as timers. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST ensure that every Stateless Reset that it sends is -smaller than the packet that triggered it, unless it maintains state -sufficient to prevent looping. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.3.toml deleted file mode 100644 index ee7d1e854c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.3.toml +++ /dev/null @@ -1,214 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3" - -# 10.3. Stateless Reset -# -# A stateless reset is provided as an option of last resort for an -# endpoint that does not have access to the state of a connection. A -# crash or outage might result in peers continuing to send data to an -# endpoint that is unable to properly continue the connection. An -# endpoint MAY send a Stateless Reset in response to receiving a packet -# that it cannot associate with an active connection. -# -# A stateless reset is not appropriate for indicating errors in active -# connections. An endpoint that wishes to communicate a fatal -# connection error MUST use a CONNECTION_CLOSE frame if it is able. -# -# To support this process, an endpoint issues a stateless reset token, -# which is a 16-byte value that is hard to guess. If the peer -# subsequently receives a Stateless Reset, which is a UDP datagram that -# ends in that stateless reset token, the peer will immediately end the -# connection. -# -# A stateless reset token is specific to a connection ID. An endpoint -# issues a stateless reset token by including the value in the -# Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers -# can also issue a stateless_reset_token transport parameter during the -# handshake that applies to the connection ID that it selected during -# the handshake. These exchanges are protected by encryption, so only -# client and server know their value. Note that clients cannot use the -# stateless_reset_token transport parameter because their transport -# parameters do not have confidentiality protection. -# -# Tokens are invalidated when their associated connection ID is retired -# via a RETIRE_CONNECTION_ID frame (Section 19.16). -# -# An endpoint that receives packets that it cannot process sends a -# packet in the following layout (see Section 1.3): -# -# Stateless Reset { -# Fixed Bits (2) = 1, -# Unpredictable Bits (38..), -# Stateless Reset Token (128), -# } -# -# Figure 10: Stateless Reset -# -# This design ensures that a Stateless Reset is -- to the extent -# possible -- indistinguishable from a regular packet with a short -# header. -# -# A Stateless Reset uses an entire UDP datagram, starting with the -# first two bits of the packet header. The remainder of the first byte -# and an arbitrary number of bytes following it are set to values that -# SHOULD be indistinguishable from random. The last 16 bytes of the -# datagram contain a stateless reset token. -# -# To entities other than its intended recipient, a Stateless Reset will -# appear to be a packet with a short header. For the Stateless Reset -# to appear as a valid QUIC packet, the Unpredictable Bits field needs -# to include at least 38 bits of data (or 5 bytes, less the two fixed -# bits). -# -# The resulting minimum size of 21 bytes does not guarantee that a -# Stateless Reset is difficult to distinguish from other packets if the -# recipient requires the use of a connection ID. To achieve that end, -# the endpoint SHOULD ensure that all packets it sends are at least 22 -# bytes longer than the minimum connection ID length that it requests -# the peer to include in its packets, adding PADDING frames as -# necessary. This ensures that any Stateless Reset sent by the peer is -# indistinguishable from a valid packet sent to the endpoint. An -# endpoint that sends a Stateless Reset in response to a packet that is -# 43 bytes or shorter SHOULD send a Stateless Reset that is one byte -# shorter than the packet it responds to. -# -# These values assume that the stateless reset token is the same length -# as the minimum expansion of the packet protection AEAD. Additional -# unpredictable bytes are necessary if the endpoint could have -# negotiated a packet protection scheme with a larger minimum -# expansion. -# -# An endpoint MUST NOT send a Stateless Reset that is three times or -# more larger than the packet it receives to avoid being used for -# amplification. Section 10.3.3 describes additional limits on -# Stateless Reset size. -# -# Endpoints MUST discard packets that are too small to be valid QUIC -# packets. To give an example, with the set of AEAD functions defined -# in [QUIC-TLS], short header packets that are smaller than 21 bytes -# are never valid. -# -# Endpoints MUST send Stateless Resets formatted as a packet with a -# short header. However, endpoints MUST treat any packet ending in a -# valid stateless reset token as a Stateless Reset, as other QUIC -# versions might allow the use of a long header. -# -# An endpoint MAY send a Stateless Reset in response to a packet with a -# long header. Sending a Stateless Reset is not effective prior to the -# stateless reset token being available to a peer. In this QUIC -# version, packets with a long header are only used during connection -# establishment. Because the stateless reset token is not available -# until connection establishment is complete or near completion, -# ignoring an unknown packet with a long header might be as effective -# as sending a Stateless Reset. -# -# An endpoint cannot determine the Source Connection ID from a packet -# with a short header; therefore, it cannot set the Destination -# Connection ID in the Stateless Reset. The Destination Connection ID -# will therefore differ from the value used in previous packets. A -# random Destination Connection ID makes the connection ID appear to be -# the result of moving to a new connection ID that was provided using a -# NEW_CONNECTION_ID frame; see Section 19.15. -# -# Using a randomized connection ID results in two problems: -# -# * The packet might not reach the peer. If the Destination -# Connection ID is critical for routing toward the peer, then this -# packet could be incorrectly routed. This might also trigger -# another Stateless Reset in response; see Section 10.3.3. A -# Stateless Reset that is not correctly routed is an ineffective -# error detection and recovery mechanism. In this case, endpoints -# will need to rely on other methods -- such as timers -- to detect -# that the connection has failed. -# -# * The randomly generated connection ID can be used by entities other -# than the peer to identify this as a potential Stateless Reset. An -# endpoint that occasionally uses different connection IDs might -# introduce some uncertainty about this. -# -# This stateless reset design is specific to QUIC version 1. An -# endpoint that supports multiple versions of QUIC needs to generate a -# Stateless Reset that will be accepted by peers that support any -# version that the endpoint might support (or might have supported -# prior to losing state). Designers of new versions of QUIC need to be -# aware of this and either (1) reuse this design or (2) use a portion -# of the packet other than the last 16 bytes for carrying data. - -[[spec]] -level = "MAY" -quote = ''' -An -endpoint MAY send a Stateless Reset in response to receiving a packet -that it cannot associate with an active connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that wishes to communicate a fatal -connection error MUST use a CONNECTION_CLOSE frame if it is able. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The remainder of the first byte -and an arbitrary number of bytes following it are set to values that -SHOULD be indistinguishable from random. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -To achieve that end, -the endpoint SHOULD ensure that all packets it sends are at least 22 -bytes longer than the minimum connection ID length that it requests -the peer to include in its packets, adding PADDING frames as -necessary. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An -endpoint that sends a Stateless Reset in response to a packet that is -43 bytes or shorter SHOULD send a Stateless Reset that is one byte -shorter than the packet it responds to. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send a Stateless Reset that is three times or -more larger than the packet it receives to avoid being used for -amplification. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST discard packets that are too small to be valid QUIC -packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST send Stateless Resets formatted as a packet with a -short header. -''' - -[[spec]] -level = "MUST" -quote = ''' -However, endpoints MUST treat any packet ending in a -valid stateless reset token as a Stateless Reset, as other QUIC -versions might allow the use of a long header. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY send a Stateless Reset in response to a packet with a -long header. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/10.toml b/specs/www.rfc-editor.org/rfc/rfc9000/10.toml deleted file mode 100644 index 5fa40c900f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/10.toml +++ /dev/null @@ -1,23 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-10" - -# 10. Connection Termination -# -# An established QUIC connection can be terminated in one of three -# ways: -# -# * idle timeout (Section 10.1) -# -# * immediate close (Section 10.2) -# -# * stateless reset (Section 10.3) -# -# An endpoint MAY discard connection state if it does not have a -# validated path on which it can send packets; see Section 8.2. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY discard connection state if it does not have a -validated path on which it can send packets; see Section 8.2. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/11.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/11.1.toml deleted file mode 100644 index 9798f25c93..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/11.1.toml +++ /dev/null @@ -1,62 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-11.1" - -# 11.1. Connection Errors -# -# Errors that result in the connection being unusable, such as an -# obvious violation of protocol semantics or corruption of state that -# affects an entire connection, MUST be signaled using a -# CONNECTION_CLOSE frame (Section 19.19). -# -# Application-specific protocol errors are signaled using the -# CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are -# specific to the transport, including all those described in this -# document, are carried in the CONNECTION_CLOSE frame with a frame type -# of 0x1c. -# -# A CONNECTION_CLOSE frame could be sent in a packet that is lost. An -# endpoint SHOULD be prepared to retransmit a packet containing a -# CONNECTION_CLOSE frame if it receives more packets on a terminated -# connection. Limiting the number of retransmissions and the time over -# which this final packet is sent limits the effort expended on -# terminated connections. -# -# An endpoint that chooses not to retransmit packets containing a -# CONNECTION_CLOSE frame risks a peer missing the first such packet. -# The only mechanism available to an endpoint that continues to receive -# data for a terminated connection is to attempt the stateless reset -# process (Section 10.3). -# -# As the AEAD for Initial packets does not provide strong -# authentication, an endpoint MAY discard an invalid Initial packet. -# Discarding an Initial packet is permitted even where this -# specification otherwise mandates a connection error. An endpoint can -# only discard a packet if it does not process the frames in the packet -# or reverts the effects of any processing. Discarding invalid Initial -# packets might be used to reduce exposure to denial of service; see -# Section 21.2. - -[[spec]] -level = "MUST" -quote = ''' -Errors that result in the connection being unusable, such as an -obvious violation of protocol semantics or corruption of state that -affects an entire connection, MUST be signaled using a -CONNECTION_CLOSE frame (Section 19.19). -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An -endpoint SHOULD be prepared to retransmit a packet containing a -CONNECTION_CLOSE frame if it receives more packets on a terminated -connection. -''' - -[[spec]] -level = "MAY" -quote = ''' -As the AEAD for Initial packets does not provide strong -authentication, an endpoint MAY discard an invalid Initial packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/11.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/11.2.toml deleted file mode 100644 index 6ed171fd98..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/11.2.toml +++ /dev/null @@ -1,38 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-11.2" - -# 11.2. Stream Errors -# -# If an application-level error affects a single stream but otherwise -# leaves the connection in a recoverable state, the endpoint can send a -# RESET_STREAM frame (Section 19.4) with an appropriate error code to -# terminate just the affected stream. -# -# Resetting a stream without the involvement of the application -# protocol could cause the application protocol to enter an -# unrecoverable state. RESET_STREAM MUST only be instigated by the -# application protocol that uses QUIC. -# -# The semantics of the application error code carried in RESET_STREAM -# are defined by the application protocol. Only the application -# protocol is able to cause a stream to be terminated. A local -# instance of the application protocol uses a direct API call, and a -# remote instance uses the STOP_SENDING frame, which triggers an -# automatic RESET_STREAM. -# -# Application protocols SHOULD define rules for handling streams that -# are prematurely canceled by either endpoint. - -[[spec]] -level = "MUST" -quote = ''' -RESET_STREAM MUST only be instigated by the -application protocol that uses QUIC. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Application protocols SHOULD define rules for handling streams that -are prematurely canceled by either endpoint. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/11.toml b/specs/www.rfc-editor.org/rfc/rfc9000/11.toml deleted file mode 100644 index bbecc8f7d9..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/11.toml +++ /dev/null @@ -1,55 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-11" - -# 11. Error Handling -# -# An endpoint that detects an error SHOULD signal the existence of that -# error to its peer. Both transport-level and application-level errors -# can affect an entire connection; see Section 11.1. Only application- -# level errors can be isolated to a single stream; see Section 11.2. -# -# The most appropriate error code (Section 20) SHOULD be included in -# the frame that signals the error. Where this specification -# identifies error conditions, it also identifies the error code that -# is used; though these are worded as requirements, different -# implementation strategies might lead to different errors being -# reported. In particular, an endpoint MAY use any applicable error -# code when it detects an error condition; a generic error code (such -# as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place -# of specific error codes. -# -# A stateless reset (Section 10.3) is not suitable for any error that -# can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A -# stateless reset MUST NOT be used by an endpoint that has the state -# necessary to send a frame on the connection. - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint that detects an error SHOULD signal the existence of that -error to its peer. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The most appropriate error code (Section 20) SHOULD be included in -the frame that signals the error. -''' - -[[spec]] -level = "MAY" -quote = ''' -In particular, an endpoint MAY use any applicable error -code when it detects an error condition; a generic error code (such -as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place -of specific error codes. -''' - -[[spec]] -level = "MUST" -quote = ''' -A -stateless reset MUST NOT be used by an endpoint that has the state -necessary to send a frame on the connection. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/12.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/12.2.toml deleted file mode 100644 index bbdb47f26b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/12.2.toml +++ /dev/null @@ -1,104 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.2" - -# 12.2. Coalescing Packets -# -# Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake -# (Section 17.2.4) packets contain a Length field that determines the -# end of the packet. The length includes both the Packet Number and -# Payload fields, both of which are confidentiality protected and -# initially of unknown length. The length of the Payload field is -# learned once header protection is removed. -# -# Using the Length field, a sender can coalesce multiple QUIC packets -# into one UDP datagram. This can reduce the number of UDP datagrams -# needed to complete the cryptographic handshake and start sending -# data. This can also be used to construct Path Maximum Transmission -# Unit (PMTU) probes; see Section 14.4.1. Receivers MUST be able to -# process coalesced packets. -# -# Coalescing packets in order of increasing encryption levels (Initial, -# 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it -# more likely that the receiver will be able to process all the packets -# in a single pass. A packet with a short header does not include a -# length, so it can only be the last packet included in a UDP datagram. -# An endpoint SHOULD include multiple frames in a single packet if they -# are to be sent at the same encryption level, instead of coalescing -# multiple packets at the same encryption level. -# -# Receivers MAY route based on the information in the first packet -# contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets -# with different connection IDs into a single UDP datagram. Receivers -# SHOULD ignore any subsequent packets with a different Destination -# Connection ID than the first packet in the datagram. -# -# Every QUIC packet that is coalesced into a single UDP datagram is -# separate and complete. The receiver of coalesced QUIC packets MUST -# individually process each QUIC packet and separately acknowledge -# them, as if they were received as the payload of different UDP -# datagrams. For example, if decryption fails (because the keys are -# not available or for any other reason), the receiver MAY either -# discard or buffer the packet for later processing and MUST attempt to -# process the remaining packets. -# -# Retry packets (Section 17.2.5), Version Negotiation packets -# (Section 17.2.1), and packets with a short header (Section 17.3) do -# not contain a Length field and so cannot be followed by other packets -# in the same UDP datagram. Note also that there is no situation where -# a Retry or Version Negotiation packet is coalesced with another -# packet. - -[[spec]] -level = "MUST" -quote = ''' -Receivers MUST be able to -process coalesced packets. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD include multiple frames in a single packet if they -are to be sent at the same encryption level, instead of coalescing -multiple packets at the same encryption level. -''' - -[[spec]] -level = "MAY" -quote = ''' -Receivers MAY route based on the information in the first packet -contained in a UDP datagram. -''' - -[[spec]] -level = "MUST" -quote = ''' -Senders MUST NOT coalesce QUIC packets -with different connection IDs into a single UDP datagram. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Receivers -SHOULD ignore any subsequent packets with a different Destination -Connection ID than the first packet in the datagram. -''' - -[[spec]] -level = "MUST" -quote = ''' -The receiver of coalesced QUIC packets MUST -individually process each QUIC packet and separately acknowledge -them, as if they were received as the payload of different UDP -datagrams. -''' - -[[spec]] -level = "MUST" -quote = ''' -For example, if decryption fails (because the keys are -not available or for any other reason), the receiver MAY either -discard or buffer the packet for later processing and MUST attempt to -process the remaining packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/12.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/12.3.toml deleted file mode 100644 index f725ffa77b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/12.3.toml +++ /dev/null @@ -1,113 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.3" - -# 12.3. Packet Numbers -# -# The packet number is an integer in the range 0 to 2^62-1. This -# number is used in determining the cryptographic nonce for packet -# protection. Each endpoint maintains a separate packet number for -# sending and receiving. -# -# Packet numbers are limited to this range because they need to be -# representable in whole in the Largest Acknowledged field of an ACK -# frame (Section 19.3). When present in a long or short header, -# however, packet numbers are reduced and encoded in 1 to 4 bytes; see -# Section 17.1. -# -# Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) -# packets do not include a packet number. -# -# Packet numbers are divided into three spaces in QUIC: -# -# Initial space: All Initial packets (Section 17.2.2) are in this -# space. -# -# Handshake space: All Handshake packets (Section 17.2.4) are in this -# space. -# -# Application data space: All 0-RTT (Section 17.2.3) and 1-RTT -# (Section 17.3.1) packets are in this space. -# -# As described in [QUIC-TLS], each packet type uses different -# protection keys. -# -# Conceptually, a packet number space is the context in which a packet -# can be processed and acknowledged. Initial packets can only be sent -# with Initial packet protection keys and acknowledged in packets that -# are also Initial packets. Similarly, Handshake packets are sent at -# the Handshake encryption level and can only be acknowledged in -# Handshake packets. -# -# This enforces cryptographic separation between the data sent in the -# different packet number spaces. Packet numbers in each space start -# at packet number 0. Subsequent packets sent in the same packet -# number space MUST increase the packet number by at least one. -# -# 0-RTT and 1-RTT data exist in the same packet number space to make -# loss recovery algorithms easier to implement between the two packet -# types. -# -# A QUIC endpoint MUST NOT reuse a packet number within the same packet -# number space in one connection. If the packet number for sending -# reaches 2^62-1, the sender MUST close the connection without sending -# a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send -# a Stateless Reset (Section 10.3) in response to further packets that -# it receives. -# -# A receiver MUST discard a newly unprotected packet unless it is -# certain that it has not processed another packet with the same packet -# number from the same packet number space. Duplicate suppression MUST -# happen after removing packet protection for the reasons described in -# Section 9.5 of [QUIC-TLS]. -# -# Endpoints that track all individual packets for the purposes of -# detecting duplicates are at risk of accumulating excessive state. -# The data required for detecting duplicates can be limited by -# maintaining a minimum packet number below which all packets are -# immediately dropped. Any minimum needs to account for large -# variations in round-trip time, which includes the possibility that a -# peer might probe network paths with much larger round-trip times; see -# Section 9. -# -# Packet number encoding at a sender and decoding at a receiver are -# described in Section 17.1. - -[[spec]] -level = "MUST" -quote = ''' -Subsequent packets sent in the same packet -number space MUST increase the packet number by at least one. -''' - -[[spec]] -level = "MUST" -quote = ''' -A QUIC endpoint MUST NOT reuse a packet number within the same packet -number space in one connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the packet number for sending -reaches 2^62-1, the sender MUST close the connection without sending -a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send -a Stateless Reset (Section 10.3) in response to further packets that -it receives. -''' - -[[spec]] -level = "MUST" -quote = ''' -A receiver MUST discard a newly unprotected packet unless it is -certain that it has not processed another packet with the same packet -number from the same packet number space. -''' - -[[spec]] -level = "MUST" -quote = ''' -Duplicate suppression MUST -happen after removing packet protection for the reasons described in -Section 9.5 of [QUIC-TLS]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/12.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/12.4.toml deleted file mode 100644 index fb33fafdb7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/12.4.toml +++ /dev/null @@ -1,195 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.4" - -# 12.4. Frames and Frame Types -# -# The payload of QUIC packets, after removing packet protection, -# consists of a sequence of complete frames, as shown in Figure 11. -# Version Negotiation, Stateless Reset, and Retry packets do not -# contain frames. -# -# Packet Payload { -# Frame (8..) ..., -# } -# -# Figure 11: QUIC Payload -# -# The payload of a packet that contains frames MUST contain at least -# one frame, and MAY contain multiple frames and multiple frame types. -# An endpoint MUST treat receipt of a packet containing no frames as a -# connection error of type PROTOCOL_VIOLATION. Frames always fit -# within a single QUIC packet and cannot span multiple packets. -# -# Each frame begins with a Frame Type, indicating its type, followed by -# additional type-dependent fields: -# -# Frame { -# Frame Type (i), -# Type-Dependent Fields (..), -# } -# -# Figure 12: Generic Frame Layout -# -# Table 3 lists and summarizes information about each frame type that -# is defined in this specification. A description of this summary is -# included after the table. -# -# +============+======================+===============+======+======+ -# | Type Value | Frame Type Name | Definition | Pkts | Spec | -# +============+======================+===============+======+======+ -# | 0x00 | PADDING | Section 19.1 | IH01 | NP | -# +------------+----------------------+---------------+------+------+ -# | 0x01 | PING | Section 19.2 | IH01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC | -# +------------+----------------------+---------------+------+------+ -# | 0x04 | RESET_STREAM | Section 19.4 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x05 | STOP_SENDING | Section 19.5 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x06 | CRYPTO | Section 19.6 | IH_1 | | -# +------------+----------------------+---------------+------+------+ -# | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | -# +------------+----------------------+---------------+------+------+ -# | 0x08-0x0f | STREAM | Section 19.8 | __01 | F | -# +------------+----------------------+---------------+------+------+ -# | 0x10 | MAX_DATA | Section 19.9 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | -# +------------+----------------------+---------------+------+------+ -# | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | -# +------------+----------------------+---------------+------+------+ -# | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | -# +------------+----------------------+---------------+------+------+ -# | 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P | -# +------------+----------------------+---------------+------+------+ -# | 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N | -# +------------+----------------------+---------------+------+------+ -# | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | -# +------------+----------------------+---------------+------+------+ -# -# Table 3: Frame Types -# -# The format and semantics of each frame type are explained in more -# detail in Section 19. The remainder of this section provides a -# summary of important and general information. -# -# The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and -# CONNECTION_CLOSE frames is used to carry other frame-specific flags. -# For all other frames, the Frame Type field simply identifies the -# frame. -# -# The "Pkts" column in Table 3 lists the types of packets that each -# frame type could appear in, indicated by the following characters: -# -# I: Initial (Section 17.2.2) -# -# H: Handshake (Section 17.2.4) -# -# 0: 0-RTT (Section 17.2.3) -# -# 1: 1-RTT (Section 17.3.1) -# -# ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial -# or Handshake packets. -# -# For more details about these restrictions, see Section 12.5. Note -# that all frames can appear in 1-RTT packets. An endpoint MUST treat -# receipt of a frame in a packet type that is not permitted as a -# connection error of type PROTOCOL_VIOLATION. -# -# The "Spec" column in Table 3 summarizes any special rules governing -# the processing or generation of the frame type, as indicated by the -# following characters: -# -# N: Packets containing only frames with this marking are not ack- -# eliciting; see Section 13.2. -# -# C: Packets containing only frames with this marking do not count -# toward bytes in flight for congestion control purposes; see -# [QUIC-RECOVERY]. -# -# P: Packets containing only frames with this marking can be used to -# probe new network paths during connection migration; see -# Section 9.1. -# -# F: The contents of frames with this marking are flow controlled; -# see Section 4. -# -# The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA -# registry; see Section 22.4. -# -# An endpoint MUST treat the receipt of a frame of unknown type as a -# connection error of type FRAME_ENCODING_ERROR. -# -# All frames are idempotent in this version of QUIC. That is, a valid -# frame does not cause undesirable side effects or errors when received -# more than once. -# -# The Frame Type field uses a variable-length integer encoding (see -# Section 16), with one exception. To ensure simple and efficient -# implementations of frame parsing, a frame type MUST use the shortest -# possible encoding. For frame types defined in this document, this -# means a single-byte encoding, even though it is possible to encode -# these values as a two-, four-, or eight-byte variable-length integer. -# For instance, though 0x4001 is a legitimate two-byte encoding for a -# variable-length integer with a value of 1, PING frames are always -# encoded as a single byte with the value 0x01. This rule applies to -# all current and future QUIC frame types. An endpoint MAY treat the -# receipt of a frame type that uses a longer encoding than necessary as -# a connection error of type PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -The payload of a packet that contains frames MUST contain at least -one frame, and MAY contain multiple frames and multiple frame types. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat receipt of a packet containing no frames as a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat -receipt of a frame in a packet type that is not permitted as a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat the receipt of a frame of unknown type as a -connection error of type FRAME_ENCODING_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -To ensure simple and efficient -implementations of frame parsing, a frame type MUST use the shortest -possible encoding. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY treat the -receipt of a frame type that uses a longer encoding than necessary as -a connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/12.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/12.5.toml deleted file mode 100644 index b3d1f97c48..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/12.5.toml +++ /dev/null @@ -1,75 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-12.5" - -# 12.5. Frames and Number Spaces -# -# Some frames are prohibited in different packet number spaces. The -# rules here generalize those of TLS, in that frames associated with -# establishing the connection can usually appear in packets in any -# packet number space, whereas those associated with transferring data -# can only appear in the application data packet number space: -# -# * PADDING, PING, and CRYPTO frames MAY appear in any packet number -# space. -# -# * CONNECTION_CLOSE frames signaling errors at the QUIC layer (type -# 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE -# frames signaling application errors (type 0x1d) MUST only appear -# in the application data packet number space. -# -# * ACK frames MAY appear in any packet number space but can only -# acknowledge packets that appeared in that packet number space. -# However, as noted below, 0-RTT packets cannot contain ACK frames. -# -# * All other frame types MUST only be sent in the application data -# packet number space. -# -# Note that it is not possible to send the following frames in 0-RTT -# packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, -# PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt -# of these frames in 0-RTT packets as a connection error of type -# PROTOCOL_VIOLATION. - -[[spec]] -level = "MAY" -quote = ''' -* PADDING, PING, and CRYPTO frames MAY appear in any packet number -space. -''' - -[[spec]] -level = "MAY" -quote = ''' -* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type -0x1c) MAY appear in any packet number space. -''' - -[[spec]] -level = "MUST" -quote = ''' -CONNECTION_CLOSE -frames signaling application errors (type 0x1d) MUST only appear -in the application data packet number space. -''' - -[[spec]] -level = "MAY" -quote = ''' -* ACK frames MAY appear in any packet number space but can only -acknowledge packets that appeared in that packet number space. -''' - -[[spec]] -level = "MUST" -quote = ''' -* All other frame types MUST only be sent in the application data -packet number space. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY treat receipt -of these frames in 0-RTT packets as a connection error of type -PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.1.toml deleted file mode 100644 index 63290401d1..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.1.toml +++ /dev/null @@ -1,35 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.1" - -# 13.1. Packet Processing -# -# A packet MUST NOT be acknowledged until packet protection has been -# successfully removed and all frames contained in the packet have been -# processed. For STREAM frames, this means the data has been enqueued -# in preparation to be received by the application protocol, but it -# does not require that data be delivered and consumed. -# -# Once the packet has been fully processed, a receiver acknowledges -# receipt by sending one or more ACK frames containing the packet -# number of the received packet. -# -# An endpoint SHOULD treat receipt of an acknowledgment for a packet it -# did not send as a connection error of type PROTOCOL_VIOLATION, if it -# is able to detect the condition. For further discussion of how this -# might be achieved, see Section 21.4. - -[[spec]] -level = "MUST" -quote = ''' -A packet MUST NOT be acknowledged until packet protection has been -successfully removed and all frames contained in the packet have been -processed. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD treat receipt of an acknowledgment for a packet it -did not send as a connection error of type PROTOCOL_VIOLATION, if it -is able to detect the condition. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.1.toml deleted file mode 100644 index 828bc72e9c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.1.toml +++ /dev/null @@ -1,145 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.1" - -# 13.2.1. Sending ACK Frames -# -# Every packet SHOULD be acknowledged at least once, and ack-eliciting -# packets MUST be acknowledged at least once within the maximum delay -# an endpoint communicated using the max_ack_delay transport parameter; -# see Section 18.2. max_ack_delay declares an explicit contract: an -# endpoint promises to never intentionally delay acknowledgments of an -# ack-eliciting packet by more than the indicated value. If it does, -# any excess accrues to the RTT estimate and could result in spurious -# or delayed retransmissions from the peer. A sender uses the -# receiver's max_ack_delay value in determining timeouts for timer- -# based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY]. -# -# An endpoint MUST acknowledge all ack-eliciting Initial and Handshake -# packets immediately and all ack-eliciting 0-RTT and 1-RTT packets -# within its advertised max_ack_delay, with the following exception. -# Prior to handshake confirmation, an endpoint might not have packet -# protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets -# when they are received. It might therefore buffer them and -# acknowledge them when the requisite keys become available. -# -# Since packets containing only ACK frames are not congestion -# controlled, an endpoint MUST NOT send more than one such packet in -# response to receiving an ack-eliciting packet. -# -# An endpoint MUST NOT send a non-ack-eliciting packet in response to a -# non-ack-eliciting packet, even if there are packet gaps that precede -# the received packet. This avoids an infinite feedback loop of -# acknowledgments, which could prevent the connection from ever -# becoming idle. Non-ack-eliciting packets are eventually acknowledged -# when the endpoint sends an ACK frame in response to other events. -# -# An endpoint that is only sending ACK frames will not receive -# acknowledgments from its peer unless those acknowledgments are -# included in packets with ack-eliciting frames. An endpoint SHOULD -# send an ACK frame with other frames when there are new ack-eliciting -# packets to acknowledge. When only non-ack-eliciting packets need to -# be acknowledged, an endpoint MAY choose not to send an ACK frame with -# outgoing frames until an ack-eliciting packet has been received. -# -# An endpoint that is only sending non-ack-eliciting packets might -# choose to occasionally add an ack-eliciting frame to those packets to -# ensure that it receives an acknowledgment; see Section 13.2.4. In -# that case, an endpoint MUST NOT send an ack-eliciting frame in all -# packets that would otherwise be non-ack-eliciting, to avoid an -# infinite feedback loop of acknowledgments. -# -# In order to assist loss detection at the sender, an endpoint SHOULD -# generate and send an ACK frame without delay when it receives an ack- -# eliciting packet either: -# -# * when the received packet has a packet number less than another -# ack-eliciting packet that has been received, or -# -# * when the packet has a packet number larger than the highest- -# numbered ack-eliciting packet that has been received and there are -# missing packets between that packet and this packet. -# -# Similarly, packets marked with the ECN Congestion Experienced (CE) -# codepoint in the IP header SHOULD be acknowledged immediately, to -# reduce the peer's response time to congestion events. -# -# The algorithms in [QUIC-RECOVERY] are expected to be resilient to -# receivers that do not follow the guidance offered above. However, an -# implementation should only deviate from these requirements after -# careful consideration of the performance implications of a change, -# for connections made by the endpoint and for other users of the -# network. - -[[spec]] -level = "MUST" -quote = ''' -Every packet SHOULD be acknowledged at least once, and ack-eliciting -packets MUST be acknowledged at least once within the maximum delay -an endpoint communicated using the max_ack_delay transport parameter; -see Section 18.2. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST acknowledge all ack-eliciting Initial and Handshake -packets immediately and all ack-eliciting 0-RTT and 1-RTT packets -within its advertised max_ack_delay, with the following exception. -''' - -[[spec]] -level = "MUST" -quote = ''' -Since packets containing only ACK frames are not congestion -controlled, an endpoint MUST NOT send more than one such packet in -response to receiving an ack-eliciting packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send a non-ack-eliciting packet in response to a -non-ack-eliciting packet, even if there are packet gaps that precede -the received packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD -send an ACK frame with other frames when there are new ack-eliciting -packets to acknowledge. -''' - -[[spec]] -level = "MAY" -quote = ''' -When only non-ack-eliciting packets need to -be acknowledged, an endpoint MAY choose not to send an ACK frame with -outgoing frames until an ack-eliciting packet has been received. -''' - -[[spec]] -level = "MUST" -quote = ''' -In -that case, an endpoint MUST NOT send an ack-eliciting frame in all -packets that would otherwise be non-ack-eliciting, to avoid an -infinite feedback loop of acknowledgments. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In order to assist loss detection at the sender, an endpoint SHOULD -generate and send an ACK frame without delay when it receives an ack- -eliciting packet either: -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Similarly, packets marked with the ECN Congestion Experienced (CE) -codepoint in the IP header SHOULD be acknowledged immediately, to -reduce the peer's response time to congestion events. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.2.toml deleted file mode 100644 index 68e2b3e6c4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.2.toml +++ /dev/null @@ -1,45 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.2" - -# 13.2.2. Acknowledgment Frequency -# -# A receiver determines how frequently to send acknowledgments in -# response to ack-eliciting packets. This determination involves a -# trade-off. -# -# Endpoints rely on timely acknowledgment to detect loss; see Section 6 -# of [QUIC-RECOVERY]. Window-based congestion controllers, such as the -# one described in Section 7 of [QUIC-RECOVERY], rely on -# acknowledgments to manage their congestion window. In both cases, -# delaying acknowledgments can adversely affect performance. -# -# On the other hand, reducing the frequency of packets that carry only -# acknowledgments reduces packet transmission and processing cost at -# both endpoints. It can improve connection throughput on severely -# asymmetric links and reduce the volume of acknowledgment traffic -# using return path capacity; see Section 3 of [RFC3449]. -# -# A receiver SHOULD send an ACK frame after receiving at least two ack- -# eliciting packets. This recommendation is general in nature and -# consistent with recommendations for TCP endpoint behavior [RFC5681]. -# Knowledge of network conditions, knowledge of the peer's congestion -# controller, or further research and experimentation might suggest -# alternative acknowledgment strategies with better performance -# characteristics. -# -# A receiver MAY process multiple available packets before determining -# whether to send an ACK frame in response. - -[[spec]] -level = "SHOULD" -quote = ''' -A receiver SHOULD send an ACK frame after receiving at least two ack- -eliciting packets. -''' - -[[spec]] -level = "MAY" -quote = ''' -A receiver MAY process multiple available packets before determining -whether to send an ACK frame in response. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.3.toml deleted file mode 100644 index 5c3f045c3a..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.3.toml +++ /dev/null @@ -1,103 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.3" - -# 13.2.3. Managing ACK Ranges -# -# When an ACK frame is sent, one or more ranges of acknowledged packets -# are included. Including acknowledgments for older packets reduces -# the chance of spurious retransmissions caused by losing previously -# sent ACK frames, at the cost of larger ACK frames. -# -# ACK frames SHOULD always acknowledge the most recently received -# packets, and the more out of order the packets are, the more -# important it is to send an updated ACK frame quickly, to prevent the -# peer from declaring a packet as lost and spuriously retransmitting -# the frames it contains. An ACK frame is expected to fit within a -# single QUIC packet. If it does not, then older ranges (those with -# the smallest packet numbers) are omitted. -# -# A receiver limits the number of ACK Ranges (Section 19.3.1) it -# remembers and sends in ACK frames, both to limit the size of ACK -# frames and to avoid resource exhaustion. After receiving -# acknowledgments for an ACK frame, the receiver SHOULD stop tracking -# those acknowledged ACK Ranges. Senders can expect acknowledgments -# for most packets, but QUIC does not guarantee receipt of an -# acknowledgment for every packet that the receiver processes. -# -# It is possible that retaining many ACK Ranges could cause an ACK -# frame to become too large. A receiver can discard unacknowledged ACK -# Ranges to limit ACK frame size, at the cost of increased -# retransmissions from the sender. This is necessary if an ACK frame -# would be too large to fit in a packet. Receivers MAY also limit ACK -# frame size further to preserve space for other frames or to limit the -# capacity that acknowledgments consume. -# -# A receiver MUST retain an ACK Range unless it can ensure that it will -# not subsequently accept packets with numbers in that range. -# Maintaining a minimum packet number that increases as ranges are -# discarded is one way to achieve this with minimal state. -# -# Receivers can discard all ACK Ranges, but they MUST retain the -# largest packet number that has been successfully processed, as that -# is used to recover packet numbers from subsequent packets; see -# Section 17.1. -# -# A receiver SHOULD include an ACK Range containing the largest -# received packet number in every ACK frame. The Largest Acknowledged -# field is used in ECN validation at a sender, and including a lower -# value than what was included in a previous ACK frame could cause ECN -# to be unnecessarily disabled; see Section 13.4.2. -# -# Section 13.2.4 describes an exemplary approach for determining what -# packets to acknowledge in each ACK frame. Though the goal of this -# algorithm is to generate an acknowledgment for every packet that is -# processed, it is still possible for acknowledgments to be lost. - -[[spec]] -level = "SHOULD" -quote = ''' -ACK frames SHOULD always acknowledge the most recently received -packets, and the more out of order the packets are, the more -important it is to send an updated ACK frame quickly, to prevent the -peer from declaring a packet as lost and spuriously retransmitting -the frames it contains. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -After receiving -acknowledgments for an ACK frame, the receiver SHOULD stop tracking -those acknowledged ACK Ranges. -''' - -[[spec]] -level = "MAY" -quote = ''' -Receivers MAY also limit ACK -frame size further to preserve space for other frames or to limit the -capacity that acknowledgments consume. -''' - -[[spec]] -level = "MUST" -quote = ''' -A receiver MUST retain an ACK Range unless it can ensure that it will -not subsequently accept packets with numbers in that range. -''' - -[[spec]] -level = "MUST" -quote = ''' -Receivers can discard all ACK Ranges, but they MUST retain the -largest packet number that has been successfully processed, as that -is used to recover packet numbers from subsequent packets; see -Section 17.1. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A receiver SHOULD include an ACK Range containing the largest -received packet number in every ACK frame. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.5.toml deleted file mode 100644 index 07b34815d8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.5.toml +++ /dev/null @@ -1,46 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.5" - -# 13.2.5. Measuring and Reporting Host Delay -# -# An endpoint measures the delays intentionally introduced between the -# time the packet with the largest packet number is received and the -# time an acknowledgment is sent. The endpoint encodes this -# acknowledgment delay in the ACK Delay field of an ACK frame; see -# Section 19.3. This allows the receiver of the ACK frame to adjust -# for any intentional delays, which is important for getting a better -# estimate of the path RTT when acknowledgments are delayed. -# -# A packet might be held in the OS kernel or elsewhere on the host -# before being processed. An endpoint MUST NOT include delays that it -# does not control when populating the ACK Delay field in an ACK frame. -# However, endpoints SHOULD include buffering delays caused by -# unavailability of decryption keys, since these delays can be large -# and are likely to be non-repeating. -# -# When the measured acknowledgment delay is larger than its -# max_ack_delay, an endpoint SHOULD report the measured delay. This -# information is especially useful during the handshake when delays -# might be large; see Section 13.2.1. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT include delays that it -does not control when populating the ACK Delay field in an ACK frame. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -However, endpoints SHOULD include buffering delays caused by -unavailability of decryption keys, since these delays can be large -and are likely to be non-repeating. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When the measured acknowledgment delay is larger than its -max_ack_delay, an endpoint SHOULD report the measured delay. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.6.toml deleted file mode 100644 index 6abef7a0a8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.6.toml +++ /dev/null @@ -1,38 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.6" - -# 13.2.6. ACK Frames and Packet Protection -# -# ACK frames MUST only be carried in a packet that has the same packet -# number space as the packet being acknowledged; see Section 12.1. For -# instance, packets that are protected with 1-RTT keys MUST be -# acknowledged in packets that are also protected with 1-RTT keys. -# -# Packets that a client sends with 0-RTT packet protection MUST be -# acknowledged by the server in packets protected by 1-RTT keys. This -# can mean that the client is unable to use these acknowledgments if -# the server cryptographic handshake messages are delayed or lost. -# Note that the same limitation applies to other data sent by the -# server protected by the 1-RTT keys. - -[[spec]] -level = "MUST" -quote = ''' -ACK frames MUST only be carried in a packet that has the same packet -number space as the packet being acknowledged; see Section 12.1. -''' - -[[spec]] -level = "MUST" -quote = ''' -For -instance, packets that are protected with 1-RTT keys MUST be -acknowledged in packets that are also protected with 1-RTT keys. -''' - -[[spec]] -level = "MUST" -quote = ''' -Packets that a client sends with 0-RTT packet protection MUST be -acknowledged by the server in packets protected by 1-RTT keys. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.7.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.7.toml deleted file mode 100644 index 969633fda6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.7.toml +++ /dev/null @@ -1,21 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2.7" - -# 13.2.7. PADDING Frames Consume Congestion Window -# -# Packets containing PADDING frames are considered to be in flight for -# congestion control purposes [QUIC-RECOVERY]. Packets containing only -# PADDING frames therefore consume congestion window but do not -# generate acknowledgments that will open the congestion window. To -# avoid a deadlock, a sender SHOULD ensure that other frames are sent -# periodically in addition to PADDING frames to elicit acknowledgments -# from the receiver. - -[[spec]] -level = "SHOULD" -quote = ''' -To -avoid a deadlock, a sender SHOULD ensure that other frames are sent -periodically in addition to PADDING frames to elicit acknowledgments -from the receiver. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.2.toml deleted file mode 100644 index 450bad9f74..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.2.toml +++ /dev/null @@ -1,26 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.2" - -# 13.2. Generating Acknowledgments -# -# Endpoints acknowledge all packets they receive and process. However, -# only ack-eliciting packets cause an ACK frame to be sent within the -# maximum ack delay. Packets that are not ack-eliciting are only -# acknowledged when an ACK frame is sent for other reasons. -# -# When sending a packet for any reason, an endpoint SHOULD attempt to -# include an ACK frame if one has not been sent recently. Doing so -# helps with timely loss detection at the peer. -# -# In general, frequent feedback from a receiver improves loss and -# congestion response, but this has to be balanced against excessive -# load generated by a receiver that sends an ACK frame in response to -# every ack-eliciting packet. The guidance offered below seeks to -# strike this balance. - -[[spec]] -level = "SHOULD" -quote = ''' -When sending a packet for any reason, an endpoint SHOULD attempt to -include an ACK frame if one has not been sent recently. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.3.toml deleted file mode 100644 index 8bfb3d2161..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.3.toml +++ /dev/null @@ -1,186 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.3" - -# 13.3. Retransmission of Information -# -# QUIC packets that are determined to be lost are not retransmitted -# whole. The same applies to the frames that are contained within lost -# packets. Instead, the information that might be carried in frames is -# sent again in new frames as needed. -# -# New frames and packets are used to carry information that is -# determined to have been lost. In general, information is sent again -# when a packet containing that information is determined to be lost, -# and sending ceases when a packet containing that information is -# acknowledged. -# -# * Data sent in CRYPTO frames is retransmitted according to the rules -# in [QUIC-RECOVERY], until all data has been acknowledged. Data in -# CRYPTO frames for Initial and Handshake packets is discarded when -# keys for the corresponding packet number space are discarded. -# -# * Application data sent in STREAM frames is retransmitted in new -# STREAM frames unless the endpoint has sent a RESET_STREAM for that -# stream. Once an endpoint sends a RESET_STREAM frame, no further -# STREAM frames are needed. -# -# * ACK frames carry the most recent set of acknowledgments and the -# acknowledgment delay from the largest acknowledged packet, as -# described in Section 13.2.1. Delaying the transmission of packets -# containing ACK frames or resending old ACK frames can cause the -# peer to generate an inflated RTT sample or unnecessarily disable -# ECN. -# -# * Cancellation of stream transmission, as carried in a RESET_STREAM -# frame, is sent until acknowledged or until all stream data is -# acknowledged by the peer (that is, either the "Reset Recvd" or -# "Data Recvd" state is reached on the sending part of the stream). -# The content of a RESET_STREAM frame MUST NOT change when it is -# sent again. -# -# * Similarly, a request to cancel stream transmission, as encoded in -# a STOP_SENDING frame, is sent until the receiving part of the -# stream enters either a "Data Recvd" or "Reset Recvd" state; see -# Section 3.5. -# -# * Connection close signals, including packets that contain -# CONNECTION_CLOSE frames, are not sent again when packet loss is -# detected. Resending these signals is described in Section 10. -# -# * The current connection maximum data is sent in MAX_DATA frames. -# An updated value is sent in a MAX_DATA frame if the packet -# containing the most recently sent MAX_DATA frame is declared lost -# or when the endpoint decides to update the limit. Care is -# necessary to avoid sending this frame too often, as the limit can -# increase frequently and cause an unnecessarily large number of -# MAX_DATA frames to be sent; see Section 4.2. -# -# * The current maximum stream data offset is sent in MAX_STREAM_DATA -# frames. Like MAX_DATA, an updated value is sent when the packet -# containing the most recent MAX_STREAM_DATA frame for a stream is -# lost or when the limit is updated, with care taken to prevent the -# frame from being sent too often. An endpoint SHOULD stop sending -# MAX_STREAM_DATA frames when the receiving part of the stream -# enters a "Size Known" or "Reset Recvd" state. -# -# * The limit on streams of a given type is sent in MAX_STREAMS -# frames. Like MAX_DATA, an updated value is sent when a packet -# containing the most recent MAX_STREAMS for a stream type frame is -# declared lost or when the limit is updated, with care taken to -# prevent the frame from being sent too often. -# -# * Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, -# and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection -# scope, STREAM_DATA_BLOCKED frames have stream scope, and -# STREAMS_BLOCKED frames are scoped to a specific stream type. A -# new frame is sent if a packet containing the most recent frame for -# a scope is lost, but only while the endpoint is blocked on the -# corresponding limit. These frames always include the limit that -# is causing blocking at the time that they are transmitted. -# -# * A liveness or path validation check using PATH_CHALLENGE frames is -# sent periodically until a matching PATH_RESPONSE frame is received -# or until there is no remaining need for liveness or path -# validation checking. PATH_CHALLENGE frames include a different -# payload each time they are sent. -# -# * Responses to path validation using PATH_RESPONSE frames are sent -# just once. The peer is expected to send more PATH_CHALLENGE -# frames as necessary to evoke additional PATH_RESPONSE frames. -# -# * New connection IDs are sent in NEW_CONNECTION_ID frames and -# retransmitted if the packet containing them is lost. -# Retransmissions of this frame carry the same sequence number -# value. Likewise, retired connection IDs are sent in -# RETIRE_CONNECTION_ID frames and retransmitted if the packet -# containing them is lost. -# -# * NEW_TOKEN frames are retransmitted if the packet containing them -# is lost. No special support is made for detecting reordered and -# duplicated NEW_TOKEN frames other than a direct comparison of the -# frame contents. -# -# * PING and PADDING frames contain no information, so lost PING or -# PADDING frames do not require repair. -# -# * The HANDSHAKE_DONE frame MUST be retransmitted until it is -# acknowledged. -# -# Endpoints SHOULD prioritize retransmission of data over sending new -# data, unless priorities specified by the application indicate -# otherwise; see Section 2.3. -# -# Even though a sender is encouraged to assemble frames containing up- -# to-date information every time it sends a packet, it is not forbidden -# to retransmit copies of frames from lost packets. A sender that -# retransmits copies of frames needs to handle decreases in available -# payload size due to changes in packet number length, connection ID -# length, and path MTU. A receiver MUST accept packets containing an -# outdated frame, such as a MAX_DATA frame carrying a smaller maximum -# data value than one found in an older packet. -# -# A sender SHOULD avoid retransmitting information from packets once -# they are acknowledged. This includes packets that are acknowledged -# after being declared lost, which can happen in the presence of -# network reordering. Doing so requires senders to retain information -# about packets after they are declared lost. A sender can discard -# this information after a period of time elapses that adequately -# allows for reordering, such as a PTO (Section 6.2 of -# [QUIC-RECOVERY]), or based on other events, such as reaching a memory -# limit. -# -# Upon detecting losses, a sender MUST take appropriate congestion -# control action. The details of loss detection and congestion control -# are described in [QUIC-RECOVERY]. - -[[spec]] -level = "MUST" -quote = ''' -The content of a RESET_STREAM frame MUST NOT change when it is -sent again. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD stop sending -MAX_STREAM_DATA frames when the receiving part of the stream -enters a "Size Known" or "Reset Recvd" state. -''' - -[[spec]] -level = "MUST" -quote = ''' -* The HANDSHAKE_DONE frame MUST be retransmitted until it is -acknowledged. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD prioritize retransmission of data over sending new -data, unless priorities specified by the application indicate -otherwise; see Section 2.3. -''' - -[[spec]] -level = "MUST" -quote = ''' -A receiver MUST accept packets containing an -outdated frame, such as a MAX_DATA frame carrying a smaller maximum -data value than one found in an older packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD avoid retransmitting information from packets once -they are acknowledged. -''' - -[[spec]] -level = "MUST" -quote = ''' -Upon detecting losses, a sender MUST take appropriate congestion -control action. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.4.1.toml deleted file mode 100644 index 34e24a2a8e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.1.toml +++ /dev/null @@ -1,44 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.1" - -# 13.4.1. Reporting ECN Counts -# -# The use of ECN requires the receiving endpoint to read the ECN field -# from an IP packet, which is not possible on all platforms. If an -# endpoint does not implement ECN support or does not have access to -# received ECN fields, it does not report ECN counts for packets it -# receives. -# -# Even if an endpoint does not set an ECT field in packets it sends, -# the endpoint MUST provide feedback about ECN markings it receives, if -# these are accessible. Failing to report the ECN counts will cause -# the sender to disable the use of ECN for this connection. -# -# On receiving an IP packet with an ECT(0), ECT(1), or ECN-CE -# codepoint, an ECN-enabled endpoint accesses the ECN field and -# increases the corresponding ECT(0), ECT(1), or ECN-CE count. These -# ECN counts are included in subsequent ACK frames; see Sections 13.2 -# and 19.3. -# -# Each packet number space maintains separate acknowledgment state and -# separate ECN counts. Coalesced QUIC packets (see Section 12.2) share -# the same IP header so the ECN counts are incremented once for each -# coalesced QUIC packet. -# -# For example, if one each of an Initial, Handshake, and 1-RTT QUIC -# packet are coalesced into a single UDP datagram, the ECN counts for -# all three packet number spaces will be incremented by one each, based -# on the ECN field of the single IP header. -# -# ECN counts are only incremented when QUIC packets from the received -# IP packet are processed. As such, duplicate QUIC packets are not -# processed and do not increase ECN counts; see Section 21.10 for -# relevant security concerns. - -[[spec]] -level = "MUST" -quote = ''' -Even if an endpoint does not set an ECT field in packets it sends, -the endpoint MUST provide feedback about ECN markings it receives, if -these are accessible. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.1.toml deleted file mode 100644 index f3d8eed173..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.1.toml +++ /dev/null @@ -1,54 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.2.1" - -# 13.4.2.1. Receiving ACK Frames with ECN Counts -# -# Erroneous application of ECN-CE markings by the network can result in -# degraded connection performance. An endpoint that receives an ACK -# frame with ECN counts therefore validates the counts before using -# them. It performs this validation by comparing newly received counts -# against those from the last successfully processed ACK frame. Any -# increase in the ECN counts is validated based on the ECN markings -# that were applied to packets that are newly acknowledged in the ACK -# frame. -# -# If an ACK frame newly acknowledges a packet that the endpoint sent -# with either the ECT(0) or ECT(1) codepoint set, ECN validation fails -# if the corresponding ECN counts are not present in the ACK frame. -# This check detects a network element that zeroes the ECN field or a -# peer that does not report ECN markings. -# -# ECN validation also fails if the sum of the increase in ECT(0) and -# ECN-CE counts is less than the number of newly acknowledged packets -# that were originally sent with an ECT(0) marking. Similarly, ECN -# validation fails if the sum of the increases to ECT(1) and ECN-CE -# counts is less than the number of newly acknowledged packets sent -# with an ECT(1) marking. These checks can detect remarking of ECN-CE -# markings by the network. -# -# An endpoint could miss acknowledgments for a packet when ACK frames -# are lost. It is therefore possible for the total increase in ECT(0), -# ECT(1), and ECN-CE counts to be greater than the number of packets -# that are newly acknowledged by an ACK frame. This is why ECN counts -# are permitted to be larger than the total number of packets that are -# acknowledged. -# -# Validating ECN counts from reordered ACK frames can result in -# failure. An endpoint MUST NOT fail ECN validation as a result of -# processing an ACK frame that does not increase the largest -# acknowledged packet number. -# -# ECN validation can fail if the received total count for either ECT(0) -# or ECT(1) exceeds the total number of packets sent with each -# corresponding ECT codepoint. In particular, validation will fail -# when an endpoint receives a non-zero ECN count corresponding to an -# ECT codepoint that it never applied. This check detects when packets -# are remarked to ECT(0) or ECT(1) in the network. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT fail ECN validation as a result of -processing an ACK frame that does not increase the largest -acknowledged packet number. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.2.toml deleted file mode 100644 index b0efe59b62..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.2.toml +++ /dev/null @@ -1,47 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.2.2" - -# 13.4.2.2. ECN Validation Outcomes -# -# If validation fails, then the endpoint MUST disable ECN. It stops -# setting the ECT codepoint in IP packets that it sends, assuming that -# either the network path or the peer does not support ECN. -# -# Even if validation fails, an endpoint MAY revalidate ECN for the same -# path at any later time in the connection. An endpoint could continue -# to periodically attempt validation. -# -# Upon successful validation, an endpoint MAY continue to set an ECT -# codepoint in subsequent packets it sends, with the expectation that -# the path is ECN capable. Network routing and path elements can -# change mid-connection; an endpoint MUST disable ECN if validation -# later fails. - -[[spec]] -level = "MUST" -quote = ''' -If validation fails, then the endpoint MUST disable ECN. -''' - -[[spec]] -level = "MAY" -quote = ''' -Even if validation fails, an endpoint MAY revalidate ECN for the same -path at any later time in the connection. -''' - -[[spec]] -level = "MAY" -quote = ''' -Upon successful validation, an endpoint MAY continue to set an ECT -codepoint in subsequent packets it sends, with the expectation that -the path is ECN capable. -''' - -[[spec]] -level = "MUST" -quote = ''' -Network routing and path elements can -change mid-connection; an endpoint MUST disable ECN if validation -later fails. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.toml deleted file mode 100644 index 15497675b2..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.4.2.toml +++ /dev/null @@ -1,45 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13.4.2" - -# 13.4.2. ECN Validation -# -# It is possible for faulty network devices to corrupt or erroneously -# drop packets that carry a non-zero ECN codepoint. To ensure -# connectivity in the presence of such devices, an endpoint validates -# the ECN counts for each network path and disables the use of ECN on -# that path if errors are detected. -# -# To perform ECN validation for a new path: -# -# * The endpoint sets an ECT(0) codepoint in the IP header of early -# outgoing packets sent on a new path to the peer [RFC8311]. -# -# * The endpoint monitors whether all packets sent with an ECT -# codepoint are eventually deemed lost (Section 6 of -# [QUIC-RECOVERY]), indicating that ECN validation has failed. -# -# If an endpoint has cause to expect that IP packets with an ECT -# codepoint might be dropped by a faulty network element, the endpoint -# could set an ECT codepoint for only the first ten outgoing packets on -# a path, or for a period of three PTOs (see Section 6.2 of -# [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints -# are subsequently lost, it can disable marking on the assumption that -# the marking caused the loss. -# -# An endpoint thus attempts to use ECN and validates this for each new -# connection, when switching to a server's preferred address, and on -# active connection migration to a new path. Appendix A.4 describes -# one possible algorithm. -# -# Other methods of probing paths for ECN support are possible, as are -# different marking strategies. Implementations MAY use other methods -# defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) -# codepoint need to perform ECN validation using the reported ECT(1) -# counts. - -[[spec]] -level = "MAY" -quote = ''' -Implementations MAY use other methods -defined in RFCs; see [RFC8311]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/13.toml b/specs/www.rfc-editor.org/rfc/rfc9000/13.toml deleted file mode 100644 index b6fb384385..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/13.toml +++ /dev/null @@ -1,48 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-13" - -# 13. Packetization and Reliability -# -# A sender sends one or more frames in a QUIC packet; see Section 12.4. -# -# A sender can minimize per-packet bandwidth and computational costs by -# including as many frames as possible in each QUIC packet. A sender -# MAY wait for a short period of time to collect multiple frames before -# sending a packet that is not maximally packed, to avoid sending out -# large numbers of small packets. An implementation MAY use knowledge -# about application sending behavior or heuristics to determine whether -# and for how long to wait. This waiting period is an implementation -# decision, and an implementation should be careful to delay -# conservatively, since any delay is likely to increase application- -# visible latency. -# -# Stream multiplexing is achieved by interleaving STREAM frames from -# multiple streams into one or more QUIC packets. A single QUIC packet -# can include multiple STREAM frames from one or more streams. -# -# One of the benefits of QUIC is avoidance of head-of-line blocking -# across multiple streams. When a packet loss occurs, only streams -# with data in that packet are blocked waiting for a retransmission to -# be received, while other streams can continue making progress. Note -# that when data from multiple streams is included in a single QUIC -# packet, loss of that packet blocks all those streams from making -# progress. Implementations are advised to include as few streams as -# necessary in outgoing packets without losing transmission efficiency -# to underfilled packets. - -[[spec]] -level = "MAY" -quote = ''' -A sender -MAY wait for a short period of time to collect multiple frames before -sending a packet that is not maximally packed, to avoid sending out -large numbers of small packets. -''' - -[[spec]] -level = "MAY" -quote = ''' -An implementation MAY use knowledge -about application sending behavior or heuristics to determine whether -and for how long to wait. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/14.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/14.1.toml deleted file mode 100644 index 0743f21f02..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/14.1.toml +++ /dev/null @@ -1,80 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.1" - -# 14.1. Initial Datagram Size -# -# A client MUST expand the payload of all UDP datagrams carrying -# Initial packets to at least the smallest allowed maximum datagram -# size of 1200 bytes by adding PADDING frames to the Initial packet or -# by coalescing the Initial packet; see Section 12.2. Initial packets -# can even be coalesced with invalid packets, which a receiver will -# discard. Similarly, a server MUST expand the payload of all UDP -# datagrams carrying ack-eliciting Initial packets to at least the -# smallest allowed maximum datagram size of 1200 bytes. -# -# Sending UDP datagrams of this size ensures that the network path -# supports a reasonable Path Maximum Transmission Unit (PMTU), in both -# directions. Additionally, a client that expands Initial packets -# helps reduce the amplitude of amplification attacks caused by server -# responses toward an unverified client address; see Section 8. -# -# Datagrams containing Initial packets MAY exceed 1200 bytes if the -# sender believes that the network path and peer both support the size -# that it chooses. -# -# A server MUST discard an Initial packet that is carried in a UDP -# datagram with a payload that is smaller than the smallest allowed -# maximum datagram size of 1200 bytes. A server MAY also immediately -# close the connection by sending a CONNECTION_CLOSE frame with an -# error code of PROTOCOL_VIOLATION; see Section 10.2.3. -# -# The server MUST also limit the number of bytes it sends before -# validating the address of the client; see Section 8. - -[[spec]] -level = "MUST" -quote = ''' -A client MUST expand the payload of all UDP datagrams carrying -Initial packets to at least the smallest allowed maximum datagram -size of 1200 bytes by adding PADDING frames to the Initial packet or -by coalescing the Initial packet; see Section 12.2. -''' - -[[spec]] -level = "MUST" -quote = ''' -Similarly, a server MUST expand the payload of all UDP -datagrams carrying ack-eliciting Initial packets to at least the -smallest allowed maximum datagram size of 1200 bytes. -''' - -[[spec]] -level = "MAY" -quote = ''' -Datagrams containing Initial packets MAY exceed 1200 bytes if the -sender believes that the network path and peer both support the size -that it chooses. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST discard an Initial packet that is carried in a UDP -datagram with a payload that is smaller than the smallest allowed -maximum datagram size of 1200 bytes. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY also immediately -close the connection by sending a CONNECTION_CLOSE frame with an -error code of PROTOCOL_VIOLATION; see Section 10.2.3. -''' - -[[spec]] -level = "MUST" -quote = ''' -The server MUST also limit the number of bytes it sends before -validating the address of the client; see Section 8. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/14.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/14.2.1.toml deleted file mode 100644 index 40630d3890..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/14.2.1.toml +++ /dev/null @@ -1,92 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.2.1" - -# 14.2.1. Handling of ICMP Messages by PMTUD -# -# PMTUD [RFC1191] [RFC8201] relies on reception of ICMP messages (that -# is, IPv6 Packet Too Big (PTB) messages) that indicate when an IP -# packet is dropped because it is larger than the local router MTU. -# DPLPMTUD can also optionally use these messages. This use of ICMP -# messages is potentially vulnerable to attacks by entities that cannot -# observe packets but might successfully guess the addresses used on -# the path. These attacks could reduce the PMTU to a bandwidth- -# inefficient value. -# -# An endpoint MUST ignore an ICMP message that claims the PMTU has -# decreased below QUIC's smallest allowed maximum datagram size. -# -# The requirements for generating ICMP [RFC1812] [RFC4443] state that -# the quoted packet should contain as much of the original packet as -# possible without exceeding the minimum MTU for the IP version. The -# size of the quoted packet can actually be smaller, or the information -# unintelligible, as described in Section 1.1 of [DPLPMTUD]. -# -# QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect -# from packet injection as specified in [RFC8201] and Section 5.2 of -# [RFC8085]. This validation SHOULD use the quoted packet supplied in -# the payload of an ICMP message to associate the message with a -# corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). -# ICMP message validation MUST include matching IP addresses and UDP -# ports [RFC8085] and, when possible, connection IDs to an active QUIC -# session. The endpoint SHOULD ignore all ICMP messages that fail -# validation. -# -# An endpoint MUST NOT increase the PMTU based on ICMP messages; see -# Item 6 in Section 3 of [DPLPMTUD]. Any reduction in QUIC's maximum -# datagram size in response to ICMP messages MAY be provisional until -# QUIC's loss detection algorithm determines that the quoted packet has -# actually been lost. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST ignore an ICMP message that claims the PMTU has -decreased below QUIC's smallest allowed maximum datagram size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect -from packet injection as specified in [RFC8201] and Section 5.2 of -[RFC8085]. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -This validation SHOULD use the quoted packet supplied in -the payload of an ICMP message to associate the message with a -corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). -''' - -[[spec]] -level = "MUST" -quote = ''' -ICMP message validation MUST include matching IP addresses and UDP -ports [RFC8085] and, when possible, connection IDs to an active QUIC -session. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The endpoint SHOULD ignore all ICMP messages that fail -validation. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT increase the PMTU based on ICMP messages; see -Item 6 in Section 3 of [DPLPMTUD]. -''' - -[[spec]] -level = "MAY" -quote = ''' -Any reduction in QUIC's maximum -datagram size in response to ICMP messages MAY be provisional until -QUIC's loss detection algorithm determines that the quoted packet has -actually been lost. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/14.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/14.2.toml deleted file mode 100644 index ad6b65370c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/14.2.toml +++ /dev/null @@ -1,97 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.2" - -# 14.2. Path Maximum Transmission Unit -# -# The PMTU is the maximum size of the entire IP packet, including the -# IP header, UDP header, and UDP payload. The UDP payload includes one -# or more QUIC packet headers and protected payloads. The PMTU can -# depend on path characteristics and can therefore change over time. -# The largest UDP payload an endpoint sends at any given time is -# referred to as the endpoint's maximum datagram size. -# -# An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD -# (Section 14.2.1) to determine whether the path to a destination will -# support a desired maximum datagram size without fragmentation. In -# the absence of these mechanisms, QUIC endpoints SHOULD NOT send -# datagrams larger than the smallest allowed maximum datagram size. -# -# Both DPLPMTUD and PMTUD send datagrams that are larger than the -# current maximum datagram size, referred to as PMTU probes. All QUIC -# packets that are not sent in a PMTU probe SHOULD be sized to fit -# within the maximum datagram size to avoid the datagram being -# fragmented or dropped [RFC8085]. -# -# If a QUIC endpoint determines that the PMTU between any pair of local -# and remote IP addresses cannot support the smallest allowed maximum -# datagram size of 1200 bytes, it MUST immediately cease sending QUIC -# packets, except for those in PMTU probes or those containing -# CONNECTION_CLOSE frames, on the affected path. An endpoint MAY -# terminate the connection if an alternative path cannot be found. -# -# Each pair of local and remote addresses could have a different PMTU. -# QUIC implementations that implement any kind of PMTU discovery -# therefore SHOULD maintain a maximum datagram size for each -# combination of local and remote IP addresses. -# -# A QUIC implementation MAY be more conservative in computing the -# maximum datagram size to allow for unknown tunnel overheads or IP -# header options/extensions. - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD -(Section 14.2.1) to determine whether the path to a destination will -support a desired maximum datagram size without fragmentation. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In -the absence of these mechanisms, QUIC endpoints SHOULD NOT send -datagrams larger than the smallest allowed maximum datagram size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -All QUIC -packets that are not sent in a PMTU probe SHOULD be sized to fit -within the maximum datagram size to avoid the datagram being -fragmented or dropped [RFC8085]. -''' - -[[spec]] -level = "MUST" -quote = ''' -If a QUIC endpoint determines that the PMTU between any pair of local -and remote IP addresses cannot support the smallest allowed maximum -datagram size of 1200 bytes, it MUST immediately cease sending QUIC -packets, except for those in PMTU probes or those containing -CONNECTION_CLOSE frames, on the affected path. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY -terminate the connection if an alternative path cannot be found. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -QUIC implementations that implement any kind of PMTU discovery -therefore SHOULD maintain a maximum datagram size for each -combination of local and remote IP addresses. -''' - -[[spec]] -level = "MAY" -quote = ''' -A QUIC implementation MAY be more conservative in computing the -maximum datagram size to allow for unknown tunnel overheads or IP -header options/extensions. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/14.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/14.3.toml deleted file mode 100644 index 83990539e2..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/14.3.toml +++ /dev/null @@ -1,26 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.3" - -# 14.3. Datagram Packetization Layer PMTU Discovery -# -# DPLPMTUD [DPLPMTUD] relies on tracking loss or acknowledgment of QUIC -# packets that are carried in PMTU probes. PMTU probes for DPLPMTUD -# that use the PADDING frame implement "Probing using padding data", as -# defined in Section 4.1 of [DPLPMTUD]. -# -# Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of -# [DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum -# datagram size. The MIN_PLPMTU is the same as the BASE_PLPMTU. -# -# QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum -# Packet Size (MPS) (Section 4.4 of [DPLPMTUD]) for each combination of -# local and remote IP addresses. This corresponds to the maximum -# datagram size. - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of -[DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum -datagram size. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/14.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/14.4.toml deleted file mode 100644 index 09b2a045a6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/14.4.toml +++ /dev/null @@ -1,24 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-14.4" - -# 14.4. Sending QUIC PMTU Probes -# -# PMTU probes are ack-eliciting packets. -# -# Endpoints could limit the content of PMTU probes to PING and PADDING -# frames, since packets that are larger than the current maximum -# datagram size are more likely to be dropped by the network. Loss of -# a QUIC packet that is carried in a PMTU probe is therefore not a -# reliable indication of congestion and SHOULD NOT trigger a congestion -# control reaction; see Item 7 in Section 3 of [DPLPMTUD]. However, -# PMTU probes consume congestion window, which could delay subsequent -# transmission by an application. - -[[spec]] -level = "SHOULD" -quote = ''' -Loss of -a QUIC packet that is carried in a PMTU probe is therefore not a -reliable indication of congestion and SHOULD NOT trigger a congestion -control reaction; see Item 7 in Section 3 of [DPLPMTUD]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/14.toml b/specs/www.rfc-editor.org/rfc/rfc9000/14.toml deleted file mode 100644 index 0e8d382f19..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/14.toml +++ /dev/null @@ -1,82 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-14" - -# 14. Datagram Size -# -# A UDP datagram can include one or more QUIC packets. The datagram -# size refers to the total UDP payload size of a single UDP datagram -# carrying QUIC packets. The datagram size includes one or more QUIC -# packet headers and protected payloads, but not the UDP or IP headers. -# -# The maximum datagram size is defined as the largest size of UDP -# payload that can be sent across a network path using a single UDP -# datagram. QUIC MUST NOT be used if the network path cannot support a -# maximum datagram size of at least 1200 bytes. -# -# QUIC assumes a minimum IP packet size of at least 1280 bytes. This -# is the IPv6 minimum size [IPv6] and is also supported by most modern -# IPv4 networks. Assuming the minimum IP header size of 40 bytes for -# IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this -# results in a maximum datagram size of 1232 bytes for IPv6 and 1252 -# bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are -# expected to be able to support QUIC. -# -# | Note: This requirement to support a UDP payload of 1200 bytes -# | limits the space available for IPv6 extension headers to 32 -# | bytes or IPv4 options to 52 bytes if the path only supports the -# | IPv6 minimum MTU of 1280 bytes. This affects Initial packets -# | and path validation. -# -# Any maximum datagram size larger than 1200 bytes can be discovered -# using Path Maximum Transmission Unit Discovery (PMTUD) (see -# Section 14.2.1) or Datagram Packetization Layer PMTU Discovery -# (DPLPMTUD) (see Section 14.3). -# -# Enforcement of the max_udp_payload_size transport parameter -# (Section 18.2) might act as an additional limit on the maximum -# datagram size. A sender can avoid exceeding this limit, once the -# value is known. However, prior to learning the value of the -# transport parameter, endpoints risk datagrams being lost if they send -# datagrams larger than the smallest allowed maximum datagram size of -# 1200 bytes. -# -# UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 -# [IPv4], the Don't Fragment (DF) bit MUST be set if possible, to -# prevent fragmentation on the path. -# -# QUIC sometimes requires datagrams to be no smaller than a certain -# size; see Section 8.1 as an example. However, the size of a datagram -# is not authenticated. That is, if an endpoint receives a datagram of -# a certain size, it cannot know that the sender sent the datagram at -# the same size. Therefore, an endpoint MUST NOT close a connection -# when it receives a datagram that does not meet size constraints; the -# endpoint MAY discard such datagrams. - -[[spec]] -level = "MUST" -quote = ''' -QUIC MUST NOT be used if the network path cannot support a -maximum datagram size of at least 1200 bytes. -''' - -[[spec]] -level = "MUST" -quote = ''' -UDP datagrams MUST NOT be fragmented at the IP layer. -''' - -[[spec]] -level = "MUST" -quote = ''' -In IPv4 -[IPv4], the Don't Fragment (DF) bit MUST be set if possible, to -prevent fragmentation on the path. -''' - -[[spec]] -level = "MUST" -quote = ''' -Therefore, an endpoint MUST NOT close a connection -when it receives a datagram that does not meet size constraints; the -endpoint MAY discard such datagrams. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/15.toml b/specs/www.rfc-editor.org/rfc/rfc9000/15.toml deleted file mode 100644 index 7811fe9ce8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/15.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-15" - -# 15. Versions -# -# QUIC versions are identified using a 32-bit unsigned number. -# -# The version 0x00000000 is reserved to represent version negotiation. -# This version of the specification is identified by the number -# 0x00000001. -# -# Other versions of QUIC might have different properties from this -# version. The properties of QUIC that are guaranteed to be consistent -# across all versions of the protocol are described in -# [QUIC-INVARIANTS]. -# -# Version 0x00000001 of QUIC uses TLS as a cryptographic handshake -# protocol, as described in [QUIC-TLS]. -# -# Versions with the most significant 16 bits of the version number -# cleared are reserved for use in future IETF consensus documents. -# -# Versions that follow the pattern 0x?a?a?a?a are reserved for use in -# forcing version negotiation to be exercised -- that is, any version -# number where the low four bits of all bytes is 1010 (in binary). A -# client or server MAY advertise support for any of these reserved -# versions. -# -# Reserved version numbers will never represent a real protocol; a -# client MAY use one of these version numbers with the expectation that -# the server will initiate version negotiation; a server MAY advertise -# support for one of these versions and can expect that clients ignore -# the value. - -[[spec]] -level = "MAY" -quote = ''' -A -client or server MAY advertise support for any of these reserved -versions. -''' - -[[spec]] -level = "MAY" -quote = ''' -Reserved version numbers will never represent a real protocol; a -client MAY use one of these version numbers with the expectation that -the server will initiate version negotiation; a server MAY advertise -support for one of these versions and can expect that clients ignore -the value. -''' - -[[spec]] -level = "MAY" -quote = ''' -Reserved version numbers will never represent a real protocol; a -client MAY use one of these version numbers with the expectation that -the server will initiate version negotiation; a server MAY advertise -support for one of these versions and can expect that clients ignore -the value. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.1.toml deleted file mode 100644 index b6ad37f9fa..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.1.toml +++ /dev/null @@ -1,74 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.1" - -# 17.1. Packet Number Encoding and Decoding -# -# Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). -# When present in long or short packet headers, they are encoded in 1 -# to 4 bytes. The number of bits required to represent the packet -# number is reduced by including only the least significant bits of the -# packet number. -# -# The encoded packet number is protected as described in Section 5.4 of -# [QUIC-TLS]. -# -# Prior to receiving an acknowledgment for a packet number space, the -# full packet number MUST be included; it is not to be truncated, as -# described below. -# -# After an acknowledgment is received for a packet number space, the -# sender MUST use a packet number size able to represent more than -# twice as large a range as the difference between the largest -# acknowledged packet number and the packet number being sent. A peer -# receiving the packet will then correctly decode the packet number, -# unless the packet is delayed in transit such that it arrives after -# many higher-numbered packets have been received. An endpoint SHOULD -# use a large enough packet number encoding to allow the packet number -# to be recovered even if the packet arrives after packets that are -# sent afterwards. -# -# As a result, the size of the packet number encoding is at least one -# bit more than the base-2 logarithm of the number of contiguous -# unacknowledged packet numbers, including the new packet. Pseudocode -# and an example for packet number encoding can be found in -# Appendix A.2. -# -# At a receiver, protection of the packet number is removed prior to -# recovering the full packet number. The full packet number is then -# reconstructed based on the number of significant bits present, the -# value of those bits, and the largest packet number received in a -# successfully authenticated packet. Recovering the full packet number -# is necessary to successfully complete the removal of packet -# protection. -# -# Once header protection is removed, the packet number is decoded by -# finding the packet number value that is closest to the next expected -# packet. The next expected packet is the highest received packet -# number plus one. Pseudocode and an example for packet number -# decoding can be found in Appendix A.3. - -[[spec]] -level = "MUST" -quote = ''' -Prior to receiving an acknowledgment for a packet number space, the -full packet number MUST be included; it is not to be truncated, as -described below. -''' - -[[spec]] -level = "MUST" -quote = ''' -After an acknowledgment is received for a packet number space, the -sender MUST use a packet number size able to represent more than -twice as large a range as the difference between the largest -acknowledged packet number and the packet number being sent. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD -use a large enough packet number encoding to allow the packet number -to be recovered even if the packet arrives after packets that are -sent afterwards. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.1.toml deleted file mode 100644 index 2a7e781f4b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.1.toml +++ /dev/null @@ -1,121 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.1" - -# 17.2.1. Version Negotiation Packet -# -# A Version Negotiation packet is inherently not version specific. -# Upon receipt by a client, it will be identified as a Version -# Negotiation packet based on the Version field having a value of 0. -# -# The Version Negotiation packet is a response to a client packet that -# contains a version that is not supported by the server. It is only -# sent by servers. -# -# The layout of a Version Negotiation packet is: -# -# Version Negotiation Packet { -# Header Form (1) = 1, -# Unused (7), -# Version (32) = 0, -# Destination Connection ID Length (8), -# Destination Connection ID (0..2040), -# Source Connection ID Length (8), -# Source Connection ID (0..2040), -# Supported Version (32) ..., -# } -# -# Figure 14: Version Negotiation Packet -# -# The value in the Unused field is set to an arbitrary value by the -# server. Clients MUST ignore the value of this field. Where QUIC -# might be multiplexed with other protocols (see [RFC7983]), servers -# SHOULD set the most significant bit of this field (0x40) to 1 so that -# Version Negotiation packets appear to have the Fixed Bit field. Note -# that other versions of QUIC might not make a similar recommendation. -# -# The Version field of a Version Negotiation packet MUST be set to -# 0x00000000. -# -# The server MUST include the value from the Source Connection ID field -# of the packet it receives in the Destination Connection ID field. -# The value for Source Connection ID MUST be copied from the -# Destination Connection ID of the received packet, which is initially -# randomly selected by a client. Echoing both connection IDs gives -# clients some assurance that the server received the packet and that -# the Version Negotiation packet was not generated by an entity that -# did not observe the Initial packet. -# -# Future versions of QUIC could have different requirements for the -# lengths of connection IDs. In particular, connection IDs might have -# a smaller minimum length or a greater maximum length. Version- -# specific rules for the connection ID therefore MUST NOT influence a -# decision about whether to send a Version Negotiation packet. -# -# The remainder of the Version Negotiation packet is a list of 32-bit -# versions that the server supports. -# -# A Version Negotiation packet is not acknowledged. It is only sent in -# response to a packet that indicates an unsupported version; see -# Section 5.2.2. -# -# The Version Negotiation packet does not include the Packet Number and -# Length fields present in other packets that use the long header form. -# Consequently, a Version Negotiation packet consumes an entire UDP -# datagram. -# -# A server MUST NOT send more than one Version Negotiation packet in -# response to a single UDP datagram. -# -# See Section 6 for a description of the version negotiation process. - -[[spec]] -level = "MUST" -quote = ''' -Clients MUST ignore the value of this field. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Where QUIC -might be multiplexed with other protocols (see [RFC7983]), servers -SHOULD set the most significant bit of this field (0x40) to 1 so that -Version Negotiation packets appear to have the Fixed Bit field. -''' - -[[spec]] -level = "MUST" -quote = ''' -The Version field of a Version Negotiation packet MUST be set to -0x00000000. -''' - -[[spec]] -level = "MUST" -quote = ''' -The server MUST include the value from the Source Connection ID field -of the packet it receives in the Destination Connection ID field. -''' - -[[spec]] -level = "MUST" -quote = ''' -The value for Source Connection ID MUST be copied from the -Destination Connection ID of the received packet, which is initially -randomly selected by a client. -''' - -[[spec]] -level = "MUST" -quote = ''' -Version- -specific rules for the connection ID therefore MUST NOT influence a -decision about whether to send a Version Negotiation packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST NOT send more than one Version Negotiation packet in -response to a single UDP datagram. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.2.toml deleted file mode 100644 index 45aec6aaee..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.2.toml +++ /dev/null @@ -1,105 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.2" - -# 17.2.2. Initial Packet -# -# An Initial packet uses long headers with a type value of 0x00. It -# carries the first CRYPTO frames sent by the client and server to -# perform key exchange, and it carries ACK frames in either direction. -# -# Initial Packet { -# Header Form (1) = 1, -# Fixed Bit (1) = 1, -# Long Packet Type (2) = 0, -# Reserved Bits (2), -# Packet Number Length (2), -# Version (32), -# Destination Connection ID Length (8), -# Destination Connection ID (0..160), -# Source Connection ID Length (8), -# Source Connection ID (0..160), -# Token Length (i), -# Token (..), -# Length (i), -# Packet Number (8..32), -# Packet Payload (8..), -# } -# -# Figure 15: Initial Packet -# -# The Initial packet contains a long header as well as the Length and -# Packet Number fields; see Section 17.2. The first byte contains the -# Reserved and Packet Number Length bits; see also Section 17.2. -# Between the Source Connection ID and Length fields, there are two -# additional fields specific to the Initial packet. -# -# Token Length: A variable-length integer specifying the length of the -# Token field, in bytes. This value is 0 if no token is present. -# Initial packets sent by the server MUST set the Token Length field -# to 0; clients that receive an Initial packet with a non-zero Token -# Length field MUST either discard the packet or generate a -# connection error of type PROTOCOL_VIOLATION. -# -# Token: The value of the token that was previously provided in a -# Retry packet or NEW_TOKEN frame; see Section 8.1. -# -# In order to prevent tampering by version-unaware middleboxes, Initial -# packets are protected with connection- and version-specific keys -# (Initial keys) as described in [QUIC-TLS]. This protection does not -# provide confidentiality or integrity against attackers that can -# observe packets, but it does prevent attackers that cannot observe -# packets from spoofing Initial packets. -# -# The client and server use the Initial packet type for any packet that -# contains an initial cryptographic handshake message. This includes -# all cases where a new packet containing the initial cryptographic -# message needs to be created, such as the packets sent after receiving -# a Retry packet; see Section 17.2.5. -# -# A server sends its first Initial packet in response to a client -# Initial. A server MAY send multiple Initial packets. The -# cryptographic key exchange could require multiple round trips or -# retransmissions of this data. -# -# The payload of an Initial packet includes a CRYPTO frame (or frames) -# containing a cryptographic handshake message, ACK frames, or both. -# PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also -# permitted. An endpoint that receives an Initial packet containing -# other frames can either discard the packet as spurious or treat it as -# a connection error. -# -# The first packet sent by a client always includes a CRYPTO frame that -# contains the start or all of the first cryptographic handshake -# message. The first CRYPTO frame sent always begins at an offset of -# 0; see Section 7. -# -# Note that if the server sends a TLS HelloRetryRequest (see -# Section 4.7 of [QUIC-TLS]), the client will send another series of -# Initial packets. These Initial packets will continue the -# cryptographic handshake and will contain CRYPTO frames starting at an -# offset matching the size of the CRYPTO frames sent in the first -# flight of Initial packets. - -[[spec]] -level = "MUST" -quote = ''' -Initial packets sent by the server MUST set the Token Length field -to 0; clients that receive an Initial packet with a non-zero Token -Length field MUST either discard the packet or generate a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -Initial packets sent by the server MUST set the Token Length field -to 0; clients that receive an Initial packet with a non-zero Token -Length field MUST either discard the packet or generate a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY send multiple Initial packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.3.toml deleted file mode 100644 index 8e6d6f0405..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.3.toml +++ /dev/null @@ -1,94 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.3" - -# 17.2.3. 0-RTT -# -# A 0-RTT packet uses long headers with a type value of 0x01, followed -# by the Length and Packet Number fields; see Section 17.2. The first -# byte contains the Reserved and Packet Number Length bits; see -# Section 17.2. A 0-RTT packet is used to carry "early" data from the -# client to the server as part of the first flight, prior to handshake -# completion. As part of the TLS handshake, the server can accept or -# reject this early data. -# -# See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its -# limitations. -# -# 0-RTT Packet { -# Header Form (1) = 1, -# Fixed Bit (1) = 1, -# Long Packet Type (2) = 1, -# Reserved Bits (2), -# Packet Number Length (2), -# Version (32), -# Destination Connection ID Length (8), -# Destination Connection ID (0..160), -# Source Connection ID Length (8), -# Source Connection ID (0..160), -# Length (i), -# Packet Number (8..32), -# Packet Payload (8..), -# } -# -# Figure 16: 0-RTT Packet -# -# Packet numbers for 0-RTT protected packets use the same space as -# 1-RTT protected packets. -# -# After a client receives a Retry packet, 0-RTT packets are likely to -# have been lost or discarded by the server. A client SHOULD attempt -# to resend data in 0-RTT packets after it sends a new Initial packet. -# New packet numbers MUST be used for any new packets that are sent; as -# described in Section 17.2.5.3, reusing packet numbers could -# compromise packet protection. -# -# A client only receives acknowledgments for its 0-RTT packets once the -# handshake is complete, as defined in Section 4.1.1 of [QUIC-TLS]. -# -# A client MUST NOT send 0-RTT packets once it starts processing 1-RTT -# packets from the server. This means that 0-RTT packets cannot -# contain any response to frames from 1-RTT packets. For instance, a -# client cannot send an ACK frame in a 0-RTT packet, because that can -# only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT -# packet MUST be carried in a 1-RTT packet. -# -# A server SHOULD treat a violation of remembered limits -# (Section 7.4.1) as a connection error of an appropriate type (for -# instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). - -[[spec]] -level = "SHOULD" -quote = ''' -A client SHOULD attempt -to resend data in 0-RTT packets after it sends a new Initial packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -New packet numbers MUST be used for any new packets that are sent; as -described in Section 17.2.5.3, reusing packet numbers could -compromise packet protection. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT send 0-RTT packets once it starts processing 1-RTT -packets from the server. -''' - -[[spec]] -level = "MUST" -quote = ''' -An acknowledgment for a 1-RTT -packet MUST be carried in a 1-RTT packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A server SHOULD treat a violation of remembered limits -(Section 7.4.1) as a connection error of an appropriate type (for -instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.4.toml deleted file mode 100644 index 8b9a7dacf8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.4.toml +++ /dev/null @@ -1,66 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.4" - -# 17.2.4. Handshake Packet -# -# A Handshake packet uses long headers with a type value of 0x02, -# followed by the Length and Packet Number fields; see Section 17.2. -# The first byte contains the Reserved and Packet Number Length bits; -# see Section 17.2. It is used to carry cryptographic handshake -# messages and acknowledgments from the server and client. -# -# Handshake Packet { -# Header Form (1) = 1, -# Fixed Bit (1) = 1, -# Long Packet Type (2) = 2, -# Reserved Bits (2), -# Packet Number Length (2), -# Version (32), -# Destination Connection ID Length (8), -# Destination Connection ID (0..160), -# Source Connection ID Length (8), -# Source Connection ID (0..160), -# Length (i), -# Packet Number (8..32), -# Packet Payload (8..), -# } -# -# Figure 17: Handshake Protected Packet -# -# Once a client has received a Handshake packet from a server, it uses -# Handshake packets to send subsequent cryptographic handshake messages -# and acknowledgments to the server. -# -# The Destination Connection ID field in a Handshake packet contains a -# connection ID that is chosen by the recipient of the packet; the -# Source Connection ID includes the connection ID that the sender of -# the packet wishes to use; see Section 7.2. -# -# Handshake packets have their own packet number space, and thus the -# first Handshake packet sent by a server contains a packet number of -# 0. -# -# The payload of this packet contains CRYPTO frames and could contain -# PING, PADDING, or ACK frames. Handshake packets MAY contain -# CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt -# of Handshake packets with other frames as a connection error of type -# PROTOCOL_VIOLATION. -# -# Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames -# for Handshake packets is discarded -- and no longer retransmitted -- -# when Handshake protection keys are discarded. - -[[spec]] -level = "MAY" -quote = ''' -Handshake packets MAY contain -CONNECTION_CLOSE frames of type 0x1c. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST treat receipt -of Handshake packets with other frames as a connection error of type -PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.1.toml deleted file mode 100644 index 2c8e2917d4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.1.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5.1" - -# 17.2.5.1. Sending a Retry Packet -# -# The server populates the Destination Connection ID with the -# connection ID that the client included in the Source Connection ID of -# the Initial packet. -# -# The server includes a connection ID of its choice in the Source -# Connection ID field. This value MUST NOT be equal to the Destination -# Connection ID field of the packet sent by the client. A client MUST -# discard a Retry packet that contains a Source Connection ID field -# that is identical to the Destination Connection ID field of its -# Initial packet. The client MUST use the value from the Source -# Connection ID field of the Retry packet in the Destination Connection -# ID field of subsequent packets that it sends. -# -# A server MAY send Retry packets in response to Initial and 0-RTT -# packets. A server can either discard or buffer 0-RTT packets that it -# receives. A server can send multiple Retry packets as it receives -# Initial or 0-RTT packets. A server MUST NOT send more than one Retry -# packet in response to a single UDP datagram. - -[[spec]] -level = "MUST" -quote = ''' -This value MUST NOT be equal to the Destination -Connection ID field of the packet sent by the client. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST -discard a Retry packet that contains a Source Connection ID field -that is identical to the Destination Connection ID field of its -Initial packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -The client MUST use the value from the Source -Connection ID field of the Retry packet in the Destination Connection -ID field of subsequent packets that it sends. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY send Retry packets in response to Initial and 0-RTT -packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST NOT send more than one Retry -packet in response to a single UDP datagram. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.2.toml deleted file mode 100644 index b6d0c2240e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.2.toml +++ /dev/null @@ -1,69 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5.2" - -# 17.2.5.2. Handling a Retry Packet -# -# A client MUST accept and process at most one Retry packet for each -# connection attempt. After the client has received and processed an -# Initial or Retry packet from the server, it MUST discard any -# subsequent Retry packets that it receives. -# -# Clients MUST discard Retry packets that have a Retry Integrity Tag -# that cannot be validated; see Section 5.8 of [QUIC-TLS]. This -# diminishes an attacker's ability to inject a Retry packet and -# protects against accidental corruption of Retry packets. A client -# MUST discard a Retry packet with a zero-length Retry Token field. -# -# The client responds to a Retry packet with an Initial packet that -# includes the provided Retry token to continue connection -# establishment. -# -# A client sets the Destination Connection ID field of this Initial -# packet to the value from the Source Connection ID field in the Retry -# packet. Changing the Destination Connection ID field also results in -# a change to the keys used to protect the Initial packet. It also -# sets the Token field to the token provided in the Retry packet. The -# client MUST NOT change the Source Connection ID because the server -# could include the connection ID as part of its token validation -# logic; see Section 8.1.4. -# -# A Retry packet does not include a packet number and cannot be -# explicitly acknowledged by a client. - -[[spec]] -level = "MUST" -quote = ''' -A client MUST accept and process at most one Retry packet for each -connection attempt. -''' - -[[spec]] -level = "MUST" -quote = ''' -After the client has received and processed an -Initial or Retry packet from the server, it MUST discard any -subsequent Retry packets that it receives. -''' - -[[spec]] -level = "MUST" -quote = ''' -Clients MUST discard Retry packets that have a Retry Integrity Tag -that cannot be validated; see Section 5.8 of [QUIC-TLS]. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client -MUST discard a Retry packet with a zero-length Retry Token field. -''' - -[[spec]] -level = "MUST" -quote = ''' -The -client MUST NOT change the Source Connection ID because the server -could include the connection ID as part of its token validation -logic; see Section 8.1.4. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.3.toml deleted file mode 100644 index 4d8be22653..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.3.toml +++ /dev/null @@ -1,77 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5.3" - -# 17.2.5.3. Continuing a Handshake after Retry -# -# Subsequent Initial packets from the client include the connection ID -# and token values from the Retry packet. The client copies the Source -# Connection ID field from the Retry packet to the Destination -# Connection ID field and uses this value until an Initial packet with -# an updated value is received; see Section 7.2. The value of the -# Token field is copied to all subsequent Initial packets; see -# Section 8.1.2. -# -# Other than updating the Destination Connection ID and Token fields, -# the Initial packet sent by the client is subject to the same -# restrictions as the first Initial packet. A client MUST use the same -# cryptographic handshake message it included in this packet. A server -# MAY treat a packet that contains a different cryptographic handshake -# message as a connection error or discard it. Note that including a -# Token field reduces the available space for the cryptographic -# handshake message, which might result in the client needing to send -# multiple Initial packets. -# -# A client MAY attempt 0-RTT after receiving a Retry packet by sending -# 0-RTT packets to the connection ID provided by the server. -# -# A client MUST NOT reset the packet number for any packet number space -# after processing a Retry packet. In particular, 0-RTT packets -# contain confidential information that will most likely be -# retransmitted on receiving a Retry packet. The keys used to protect -# these new 0-RTT packets will not change as a result of responding to -# a Retry packet. However, the data sent in these packets could be -# different than what was sent earlier. Sending these new packets with -# the same packet number is likely to compromise the packet protection -# for those packets because the same key and nonce could be used to -# protect different content. A server MAY abort the connection if it -# detects that the client reset the packet number. -# -# The connection IDs used in Initial and Retry packets exchanged -# between client and server are copied to the transport parameters and -# validated as described in Section 7.3. - -[[spec]] -level = "MUST" -quote = ''' -A client MUST use the same -cryptographic handshake message it included in this packet. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server -MAY treat a packet that contains a different cryptographic handshake -message as a connection error or discard it. -''' - -[[spec]] -level = "MAY" -quote = ''' -A client MAY attempt 0-RTT after receiving a Retry packet by sending -0-RTT packets to the connection ID provided by the server. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT reset the packet number for any packet number space -after processing a Retry packet. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY abort the connection if it -detects that the client reset the packet number. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.toml deleted file mode 100644 index 988ccad45b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.5.toml +++ /dev/null @@ -1,44 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.5" - -# 17.2.5. Retry Packet -# -# As shown in Figure 18, a Retry packet uses a long packet header with -# a type value of 0x03. It carries an address validation token created -# by the server. It is used by a server that wishes to perform a -# retry; see Section 8.1. -# -# Retry Packet { -# Header Form (1) = 1, -# Fixed Bit (1) = 1, -# Long Packet Type (2) = 3, -# Unused (4), -# Version (32), -# Destination Connection ID Length (8), -# Destination Connection ID (0..160), -# Source Connection ID Length (8), -# Source Connection ID (0..160), -# Retry Token (..), -# Retry Integrity Tag (128), -# } -# -# Figure 18: Retry Packet -# -# A Retry packet does not contain any protected fields. The value in -# the Unused field is set to an arbitrary value by the server; a client -# MUST ignore these bits. In addition to the fields from the long -# header, it contains these additional fields: -# -# Retry Token: An opaque token that the server can use to validate the -# client's address. -# -# Retry Integrity Tag: Defined in Section 5.8 ("Retry Packet -# Integrity") of [QUIC-TLS]. - -[[spec]] -level = "MUST" -quote = ''' -The value in -the Unused field is set to an arbitrary value by the server; a client -MUST ignore these bits. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.2.toml deleted file mode 100644 index 8a14ae65d3..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.2.toml +++ /dev/null @@ -1,204 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2" - -# 17.2. Long Header Packets -# -# Long Header Packet { -# Header Form (1) = 1, -# Fixed Bit (1) = 1, -# Long Packet Type (2), -# Type-Specific Bits (4), -# Version (32), -# Destination Connection ID Length (8), -# Destination Connection ID (0..160), -# Source Connection ID Length (8), -# Source Connection ID (0..160), -# Type-Specific Payload (..), -# } -# -# Figure 13: Long Header Packet Format -# -# Long headers are used for packets that are sent prior to the -# establishment of 1-RTT keys. Once 1-RTT keys are available, a sender -# switches to sending packets using the short header (Section 17.3). -# The long form allows for special packets -- such as the Version -# Negotiation packet -- to be represented in this uniform fixed-length -# packet format. Packets that use the long header contain the -# following fields: -# -# Header Form: 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, unless the -# packet is a Version Negotiation packet. Packets containing a zero -# value for this bit are not valid packets in this version and MUST -# be discarded. A value of 1 for this bit allows QUIC to coexist -# with other protocols; see [RFC7983]. -# -# Long Packet Type: The next two bits (those with a mask of 0x30) of -# byte 0 contain a packet type. Packet types are listed in Table 5. -# -# Type-Specific Bits: The semantics of the lower four bits (those with -# a mask of 0x0f) of byte 0 are determined by the packet type. -# -# Version: The QUIC Version is a 32-bit field that follows the first -# byte. This field indicates the version of QUIC that is in use and -# determines how the rest of the protocol fields are interpreted. -# -# 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. In QUIC version 1, this value MUST NOT exceed -# 20 bytes. Endpoints that receive a version 1 long header with a -# value larger than 20 MUST drop the packet. In order to properly -# form a Version Negotiation packet, servers SHOULD be able to read -# longer connection IDs from other QUIC versions. -# -# Destination Connection ID: The Destination Connection ID field -# follows the Destination Connection ID Length field, which -# indicates the length of this field. Section 7.2 describes the use -# of this field in more detail. -# -# 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. In QUIC version 1, this value MUST NOT -# exceed 20 bytes. Endpoints that receive a version 1 long header -# with a value larger than 20 MUST drop the packet. In order to -# properly form a Version Negotiation packet, servers SHOULD be able -# to read longer connection IDs from other QUIC versions. -# -# Source Connection ID: The Source Connection ID field follows the -# Source Connection ID Length field, which indicates the length of -# this field. Section 7.2 describes the use of this field in more -# detail. -# -# Type-Specific Payload: The remainder of the packet, if any, is type -# specific. -# -# In this version of QUIC, the following packet types with the long -# header are defined: -# -# +======+===========+================+ -# | Type | Name | Section | -# +======+===========+================+ -# | 0x00 | Initial | Section 17.2.2 | -# +------+-----------+----------------+ -# | 0x01 | 0-RTT | Section 17.2.3 | -# +------+-----------+----------------+ -# | 0x02 | Handshake | Section 17.2.4 | -# +------+-----------+----------------+ -# | 0x03 | Retry | Section 17.2.5 | -# +------+-----------+----------------+ -# -# Table 5: Long Header Packet Types -# -# The header form bit, Destination and Source Connection ID lengths, -# Destination and Source Connection ID fields, and Version fields of a -# long header packet are version independent. The other fields in the -# first byte are version specific. See [QUIC-INVARIANTS] for details -# on how packets from different versions of QUIC are interpreted. -# -# The interpretation of the fields and the payload are specific to a -# version and packet type. While type-specific semantics for this -# version are described in the following sections, several long header -# packets in this version of QUIC contain these additional fields: -# -# Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are -# reserved across multiple packet types. These bits are protected -# using header protection; see Section 5.4 of [QUIC-TLS]. The value -# included prior to protection MUST be set to 0. An endpoint MUST -# treat receipt of a packet that has a non-zero value for these bits -# after removing both packet and header protection as a connection -# error of type PROTOCOL_VIOLATION. Discarding such a packet after -# only removing header protection can expose the endpoint to -# attacks; see Section 9.5 of [QUIC-TLS]. -# -# Packet Number Length: In packet types that contain a Packet Number -# field, the least significant two bits (those with a mask of 0x03) -# of byte 0 contain the length of the Packet Number field, encoded -# as an unsigned two-bit integer that is one less than the length of -# the Packet Number field in bytes. That is, the length of the -# Packet Number field is the value of this field plus one. These -# bits are protected using header protection; see Section 5.4 of -# [QUIC-TLS]. -# -# Length: This is the length of the remainder of the packet (that is, -# the Packet Number and Payload fields) in bytes, encoded as a -# variable-length integer (Section 16). -# -# Packet Number: This field is 1 to 4 bytes long. The packet number -# is protected using header protection; see Section 5.4 of -# [QUIC-TLS]. The length of the Packet Number field is encoded in -# the Packet Number Length bits of byte 0; see above. -# -# Packet Payload: This is the payload of the packet -- containing a -# sequence of frames -- that is protected using packet protection. - -[[spec]] -level = "MUST" -quote = ''' -Packets containing a zero -value for this bit are not valid packets in this version and MUST -be discarded. -''' - -[[spec]] -level = "MUST" -quote = ''' -In QUIC version 1, this value MUST NOT exceed -20 bytes. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints that receive a version 1 long header with a -value larger than 20 MUST drop the packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In order to properly -form a Version Negotiation packet, servers SHOULD be able to read -longer connection IDs from other QUIC versions. -''' - -[[spec]] -level = "MUST" -quote = ''' -In QUIC version 1, this value MUST NOT -exceed 20 bytes. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints that receive a version 1 long header -with a value larger than 20 MUST drop the packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In order to -properly form a Version Negotiation packet, servers SHOULD be able -to read longer connection IDs from other QUIC versions. -''' - -[[spec]] -level = "MUST" -quote = ''' -The value -included prior to protection MUST be set to 0. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST -treat receipt of a packet that has a non-zero value for these bits -after removing both packet and header protection as a connection -error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.3.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.3.1.toml deleted file mode 100644 index 38799d5927..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.3.1.toml +++ /dev/null @@ -1,101 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.3.1" - -# 17.3.1. 1-RTT Packet -# -# A 1-RTT packet uses a short packet header. It is used after the -# version and 1-RTT keys are negotiated. -# -# 1-RTT Packet { -# Header Form (1) = 0, -# Fixed Bit (1) = 1, -# Spin Bit (1), -# Reserved Bits (2), -# Key Phase (1), -# Packet Number Length (2), -# Destination Connection ID (0..160), -# Packet Number (8..32), -# Packet Payload (8..), -# } -# -# Figure 19: 1-RTT Packet -# -# 1-RTT packets contain the following fields: -# -# Header Form: The most significant bit (0x80) of byte 0 is set to 0 -# for the short header. -# -# Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets -# containing a zero value for this bit are not valid packets in this -# version and MUST be discarded. A value of 1 for this bit allows -# QUIC to coexist with other protocols; see [RFC7983]. -# -# Spin Bit: The third most significant bit (0x20) of byte 0 is the -# latency spin bit, set as described in Section 17.4. -# -# Reserved Bits: The next two bits (those with a mask of 0x18) of byte -# 0 are reserved. These bits are protected using header protection; -# see Section 5.4 of [QUIC-TLS]. The value included prior to -# protection MUST be set to 0. An endpoint MUST treat receipt of a -# packet that has a non-zero value for these bits, after removing -# both packet and header protection, as a connection error of type -# PROTOCOL_VIOLATION. Discarding such a packet after only removing -# header protection can expose the endpoint to attacks; see -# Section 9.5 of [QUIC-TLS]. -# -# Key Phase: The next bit (0x04) of byte 0 indicates the key phase, -# which allows a recipient of a packet to identify the packet -# protection keys that are used to protect the packet. See -# [QUIC-TLS] for details. This bit is protected using header -# protection; see Section 5.4 of [QUIC-TLS]. -# -# Packet Number Length: The least significant two bits (those with a -# mask of 0x03) of byte 0 contain the length of the Packet Number -# field, encoded as an unsigned two-bit integer that is one less -# than the length of the Packet Number field in bytes. That is, the -# length of the Packet Number field is the value of this field plus -# one. These bits are protected using header protection; see -# Section 5.4 of [QUIC-TLS]. -# -# Destination Connection ID: The Destination Connection ID is a -# connection ID that is chosen by the intended recipient of the -# packet. See Section 5.1 for more details. -# -# Packet Number: The Packet Number field is 1 to 4 bytes long. The -# packet number is protected using header protection; see -# Section 5.4 of [QUIC-TLS]. The length of the Packet Number field -# is encoded in Packet Number Length field. See Section 17.1 for -# details. -# -# Packet Payload: 1-RTT packets always include a 1-RTT protected -# payload. -# -# The header form bit and the Destination Connection ID field of a -# short header packet are version independent. The remaining fields -# are specific to the selected QUIC version. See [QUIC-INVARIANTS] for -# details on how packets from different versions of QUIC are -# interpreted. - -[[spec]] -level = "MUST" -quote = ''' -Packets -containing a zero value for this bit are not valid packets in this -version and MUST be discarded. -''' - -[[spec]] -level = "MUST" -quote = ''' -The value included prior to -protection MUST be set to 0. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat receipt of a -packet that has a non-zero value for these bits, after removing -both packet and header protection, as a connection error of type -PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/17.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/17.4.toml deleted file mode 100644 index a4878f5d9a..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/17.4.toml +++ /dev/null @@ -1,110 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.4" - -# 17.4. Latency Spin Bit -# -# The latency spin bit, which is defined for 1-RTT packets -# (Section 17.3.1), enables passive latency monitoring from observation -# points on the network path throughout the duration of a connection. -# The server reflects the spin value received, while the client "spins" -# it after one RTT. On-path observers can measure the time between two -# spin bit toggle events to estimate the end-to-end RTT of a -# connection. -# -# The spin bit is only present in 1-RTT packets, since it is possible -# to measure the initial RTT of a connection by observing the -# handshake. Therefore, the spin bit is available after version -# negotiation and connection establishment are completed. On-path -# measurement and use of the latency spin bit are further discussed in -# [QUIC-MANAGEABILITY]. -# -# The spin bit is an OPTIONAL feature of this version of QUIC. An -# endpoint that does not support this feature MUST disable it, as -# defined below. -# -# Each endpoint unilaterally decides if the spin bit is enabled or -# disabled for a connection. Implementations MUST allow administrators -# of clients and servers to disable the spin bit either globally or on -# a per-connection basis. Even when the spin bit is not disabled by -# the administrator, endpoints MUST disable their use of the spin bit -# for a random selection of at least one in every 16 network paths, or -# for one in every 16 connection IDs, in order to ensure that QUIC -# connections that disable the spin bit are commonly observed on the -# network. As each endpoint disables the spin bit independently, this -# ensures that the spin bit signal is disabled on approximately one in -# eight network paths. -# -# When the spin bit is disabled, endpoints MAY set the spin bit to any -# value and MUST ignore any incoming value. It is RECOMMENDED that -# endpoints set the spin bit to a random value either chosen -# independently for each packet or chosen independently for each -# connection ID. -# -# If the spin bit is enabled for the connection, the endpoint maintains -# a spin value for each network path and sets the spin bit in the -# packet header to the currently stored value when a 1-RTT packet is -# sent on that path. The spin value is initialized to 0 in the -# endpoint for each network path. Each endpoint also remembers the -# highest packet number seen from its peer on each path. -# -# When a server receives a 1-RTT packet that increases the highest -# packet number seen by the server from the client on a given network -# path, it sets the spin value for that path to be equal to the spin -# bit in the received packet. -# -# When a client receives a 1-RTT packet that increases the highest -# packet number seen by the client from the server on a given network -# path, it sets the spin value for that path to the inverse of the spin -# bit in the received packet. -# -# An endpoint resets the spin value for a network path to 0 when -# changing the connection ID being used on that network path. - -[[spec]] -level = "MAY" -quote = ''' -The spin bit is an OPTIONAL feature of this version of QUIC. -''' - -[[spec]] -level = "MUST" -quote = ''' -An -endpoint that does not support this feature MUST disable it, as -defined below. -''' - -[[spec]] -level = "MUST" -quote = ''' -Implementations MUST allow administrators -of clients and servers to disable the spin bit either globally or on -a per-connection basis. -''' - -[[spec]] -level = "MUST" -quote = ''' -Even when the spin bit is not disabled by -the administrator, endpoints MUST disable their use of the spin bit -for a random selection of at least one in every 16 network paths, or -for one in every 16 connection IDs, in order to ensure that QUIC -connections that disable the spin bit are commonly observed on the -network. -''' - -[[spec]] -level = "MUST" -quote = ''' -When the spin bit is disabled, endpoints MAY set the spin bit to any -value and MUST ignore any incoming value. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -It is RECOMMENDED that -endpoints set the spin bit to a random value either chosen -independently for each packet or chosen independently for each -connection ID. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/18.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/18.2.toml deleted file mode 100644 index 209b9e04fc..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/18.2.toml +++ /dev/null @@ -1,291 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-18.2" - -# 18.2. Transport Parameter Definitions -# -# This section details the transport parameters defined in this -# document. -# -# Many transport parameters listed here have integer values. Those -# transport parameters that are identified as integers use a variable- -# length integer encoding; see Section 16. Transport parameters have a -# default value of 0 if the transport parameter is absent, unless -# otherwise stated. -# -# The following transport parameters are defined: -# -# original_destination_connection_id (0x00): This parameter is the -# value of the Destination Connection ID field from the first -# Initial packet sent by the client; see Section 7.3. This -# transport parameter is only sent by a server. -# -# max_idle_timeout (0x01): The maximum idle timeout is a value in -# milliseconds that is encoded as an integer; see (Section 10.1). -# Idle timeout is disabled when both endpoints omit this transport -# parameter or specify a value of 0. -# -# stateless_reset_token (0x02): A stateless reset token is used in -# verifying a stateless reset; see Section 10.3. This parameter is -# a sequence of 16 bytes. This transport parameter MUST NOT be sent -# by a client but MAY be sent by a server. A server that does not -# send this transport parameter cannot use stateless reset -# (Section 10.3) for the connection ID negotiated during the -# handshake. -# -# max_udp_payload_size (0x03): The maximum UDP payload size parameter -# is an integer value that limits the size of UDP payloads that the -# endpoint is willing to receive. UDP datagrams with payloads -# larger than this limit are not likely to be processed by the -# receiver. -# -# The default for this parameter is the maximum permitted UDP -# payload of 65527. Values below 1200 are invalid. -# -# This limit does act as an additional constraint on datagram size -# in the same way as the path MTU, but it is a property of the -# endpoint and not the path; see Section 14. It is expected that -# this is the space an endpoint dedicates to holding incoming -# packets. -# -# initial_max_data (0x04): The initial maximum data parameter is an -# integer value that contains the initial value for the maximum -# amount of data that can be sent on the connection. This is -# equivalent to sending a MAX_DATA (Section 19.9) for the connection -# immediately after completing the handshake. -# -# initial_max_stream_data_bidi_local (0x05): This parameter is an -# integer value specifying the initial flow control limit for -# locally initiated bidirectional streams. This limit applies to -# newly created bidirectional streams opened by the endpoint that -# sends the transport parameter. In client transport parameters, -# this applies to streams with an identifier with the least -# significant two bits set to 0x00; in server transport parameters, -# this applies to streams with the least significant two bits set to -# 0x01. -# -# initial_max_stream_data_bidi_remote (0x06): This parameter is an -# integer value specifying the initial flow control limit for peer- -# initiated bidirectional streams. This limit applies to newly -# created bidirectional streams opened by the endpoint that receives -# the transport parameter. In client transport parameters, this -# applies to streams with an identifier with the least significant -# two bits set to 0x01; in server transport parameters, this applies -# to streams with the least significant two bits set to 0x00. -# -# initial_max_stream_data_uni (0x07): This parameter is an integer -# value specifying the initial flow control limit for unidirectional -# streams. This limit applies to newly created unidirectional -# streams opened by the endpoint that receives the transport -# parameter. In client transport parameters, this applies to -# streams with an identifier with the least significant two bits set -# to 0x03; in server transport parameters, this applies to streams -# with the least significant two bits set to 0x02. -# -# initial_max_streams_bidi (0x08): The initial maximum bidirectional -# streams parameter is an integer value that contains the initial -# maximum number of bidirectional streams the endpoint that receives -# this transport parameter is permitted to initiate. If this -# parameter is absent or zero, the peer cannot open bidirectional -# streams until a MAX_STREAMS frame is sent. Setting this parameter -# is equivalent to sending a MAX_STREAMS (Section 19.11) of the -# corresponding type with the same value. -# -# initial_max_streams_uni (0x09): The initial maximum unidirectional -# streams parameter is an integer value that contains the initial -# maximum number of unidirectional streams the endpoint that -# receives this transport parameter is permitted to initiate. If -# this parameter is absent or zero, the peer cannot open -# unidirectional streams until a MAX_STREAMS frame is sent. Setting -# this parameter is equivalent to sending a MAX_STREAMS -# (Section 19.11) of the corresponding type with the same value. -# -# ack_delay_exponent (0x0a): The acknowledgment delay exponent is an -# integer value indicating an exponent used to decode the ACK Delay -# field in the ACK frame (Section 19.3). If this value is absent, a -# default value of 3 is assumed (indicating a multiplier of 8). -# Values above 20 are invalid. -# -# max_ack_delay (0x0b): The maximum acknowledgment delay is an integer -# value indicating the maximum amount of time in milliseconds by -# which the endpoint will delay sending acknowledgments. This value -# SHOULD include the receiver's expected delays in alarms firing. -# For example, if a receiver sets a timer for 5ms and alarms -# commonly fire up to 1ms late, then it should send a max_ack_delay -# of 6ms. If this value is absent, a default of 25 milliseconds is -# assumed. Values of 2^14 or greater are invalid. -# -# disable_active_migration (0x0c): The disable active migration -# transport parameter is included if the endpoint does not support -# active connection migration (Section 9) on the address being used -# during the handshake. An endpoint that receives this transport -# parameter MUST NOT use a new local address when sending to the -# address that the peer used during the handshake. This transport -# parameter does not prohibit connection migration after a client -# has acted on a preferred_address transport parameter. This -# parameter is a zero-length value. -# -# preferred_address (0x0d): The server's preferred address is used to -# effect a change in server address at the end of the handshake, as -# described in Section 9.6. This transport parameter is only sent -# by a server. Servers MAY choose to only send a preferred address -# of one address family by sending an all-zero address and port -# (0.0.0.0:0 or [::]:0) for the other family. IP addresses are -# encoded in network byte order. -# -# The preferred_address transport parameter contains an address and -# port for both IPv4 and IPv6. The four-byte IPv4 Address field is -# followed by the associated two-byte IPv4 Port field. This is -# followed by a 16-byte IPv6 Address field and two-byte IPv6 Port -# field. After address and port pairs, a Connection ID Length field -# describes the length of the following Connection ID field. -# Finally, a 16-byte Stateless Reset Token field includes the -# stateless reset token associated with the connection ID. The -# format of this transport parameter is shown in Figure 22 below. -# -# The Connection ID field and the Stateless Reset Token field -# contain an alternative connection ID that has a sequence number of -# 1; see Section 5.1.1. Having these values sent alongside the -# preferred address ensures that there will be at least one unused -# active connection ID when the client initiates migration to the -# preferred address. -# -# The Connection ID and Stateless Reset Token fields of a preferred -# address are identical in syntax and semantics to the corresponding -# fields of a NEW_CONNECTION_ID frame (Section 19.15). A server -# that chooses a zero-length connection ID MUST NOT provide a -# preferred address. Similarly, a server MUST NOT include a zero- -# length connection ID in this transport parameter. A client MUST -# treat a violation of these requirements as a connection error of -# type TRANSPORT_PARAMETER_ERROR. -# -# Preferred Address { -# IPv4 Address (32), -# IPv4 Port (16), -# IPv6 Address (128), -# IPv6 Port (16), -# Connection ID Length (8), -# Connection ID (..), -# Stateless Reset Token (128), -# } -# -# Figure 22: Preferred Address Format -# -# active_connection_id_limit (0x0e): This is an integer value -# specifying the maximum number of connection IDs from the peer that -# an endpoint is willing to store. This value includes the -# connection ID received during the handshake, that received in the -# preferred_address transport parameter, and those received in -# NEW_CONNECTION_ID frames. The value of the -# active_connection_id_limit parameter MUST be at least 2. An -# endpoint that receives a value less than 2 MUST close the -# connection with an error of type TRANSPORT_PARAMETER_ERROR. If -# this transport parameter is absent, a default of 2 is assumed. If -# an endpoint issues a zero-length connection ID, it will never send -# a NEW_CONNECTION_ID frame and therefore ignores the -# active_connection_id_limit value received from its peer. -# -# initial_source_connection_id (0x0f): This is the value that the -# endpoint included in the Source Connection ID field of the first -# Initial packet it sends for the connection; see Section 7.3. -# -# retry_source_connection_id (0x10): This is the value that the server -# included in the Source Connection ID field of a Retry packet; see -# Section 7.3. This transport parameter is only sent by a server. -# -# If present, transport parameters that set initial per-stream flow -# control limits (initial_max_stream_data_bidi_local, -# initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) -# are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on -# every stream of the corresponding type immediately after opening. If -# the transport parameter is absent, streams of that type start with a -# flow control limit of 0. -# -# A client MUST NOT include any server-only transport parameter: -# original_destination_connection_id, preferred_address, -# retry_source_connection_id, or stateless_reset_token. A server MUST -# treat receipt of any of these transport parameters as a connection -# error of type TRANSPORT_PARAMETER_ERROR. - -[[spec]] -level = "MUST" -quote = ''' -This transport parameter MUST NOT be sent -by a client but MAY be sent by a server. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -This value -SHOULD include the receiver's expected delays in alarms firing. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that receives this transport -parameter MUST NOT use a new local address when sending to the -address that the peer used during the handshake. -''' - -[[spec]] -level = "MAY" -quote = ''' -Servers MAY choose to only send a preferred address -of one address family by sending an all-zero address and port -(0.0.0.0:0 or [::]:0) for the other family. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server -that chooses a zero-length connection ID MUST NOT provide a -preferred address. -''' - -[[spec]] -level = "MUST" -quote = ''' -Similarly, a server MUST NOT include a zero- -length connection ID in this transport parameter. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST -treat a violation of these requirements as a connection error of -type TRANSPORT_PARAMETER_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -The value of the -active_connection_id_limit parameter MUST be at least 2. -''' - -[[spec]] -level = "MUST" -quote = ''' -An -endpoint that receives a value less than 2 MUST close the -connection with an error of type TRANSPORT_PARAMETER_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT include any server-only transport parameter: -original_destination_connection_id, preferred_address, -retry_source_connection_id, or stateless_reset_token. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST -treat receipt of any of these transport parameters as a connection -error of type TRANSPORT_PARAMETER_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.10.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.10.toml deleted file mode 100644 index d92e57693d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.10.toml +++ /dev/null @@ -1,79 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.10" - -# 19.10. MAX_STREAM_DATA Frames -# -# A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform -# a peer of the maximum amount of data that can be sent on a stream. -# -# A MAX_STREAM_DATA frame can be sent for streams in the "Recv" state; -# see Section 3.2. Receiving a MAX_STREAM_DATA frame for a locally -# initiated stream that has not yet been created MUST be treated as a -# connection error of type STREAM_STATE_ERROR. An endpoint that -# receives a MAX_STREAM_DATA frame for a receive-only stream MUST -# terminate the connection with error STREAM_STATE_ERROR. -# -# MAX_STREAM_DATA frames are formatted as shown in Figure 34. -# -# MAX_STREAM_DATA Frame { -# Type (i) = 0x11, -# Stream ID (i), -# Maximum Stream Data (i), -# } -# -# Figure 34: MAX_STREAM_DATA Frame Format -# -# MAX_STREAM_DATA frames contain the following fields: -# -# Stream ID: The stream ID of the affected stream, encoded as a -# variable-length integer. -# -# Maximum Stream Data: A variable-length integer indicating the -# maximum amount of data that can be sent on the identified stream, -# in units of bytes. -# -# When counting data toward this limit, an endpoint accounts for the -# largest received offset of data that is sent or received on the -# stream. Loss or reordering can mean that the largest received offset -# on a stream can be greater than the total size of data received on -# that stream. Receiving STREAM frames might not increase the largest -# received offset. -# -# The data sent on a stream MUST NOT exceed the largest maximum stream -# data value advertised by the receiver. An endpoint MUST terminate a -# connection with an error of type FLOW_CONTROL_ERROR if it receives -# more data than the largest maximum stream data that it has sent for -# the affected stream. This includes violations of remembered limits -# in Early Data; see Section 7.4.1. - -[[spec]] -level = "MUST" -quote = ''' -Receiving a MAX_STREAM_DATA frame for a locally -initiated stream that has not yet been created MUST be treated as a -connection error of type STREAM_STATE_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that -receives a MAX_STREAM_DATA frame for a receive-only stream MUST -terminate the connection with error STREAM_STATE_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -The data sent on a stream MUST NOT exceed the largest maximum stream -data value advertised by the receiver. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST terminate a -connection with an error of type FLOW_CONTROL_ERROR if it receives -more data than the largest maximum stream data that it has sent for -the affected stream. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.11.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.11.toml deleted file mode 100644 index ff8aa51236..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.11.toml +++ /dev/null @@ -1,76 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.11" - -# 19.11. MAX_STREAMS Frames -# -# A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the -# cumulative number of streams of a given type it is permitted to open. -# A MAX_STREAMS frame with a type of 0x12 applies to bidirectional -# streams, and a MAX_STREAMS frame with a type of 0x13 applies to -# unidirectional streams. -# -# MAX_STREAMS frames are formatted as shown in Figure 35. -# -# MAX_STREAMS Frame { -# Type (i) = 0x12..0x13, -# Maximum Streams (i), -# } -# -# Figure 35: MAX_STREAMS Frame Format -# -# MAX_STREAMS frames contain the following field: -# -# Maximum Streams: A count of the cumulative number of streams of the -# corresponding type that can be opened over the lifetime of the -# connection. This value cannot exceed 2^60, as it is not possible -# to encode stream IDs larger than 2^62-1. Receipt of a frame that -# permits opening of a stream larger than this limit MUST be treated -# as a connection error of type FRAME_ENCODING_ERROR. -# -# Loss or reordering can cause an endpoint to receive a MAX_STREAMS -# frame with a lower stream limit than was previously received. -# MAX_STREAMS frames that do not increase the stream limit MUST be -# ignored. -# -# An endpoint MUST NOT open more streams than permitted by the current -# stream limit set by its peer. For instance, a server that receives a -# unidirectional stream limit of 3 is permitted to open streams 3, 7, -# and 11, but not stream 15. An endpoint MUST terminate a connection -# with an error of type STREAM_LIMIT_ERROR if a peer opens more streams -# than was permitted. This includes violations of remembered limits in -# Early Data; see Section 7.4.1. -# -# Note that these frames (and the corresponding transport parameters) -# do not describe the number of streams that can be opened -# concurrently. The limit includes streams that have been closed as -# well as those that are open. - -[[spec]] -level = "MUST" -quote = ''' -Receipt of a frame that -permits opening of a stream larger than this limit MUST be treated -as a connection error of type FRAME_ENCODING_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -MAX_STREAMS frames that do not increase the stream limit MUST be -ignored. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT open more streams than permitted by the current -stream limit set by its peer. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST terminate a connection -with an error of type STREAM_LIMIT_ERROR if a peer opens more streams -than was permitted. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.12.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.12.toml deleted file mode 100644 index 003c290bec..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.12.toml +++ /dev/null @@ -1,31 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.12" - -# 19.12. DATA_BLOCKED Frames -# -# A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes -# to send data but is unable to do so due to connection-level flow -# control; see Section 4. DATA_BLOCKED frames can be used as input to -# tuning of flow control algorithms; see Section 4.2. -# -# DATA_BLOCKED frames are formatted as shown in Figure 36. -# -# DATA_BLOCKED Frame { -# Type (i) = 0x14, -# Maximum Data (i), -# } -# -# Figure 36: DATA_BLOCKED Frame Format -# -# DATA_BLOCKED frames contain the following field: -# -# Maximum Data: A variable-length integer indicating the connection- -# level limit at which blocking occurred. - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes -to send data but is unable to do so due to connection-level flow -control; see Section 4. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.13.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.13.toml deleted file mode 100644 index 0df25ed2a0..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.13.toml +++ /dev/null @@ -1,44 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.13" - -# 19.13. STREAM_DATA_BLOCKED Frames -# -# A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it -# wishes to send data but is unable to do so due to stream-level flow -# control. This frame is analogous to DATA_BLOCKED (Section 19.12). -# -# An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only -# stream MUST terminate the connection with error STREAM_STATE_ERROR. -# -# STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37. -# -# STREAM_DATA_BLOCKED Frame { -# Type (i) = 0x15, -# Stream ID (i), -# Maximum Stream Data (i), -# } -# -# Figure 37: STREAM_DATA_BLOCKED Frame Format -# -# STREAM_DATA_BLOCKED frames contain the following fields: -# -# Stream ID: A variable-length integer indicating the stream that is -# blocked due to flow control. -# -# Maximum Stream Data: A variable-length integer indicating the offset -# of the stream at which the blocking occurred. - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it -wishes to send data but is unable to do so due to stream-level flow -control. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only -stream MUST terminate the connection with error STREAM_STATE_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.14.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.14.toml deleted file mode 100644 index 79d933fbd6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.14.toml +++ /dev/null @@ -1,49 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.14" - -# 19.14. STREAMS_BLOCKED Frames -# -# A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when -# it wishes to open a stream but is unable to do so due to the maximum -# stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED -# frame of type 0x16 is used to indicate reaching the bidirectional -# stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to -# indicate reaching the unidirectional stream limit. -# -# A STREAMS_BLOCKED frame does not open the stream, but informs the -# peer that a new stream was needed and the stream limit prevented the -# creation of the stream. -# -# STREAMS_BLOCKED frames are formatted as shown in Figure 38. -# -# STREAMS_BLOCKED Frame { -# Type (i) = 0x16..0x17, -# Maximum Streams (i), -# } -# -# Figure 38: STREAMS_BLOCKED Frame Format -# -# STREAMS_BLOCKED frames contain the following field: -# -# Maximum Streams: A variable-length integer indicating the maximum -# number of streams allowed at the time the frame was sent. This -# value cannot exceed 2^60, as it is not possible to encode stream -# IDs larger than 2^62-1. Receipt of a frame that encodes a larger -# stream ID MUST be treated as a connection error of type -# STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR. - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when -it wishes to open a stream but is unable to do so due to the maximum -stream limit set by its peer; see Section 19.11. -''' - -[[spec]] -level = "MUST" -quote = ''' -Receipt of a frame that encodes a larger -stream ID MUST be treated as a connection error of type -STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.15.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.15.toml deleted file mode 100644 index 6d1d1d753e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.15.toml +++ /dev/null @@ -1,157 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.15" - -# 19.15. NEW_CONNECTION_ID Frames -# -# An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide -# its peer with alternative connection IDs that can be used to break -# linkability when migrating connections; see Section 9.5. -# -# NEW_CONNECTION_ID frames are formatted as shown in Figure 39. -# -# NEW_CONNECTION_ID Frame { -# Type (i) = 0x18, -# Sequence Number (i), -# Retire Prior To (i), -# Length (8), -# Connection ID (8..160), -# Stateless Reset Token (128), -# } -# -# Figure 39: NEW_CONNECTION_ID Frame Format -# -# NEW_CONNECTION_ID frames contain the following fields: -# -# Sequence Number: The sequence number assigned to the connection ID -# by the sender, encoded as a variable-length integer; see -# Section 5.1.1. -# -# Retire Prior To: A variable-length integer indicating which -# connection IDs should be retired; see Section 5.1.2. -# -# Length: An 8-bit unsigned integer containing the length of the -# connection ID. Values less than 1 and greater than 20 are invalid -# and MUST be treated as a connection error of type -# FRAME_ENCODING_ERROR. -# -# Connection ID: A connection ID of the specified length. -# -# Stateless Reset Token: A 128-bit value that will be used for a -# stateless reset when the associated connection ID is used; see -# Section 10.3. -# -# An endpoint MUST NOT send this frame if it currently requires that -# its peer send packets with a zero-length Destination Connection ID. -# Changing the length of a connection ID to or from zero length makes -# it difficult to identify when the value of the connection ID changed. -# An endpoint that is sending packets with a zero-length Destination -# Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a -# connection error of type PROTOCOL_VIOLATION. -# -# Transmission errors, timeouts, and retransmissions might cause the -# same NEW_CONNECTION_ID frame to be received multiple times. Receipt -# of the same frame multiple times MUST NOT be treated as a connection -# error. A receiver can use the sequence number supplied in the -# NEW_CONNECTION_ID frame to handle receiving the same -# NEW_CONNECTION_ID frame multiple times. -# -# If an endpoint receives a NEW_CONNECTION_ID frame that repeats a -# previously issued connection ID with a different Stateless Reset -# Token field value or a different Sequence Number field value, or if a -# sequence number is used for different connection IDs, the endpoint -# MAY treat that receipt as a connection error of type -# PROTOCOL_VIOLATION. -# -# The Retire Prior To field applies to connection IDs established -# during connection setup and the preferred_address transport -# parameter; see Section 5.1.2. The value in the Retire Prior To field -# MUST be less than or equal to the value in the Sequence Number field. -# Receiving a value in the Retire Prior To field that is greater than -# that in the Sequence Number field MUST be treated as a connection -# error of type FRAME_ENCODING_ERROR. -# -# Once a sender indicates a Retire Prior To value, smaller values sent -# in subsequent NEW_CONNECTION_ID frames have no effect. A receiver -# MUST ignore any Retire Prior To fields that do not increase the -# largest received Retire Prior To value. -# -# An endpoint that receives a NEW_CONNECTION_ID frame with a sequence -# number smaller than the Retire Prior To field of a previously -# received NEW_CONNECTION_ID frame MUST send a corresponding -# RETIRE_CONNECTION_ID frame that retires the newly received connection -# ID, unless it has already done so for that sequence number. - -[[spec]] -level = "MUST" -quote = ''' -Values less than 1 and greater than 20 are invalid -and MUST be treated as a connection error of type -FRAME_ENCODING_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send this frame if it currently requires that -its peer send packets with a zero-length Destination Connection ID. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that is sending packets with a zero-length Destination -Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -Receipt -of the same frame multiple times MUST NOT be treated as a connection -error. -''' - -[[spec]] -level = "MAY" -quote = ''' -If an endpoint receives a NEW_CONNECTION_ID frame that repeats a -previously issued connection ID with a different Stateless Reset -Token field value or a different Sequence Number field value, or if a -sequence number is used for different connection IDs, the endpoint -MAY treat that receipt as a connection error of type -PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -The value in the Retire Prior To field -MUST be less than or equal to the value in the Sequence Number field. -''' - -[[spec]] -level = "MUST" -quote = ''' -Receiving a value in the Retire Prior To field that is greater than -that in the Sequence Number field MUST be treated as a connection -error of type FRAME_ENCODING_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -A receiver -MUST ignore any Retire Prior To fields that do not increase the -largest received Retire Prior To value. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that receives a NEW_CONNECTION_ID frame with a sequence -number smaller than the Retire Prior To field of a previously -received NEW_CONNECTION_ID frame MUST send a corresponding -RETIRE_CONNECTION_ID frame that retires the newly received connection -ID, unless it has already done so for that sequence number. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.16.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.16.toml deleted file mode 100644 index faee8d09a4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.16.toml +++ /dev/null @@ -1,74 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.16" - -# 19.16. RETIRE_CONNECTION_ID Frames -# -# An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to -# indicate that it will no longer use a connection ID that was issued -# by its peer. This includes the connection ID provided during the -# handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a -# request to the peer to send additional connection IDs for future use; -# see Section 5.1. New connection IDs can be delivered to a peer using -# the NEW_CONNECTION_ID frame (Section 19.15). -# -# Retiring a connection ID invalidates the stateless reset token -# associated with that connection ID. -# -# RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40. -# -# RETIRE_CONNECTION_ID Frame { -# Type (i) = 0x19, -# Sequence Number (i), -# } -# -# Figure 40: RETIRE_CONNECTION_ID Frame Format -# -# RETIRE_CONNECTION_ID frames contain the following field: -# -# Sequence Number: The sequence number of the connection ID being -# retired; see Section 5.1.2. -# -# Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number -# greater than any previously sent to the peer MUST be treated as a -# connection error of type PROTOCOL_VIOLATION. -# -# The sequence number specified in a RETIRE_CONNECTION_ID frame MUST -# NOT refer to the Destination Connection ID field of the packet in -# which the frame is contained. The peer MAY treat this as a -# connection error of type PROTOCOL_VIOLATION. -# -# An endpoint cannot send this frame if it was provided with a zero- -# length connection ID by its peer. An endpoint that provides a zero- -# length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID -# frame as a connection error of type PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number -greater than any previously sent to the peer MUST be treated as a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -The sequence number specified in a RETIRE_CONNECTION_ID frame MUST -NOT refer to the Destination Connection ID field of the packet in -which the frame is contained. -''' - -[[spec]] -level = "MAY" -quote = ''' -The peer MAY treat this as a -connection error of type PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that provides a zero- -length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID -frame as a connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.17.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.17.toml deleted file mode 100644 index 1fd528441f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.17.toml +++ /dev/null @@ -1,35 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.17" - -# 19.17. PATH_CHALLENGE Frames -# -# Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check -# reachability to the peer and for path validation during connection -# migration. -# -# PATH_CHALLENGE frames are formatted as shown in Figure 41. -# -# PATH_CHALLENGE Frame { -# Type (i) = 0x1a, -# Data (64), -# } -# -# Figure 41: PATH_CHALLENGE Frame Format -# -# PATH_CHALLENGE frames contain the following field: -# -# Data: This 8-byte field contains arbitrary data. -# -# Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that -# it is easier to receive the packet than it is to guess the value -# correctly. -# -# The recipient of this frame MUST generate a PATH_RESPONSE frame -# (Section 19.18) containing the same Data value. - -[[spec]] -level = "MUST" -quote = ''' -The recipient of this frame MUST generate a PATH_RESPONSE frame -(Section 19.18) containing the same Data value. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.18.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.18.toml deleted file mode 100644 index a438972f19..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.18.toml +++ /dev/null @@ -1,30 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.18" - -# 19.18. PATH_RESPONSE Frames -# -# A PATH_RESPONSE frame (type=0x1b) is sent in response to a -# PATH_CHALLENGE frame. -# -# PATH_RESPONSE frames are formatted as shown in Figure 42. The format -# of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE -# frame; see Section 19.17. -# -# PATH_RESPONSE Frame { -# Type (i) = 0x1b, -# Data (64), -# } -# -# Figure 42: PATH_RESPONSE Frame Format -# -# If the content of a PATH_RESPONSE frame does not match the content of -# a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint -# MAY generate a connection error of type PROTOCOL_VIOLATION. - -[[spec]] -level = "MAY" -quote = ''' -If the content of a PATH_RESPONSE frame does not match the content of -a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint -MAY generate a connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.19.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.19.toml deleted file mode 100644 index 95cead9584..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.19.toml +++ /dev/null @@ -1,67 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.19" - -# 19.19. CONNECTION_CLOSE Frames -# -# An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to -# notify its peer that the connection is being closed. The -# CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors -# at only the QUIC layer, or the absence of errors (with the NO_ERROR -# code). The CONNECTION_CLOSE frame with a type of 0x1d is used to -# signal an error with the application that uses QUIC. -# -# If there are open streams that have not been explicitly closed, they -# are implicitly closed when the connection is closed. -# -# CONNECTION_CLOSE frames are formatted as shown in Figure 43. -# -# CONNECTION_CLOSE Frame { -# Type (i) = 0x1c..0x1d, -# Error Code (i), -# [Frame Type (i)], -# Reason Phrase Length (i), -# Reason Phrase (..), -# } -# -# Figure 43: CONNECTION_CLOSE Frame Format -# -# CONNECTION_CLOSE frames contain the following fields: -# -# Error Code: A variable-length integer that indicates the reason for -# closing this connection. A CONNECTION_CLOSE frame of type 0x1c -# uses codes from the space defined in Section 20.1. A -# CONNECTION_CLOSE frame of type 0x1d uses codes defined by the -# application protocol; see Section 20.2. -# -# Frame Type: A variable-length integer encoding the type of frame -# that triggered the error. A value of 0 (equivalent to the mention -# of the PADDING frame) is used when the frame type is unknown. The -# application-specific variant of CONNECTION_CLOSE (type 0x1d) does -# not include this field. -# -# Reason Phrase Length: A variable-length integer specifying the -# length of the reason phrase in bytes. Because a CONNECTION_CLOSE -# frame cannot be split between packets, any limits on packet size -# will also limit the space available for a reason phrase. -# -# Reason Phrase: Additional diagnostic information for the closure. -# This can be zero length if the sender chooses not to give details -# beyond the Error Code value. This SHOULD be a UTF-8 encoded -# string [RFC3629], though the frame does not carry information, -# such as language tags, that would aid comprehension by any entity -# other than the one that created the text. -# -# The application-specific variant of CONNECTION_CLOSE (type 0x1d) can -# only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an -# application wishes to abandon a connection during the handshake, an -# endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error -# code of APPLICATION_ERROR in an Initial or Handshake packet. - -[[spec]] -level = "SHOULD" -quote = ''' -This SHOULD be a UTF-8 encoded -string [RFC3629], though the frame does not carry information, -such as language tags, that would aid comprehension by any entity -other than the one that created the text. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.20.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.20.toml deleted file mode 100644 index ce12fa74cf..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.20.toml +++ /dev/null @@ -1,36 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.20" - -# 19.20. HANDSHAKE_DONE Frames -# -# The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal -# confirmation of the handshake to the client. -# -# HANDSHAKE_DONE frames are formatted as shown in Figure 44, which -# shows that HANDSHAKE_DONE frames have no content. -# -# HANDSHAKE_DONE Frame { -# Type (i) = 0x1e, -# } -# -# Figure 44: HANDSHAKE_DONE Frame Format -# -# A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST -# NOT send a HANDSHAKE_DONE frame before completing the handshake. A -# server MUST treat receipt of a HANDSHAKE_DONE frame as a connection -# error of type PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -Servers MUST -NOT send a HANDSHAKE_DONE frame before completing the handshake. -''' - -[[spec]] -level = "MUST" -quote = ''' -A -server MUST treat receipt of a HANDSHAKE_DONE frame as a connection -error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.21.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.21.toml deleted file mode 100644 index e856212ae8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.21.toml +++ /dev/null @@ -1,60 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.21" - -# 19.21. Extension Frames -# -# QUIC frames do not use a self-describing encoding. An endpoint -# therefore needs to understand the syntax of all frames before it can -# successfully process a packet. This allows for efficient encoding of -# frames, but it means that an endpoint cannot send a frame of a type -# that is unknown to its peer. -# -# An extension to QUIC that wishes to use a new type of frame MUST -# first ensure that a peer is able to understand the frame. An -# endpoint can use a transport parameter to signal its willingness to -# receive extension frame types. One transport parameter can indicate -# support for one or more extension frame types. -# -# Extensions that modify or replace core protocol functionality -# (including frame types) will be difficult to combine with other -# extensions that modify or replace the same functionality unless the -# behavior of the combination is explicitly defined. Such extensions -# SHOULD define their interaction with previously defined extensions -# modifying the same protocol components. -# -# Extension frames MUST be congestion controlled and MUST cause an ACK -# frame to be sent. The exception is extension frames that replace or -# supplement the ACK frame. Extension frames are not included in flow -# control unless specified in the extension. -# -# An IANA registry is used to manage the assignment of frame types; see -# Section 22.4. - -[[spec]] -level = "MUST" -quote = ''' -An extension to QUIC that wishes to use a new type of frame MUST -first ensure that a peer is able to understand the frame. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Such extensions -SHOULD define their interaction with previously defined extensions -modifying the same protocol components. -''' - -[[spec]] -level = "MUST" -quote = ''' -Extension frames MUST be congestion controlled and MUST cause an ACK -frame to be sent. -''' - -[[spec]] -level = "MUST" -quote = ''' -Extension frames MUST be congestion controlled and MUST cause an ACK -frame to be sent. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.3.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.3.1.toml deleted file mode 100644 index 0347d57532..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.3.1.toml +++ /dev/null @@ -1,70 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.3.1" - -# 19.3.1. ACK Ranges -# -# Each ACK Range consists of alternating Gap and ACK Range Length -# values in descending packet number order. ACK Ranges can be -# repeated. The number of Gap and ACK Range Length values is -# determined by the ACK Range Count field; one of each value is present -# for each value in the ACK Range Count field. -# -# ACK Ranges are structured as shown in Figure 26. -# -# ACK Range { -# Gap (i), -# ACK Range Length (i), -# } -# -# Figure 26: ACK Ranges -# -# The fields that form each ACK Range are: -# -# Gap: A variable-length integer indicating the number of contiguous -# unacknowledged packets preceding the packet number one lower than -# the smallest in the preceding ACK Range. -# -# ACK Range Length: A variable-length integer indicating the number of -# contiguous acknowledged packets preceding the largest packet -# number, as determined by the preceding Gap. -# -# Gap and ACK Range Length values use a relative integer encoding for -# efficiency. Though each encoded value is positive, the values are -# subtracted, so that each ACK Range describes progressively lower- -# numbered packets. -# -# Each ACK Range acknowledges a contiguous range of packets by -# indicating the number of acknowledged packets that precede the -# largest packet number in that range. A value of 0 indicates that -# only the largest packet number is acknowledged. Larger ACK Range -# values indicate a larger range, with corresponding lower values for -# the smallest packet number in the range. Thus, given a largest -# packet number for the range, the smallest value is determined by the -# following formula: -# -# smallest = largest - ack_range -# -# An ACK Range acknowledges all packets between the smallest packet -# number and the largest, inclusive. -# -# The largest value for an ACK Range is determined by cumulatively -# subtracting the size of all preceding ACK Range Lengths and Gaps. -# -# Each Gap indicates a range of packets that are not being -# acknowledged. The number of packets in the gap is one higher than -# the encoded value of the Gap field. -# -# The value of the Gap field establishes the largest packet number -# value for the subsequent ACK Range using the following formula: -# -# largest = previous_smallest - gap - 2 -# -# If any computed packet number is negative, an endpoint MUST generate -# a connection error of type FRAME_ENCODING_ERROR. - -[[spec]] -level = "MUST" -quote = ''' -If any computed packet number is negative, an endpoint MUST generate -a connection error of type FRAME_ENCODING_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.3.toml deleted file mode 100644 index 76d192792f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.3.toml +++ /dev/null @@ -1,85 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.3" - -# 19.3. ACK Frames -# -# Receivers send ACK frames (types 0x02 and 0x03) to inform senders of -# packets they have received and processed. The ACK frame contains one -# or more ACK Ranges. ACK Ranges identify acknowledged packets. If -# the frame type is 0x03, ACK frames also contain the cumulative count -# of QUIC packets with associated ECN marks received on the connection -# up until this point. QUIC implementations MUST properly handle both -# types, and, if they have enabled ECN for packets they send, they -# SHOULD use the information in the ECN section to manage their -# congestion state. -# -# QUIC acknowledgments are irrevocable. Once acknowledged, a packet -# remains acknowledged, even if it does not appear in a future ACK -# frame. This is unlike reneging for TCP Selective Acknowledgments -# (SACKs) [RFC2018]. -# -# Packets from different packet number spaces can be identified using -# the same numeric value. An acknowledgment for a packet needs to -# indicate both a packet number and a packet number space. This is -# accomplished by having each ACK frame only acknowledge packet numbers -# in the same space as the packet in which the ACK frame is contained. -# -# Version Negotiation and Retry packets cannot be acknowledged because -# they do not contain a packet number. Rather than relying on ACK -# frames, these packets are implicitly acknowledged by the next Initial -# packet sent by the client. -# -# ACK frames are formatted as shown in Figure 25. -# -# ACK Frame { -# Type (i) = 0x02..0x03, -# Largest Acknowledged (i), -# ACK Delay (i), -# ACK Range Count (i), -# First ACK Range (i), -# ACK Range (..) ..., -# [ECN Counts (..)], -# } -# -# Figure 25: ACK Frame Format -# -# ACK frames contain the following fields: -# -# Largest Acknowledged: A variable-length integer representing the -# largest packet number the peer is acknowledging; this is usually -# the largest packet number that the peer has received prior to -# generating the ACK frame. Unlike the packet number in the QUIC -# long or short header, the value in an ACK frame is not truncated. -# -# ACK Delay: A variable-length integer encoding the acknowledgment -# delay in microseconds; see Section 13.2.5. It is decoded by -# multiplying the value in the field by 2 to the power of the -# ack_delay_exponent transport parameter sent by the sender of the -# ACK frame; see Section 18.2. Compared to simply expressing the -# delay as an integer, this encoding allows for a larger range of -# values within the same number of bytes, at the cost of lower -# resolution. -# -# ACK Range Count: A variable-length integer specifying the number of -# ACK Range fields in the frame. -# -# First ACK Range: A variable-length integer indicating the number of -# contiguous packets preceding the Largest Acknowledged that are -# being acknowledged. That is, the smallest packet acknowledged in -# the range is determined by subtracting the First ACK Range value -# from the Largest Acknowledged field. -# -# ACK Ranges: Contains additional ranges of packets that are -# alternately not acknowledged (Gap) and acknowledged (ACK Range); -# see Section 19.3.1. -# -# ECN Counts: The three ECN counts; see Section 19.3.2. - -[[spec]] -level = "MUST" -quote = ''' -QUIC implementations MUST properly handle both -types, and, if they have enabled ECN for packets they send, they -SHOULD use the information in the ECN section to manage their -congestion state. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.4.toml deleted file mode 100644 index 472e7358b9..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.4.toml +++ /dev/null @@ -1,46 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.4" - -# 19.4. RESET_STREAM Frames -# -# An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly -# terminate the sending part of a stream. -# -# After sending a RESET_STREAM, an endpoint ceases transmission and -# retransmission of STREAM frames on the identified stream. A receiver -# of RESET_STREAM can discard any data that it already received on that -# stream. -# -# An endpoint that receives a RESET_STREAM frame for a send-only stream -# MUST terminate the connection with error STREAM_STATE_ERROR. -# -# RESET_STREAM frames are formatted as shown in Figure 28. -# -# RESET_STREAM Frame { -# Type (i) = 0x04, -# Stream ID (i), -# Application Protocol Error Code (i), -# Final Size (i), -# } -# -# Figure 28: RESET_STREAM Frame Format -# -# RESET_STREAM frames contain the following fields: -# -# Stream ID: A variable-length integer encoding of the stream ID of -# the stream being terminated. -# -# Application Protocol Error Code: A variable-length integer -# containing the application protocol error code (see Section 20.2) -# that indicates why the stream is being closed. -# -# Final Size: A variable-length integer indicating the final size of -# the stream by the RESET_STREAM sender, in units of bytes; see -# Section 4.5. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that receives a RESET_STREAM frame for a send-only stream -MUST terminate the connection with error STREAM_STATE_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.5.toml deleted file mode 100644 index 24b2f96087..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.5.toml +++ /dev/null @@ -1,50 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.5" - -# 19.5. STOP_SENDING Frames -# -# An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that -# incoming data is being discarded on receipt per application request. -# STOP_SENDING requests that a peer cease transmission on a stream. -# -# A STOP_SENDING frame can be sent for streams in the "Recv" or "Size -# Known" states; see Section 3.2. Receiving a STOP_SENDING frame for a -# locally initiated stream that has not yet been created MUST be -# treated as a connection error of type STREAM_STATE_ERROR. An -# endpoint that receives a STOP_SENDING frame for a receive-only stream -# MUST terminate the connection with error STREAM_STATE_ERROR. -# -# STOP_SENDING frames are formatted as shown in Figure 29. -# -# STOP_SENDING Frame { -# Type (i) = 0x05, -# Stream ID (i), -# Application Protocol Error Code (i), -# } -# -# Figure 29: STOP_SENDING Frame Format -# -# STOP_SENDING frames contain the following fields: -# -# Stream ID: A variable-length integer carrying the stream ID of the -# stream being ignored. -# -# Application Protocol Error Code: A variable-length integer -# containing the application-specified reason the sender is ignoring -# the stream; see Section 20.2. - -[[spec]] -level = "MUST" -quote = ''' -Receiving a STOP_SENDING frame for a -locally initiated stream that has not yet been created MUST be -treated as a connection error of type STREAM_STATE_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -An -endpoint that receives a STOP_SENDING frame for a receive-only stream -MUST terminate the connection with error STREAM_STATE_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.6.toml deleted file mode 100644 index 9bdfa0f70d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.6.toml +++ /dev/null @@ -1,56 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.6" - -# 19.6. CRYPTO Frames -# -# A CRYPTO frame (type=0x06) is used to transmit cryptographic -# handshake messages. It can be sent in all packet types except 0-RTT. -# The CRYPTO frame offers the cryptographic protocol an in-order stream -# of bytes. CRYPTO frames are functionally identical to STREAM frames, -# except that they do not bear a stream identifier; they are not flow -# controlled; and they do not carry markers for optional offset, -# optional length, and the end of the stream. -# -# CRYPTO frames are formatted as shown in Figure 30. -# -# CRYPTO Frame { -# Type (i) = 0x06, -# Offset (i), -# Length (i), -# Crypto Data (..), -# } -# -# Figure 30: CRYPTO Frame Format -# -# CRYPTO frames contain the following fields: -# -# Offset: A variable-length integer specifying the byte offset in the -# stream for the data in this CRYPTO frame. -# -# Length: A variable-length integer specifying the length of the -# Crypto Data field in this CRYPTO frame. -# -# Crypto Data: The cryptographic message data. -# -# There is a separate flow of cryptographic handshake data in each -# encryption level, each of which starts at an offset of 0. This -# implies that each encryption level is treated as a separate CRYPTO -# stream of data. -# -# The largest offset delivered on a stream -- the sum of the offset and -# data length -- cannot exceed 2^62-1. Receipt of a frame that exceeds -# this limit MUST be treated as a connection error of type -# FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. -# -# Unlike STREAM frames, which include a stream ID indicating to which -# stream the data belongs, the CRYPTO frame carries data for a single -# stream per encryption level. The stream does not have an explicit -# end, so CRYPTO frames do not have a FIN bit. - -[[spec]] -level = "MUST" -quote = ''' -Receipt of a frame that exceeds -this limit MUST be treated as a connection error of type -FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.7.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.7.toml deleted file mode 100644 index 21e401e5dd..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.7.toml +++ /dev/null @@ -1,66 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.7" - -# 19.7. NEW_TOKEN Frames -# -# A server sends a NEW_TOKEN frame (type=0x07) to provide the client -# with a token to send in the header of an Initial packet for a future -# connection. -# -# NEW_TOKEN frames are formatted as shown in Figure 31. -# -# NEW_TOKEN Frame { -# Type (i) = 0x07, -# Token Length (i), -# Token (..), -# } -# -# Figure 31: NEW_TOKEN Frame Format -# -# NEW_TOKEN frames contain the following fields: -# -# Token Length: A variable-length integer specifying the length of the -# token in bytes. -# -# Token: An opaque blob that the client can use with a future Initial -# packet. The token MUST NOT be empty. A client MUST treat receipt -# of a NEW_TOKEN frame with an empty Token field as a connection -# error of type FRAME_ENCODING_ERROR. -# -# A client might receive multiple NEW_TOKEN frames that contain the -# same token value if packets containing the frame are incorrectly -# determined to be lost. Clients are responsible for discarding -# duplicate values, which might be used to link connection attempts; -# see Section 8.1.3. -# -# Clients MUST NOT send NEW_TOKEN frames. A server MUST treat receipt -# of a NEW_TOKEN frame as a connection error of type -# PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -The token MUST NOT be empty. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST treat receipt -of a NEW_TOKEN frame with an empty Token field as a connection -error of type FRAME_ENCODING_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -Clients MUST NOT send NEW_TOKEN frames. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST treat receipt -of a NEW_TOKEN frame as a connection error of type -PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.8.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.8.toml deleted file mode 100644 index 77f88240d1..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.8.toml +++ /dev/null @@ -1,86 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.8" - -# 19.8. STREAM Frames -# -# STREAM frames implicitly create a stream and carry stream data. The -# Type field in the STREAM frame takes the form 0b00001XXX (or the set -# of values from 0x08 to 0x0f). The three low-order bits of the frame -# type determine the fields that are present in the frame: -# -# * The OFF bit (0x04) in the frame type is set to indicate that there -# is an Offset field present. When set to 1, the Offset field is -# present. When set to 0, the Offset field is absent and the Stream -# Data starts at an offset of 0 (that is, the frame contains the -# first bytes of the stream, or the end of a stream that includes no -# data). -# -# * The LEN bit (0x02) in the frame type is set to indicate that there -# is a Length field present. If this bit is set to 0, the Length -# field is absent and the Stream Data field extends to the end of -# the packet. If this bit is set to 1, the Length field is present. -# -# * The FIN bit (0x01) indicates that the frame marks the end of the -# stream. The final size of the stream is the sum of the offset and -# the length of this frame. -# -# An endpoint MUST terminate the connection with error -# STREAM_STATE_ERROR if it receives a STREAM frame for a locally -# initiated stream that has not yet been created, or for a send-only -# stream. -# -# STREAM frames are formatted as shown in Figure 32. -# -# STREAM Frame { -# Type (i) = 0x08..0x0f, -# Stream ID (i), -# [Offset (i)], -# [Length (i)], -# Stream Data (..), -# } -# -# Figure 32: STREAM Frame Format -# -# STREAM frames contain the following fields: -# -# Stream ID: A variable-length integer indicating the stream ID of the -# stream; see Section 2.1. -# -# Offset: A variable-length integer specifying the byte offset in the -# stream for the data in this STREAM frame. This field is present -# when the OFF bit is set to 1. When the Offset field is absent, -# the offset is 0. -# -# Length: A variable-length integer specifying the length of the -# Stream Data field in this STREAM frame. This field is present -# when the LEN bit is set to 1. When the LEN bit is set to 0, the -# Stream Data field consumes all the remaining bytes in the packet. -# -# Stream Data: The bytes from the designated stream to be delivered. -# -# When a Stream Data field has a length of 0, the offset in the STREAM -# frame is the offset of the next byte that would be sent. -# -# The first byte in the stream has an offset of 0. The largest offset -# delivered on a stream -- the sum of the offset and data length -- -# cannot exceed 2^62-1, as it is not possible to provide flow control -# credit for that data. Receipt of a frame that exceeds this limit -# MUST be treated as a connection error of type FRAME_ENCODING_ERROR or -# FLOW_CONTROL_ERROR. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST terminate the connection with error -STREAM_STATE_ERROR if it receives a STREAM frame for a locally -initiated stream that has not yet been created, or for a send-only -stream. -''' - -[[spec]] -level = "MUST" -quote = ''' -Receipt of a frame that exceeds this limit -MUST be treated as a connection error of type FRAME_ENCODING_ERROR or -FLOW_CONTROL_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/19.9.toml b/specs/www.rfc-editor.org/rfc/rfc9000/19.9.toml deleted file mode 100644 index fd6df796c0..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/19.9.toml +++ /dev/null @@ -1,48 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-19.9" - -# 19.9. MAX_DATA Frames -# -# A MAX_DATA frame (type=0x10) is used in flow control to inform the -# peer of the maximum amount of data that can be sent on the connection -# as a whole. -# -# MAX_DATA frames are formatted as shown in Figure 33. -# -# MAX_DATA Frame { -# Type (i) = 0x10, -# Maximum Data (i), -# } -# -# Figure 33: MAX_DATA Frame Format -# -# MAX_DATA frames contain the following field: -# -# Maximum Data: A variable-length integer indicating the maximum -# amount of data that can be sent on the entire connection, in units -# of bytes. -# -# All data sent in STREAM frames counts toward this limit. The sum of -# the final sizes on all streams -- including streams in terminal -# states -- MUST NOT exceed the value advertised by a receiver. An -# endpoint MUST terminate a connection with an error of type -# FLOW_CONTROL_ERROR if it receives more data than the maximum data -# value that it has sent. This includes violations of remembered -# limits in Early Data; see Section 7.4.1. - -[[spec]] -level = "MUST" -quote = ''' -The sum of -the final sizes on all streams -- including streams in terminal -states -- MUST NOT exceed the value advertised by a receiver. -''' - -[[spec]] -level = "MUST" -quote = ''' -An -endpoint MUST terminate a connection with an error of type -FLOW_CONTROL_ERROR if it receives more data than the maximum data -value that it has sent. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/2.1.toml deleted file mode 100644 index 116ccdd685..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/2.1.toml +++ /dev/null @@ -1,54 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-2.1" - -# 2.1. Stream Types and Identifiers -# -# Streams can be unidirectional or bidirectional. Unidirectional -# streams carry data in one direction: from the initiator of the stream -# to its peer. Bidirectional streams allow for data to be sent in both -# directions. -# -# Streams are identified within a connection by a numeric value, -# referred to as the stream ID. A stream ID is a 62-bit integer (0 to -# 2^62-1) that is unique for all streams on a connection. Stream IDs -# are encoded as variable-length integers; see Section 16. A QUIC -# endpoint MUST NOT reuse a stream ID within a connection. -# -# The least significant bit (0x01) of the stream ID identifies the -# initiator of the stream. Client-initiated streams have even-numbered -# stream IDs (with the bit set to 0), and server-initiated streams have -# odd-numbered stream IDs (with the bit set to 1). -# -# The second least significant bit (0x02) of the stream ID -# distinguishes between bidirectional streams (with the bit set to 0) -# and unidirectional streams (with the bit set to 1). -# -# The two least significant bits from a stream ID therefore identify a -# stream as one of four types, as summarized in Table 1. -# -# +======+==================================+ -# | Bits | Stream Type | -# +======+==================================+ -# | 0x00 | Client-Initiated, Bidirectional | -# +------+----------------------------------+ -# | 0x01 | Server-Initiated, Bidirectional | -# +------+----------------------------------+ -# | 0x02 | Client-Initiated, Unidirectional | -# +------+----------------------------------+ -# | 0x03 | Server-Initiated, Unidirectional | -# +------+----------------------------------+ -# -# Table 1: Stream ID Types -# -# The stream space for each type begins at the minimum value (0x00 -# through 0x03, respectively); successive streams of each type are -# created with numerically increasing stream IDs. A stream ID that is -# used out of order results in all streams of that type with lower- -# numbered stream IDs also being opened. - -[[spec]] -level = "MUST" -quote = ''' -A QUIC -endpoint MUST NOT reuse a stream ID within a connection. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/2.2.toml deleted file mode 100644 index 2b9ecb6394..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/2.2.toml +++ /dev/null @@ -1,63 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-2.2" - -# 2.2. Sending and Receiving Data -# -# STREAM frames (Section 19.8) encapsulate data sent by an application. -# An endpoint uses the Stream ID and Offset fields in STREAM frames to -# place data in order. -# -# Endpoints MUST be able to deliver stream data to an application as an -# ordered byte stream. Delivering an ordered byte stream requires that -# an endpoint buffer any data that is received out of order, up to the -# advertised flow control limit. -# -# QUIC makes no specific allowances for delivery of stream data out of -# order. However, implementations MAY choose to offer the ability to -# deliver data out of order to a receiving application. -# -# An endpoint could receive data for a stream at the same stream offset -# multiple times. Data that has already been received can be -# discarded. The data at a given offset MUST NOT change if it is sent -# multiple times; an endpoint MAY treat receipt of different data at -# the same offset within a stream as a connection error of type -# PROTOCOL_VIOLATION. -# -# Streams are an ordered byte-stream abstraction with no other -# structure visible to QUIC. STREAM frame boundaries are not expected -# to be preserved when data is transmitted, retransmitted after packet -# loss, or delivered to the application at a receiver. -# -# An endpoint MUST NOT send data on any stream without ensuring that it -# is within the flow control limits set by its peer. Flow control is -# described in detail in Section 4. - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST be able to deliver stream data to an application as an -ordered byte stream. -''' - -[[spec]] -level = "MAY" -quote = ''' -However, implementations MAY choose to offer the ability to -deliver data out of order to a receiving application. -''' - -[[spec]] -level = "MUST" -quote = ''' -The data at a given offset MUST NOT change if it is sent -multiple times; an endpoint MAY treat receipt of different data at -the same offset within a stream as a connection error of type -PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send data on any stream without ensuring that it -is within the flow control limits set by its peer. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/2.3.toml deleted file mode 100644 index 4ac80ffee4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/2.3.toml +++ /dev/null @@ -1,24 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-2.3" - -# 2.3. Stream Prioritization -# -# Stream multiplexing can have a significant effect on application -# performance if resources allocated to streams are correctly -# prioritized. -# -# QUIC does not provide a mechanism for exchanging prioritization -# information. Instead, it relies on receiving priority information -# from the application. -# -# A QUIC implementation SHOULD provide ways in which an application can -# indicate the relative priority of streams. An implementation uses -# information provided by the application to determine how to allocate -# resources to active streams. - -[[spec]] -level = "SHOULD" -quote = ''' -A QUIC implementation SHOULD provide ways in which an application can -indicate the relative priority of streams. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.11.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.11.toml deleted file mode 100644 index 5aac3bf13d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.11.toml +++ /dev/null @@ -1,53 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.11" - -# 21.11. Stateless Reset Oracle -# -# Stateless resets create a possible denial-of-service attack analogous -# to a TCP reset injection. This attack is possible if an attacker is -# able to cause a stateless reset token to be generated for a -# connection with a selected connection ID. An attacker that can cause -# this token to be generated can reset an active connection with the -# same connection ID. -# -# If a packet can be routed to different instances that share a static -# key -- for example, by changing an IP address or port -- then an -# attacker can cause the server to send a stateless reset. To defend -# against this style of denial of service, endpoints that share a -# static key for stateless resets (see Section 10.3.2) MUST be arranged -# so that packets with a given connection ID always arrive at an -# instance that has connection state, unless that connection is no -# longer active. -# -# More generally, servers MUST NOT generate a stateless reset if a -# connection with the corresponding connection ID could be active on -# any endpoint using the same static key. -# -# In the case of a cluster that uses dynamic load balancing, it is -# possible that a change in load-balancer configuration could occur -# while an active instance retains connection state. Even if an -# instance retains connection state, the change in routing and -# resulting stateless reset will result in the connection being -# terminated. If there is no chance of the packet being routed to the -# correct instance, it is better to send a stateless reset than wait -# for the connection to time out. However, this is acceptable only if -# the routing cannot be influenced by an attacker. - -[[spec]] -level = "MUST" -quote = ''' -To defend -against this style of denial of service, endpoints that share a -static key for stateless resets (see Section 10.3.2) MUST be arranged -so that packets with a given connection ID always arrive at an -instance that has connection state, unless that connection is no -longer active. -''' - -[[spec]] -level = "MUST" -quote = ''' -More generally, servers MUST NOT generate a stateless reset if a -connection with the corresponding connection ID could be active on -any endpoint using the same static key. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.12.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.12.toml deleted file mode 100644 index 8401377265..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.12.toml +++ /dev/null @@ -1,21 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.12" - -# 21.12. Version Downgrade -# -# This document defines QUIC Version Negotiation packets (Section 6), -# which can be used to negotiate the QUIC version used between two -# endpoints. However, this document does not specify how this -# negotiation will be performed between this version and subsequent -# future versions. In particular, Version Negotiation packets do not -# contain any mechanism to prevent version downgrade attacks. Future -# versions of QUIC that use Version Negotiation packets MUST define a -# mechanism that is robust against version downgrade attacks. - -[[spec]] -level = "MUST" -quote = ''' -Future -versions of QUIC that use Version Negotiation packets MUST define a -mechanism that is robust against version downgrade attacks. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.3.toml deleted file mode 100644 index 00e9093583..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.3.toml +++ /dev/null @@ -1,22 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.3" - -# 21.3. Amplification Attack -# -# An attacker might be able to receive an address validation token -# (Section 8) from a server and then release the IP address it used to -# acquire that token. At a later time, the attacker can initiate a -# 0-RTT connection with a server by spoofing this same address, which -# might now address a different (victim) endpoint. The attacker can -# thus potentially cause the server to send an initial congestion -# window's worth of data towards the victim. -# -# Servers SHOULD provide mitigations for this attack by limiting the -# usage and lifetime of address validation tokens; see Section 8.1.3. - -[[spec]] -level = "SHOULD" -quote = ''' -Servers SHOULD provide mitigations for this attack by limiting the -usage and lifetime of address validation tokens; see Section 8.1.3. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.4.toml deleted file mode 100644 index 04b4d06603..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.4.toml +++ /dev/null @@ -1,18 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.4" - -# 21.4. Optimistic ACK Attack -# -# An endpoint that acknowledges packets it has not received might cause -# a congestion controller to permit sending at rates beyond what the -# network supports. An endpoint MAY skip packet numbers when sending -# packets to detect this behavior. An endpoint can then immediately -# close the connection with a connection error of type -# PROTOCOL_VIOLATION; see Section 10.2. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY skip packet numbers when sending -packets to detect this behavior. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.5.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.5.3.toml deleted file mode 100644 index ebf087c64f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.5.3.toml +++ /dev/null @@ -1,26 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5.3" - -# 21.5.3. Request Forgery with Preferred Addresses -# -# Servers can specify a preferred address, which clients then migrate -# to after confirming the handshake; see Section 9.6. The Destination -# Connection ID field of packets that the client sends to a preferred -# address can be used for request forgery. -# -# A client MUST NOT send non-probing frames to a preferred address -# prior to validating that address; see Section 8. This greatly -# reduces the options that a server has to control the encrypted -# portion of datagrams. -# -# This document does not offer any additional countermeasures that are -# specific to the use of preferred addresses and can be implemented by -# endpoints. The generic measures described in Section 21.5.6 could be -# used as further mitigation. - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT send non-probing frames to a preferred address -prior to validating that address; see Section 8. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.5.6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.5.6.toml deleted file mode 100644 index 3c2539e2ff..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.5.6.toml +++ /dev/null @@ -1,102 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5.6" - -# 21.5.6. Generic Request Forgery Countermeasures -# -# The most effective defense against request forgery attacks is to -# modify vulnerable services to use strong authentication. However, -# this is not always something that is within the control of a QUIC -# deployment. This section outlines some other steps that QUIC -# endpoints could take unilaterally. These additional steps are all -# discretionary because, depending on circumstances, they could -# interfere with or prevent legitimate uses. -# -# Services offered over loopback interfaces often lack proper -# authentication. Endpoints MAY prevent connection attempts or -# migration to a loopback address. Endpoints SHOULD NOT allow -# connections or migration to a loopback address if the same service -# was previously available at a different interface or if the address -# was provided by a service at a non-loopback address. Endpoints that -# depend on these capabilities could offer an option to disable these -# protections. -# -# Similarly, endpoints could regard a change in address to a link-local -# address [RFC4291] or an address in a private-use range [RFC1918] from -# a global, unique-local [RFC4193], or non-private address as a -# potential attempt at request forgery. Endpoints could refuse to use -# these addresses entirely, but that carries a significant risk of -# interfering with legitimate uses. Endpoints SHOULD NOT refuse to use -# an address unless they have specific knowledge about the network -# indicating that sending datagrams to unvalidated addresses in a given -# range is not safe. -# -# Endpoints MAY choose to reduce the risk of request forgery by not -# including values from NEW_TOKEN frames in Initial packets or by only -# sending probing frames in packets prior to completing address -# validation. Note that this does not prevent an attacker from using -# the Destination Connection ID field for an attack. -# -# Endpoints are not expected to have specific information about the -# location of servers that could be vulnerable targets of a request -# forgery attack. However, it might be possible over time to identify -# specific UDP ports that are common targets of attacks or particular -# patterns in datagrams that are used for attacks. Endpoints MAY -# choose to avoid sending datagrams to these ports or not send -# datagrams that match these patterns prior to validating the -# destination address. Endpoints MAY retire connection IDs containing -# patterns known to be problematic without using them. -# -# | Note: Modifying endpoints to apply these protections is more -# | efficient than deploying network-based protections, as -# | endpoints do not need to perform any additional processing when -# | sending to an address that has been validated. - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY prevent connection attempts or -migration to a loopback address. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD NOT allow -connections or migration to a loopback address if the same service -was previously available at a different interface or if the address -was provided by a service at a non-loopback address. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD NOT refuse to use -an address unless they have specific knowledge about the network -indicating that sending datagrams to unvalidated addresses in a given -range is not safe. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY choose to reduce the risk of request forgery by not -including values from NEW_TOKEN frames in Initial packets or by only -sending probing frames in packets prior to completing address -validation. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY -choose to avoid sending datagrams to these ports or not send -datagrams that match these patterns prior to validating the -destination address. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY retire connection IDs containing -patterns known to be problematic without using them. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.5.toml deleted file mode 100644 index 71323e1ccb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.5.toml +++ /dev/null @@ -1,70 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5" - -# 21.5. Request Forgery Attacks -# -# A request forgery attack occurs where an endpoint causes its peer to -# issue a request towards a victim, with the request controlled by the -# endpoint. Request forgery attacks aim to provide an attacker with -# access to capabilities of its peer that might otherwise be -# unavailable to the attacker. For a networking protocol, a request -# forgery attack is often used to exploit any implicit authorization -# conferred on the peer by the victim due to the peer's location in the -# network. -# -# For request forgery to be effective, an attacker needs to be able to -# influence what packets the peer sends and where these packets are -# sent. If an attacker can target a vulnerable service with a -# controlled payload, that service might perform actions that are -# attributed to the attacker's peer but are decided by the attacker. -# -# For example, cross-site request forgery [CSRF] exploits on the Web -# cause a client to issue requests that include authorization cookies -# [COOKIE], allowing one site access to information and actions that -# are intended to be restricted to a different site. -# -# As QUIC runs over UDP, the primary attack modality of concern is one -# where an attacker can select the address to which its peer sends UDP -# datagrams and can control some of the unprotected content of those -# packets. As much of the data sent by QUIC endpoints is protected, -# this includes control over ciphertext. An attack is successful if an -# attacker can cause a peer to send a UDP datagram to a host that will -# perform some action based on content in the datagram. -# -# This section discusses ways in which QUIC might be used for request -# forgery attacks. -# -# This section also describes limited countermeasures that can be -# implemented by QUIC endpoints. These mitigations can be employed -# unilaterally by a QUIC implementation or deployment, without -# potential targets for request forgery attacks taking action. -# However, these countermeasures could be insufficient if UDP-based -# services do not properly authorize requests. -# -# Because the migration attack described in Section 21.5.4 is quite -# powerful and does not have adequate countermeasures, QUIC server -# implementations should assume that attackers can cause them to -# generate arbitrary UDP payloads to arbitrary destinations. QUIC -# servers SHOULD NOT be deployed in networks that do not deploy ingress -# filtering [BCP38] and also have inadequately secured UDP endpoints. -# -# Although it is not generally possible to ensure that clients are not -# co-located with vulnerable endpoints, this version of QUIC does not -# allow servers to migrate, thus preventing spoofed migration attacks -# on clients. Any future extension that allows server migration MUST -# also define countermeasures for forgery attacks. - -[[spec]] -level = "SHOULD" -quote = ''' -QUIC -servers SHOULD NOT be deployed in networks that do not deploy ingress -filtering [BCP38] and also have inadequately secured UDP endpoints. -''' - -[[spec]] -level = "MUST" -quote = ''' -Any future extension that allows server migration MUST -also define countermeasures for forgery attacks. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.6.toml deleted file mode 100644 index 4622749b75..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.6.toml +++ /dev/null @@ -1,31 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.6" - -# 21.6. Slowloris Attacks -# -# The attacks commonly known as Slowloris [SLOWLORIS] try to keep many -# connections to the target endpoint open and hold them open as long as -# possible. These attacks can be executed against a QUIC endpoint by -# generating the minimum amount of activity necessary to avoid being -# closed for inactivity. This might involve sending small amounts of -# data, gradually opening flow control windows in order to control the -# sender rate, or manufacturing ACK frames that simulate a high loss -# rate. -# -# QUIC deployments SHOULD provide mitigations for the Slowloris -# attacks, such as increasing the maximum number of clients the server -# will allow, limiting the number of connections a single IP address is -# allowed to make, imposing restrictions on the minimum transfer speed -# a connection is allowed to have, and restricting the length of time -# an endpoint is allowed to stay connected. - -[[spec]] -level = "SHOULD" -quote = ''' -QUIC deployments SHOULD provide mitigations for the Slowloris -attacks, such as increasing the maximum number of clients the server -will allow, limiting the number of connections a single IP address is -allowed to make, imposing restrictions on the minimum transfer speed -a connection is allowed to have, and restricting the length of time -an endpoint is allowed to stay connected. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.7.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.7.toml deleted file mode 100644 index d180ee1d83..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.7.toml +++ /dev/null @@ -1,34 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.7" - -# 21.7. Stream Fragmentation and Reassembly Attacks -# -# An adversarial sender might intentionally not send portions of the -# stream data, causing the receiver to commit resources for the unsent -# data. This could cause a disproportionate receive buffer memory -# commitment and/or the creation of a large and inefficient data -# structure at the receiver. -# -# An adversarial receiver might intentionally not acknowledge packets -# containing stream data in an attempt to force the sender to store the -# unacknowledged stream data for retransmission. -# -# The attack on receivers is mitigated if flow control windows -# correspond to available memory. However, some receivers will -# overcommit memory and advertise flow control offsets in the aggregate -# that exceed actual available memory. The overcommitment strategy can -# lead to better performance when endpoints are well behaved, but -# renders endpoints vulnerable to the stream fragmentation attack. -# -# QUIC deployments SHOULD provide mitigations for stream fragmentation -# attacks. Mitigations could consist of avoiding overcommitting -# memory, limiting the size of tracking data structures, delaying -# reassembly of STREAM frames, implementing heuristics based on the age -# and duration of reassembly holes, or some combination of these. - -[[spec]] -level = "SHOULD" -quote = ''' -QUIC deployments SHOULD provide mitigations for stream fragmentation -attacks. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/21.9.toml b/specs/www.rfc-editor.org/rfc/rfc9000/21.9.toml deleted file mode 100644 index 4ae8ca12b3..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/21.9.toml +++ /dev/null @@ -1,39 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.9" - -# 21.9. Peer Denial of Service -# -# QUIC and TLS both contain frames or messages that have legitimate -# uses in some contexts, but these frames or messages can be abused to -# cause a peer to expend processing resources without having any -# observable impact on the state of the connection. -# -# Messages can also be used to change and revert state in small or -# inconsequential ways, such as by sending small increments to flow -# control limits. -# -# If processing costs are disproportionately large in comparison to -# bandwidth consumption or effect on state, then this could allow a -# malicious peer to exhaust processing capacity. -# -# While there are legitimate uses for all messages, implementations -# SHOULD track cost of processing relative to progress and treat -# excessive quantities of any non-productive packets as indicative of -# an attack. Endpoints MAY respond to this condition with a connection -# error or by dropping packets. - -[[spec]] -level = "SHOULD" -quote = ''' -While there are legitimate uses for all messages, implementations -SHOULD track cost of processing relative to progress and treat -excessive quantities of any non-productive packets as indicative of -an attack. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY respond to this condition with a connection -error or by dropping packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.1.1.toml deleted file mode 100644 index 06e01c8f2d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.1.toml +++ /dev/null @@ -1,48 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.1" - -# 22.1.1. Provisional Registrations -# -# Provisional registrations of codepoints are intended to allow for -# private use and experimentation with extensions to QUIC. Provisional -# registrations only require the inclusion of the codepoint value and -# contact information. However, provisional registrations could be -# reclaimed and reassigned for another purpose. -# -# Provisional registrations require Expert Review, as defined in -# Section 4.5 of [RFC8126]. The designated expert or experts are -# advised that only registrations for an excessive proportion of -# remaining codepoint space or the very first unassigned value (see -# Section 22.1.2) can be rejected. -# -# Provisional registrations will include a Date field that indicates -# when the registration was last updated. A request to update the date -# on any provisional registration can be made without review from the -# designated expert(s). -# -# All QUIC registries include the following fields to support -# provisional registration: -# -# Value: The assigned codepoint. -# Status: "permanent" or "provisional". -# Specification: A reference to a publicly available specification for -# the value. -# Date: The date of the last update to the registration. -# Change Controller: The entity that is responsible for the definition -# of the registration. -# Contact: Contact details for the registrant. -# Notes: Supplementary notes about the registration. -# -# Provisional registrations MAY omit the Specification and Notes -# fields, plus any additional fields that might be required for a -# permanent registration. The Date field is not required as part of -# requesting a registration, as it is set to the date the registration -# is created or updated. - -[[spec]] -level = "MAY" -quote = ''' -Provisional registrations MAY omit the Specification and Notes -fields, plus any additional fields that might be required for a -permanent registration. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.1.2.toml deleted file mode 100644 index c0df7887fa..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.2.toml +++ /dev/null @@ -1,65 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.2" - -# 22.1.2. Selecting Codepoints -# -# New requests for codepoints from QUIC registries SHOULD use a -# randomly selected codepoint that excludes both existing allocations -# and the first unallocated codepoint in the selected space. Requests -# for multiple codepoints MAY use a contiguous range. This minimizes -# the risk that differing semantics are attributed to the same -# codepoint by different implementations. -# -# The use of the first unassigned codepoint is reserved for allocation -# using the Standards Action policy; see Section 4.9 of [RFC8126]. The -# early codepoint assignment process [EARLY-ASSIGN] can be used for -# these values. -# -# For codepoints that are encoded in variable-length integers -# (Section 16), such as frame types, codepoints that encode to four or -# eight bytes (that is, values 2^14 and above) SHOULD be used unless -# the usage is especially sensitive to having a longer encoding. -# -# Applications to register codepoints in QUIC registries MAY include a -# requested codepoint as part of the registration. IANA MUST allocate -# the selected codepoint if the codepoint is unassigned and the -# requirements of the registration policy are met. - -[[spec]] -level = "SHOULD" -quote = ''' -New requests for codepoints from QUIC registries SHOULD use a -randomly selected codepoint that excludes both existing allocations -and the first unallocated codepoint in the selected space. -''' - -[[spec]] -level = "MAY" -quote = ''' -Requests -for multiple codepoints MAY use a contiguous range. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -For codepoints that are encoded in variable-length integers -(Section 16), such as frame types, codepoints that encode to four or -eight bytes (that is, values 2^14 and above) SHOULD be used unless -the usage is especially sensitive to having a longer encoding. -''' - -[[spec]] -level = "MAY" -quote = ''' -Applications to register codepoints in QUIC registries MAY include a -requested codepoint as part of the registration. -''' - -[[spec]] -level = "MUST" -quote = ''' -IANA MUST allocate -the selected codepoint if the codepoint is unassigned and the -requirements of the registration policy are met. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.1.3.toml deleted file mode 100644 index bf59e88d28..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.3.toml +++ /dev/null @@ -1,81 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.3" - -# 22.1.3. Reclaiming Provisional Codepoints -# -# A request might be made to remove an unused provisional registration -# from the registry to reclaim space in a registry, or a portion of the -# registry (such as the 64-16383 range for codepoints that use -# variable-length encodings). This SHOULD be done only for the -# codepoints with the earliest recorded date, and entries that have -# been updated less than a year prior SHOULD NOT be reclaimed. -# -# A request to remove a codepoint MUST be reviewed by the designated -# experts. The experts MUST attempt to determine whether the codepoint -# is still in use. Experts are advised to contact the listed contacts -# for the registration, plus as wide a set of protocol implementers as -# possible in order to determine whether any use of the codepoint is -# known. The experts are also advised to allow at least four weeks for -# responses. -# -# If any use of the codepoints is identified by this search or a -# request to update the registration is made, the codepoint MUST NOT be -# reclaimed. Instead, the date on the registration is updated. A note -# might be added for the registration recording relevant information -# that was learned. -# -# If no use of the codepoint was identified and no request was made to -# update the registration, the codepoint MAY be removed from the -# registry. -# -# This review and consultation process also applies to requests to -# change a provisional registration into a permanent registration, -# except that the goal is not to determine whether there is no use of -# the codepoint but to determine that the registration is an accurate -# representation of any deployed usage. - -[[spec]] -level = "SHOULD" -quote = ''' -This SHOULD be done only for the -codepoints with the earliest recorded date, and entries that have -been updated less than a year prior SHOULD NOT be reclaimed. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -This SHOULD be done only for the -codepoints with the earliest recorded date, and entries that have -been updated less than a year prior SHOULD NOT be reclaimed. -''' - -[[spec]] -level = "MUST" -quote = ''' -A request to remove a codepoint MUST be reviewed by the designated -experts. -''' - -[[spec]] -level = "MUST" -quote = ''' -The experts MUST attempt to determine whether the codepoint -is still in use. -''' - -[[spec]] -level = "MUST" -quote = ''' -If any use of the codepoints is identified by this search or a -request to update the registration is made, the codepoint MUST NOT be -reclaimed. -''' - -[[spec]] -level = "MAY" -quote = ''' -If no use of the codepoint was identified and no request was made to -update the registration, the codepoint MAY be removed from the -registry. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.1.4.toml deleted file mode 100644 index a69111ca07..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.1.4.toml +++ /dev/null @@ -1,50 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.1.4" - -# 22.1.4. Permanent Registrations -# -# Permanent registrations in QUIC registries use the Specification -# Required policy (Section 4.6 of [RFC8126]), unless otherwise -# specified. The designated expert or experts verify that a -# specification exists and is readily accessible. Experts are -# encouraged to be biased towards approving registrations unless they -# are abusive, frivolous, or actively harmful (not merely aesthetically -# displeasing or architecturally dubious). The creation of a registry -# MAY specify additional constraints on permanent registrations. -# -# The creation of a registry MAY identify a range of codepoints where -# registrations are governed by a different registration policy. For -# instance, the "QUIC Frame Types" registry (Section 22.4) has a -# stricter policy for codepoints in the range from 0 to 63. -# -# Any stricter requirements for permanent registrations do not prevent -# provisional registrations for affected codepoints. For instance, a -# provisional registration for a frame type of 61 could be requested. -# -# All registrations made by Standards Track publications MUST be -# permanent. -# -# All registrations in this document are assigned a permanent status -# and list a change controller of the IETF and a contact of the QUIC -# Working Group (quic@ietf.org). - -[[spec]] -level = "MAY" -quote = ''' -The creation of a registry -MAY specify additional constraints on permanent registrations. -''' - -[[spec]] -level = "MAY" -quote = ''' -The creation of a registry MAY identify a range of codepoints where -registrations are governed by a different registration policy. -''' - -[[spec]] -level = "MUST" -quote = ''' -All registrations made by Standards Track publications MUST be -permanent. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.2.toml deleted file mode 100644 index f00e378340..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.2.toml +++ /dev/null @@ -1,37 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.2" - -# 22.2. QUIC Versions Registry -# -# IANA has added a registry for "QUIC Versions" under a "QUIC" heading. -# -# The "QUIC Versions" registry governs a 32-bit space; see Section 15. -# This registry follows the registration policy from Section 22.1. -# Permanent registrations in this registry are assigned using the -# Specification Required policy (Section 4.6 of [RFC8126]). -# -# The codepoint of 0x00000001 for the protocol is assigned with -# permanent status to the protocol defined in this document. The -# codepoint of 0x00000000 is permanently reserved; the note for this -# codepoint indicates that this version is reserved for version -# negotiation. -# -# All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST -# NOT be assigned by IANA, and MUST NOT appear in the listing of -# assigned values. - -[[spec]] -level = "MUST" -quote = ''' -All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST -NOT be assigned by IANA, and MUST NOT appear in the listing of -assigned values. -''' - -[[spec]] -level = "MUST" -quote = ''' -All codepoints that follow the pattern 0x?a?a?a?a are reserved, MUST -NOT be assigned by IANA, and MUST NOT appear in the listing of -assigned values. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.3.toml deleted file mode 100644 index 046a15c3aa..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.3.toml +++ /dev/null @@ -1,89 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.3" - -# 22.3. QUIC Transport Parameters Registry -# -# IANA has added a registry for "QUIC Transport Parameters" under a -# "QUIC" heading. -# -# The "QUIC Transport Parameters" registry governs a 62-bit space. -# This registry follows the registration policy from Section 22.1. -# Permanent registrations in this registry are assigned using the -# Specification Required policy (Section 4.6 of [RFC8126]), except for -# values between 0x00 and 0x3f (in hexadecimal), inclusive, which are -# assigned using Standards Action or IESG Approval as defined in -# Sections 4.9 and 4.10 of [RFC8126]. -# -# In addition to the fields listed in Section 22.1.1, permanent -# registrations in this registry MUST include the following field: -# -# Parameter Name: A short mnemonic for the parameter. -# -# The initial contents of this registry are shown in Table 6. -# -# +=======+=====================================+===============+ -# | Value | Parameter Name | Specification | -# +=======+=====================================+===============+ -# | 0x00 | original_destination_connection_id | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x01 | max_idle_timeout | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x02 | stateless_reset_token | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x03 | max_udp_payload_size | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x04 | initial_max_data | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x07 | initial_max_stream_data_uni | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x08 | initial_max_streams_bidi | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x09 | initial_max_streams_uni | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x0a | ack_delay_exponent | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x0b | max_ack_delay | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x0c | disable_active_migration | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x0d | preferred_address | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x0e | active_connection_id_limit | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x0f | initial_source_connection_id | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# | 0x10 | retry_source_connection_id | Section 18.2 | -# +-------+-------------------------------------+---------------+ -# -# Table 6: Initial QUIC Transport Parameters Registry Entries -# -# 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. - -[[spec]] -level = "MUST" -quote = ''' -In addition to the fields listed in Section 22.1.1, permanent -registrations in this registry MUST include the following field: -''' - -[[spec]] -level = "MUST" -quote = ''' -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. -''' - -[[spec]] -level = "MUST" -quote = ''' -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. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.4.toml deleted file mode 100644 index df6199cfdb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.4.toml +++ /dev/null @@ -1,48 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.4" - -# 22.4. QUIC Frame Types Registry -# -# IANA has added a registry for "QUIC Frame Types" under a "QUIC" -# heading. -# -# The "QUIC Frame Types" registry governs a 62-bit space. This -# registry follows the registration policy from Section 22.1. -# Permanent registrations in this registry are assigned using the -# Specification Required policy (Section 4.6 of [RFC8126]), except for -# values between 0x00 and 0x3f (in hexadecimal), inclusive, which are -# assigned using Standards Action or IESG Approval as defined in -# Sections 4.9 and 4.10 of [RFC8126]. -# -# In addition to the fields listed in Section 22.1.1, permanent -# registrations in this registry MUST include the following field: -# -# Frame Type Name: A short mnemonic for the frame type. -# -# In addition to the advice in Section 22.1, specifications for new -# permanent registrations SHOULD describe the means by which an -# endpoint might determine that it can send the identified type of -# frame. An accompanying transport parameter registration is expected -# for most registrations; see Section 22.3. Specifications for -# permanent registrations also need to describe the format and assigned -# semantics of any fields in the frame. -# -# The initial contents of this registry are tabulated in Table 3. Note -# that the registry does not include the "Pkts" and "Spec" columns from -# Table 3. - -[[spec]] -level = "MUST" -quote = ''' -In addition to the fields listed in Section 22.1.1, permanent -registrations in this registry MUST include the following field: -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In addition to the advice in Section 22.1, specifications for new -permanent registrations SHOULD describe the means by which an -endpoint might determine that it can send the identified type of -frame. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/22.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/22.5.toml deleted file mode 100644 index b09f90d7e2..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/22.5.toml +++ /dev/null @@ -1,105 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-22.5" - -# 22.5. QUIC Transport Error Codes Registry -# -# IANA has added a registry for "QUIC Transport Error Codes" under a -# "QUIC" heading. -# -# The "QUIC Transport Error Codes" registry governs a 62-bit space. -# This space is split into three ranges that are governed by different -# policies. Permanent registrations in this registry are assigned -# using the Specification Required policy (Section 4.6 of [RFC8126]), -# except for values between 0x00 and 0x3f (in hexadecimal), inclusive, -# which are assigned using Standards Action or IESG Approval as defined -# in Sections 4.9 and 4.10 of [RFC8126]. -# -# In addition to the fields listed in Section 22.1.1, permanent -# registrations in this registry MUST include the following fields: -# -# Code: A short mnemonic for the parameter. -# -# Description: A brief description of the error code semantics, which -# MAY be a summary if a specification reference is provided. -# -# The initial contents of this registry are shown in Table 7. -# -# +=======+===========================+================+==============+ -# |Value | Code |Description |Specification | -# +=======+===========================+================+==============+ -# |0x00 | NO_ERROR |No error |Section 20 | -# +-------+---------------------------+----------------+--------------+ -# |0x01 | INTERNAL_ERROR |Implementation |Section 20 | -# | | |error | | -# +-------+---------------------------+----------------+--------------+ -# |0x02 | CONNECTION_REFUSED |Server refuses a|Section 20 | -# | | |connection | | -# +-------+---------------------------+----------------+--------------+ -# |0x03 | FLOW_CONTROL_ERROR |Flow control |Section 20 | -# | | |error | | -# +-------+---------------------------+----------------+--------------+ -# |0x04 | STREAM_LIMIT_ERROR |Too many streams|Section 20 | -# | | |opened | | -# +-------+---------------------------+----------------+--------------+ -# |0x05 | STREAM_STATE_ERROR |Frame received |Section 20 | -# | | |in invalid | | -# | | |stream state | | -# +-------+---------------------------+----------------+--------------+ -# |0x06 | FINAL_SIZE_ERROR |Change to final |Section 20 | -# | | |size | | -# +-------+---------------------------+----------------+--------------+ -# |0x07 | FRAME_ENCODING_ERROR |Frame encoding |Section 20 | -# | | |error | | -# +-------+---------------------------+----------------+--------------+ -# |0x08 | TRANSPORT_PARAMETER_ERROR |Error in |Section 20 | -# | | |transport | | -# | | |parameters | | -# +-------+---------------------------+----------------+--------------+ -# |0x09 | CONNECTION_ID_LIMIT_ERROR |Too many |Section 20 | -# | | |connection IDs | | -# | | |received | | -# +-------+---------------------------+----------------+--------------+ -# |0x0a | PROTOCOL_VIOLATION |Generic protocol|Section 20 | -# | | |violation | | -# +-------+---------------------------+----------------+--------------+ -# |0x0b | INVALID_TOKEN |Invalid Token |Section 20 | -# | | |received | | -# +-------+---------------------------+----------------+--------------+ -# |0x0c | APPLICATION_ERROR |Application |Section 20 | -# | | |error | | -# +-------+---------------------------+----------------+--------------+ -# |0x0d | CRYPTO_BUFFER_EXCEEDED |CRYPTO data |Section 20 | -# | | |buffer | | -# | | |overflowed | | -# +-------+---------------------------+----------------+--------------+ -# |0x0e | KEY_UPDATE_ERROR |Invalid packet |Section 20 | -# | | |protection | | -# | | |update | | -# +-------+---------------------------+----------------+--------------+ -# |0x0f | AEAD_LIMIT_REACHED |Excessive use of|Section 20 | -# | | |packet | | -# | | |protection keys | | -# +-------+---------------------------+----------------+--------------+ -# |0x10 | NO_VIABLE_PATH |No viable |Section 20 | -# | | |network path | | -# | | |exists | | -# +-------+---------------------------+----------------+--------------+ -# |0x0100-| CRYPTO_ERROR |TLS alert code |Section 20 | -# |0x01ff | | | | -# +-------+---------------------------+----------------+--------------+ -# -# Table 7: Initial QUIC Transport Error Codes Registry Entries - -[[spec]] -level = "MUST" -quote = ''' -In addition to the fields listed in Section 22.1.1, permanent -registrations in this registry MUST include the following fields: -''' - -[[spec]] -level = "MAY" -quote = ''' -Description: A brief description of the error code semantics, which -MAY be a summary if a specification reference is provided. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/3.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/3.1.toml deleted file mode 100644 index 6762da9b7e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/3.1.toml +++ /dev/null @@ -1,101 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.1" - -# 3.1. Sending Stream States -# -# Figure 2 shows the states for the part of a stream that sends data to -# a peer. -# -# o -# | Create Stream (Sending) -# | Peer Creates Bidirectional Stream -# v -# +-------+ -# | Ready | Send RESET_STREAM -# | |-----------------------. -# +-------+ | -# | | -# | Send STREAM / | -# | STREAM_DATA_BLOCKED | -# v | -# +-------+ | -# | Send | Send RESET_STREAM | -# | |---------------------->| -# +-------+ | -# | | -# | Send STREAM + FIN | -# v v -# +-------+ +-------+ -# | Data | Send RESET_STREAM | Reset | -# | Sent |------------------>| Sent | -# +-------+ +-------+ -# | | -# | Recv All ACKs | Recv ACK -# v v -# +-------+ +-------+ -# | Data | | Reset | -# | Recvd | | Recvd | -# +-------+ +-------+ -# -# Figure 2: States for Sending Parts of Streams -# -# The sending part of a stream that the endpoint initiates (types 0 and -# 2 for clients, 1 and 3 for servers) is opened by the application. -# The "Ready" state represents a newly created stream that is able to -# accept data from the application. Stream data might be buffered in -# this state in preparation for sending. -# -# Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a -# sending part of a stream to enter the "Send" state. An -# implementation might choose to defer allocating a stream ID to a -# stream until it sends the first STREAM frame and enters this state, -# which can allow for better stream prioritization. -# -# The sending part of a bidirectional stream initiated by a peer (type -# 0 for a server, type 1 for a client) starts in the "Ready" state when -# the receiving part is created. -# -# In the "Send" state, an endpoint transmits -- and retransmits as -# necessary -- stream data in STREAM frames. The endpoint respects the -# flow control limits set by its peer and continues to accept and -# process MAX_STREAM_DATA frames. An endpoint in the "Send" state -# generates STREAM_DATA_BLOCKED frames if it is blocked from sending by -# stream flow control limits (Section 4.1). -# -# After the application indicates that all stream data has been sent -# and a STREAM frame containing the FIN bit is sent, the sending part -# of the stream enters the "Data Sent" state. From this state, the -# endpoint only retransmits stream data as necessary. The endpoint -# does not need to check flow control limits or send -# STREAM_DATA_BLOCKED frames for a stream in this state. -# MAX_STREAM_DATA frames might be received until the peer receives the -# final stream offset. The endpoint can safely ignore any -# MAX_STREAM_DATA frames it receives from its peer for a stream in this -# state. -# -# Once all stream data has been successfully acknowledged, the sending -# part of the stream enters the "Data Recvd" state, which is a terminal -# state. -# -# From any state that is one of "Ready", "Send", or "Data Sent", an -# application can signal that it wishes to abandon transmission of -# stream data. Alternatively, an endpoint might receive a STOP_SENDING -# frame from its peer. In either case, the endpoint sends a -# RESET_STREAM frame, which causes the stream to enter the "Reset Sent" -# state. -# -# An endpoint MAY send a RESET_STREAM as the first frame that mentions -# a stream; this causes the sending part of that stream to open and -# then immediately transition to the "Reset Sent" state. -# -# Once a packet containing a RESET_STREAM has been acknowledged, the -# sending part of the stream enters the "Reset Recvd" state, which is a -# terminal state. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY send a RESET_STREAM as the first frame that mentions -a stream; this causes the sending part of that stream to open and -then immediately transition to the "Reset Sent" state. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/3.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/3.2.toml deleted file mode 100644 index 80e82c4440..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/3.2.toml +++ /dev/null @@ -1,134 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.2" - -# 3.2. Receiving Stream States -# -# Figure 3 shows the states for the part of a stream that receives data -# from a peer. The states for a receiving part of a stream mirror only -# some of the states of the sending part of the stream at the peer. -# The receiving part of a stream does not track states on the sending -# part that cannot be observed, such as the "Ready" state. Instead, -# the receiving part of a stream tracks the delivery of data to the -# application, some of which cannot be observed by the sender. -# -# o -# | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM -# | Create Bidirectional Stream (Sending) -# | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) -# | Create Higher-Numbered Stream -# v -# +-------+ -# | Recv | Recv RESET_STREAM -# | |-----------------------. -# +-------+ | -# | | -# | Recv STREAM + FIN | -# v | -# +-------+ | -# | Size | Recv RESET_STREAM | -# | Known |---------------------->| -# +-------+ | -# | | -# | Recv All Data | -# v v -# +-------+ Recv RESET_STREAM +-------+ -# | Data |--- (optional) --->| Reset | -# | Recvd | Recv All Data | Recvd | -# +-------+<-- (optional) ----+-------+ -# | | -# | App Read All Data | App Read Reset -# v v -# +-------+ +-------+ -# | Data | | Reset | -# | Read | | Read | -# +-------+ +-------+ -# -# Figure 3: States for Receiving Parts of Streams -# -# The receiving part of a stream initiated by a peer (types 1 and 3 for -# a client, or 0 and 2 for a server) is created when the first STREAM, -# STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that -# stream. For bidirectional streams initiated by a peer, receipt of a -# MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the -# stream also creates the receiving part. The initial state for the -# receiving part of a stream is "Recv". -# -# For a bidirectional stream, the receiving part enters the "Recv" -# state when the sending part initiated by the endpoint (type 0 for a -# client, type 1 for a server) enters the "Ready" state. -# -# An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or -# STOP_SENDING frame is received from the peer for that stream. -# Receiving a MAX_STREAM_DATA frame for an unopened stream indicates -# that the remote peer has opened the stream and is providing flow -# control credit. Receiving a STOP_SENDING frame for an unopened -# stream indicates that the remote peer no longer wishes to receive -# data on this stream. Either frame might arrive before a STREAM or -# STREAM_DATA_BLOCKED frame if packets are lost or reordered. -# -# Before a stream is created, all streams of the same type with lower- -# numbered stream IDs MUST be created. This ensures that the creation -# order for streams is consistent on both endpoints. -# -# In the "Recv" state, the endpoint receives STREAM and -# STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be -# reassembled into the correct order for delivery to the application. -# As data is consumed by the application and buffer space becomes -# available, the endpoint sends MAX_STREAM_DATA frames to allow the -# peer to send more data. -# -# When a STREAM frame with a FIN bit is received, the final size of the -# stream is known; see Section 4.5. The receiving part of the stream -# then enters the "Size Known" state. In this state, the endpoint no -# longer needs to send MAX_STREAM_DATA frames; it only receives any -# retransmissions of stream data. -# -# Once all data for the stream has been received, the receiving part -# enters the "Data Recvd" state. This might happen as a result of -# receiving the same STREAM frame that causes the transition to "Size -# Known". After all data has been received, any STREAM or -# STREAM_DATA_BLOCKED frames for the stream can be discarded. -# -# The "Data Recvd" state persists until stream data has been delivered -# to the application. Once stream data has been delivered, the stream -# enters the "Data Read" state, which is a terminal state. -# -# Receiving a RESET_STREAM frame in the "Recv" or "Size Known" state -# causes the stream to enter the "Reset Recvd" state. This might cause -# the delivery of stream data to the application to be interrupted. -# -# It is possible that all stream data has already been received when a -# RESET_STREAM is received (that is, in the "Data Recvd" state). -# Similarly, it is possible for remaining stream data to arrive after -# receiving a RESET_STREAM frame (the "Reset Recvd" state). An -# implementation is free to manage this situation as it chooses. -# -# Sending a RESET_STREAM means that an endpoint cannot guarantee -# delivery of stream data; however, there is no requirement that stream -# data not be delivered if a RESET_STREAM is received. An -# implementation MAY interrupt delivery of stream data, discard any -# data that was not consumed, and signal the receipt of the -# RESET_STREAM. A RESET_STREAM signal might be suppressed or withheld -# if stream data is completely received and is buffered to be read by -# the application. If the RESET_STREAM is suppressed, the receiving -# part of the stream remains in "Data Recvd". -# -# Once the application receives the signal indicating that the stream -# was reset, the receiving part of the stream transitions to the "Reset -# Read" state, which is a terminal state. - -[[spec]] -level = "MUST" -quote = ''' -Before a stream is created, all streams of the same type with lower- -numbered stream IDs MUST be created. -''' - -[[spec]] -level = "MAY" -quote = ''' -An -implementation MAY interrupt delivery of stream data, discard any -data that was not consumed, and signal the receipt of the -RESET_STREAM. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/3.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/3.3.toml deleted file mode 100644 index ee5fd0d9fa..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/3.3.toml +++ /dev/null @@ -1,51 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.3" - -# 3.3. Permitted Frame Types -# -# The sender of a stream sends just three frame types that affect the -# state of a stream at either the sender or the receiver: STREAM -# (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM -# (Section 19.4). -# -# A sender MUST NOT send any of these frames from a terminal state -# ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send a STREAM or -# STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or -# any terminal state -- that is, after sending a RESET_STREAM frame. A -# receiver could receive any of these three frames in any state, due to -# the possibility of delayed delivery of packets carrying them. -# -# The receiver of a stream sends MAX_STREAM_DATA frames (Section 19.10) -# and STOP_SENDING frames (Section 19.5). -# -# The receiver only sends MAX_STREAM_DATA frames in the "Recv" state. -# A receiver MAY send a STOP_SENDING frame in any state where it has -# not received a RESET_STREAM frame -- that is, states other than -# "Reset Recvd" or "Reset Read". However, there is little value in -# sending a STOP_SENDING frame in the "Data Recvd" state, as all stream -# data has been received. A sender could receive either of these two -# types of frames in any state as a result of delayed delivery of -# packets. - -[[spec]] -level = "MUST" -quote = ''' -A sender MUST NOT send any of these frames from a terminal state -("Data Recvd" or "Reset Recvd"). -''' - -[[spec]] -level = "MUST" -quote = ''' -A sender MUST NOT send a STREAM or -STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or -any terminal state -- that is, after sending a RESET_STREAM frame. -''' - -[[spec]] -level = "MAY" -quote = ''' -A receiver MAY send a STOP_SENDING frame in any state where it has -not received a RESET_STREAM frame -- that is, states other than -"Reset Recvd" or "Reset Read". -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/3.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/3.5.toml deleted file mode 100644 index ef4553ef89..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/3.5.toml +++ /dev/null @@ -1,104 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-3.5" - -# 3.5. Solicited State Transitions -# -# If an application is no longer interested in the data it is receiving -# on a stream, it can abort reading the stream and specify an -# application error code. -# -# If the stream is in the "Recv" or "Size Known" state, the transport -# SHOULD signal this by sending a STOP_SENDING frame to prompt closure -# of the stream in the opposite direction. This typically indicates -# that the receiving application is no longer reading data it receives -# from the stream, but it is not a guarantee that incoming data will be -# ignored. -# -# STREAM frames received after sending a STOP_SENDING frame are still -# counted toward connection and stream flow control, even though these -# frames can be discarded upon receipt. -# -# A STOP_SENDING frame requests that the receiving endpoint send a -# RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame -# MUST send a RESET_STREAM frame if the stream is in the "Ready" or -# "Send" state. If the stream is in the "Data Sent" state, the -# endpoint MAY defer sending the RESET_STREAM frame until the packets -# containing outstanding data are acknowledged or declared lost. If -# any outstanding data is declared lost, the endpoint SHOULD send a -# RESET_STREAM frame instead of retransmitting the data. -# -# An endpoint SHOULD copy the error code from the STOP_SENDING frame to -# the RESET_STREAM frame it sends, but it can use any application error -# code. An endpoint that sends a STOP_SENDING frame MAY ignore the -# error code in any RESET_STREAM frames subsequently received for that -# stream. -# -# STOP_SENDING SHOULD only be sent for a stream that has not been reset -# by the peer. STOP_SENDING is most useful for streams in the "Recv" -# or "Size Known" state. -# -# An endpoint is expected to send another STOP_SENDING frame if a -# packet containing a previous STOP_SENDING is lost. However, once -# either all stream data or a RESET_STREAM frame has been received for -# the stream -- that is, the stream is in any state other than "Recv" -# or "Size Known" -- sending a STOP_SENDING frame is unnecessary. -# -# An endpoint that wishes to terminate both directions of a -# bidirectional stream can terminate one direction by sending a -# RESET_STREAM frame, and it can encourage prompt termination in the -# opposite direction by sending a STOP_SENDING frame. - -[[spec]] -level = "SHOULD" -quote = ''' -If the stream is in the "Recv" or "Size Known" state, the transport -SHOULD signal this by sending a STOP_SENDING frame to prompt closure -of the stream in the opposite direction. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that receives a STOP_SENDING frame -MUST send a RESET_STREAM frame if the stream is in the "Ready" or -"Send" state. -''' - -[[spec]] -level = "MAY" -quote = ''' -If the stream is in the "Data Sent" state, the -endpoint MAY defer sending the RESET_STREAM frame until the packets -containing outstanding data are acknowledged or declared lost. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If -any outstanding data is declared lost, the endpoint SHOULD send a -RESET_STREAM frame instead of retransmitting the data. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD copy the error code from the STOP_SENDING frame to -the RESET_STREAM frame it sends, but it can use any application error -code. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint that sends a STOP_SENDING frame MAY ignore the -error code in any RESET_STREAM frames subsequently received for that -stream. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -STOP_SENDING SHOULD only be sent for a stream that has not been reset -by the peer. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/4.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/4.1.toml deleted file mode 100644 index 4f968b7ebf..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/4.1.toml +++ /dev/null @@ -1,99 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.1" - -# 4.1. Data Flow Control -# -# QUIC employs a limit-based flow control scheme where a receiver -# advertises the limit of total bytes it is prepared to receive on a -# given stream or for the entire connection. This leads to two levels -# of data flow control in QUIC: -# -# * Stream flow control, which prevents a single stream from consuming -# the entire receive buffer for a connection by limiting the amount -# of data that can be sent on each stream. -# -# * Connection flow control, which prevents senders from exceeding a -# receiver's buffer capacity for the connection by limiting the -# total bytes of stream data sent in STREAM frames on all streams. -# -# Senders MUST NOT send data in excess of either limit. -# -# A receiver sets initial limits for all streams through transport -# parameters during the handshake (Section 7.4). Subsequently, a -# receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA -# frames (Section 19.9) to the sender to advertise larger limits. -# -# A receiver can advertise a larger limit for a stream by sending a -# MAX_STREAM_DATA frame with the corresponding stream ID. A -# MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a -# stream. A receiver could determine the flow control offset to be -# advertised based on the current offset of data consumed on that -# stream. -# -# A receiver can advertise a larger limit for a connection by sending a -# MAX_DATA frame, which indicates the maximum of the sum of the -# absolute byte offsets of all streams. A receiver maintains a -# cumulative sum of bytes received on all streams, which is used to -# check for violations of the advertised connection or stream data -# limits. A receiver could determine the maximum data limit to be -# advertised based on the sum of bytes consumed on all streams. -# -# Once a receiver advertises a limit for the connection or a stream, it -# is not an error to advertise a smaller limit, but the smaller limit -# has no effect. -# -# A receiver MUST close the connection with an error of type -# FLOW_CONTROL_ERROR if the sender violates the advertised connection -# or stream data limits; see Section 11 for details on error handling. -# -# A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do -# not increase flow control limits. -# -# If a sender has sent data up to the limit, it will be unable to send -# new data and is considered blocked. A sender SHOULD send a -# STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver -# that it has data to write but is blocked by flow control limits. If -# a sender is blocked for a period longer than the idle timeout -# (Section 10.1), the receiver might close the connection even when the -# sender has data that is available for transmission. To keep the -# connection from closing, a sender that is flow control limited SHOULD -# periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it -# has no ack-eliciting packets in flight. - -[[spec]] -level = "MUST" -quote = ''' -Senders MUST NOT send data in excess of either limit. -''' - -[[spec]] -level = "MUST" -quote = ''' -A receiver MUST close the connection with an error of type -FLOW_CONTROL_ERROR if the sender violates the advertised connection -or stream data limits; see Section 11 for details on error handling. -''' - -[[spec]] -level = "MUST" -quote = ''' -A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do -not increase flow control limits. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD send a -STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver -that it has data to write but is blocked by flow control limits. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -To keep the -connection from closing, a sender that is flow control limited SHOULD -periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it -has no ack-eliciting packets in flight. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/4.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/4.2.toml deleted file mode 100644 index 5280d8d069..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/4.2.toml +++ /dev/null @@ -1,58 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.2" - -# 4.2. Increasing Flow Control Limits -# -# Implementations decide when and how much credit to advertise in -# MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few -# considerations. -# -# To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or -# MAX_DATA frame multiple times within a round trip or send it early -# enough to allow time for loss of the frame and subsequent recovery. -# -# Control frames contribute to connection overhead. Therefore, -# frequently sending MAX_STREAM_DATA and MAX_DATA frames with small -# changes is undesirable. On the other hand, if updates are less -# frequent, larger increments to limits are necessary to avoid blocking -# a sender, requiring larger resource commitments at the receiver. -# There is a trade-off between resource commitment and overhead when -# determining how large a limit is advertised. -# -# A receiver can use an autotuning mechanism to tune the frequency and -# amount of advertised additional credit based on a round-trip time -# estimate and the rate at which the receiving application consumes -# data, similar to common TCP implementations. As an optimization, an -# endpoint could send frames related to flow control only when there -# are other frames to send, ensuring that flow control does not cause -# extra packets to be sent. -# -# A blocked sender is not required to send STREAM_DATA_BLOCKED or -# DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a -# STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a -# MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the -# sender being blocked for the rest of the connection. Even if the -# sender sends these frames, waiting for them will result in the sender -# being blocked for at least an entire round trip. -# -# When a sender receives credit after being blocked, it might be able -# to send a large amount of data in response, resulting in short-term -# congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of -# how a sender can avoid this congestion. - -[[spec]] -level = "MAY" -quote = ''' -To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or -MAX_DATA frame multiple times within a round trip or send it early -enough to allow time for loss of the frame and subsequent recovery. -''' - -[[spec]] -level = "MUST" -quote = ''' -Therefore, a receiver MUST NOT wait for a -STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a -MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the -sender being blocked for the rest of the connection. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/4.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/4.4.toml deleted file mode 100644 index 6036ccbfa5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/4.4.toml +++ /dev/null @@ -1,26 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.4" - -# 4.4. Handling Stream Cancellation -# -# Endpoints need to eventually agree on the amount of flow control -# credit that has been consumed on every stream, to be able to account -# for all bytes for connection-level flow control. -# -# On receipt of a RESET_STREAM frame, an endpoint will tear down state -# for the matching stream and ignore further data arriving on that -# stream. -# -# RESET_STREAM terminates one direction of a stream abruptly. For a -# bidirectional stream, RESET_STREAM has no effect on data flow in the -# opposite direction. Both endpoints MUST maintain flow control state -# for the stream in the unterminated direction until that direction -# enters a terminal state. - -[[spec]] -level = "MUST" -quote = ''' -Both endpoints MUST maintain flow control state -for the stream in the unterminated direction until that direction -enters a terminal state. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/4.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/4.5.toml deleted file mode 100644 index e5590dd0eb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/4.5.toml +++ /dev/null @@ -1,71 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.5" - -# 4.5. Stream Final Size -# -# The final size is the amount of flow control credit that is consumed -# by a stream. Assuming that every contiguous byte on the stream was -# sent once, the final size is the number of bytes sent. More -# generally, this is one higher than the offset of the byte with the -# largest offset sent on the stream, or zero if no bytes were sent. -# -# A sender always communicates the final size of a stream to the -# receiver reliably, no matter how the stream is terminated. The final -# size is the sum of the Offset and Length fields of a STREAM frame -# with a FIN flag, noting that these fields might be implicit. -# Alternatively, the Final Size field of a RESET_STREAM frame carries -# this value. This guarantees that both endpoints agree on how much -# flow control credit was consumed by the sender on that stream. -# -# An endpoint will know the final size for a stream when the receiving -# part of the stream enters the "Size Known" or "Reset Recvd" state -# (Section 3). The receiver MUST use the final size of the stream to -# account for all bytes sent on the stream in its connection-level flow -# controller. -# -# An endpoint MUST NOT send data on a stream at or beyond the final -# size. -# -# Once a final size for a stream is known, it cannot change. If a -# RESET_STREAM or STREAM frame is received indicating a change in the -# final size for the stream, an endpoint SHOULD respond with an error -# of type FINAL_SIZE_ERROR; see Section 11 for details on error -# handling. A receiver SHOULD treat receipt of data at or beyond the -# final size as an error of type FINAL_SIZE_ERROR, even after a stream -# is closed. Generating these errors is not mandatory, because -# requiring that an endpoint generate these errors also means that the -# endpoint needs to maintain the final size state for closed streams, -# which could mean a significant state commitment. - -[[spec]] -level = "MUST" -quote = ''' -The receiver MUST use the final size of the stream to -account for all bytes sent on the stream in its connection-level flow -controller. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send data on a stream at or beyond the final -size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If a -RESET_STREAM or STREAM frame is received indicating a change in the -final size for the stream, an endpoint SHOULD respond with an error -of type FINAL_SIZE_ERROR; see Section 11 for details on error -handling. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A receiver SHOULD treat receipt of data at or beyond the -final size as an error of type FINAL_SIZE_ERROR, even after a stream -is closed. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/4.6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/4.6.toml deleted file mode 100644 index f1331841f5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/4.6.toml +++ /dev/null @@ -1,93 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.6" - -# 4.6. Controlling Concurrency -# -# An endpoint limits the cumulative number of incoming streams a peer -# can open. Only streams with a stream ID less than "(max_streams * 4 -# + first_stream_id_of_type)" can be opened; see Table 1. Initial -# limits are set in the transport parameters; see Section 18.2. -# Subsequent limits are advertised using MAX_STREAMS frames; see -# Section 19.11. Separate limits apply to unidirectional and -# bidirectional streams. -# -# If a max_streams transport parameter or a MAX_STREAMS frame is -# received with a value greater than 2^60, this would allow a maximum -# stream ID that cannot be expressed as a variable-length integer; see -# Section 16. If either is received, the connection MUST be closed -# immediately with a connection error of type TRANSPORT_PARAMETER_ERROR -# if the offending value was received in a transport parameter or of -# type FRAME_ENCODING_ERROR if it was received in a frame; see -# Section 10.2. -# -# Endpoints MUST NOT exceed the limit set by their peer. An endpoint -# that receives a frame with a stream ID exceeding the limit it has -# sent MUST treat this as a connection error of type -# STREAM_LIMIT_ERROR; see Section 11 for details on error handling. -# -# Once a receiver advertises a stream limit using the MAX_STREAMS -# frame, advertising a smaller limit has no effect. MAX_STREAMS frames -# that do not increase the stream limit MUST be ignored. -# -# As with stream and connection flow control, this document leaves -# implementations to decide when and how many streams should be -# advertised to a peer via MAX_STREAMS. Implementations might choose -# to increase limits as streams are closed, to keep the number of -# streams available to peers roughly consistent. -# -# An endpoint that is unable to open a new stream due to the peer's -# limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This -# signal is considered useful for debugging. An endpoint MUST NOT wait -# to receive this signal before advertising additional credit, since -# doing so will mean that the peer will be blocked for at least an -# entire round trip, and potentially indefinitely if the peer chooses -# not to send STREAMS_BLOCKED frames. - -[[spec]] -level = "MUST" -quote = ''' -If either is received, the connection MUST be closed -immediately with a connection error of type TRANSPORT_PARAMETER_ERROR -if the offending value was received in a transport parameter or of -type FRAME_ENCODING_ERROR if it was received in a frame; see -Section 10.2. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST NOT exceed the limit set by their peer. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint -that receives a frame with a stream ID exceeding the limit it has -sent MUST treat this as a connection error of type -STREAM_LIMIT_ERROR; see Section 11 for details on error handling. -''' - -[[spec]] -level = "MUST" -quote = ''' -MAX_STREAMS frames -that do not increase the stream limit MUST be ignored. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint that is unable to open a new stream due to the peer's -limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT wait -to receive this signal before advertising additional credit, since -doing so will mean that the peer will be blocked for at least an -entire round trip, and potentially indefinitely if the peer chooses -not to send STREAMS_BLOCKED frames. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/4.toml deleted file mode 100644 index 33b2b709cd..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/4.toml +++ /dev/null @@ -1,32 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-4" - -# 4. Flow Control -# -# Receivers need to limit the amount of data that they are required to -# buffer, in order to prevent a fast sender from overwhelming them or a -# malicious sender from consuming a large amount of memory. To enable -# a receiver to limit memory commitments for a connection, streams are -# flow controlled both individually and across a connection as a whole. -# A QUIC receiver controls the maximum amount of data the sender can -# send on a stream as well as across all streams at any time, as -# described in Sections 4.1 and 4.2. -# -# Similarly, to limit concurrency within a connection, a QUIC endpoint -# controls the maximum cumulative number of streams that its peer can -# initiate, as described in Section 4.6. -# -# Data sent in CRYPTO frames is not flow controlled in the same way as -# stream data. QUIC relies on the cryptographic protocol -# implementation to avoid excessive buffering of data; see [QUIC-TLS]. -# To avoid excessive buffering at multiple layers, QUIC implementations -# SHOULD provide an interface for the cryptographic protocol -# implementation to communicate its buffering limits. - -[[spec]] -level = "SHOULD" -quote = ''' -To avoid excessive buffering at multiple layers, QUIC implementations -SHOULD provide an interface for the cryptographic protocol -implementation to communicate its buffering limits. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.1.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.1.1.toml deleted file mode 100644 index fe9297fc44..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.1.1.toml +++ /dev/null @@ -1,160 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.1.1" - -# 5.1.1. Issuing Connection IDs -# -# Each connection ID has an associated sequence number to assist in -# detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer -# to the same value. The initial connection ID issued by an endpoint -# is sent in the Source Connection ID field of the long packet header -# (Section 17.2) during the handshake. The sequence number of the -# initial connection ID is 0. If the preferred_address transport -# parameter is sent, the sequence number of the supplied connection ID -# is 1. -# -# Additional connection IDs are communicated to the peer using -# NEW_CONNECTION_ID frames (Section 19.15). The sequence number on -# each newly issued connection ID MUST increase by 1. The connection -# ID that a client selects for the first Destination Connection ID -# field it sends and any connection ID provided by a Retry packet are -# not assigned sequence numbers. -# -# When an endpoint issues a connection ID, it MUST accept packets that -# carry this connection ID for the duration of the connection or until -# its peer invalidates the connection ID via a RETIRE_CONNECTION_ID -# frame (Section 19.16). Connection IDs that are issued and not -# retired are considered active; any active connection ID is valid for -# use with the current connection at any time, in any packet type. -# This includes the connection ID issued by the server via the -# preferred_address transport parameter. -# -# An endpoint SHOULD ensure that its peer has a sufficient number of -# available and unused connection IDs. Endpoints advertise the number -# of active connection IDs they are willing to maintain using the -# active_connection_id_limit transport parameter. An endpoint MUST NOT -# provide more connection IDs than the peer's limit. An endpoint MAY -# send connection IDs that temporarily exceed a peer's limit if the -# NEW_CONNECTION_ID frame also requires the retirement of any excess, -# by including a sufficiently large value in the Retire Prior To field. -# -# A NEW_CONNECTION_ID frame might cause an endpoint to add some active -# connection IDs and retire others based on the value of the Retire -# Prior To field. After processing a NEW_CONNECTION_ID frame and -# adding and retiring active connection IDs, if the number of active -# connection IDs exceeds the value advertised in its -# active_connection_id_limit transport parameter, an endpoint MUST -# close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. -# -# An endpoint SHOULD supply a new connection ID when the peer retires a -# connection ID. If an endpoint provided fewer connection IDs than the -# peer's active_connection_id_limit, it MAY supply a new connection ID -# when it receives a packet with a previously unused connection ID. An -# endpoint MAY limit the total number of connection IDs issued for each -# connection to avoid the risk of running out of connection IDs; see -# Section 10.3.2. An endpoint MAY also limit the issuance of -# connection IDs to reduce the amount of per-path state it maintains, -# such as path validation status, as its peer might interact with it -# over as many paths as there are issued connection IDs. -# -# An endpoint that initiates migration and requires non-zero-length -# connection IDs SHOULD ensure that the pool of connection IDs -# available to its peer allows the peer to use a new connection ID on -# migration, as the peer will be unable to respond if the pool is -# exhausted. -# -# An endpoint that selects a zero-length connection ID during the -# handshake cannot issue a new connection ID. A zero-length -# Destination Connection ID field is used in all packets sent toward -# such an endpoint over any network path. - -[[spec]] -level = "MUST" -quote = ''' -The sequence number on -each newly issued connection ID MUST increase by 1. -''' - -[[spec]] -level = "MUST" -quote = ''' -When an endpoint issues a connection ID, it MUST accept packets that -carry this connection ID for the duration of the connection or until -its peer invalidates the connection ID via a RETIRE_CONNECTION_ID -frame (Section 19.16). -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD ensure that its peer has a sufficient number of -available and unused connection IDs. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT -provide more connection IDs than the peer's limit. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY -send connection IDs that temporarily exceed a peer's limit if the -NEW_CONNECTION_ID frame also requires the retirement of any excess, -by including a sufficiently large value in the Retire Prior To field. -''' - -[[spec]] -level = "MUST" -quote = ''' -After processing a NEW_CONNECTION_ID frame and -adding and retiring active connection IDs, if the number of active -connection IDs exceeds the value advertised in its -active_connection_id_limit transport parameter, an endpoint MUST -close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD supply a new connection ID when the peer retires a -connection ID. -''' - -[[spec]] -level = "MAY" -quote = ''' -If an endpoint provided fewer connection IDs than the -peer's active_connection_id_limit, it MAY supply a new connection ID -when it receives a packet with a previously unused connection ID. -''' - -[[spec]] -level = "MAY" -quote = ''' -An -endpoint MAY limit the total number of connection IDs issued for each -connection to avoid the risk of running out of connection IDs; see -Section 10.3.2. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY also limit the issuance of -connection IDs to reduce the amount of per-path state it maintains, -such as path validation status, as its peer might interact with it -over as many paths as there are issued connection IDs. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint that initiates migration and requires non-zero-length -connection IDs SHOULD ensure that the pool of connection IDs -available to its peer allows the peer to use a new connection ID on -migration, as the peer will be unable to respond if the pool is -exhausted. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.1.2.toml deleted file mode 100644 index 0a22dfc011..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.1.2.toml +++ /dev/null @@ -1,121 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.1.2" - -# 5.1.2. Consuming and Retiring Connection IDs -# -# An endpoint can change the connection ID it uses for a peer to -# another available one at any time during the connection. An endpoint -# consumes connection IDs in response to a migrating peer; see -# Section 9.5 for more details. -# -# An endpoint maintains a set of connection IDs received from its peer, -# any of which it can use when sending packets. When the endpoint -# wishes to remove a connection ID from use, it sends a -# RETIRE_CONNECTION_ID frame to its peer. Sending a -# RETIRE_CONNECTION_ID frame indicates that the connection ID will not -# be used again and requests that the peer replace it with a new -# connection ID using a NEW_CONNECTION_ID frame. -# -# As discussed in Section 9.5, endpoints limit the use of a connection -# ID to packets sent from a single local address to a single -# destination address. Endpoints SHOULD retire connection IDs when -# they are no longer actively using either the local or destination -# address for which the connection ID was used. -# -# An endpoint might need to stop accepting previously issued connection -# IDs in certain circumstances. Such an endpoint can cause its peer to -# retire connection IDs by sending a NEW_CONNECTION_ID frame with an -# increased Retire Prior To field. The endpoint SHOULD continue to -# accept the previously issued connection IDs until they are retired by -# the peer. If the endpoint can no longer process the indicated -# connection IDs, it MAY close the connection. -# -# Upon receipt of an increased Retire Prior To field, the peer MUST -# stop using the corresponding connection IDs and retire them with -# RETIRE_CONNECTION_ID frames before adding the newly provided -# connection ID to the set of active connection IDs. This ordering -# allows an endpoint to replace all active connection IDs without the -# possibility of a peer having no available connection IDs and without -# exceeding the limit the peer sets in the active_connection_id_limit -# transport parameter; see Section 18.2. Failure to cease using the -# connection IDs when requested can result in connection failures, as -# the issuing endpoint might be unable to continue using the connection -# IDs with the active connection. -# -# An endpoint SHOULD limit the number of connection IDs it has retired -# locally for which RETIRE_CONNECTION_ID frames have not yet been -# acknowledged. An endpoint SHOULD allow for sending and tracking a -# number of RETIRE_CONNECTION_ID frames of at least twice the value of -# the active_connection_id_limit transport parameter. An endpoint MUST -# NOT forget a connection ID without retiring it, though it MAY choose -# to treat having connection IDs in need of retirement that exceed this -# limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. -# -# Endpoints SHOULD NOT issue updates of the Retire Prior To field -# before receiving RETIRE_CONNECTION_ID frames that retire all -# connection IDs indicated by the previous Retire Prior To value. - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD retire connection IDs when -they are no longer actively using either the local or destination -address for which the connection ID was used. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The endpoint SHOULD continue to -accept the previously issued connection IDs until they are retired by -the peer. -''' - -[[spec]] -level = "MAY" -quote = ''' -If the endpoint can no longer process the indicated -connection IDs, it MAY close the connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -Upon receipt of an increased Retire Prior To field, the peer MUST -stop using the corresponding connection IDs and retire them with -RETIRE_CONNECTION_ID frames before adding the newly provided -connection ID to the set of active connection IDs. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD limit the number of connection IDs it has retired -locally for which RETIRE_CONNECTION_ID frames have not yet been -acknowledged. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD allow for sending and tracking a -number of RETIRE_CONNECTION_ID frames of at least twice the value of -the active_connection_id_limit transport parameter. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST -NOT forget a connection ID without retiring it, though it MAY choose -to treat having connection IDs in need of retirement that exceed this -limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD NOT issue updates of the Retire Prior To field -before receiving RETIRE_CONNECTION_ID frames that retire all -connection IDs indicated by the previous Retire Prior To value. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.1.toml deleted file mode 100644 index 9444250cb7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.1.toml +++ /dev/null @@ -1,85 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.1" - -# 5.1. Connection ID -# -# Each connection possesses a set of connection identifiers, or -# connection IDs, each of which can identify the connection. -# Connection IDs are independently selected by endpoints; each endpoint -# selects the connection IDs that its peer uses. -# -# The primary function of a connection ID is to ensure that changes in -# addressing at lower protocol layers (UDP, IP) do not cause packets -# for a QUIC connection to be delivered to the wrong endpoint. Each -# endpoint selects connection IDs using an implementation-specific (and -# perhaps deployment-specific) method that will allow packets with that -# connection ID to be routed back to the endpoint and to be identified -# by the endpoint upon receipt. -# -# Multiple connection IDs are used so that endpoints can send packets -# that cannot be identified by an observer as being for the same -# connection without cooperation from an endpoint; see Section 9.5. -# -# Connection IDs MUST NOT contain any information that can be used by -# an external observer (that is, one that does not cooperate with the -# issuer) to correlate them with other connection IDs for the same -# connection. As a trivial example, this means the same connection ID -# MUST NOT be issued more than once on the same connection. -# -# Packets with long headers include Source Connection ID and -# Destination Connection ID fields. These fields are used to set the -# connection IDs for new connections; see Section 7.2 for details. -# -# Packets with short headers (Section 17.3) only include the -# Destination Connection ID and omit the explicit length. The length -# of the Destination Connection ID field is expected to be known to -# endpoints. Endpoints using a load balancer that routes based on -# connection ID could agree with the load balancer on a fixed length -# for connection IDs or agree on an encoding scheme. A fixed portion -# could encode an explicit length, which allows the entire connection -# ID to vary in length and still be used by the load balancer. -# -# A Version Negotiation (Section 17.2.1) packet echoes the connection -# IDs selected by the client, both to ensure correct routing toward the -# client and to demonstrate that the packet is in response to a packet -# sent by the client. -# -# A zero-length connection ID can be used when a connection ID is not -# needed to route to the correct endpoint. However, multiplexing -# connections on the same local IP address and port while using zero- -# length connection IDs will cause failures in the presence of peer -# connection migration, NAT rebinding, and client port reuse. An -# endpoint MUST NOT use the same IP address and port for multiple -# concurrent connections with zero-length connection IDs, unless it is -# certain that those protocol features are not in use. -# -# When an endpoint uses a non-zero-length connection ID, it needs to -# ensure that the peer has a supply of connection IDs from which to -# choose for packets sent to the endpoint. These connection IDs are -# supplied by the endpoint using the NEW_CONNECTION_ID frame -# (Section 19.15). - -[[spec]] -level = "MUST" -quote = ''' -Connection IDs MUST NOT contain any information that can be used by -an external observer (that is, one that does not cooperate with the -issuer) to correlate them with other connection IDs for the same -connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -As a trivial example, this means the same connection ID -MUST NOT be issued more than once on the same connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -An -endpoint MUST NOT use the same IP address and port for multiple -concurrent connections with zero-length connection IDs, unless it is -certain that those protocol features are not in use. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.2.1.toml deleted file mode 100644 index d1c3fa6e91..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.1.toml +++ /dev/null @@ -1,40 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2.1" - -# 5.2.1. Client Packet Handling -# -# Valid packets sent to clients always include a Destination Connection -# ID that matches a value the client selects. Clients that choose to -# receive zero-length connection IDs can use the local address and port -# to identify a connection. Packets that do not match an existing -# connection -- based on Destination Connection ID or, if this value is -# zero length, local IP address and port -- are discarded. -# -# Due to packet reordering or loss, a client might receive packets for -# a connection that are encrypted with a key it has not yet computed. -# The client MAY drop these packets, or it MAY buffer them in -# anticipation of later packets that allow it to compute the key. -# -# If a client receives a packet that uses a different version than it -# initially selected, it MUST discard that packet. - -[[spec]] -level = "MAY" -quote = ''' -The client MAY drop these packets, or it MAY buffer them in -anticipation of later packets that allow it to compute the key. -''' - -[[spec]] -level = "MAY" -quote = ''' -The client MAY drop these packets, or it MAY buffer them in -anticipation of later packets that allow it to compute the key. -''' - -[[spec]] -level = "MUST" -quote = ''' -If a client receives a packet that uses a different version than it -initially selected, it MUST discard that packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.2.2.toml deleted file mode 100644 index 8157ff7e60..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.2.toml +++ /dev/null @@ -1,100 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2.2" - -# 5.2.2. Server Packet Handling -# -# If a server receives a packet that indicates an unsupported version -# and if the packet is large enough to initiate a new connection for -# any supported version, the server SHOULD send a Version Negotiation -# packet as described in Section 6.1. A server MAY limit the number of -# packets to which it responds with a Version Negotiation packet. -# Servers MUST drop smaller packets that specify unsupported versions. -# -# The first packet for an unsupported version can use different -# semantics and encodings for any version-specific field. In -# particular, different packet protection keys might be used for -# different versions. Servers that do not support a particular version -# are unlikely to be able to decrypt the payload of the packet or -# properly interpret the result. Servers SHOULD respond with a Version -# Negotiation packet, provided that the datagram is sufficiently long. -# -# Packets with a supported version, or no Version field, are matched to -# a connection using the connection ID or -- for packets with zero- -# length connection IDs -- the local address and port. These packets -# are processed using the selected connection; otherwise, the server -# continues as described below. -# -# If the packet is an Initial packet fully conforming with the -# specification, the server proceeds with the handshake (Section 7). -# This commits the server to the version that the client selected. -# -# If a server refuses to accept a new connection, it SHOULD send an -# Initial packet containing a CONNECTION_CLOSE frame with error code -# CONNECTION_REFUSED. -# -# If the packet is a 0-RTT packet, the server MAY buffer a limited -# number of these packets in anticipation of a late-arriving Initial -# packet. Clients are not able to send Handshake packets prior to -# receiving a server response, so servers SHOULD ignore any such -# packets. -# -# Servers MUST drop incoming packets under all other circumstances. - -[[spec]] -level = "SHOULD" -quote = ''' -If a server receives a packet that indicates an unsupported version -and if the packet is large enough to initiate a new connection for -any supported version, the server SHOULD send a Version Negotiation -packet as described in Section 6.1. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY limit the number of -packets to which it responds with a Version Negotiation packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -Servers MUST drop smaller packets that specify unsupported versions. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Servers SHOULD respond with a Version -Negotiation packet, provided that the datagram is sufficiently long. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If a server refuses to accept a new connection, it SHOULD send an -Initial packet containing a CONNECTION_CLOSE frame with error code -CONNECTION_REFUSED. -''' - -[[spec]] -level = "MAY" -quote = ''' -If the packet is a 0-RTT packet, the server MAY buffer a limited -number of these packets in anticipation of a late-arriving Initial -packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Clients are not able to send Handshake packets prior to -receiving a server response, so servers SHOULD ignore any such -packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -Servers MUST drop incoming packets under all other circumstances. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.2.3.toml deleted file mode 100644 index ee982b8475..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.3.toml +++ /dev/null @@ -1,47 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2.3" - -# 5.2.3. Considerations for Simple Load Balancers -# -# A server deployment could load-balance among servers using only -# source and destination IP addresses and ports. Changes to the -# client's IP address or port could result in packets being forwarded -# to the wrong server. Such a server deployment could use one of the -# following methods for connection continuity when a client's address -# changes. -# -# * Servers could use an out-of-band mechanism to forward packets to -# the correct server based on connection ID. -# -# * If servers can use a dedicated server IP address or port, other -# than the one that the client initially connects to, they could use -# the preferred_address transport parameter to request that clients -# move connections to that dedicated address. Note that clients -# could choose not to use the preferred address. -# -# A server in a deployment that does not implement a solution to -# maintain connection continuity when the client address changes SHOULD -# indicate that migration is not supported by using the -# disable_active_migration transport parameter. The -# disable_active_migration transport parameter does not prohibit -# connection migration after a client has acted on a preferred_address -# transport parameter. -# -# Server deployments that use this simple form of load balancing MUST -# avoid the creation of a stateless reset oracle; see Section 21.11. - -[[spec]] -level = "SHOULD" -quote = ''' -A server in a deployment that does not implement a solution to -maintain connection continuity when the client address changes SHOULD -indicate that migration is not supported by using the -disable_active_migration transport parameter. -''' - -[[spec]] -level = "MUST" -quote = ''' -Server deployments that use this simple form of load balancing MUST -avoid the creation of a stateless reset oracle; see Section 21.11. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/5.2.toml deleted file mode 100644 index 7218326971..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/5.2.toml +++ /dev/null @@ -1,55 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-5.2" - -# 5.2. Matching Packets to Connections -# -# Incoming packets are classified on receipt. Packets can either be -# associated with an existing connection or -- for servers -- -# potentially create a new connection. -# -# Endpoints try to associate a packet with an existing connection. If -# the packet has a non-zero-length Destination Connection ID -# corresponding to an existing connection, QUIC processes that packet -# accordingly. Note that more than one connection ID can be associated -# with a connection; see Section 5.1. -# -# If the Destination Connection ID is zero length and the addressing -# information in the packet matches the addressing information the -# endpoint uses to identify a connection with a zero-length connection -# ID, QUIC processes the packet as part of that connection. An -# endpoint can use just destination IP and port or both source and -# destination addresses for identification, though this makes -# connections fragile as described in Section 5.1. -# -# Endpoints can send a Stateless Reset (Section 10.3) for any packets -# that cannot be attributed to an existing connection. A Stateless -# Reset allows a peer to more quickly identify when a connection -# becomes unusable. -# -# Packets that are matched to an existing connection are discarded if -# the packets are inconsistent with the state of that connection. For -# example, packets are discarded if they indicate a different protocol -# version than that of the connection or if the removal of packet -# protection is unsuccessful once the expected keys are available. -# -# Invalid packets that lack strong integrity protection, such as -# Initial, Retry, or Version Negotiation, MAY be discarded. An -# endpoint MUST generate a connection error if processing the contents -# of these packets prior to discovering an error, or fully revert any -# changes made during that processing. - -[[spec]] -level = "MAY" -quote = ''' -Invalid packets that lack strong integrity protection, such as -Initial, Retry, or Version Negotiation, MAY be discarded. -''' - -[[spec]] -level = "MUST" -quote = ''' -An -endpoint MUST generate a connection error if processing the contents -of these packets prior to discovering an error, or fully revert any -changes made during that processing. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/6.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/6.1.toml deleted file mode 100644 index c3abcf3e23..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/6.1.toml +++ /dev/null @@ -1,36 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-6.1" - -# 6.1. Sending Version Negotiation Packets -# -# If the version selected by the client is not acceptable to the -# server, the server responds with a Version Negotiation packet; see -# Section 17.2.1. This includes a list of versions that the server -# will accept. An endpoint MUST NOT send a Version Negotiation packet -# in response to receiving a Version Negotiation packet. -# -# This system allows a server to process packets with unsupported -# versions without retaining state. Though either the Initial packet -# or the Version Negotiation packet that is sent in response could be -# lost, the client will send new packets until it successfully receives -# a response or it abandons the connection attempt. -# -# A server MAY limit the number of Version Negotiation packets it -# sends. For instance, a server that is able to recognize packets as -# 0-RTT might choose not to send Version Negotiation packets in -# response to 0-RTT packets with the expectation that it will -# eventually receive an Initial packet. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send a Version Negotiation packet -in response to receiving a Version Negotiation packet. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY limit the number of Version Negotiation packets it -sends. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/6.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/6.2.toml deleted file mode 100644 index eb895a56ea..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/6.2.toml +++ /dev/null @@ -1,48 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-6.2" - -# 6.2. Handling Version Negotiation Packets -# -# Version Negotiation packets are designed to allow for functionality -# to be defined in the future that allows QUIC to negotiate the version -# of QUIC to use for a connection. Future Standards Track -# specifications might change how implementations that support multiple -# versions of QUIC react to Version Negotiation packets received in -# response to an attempt to establish a connection using this version. -# -# A client that supports only this version of QUIC MUST abandon the -# current connection attempt if it receives a Version Negotiation -# packet, with the following two exceptions. A client MUST discard any -# Version Negotiation packet if it has received and successfully -# processed any other packet, including an earlier Version Negotiation -# packet. A client MUST discard a Version Negotiation packet that -# lists the QUIC version selected by the client. -# -# How to perform version negotiation is left as future work defined by -# future Standards Track specifications. In particular, that future -# work will ensure robustness against version downgrade attacks; see -# Section 21.12. - -[[spec]] -level = "MUST" -quote = ''' -A client that supports only this version of QUIC MUST abandon the -current connection attempt if it receives a Version Negotiation -packet, with the following two exceptions. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST discard any -Version Negotiation packet if it has received and successfully -processed any other packet, including an earlier Version Negotiation -packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST discard a Version Negotiation packet that -lists the QUIC version selected by the client. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/6.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/6.3.toml deleted file mode 100644 index 560bc11796..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/6.3.toml +++ /dev/null @@ -1,31 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-6.3" - -# 6.3. Using Reserved Versions -# -# For a server to use a new version in the future, clients need to -# correctly handle unsupported versions. Some version numbers -# (0x?a?a?a?a, as defined in Section 15) are reserved for inclusion in -# fields that contain version numbers. -# -# Endpoints MAY add reserved versions to any field where unknown or -# unsupported versions are ignored to test that a peer correctly -# ignores the value. For instance, an endpoint could include a -# reserved version in a Version Negotiation packet; see Section 17.2.1. -# Endpoints MAY send packets with a reserved version to test that a -# peer correctly discards the packet. - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY add reserved versions to any field where unknown or -unsupported versions are ignored to test that a peer correctly -ignores the value. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY send packets with a reserved version to test that a -peer correctly discards the packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/6.toml deleted file mode 100644 index 61d1a8a68e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/6.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-6" - -# 6. Version Negotiation -# -# Version negotiation allows a server to indicate that it does not -# support the version the client used. A server sends a Version -# Negotiation packet in response to each packet that might initiate a -# new connection; see Section 5.2 for details. -# -# The size of the first packet sent by a client will determine whether -# a server sends a Version Negotiation packet. Clients that support -# multiple QUIC versions SHOULD ensure that the first UDP datagram they -# send is sized to the largest of the minimum datagram sizes from all -# versions they support, using PADDING frames (Section 19.1) as -# necessary. This ensures that the server responds if there is a -# mutually supported version. A server might not send a Version -# Negotiation packet if the datagram it receives is smaller than the -# minimum size specified in a different version; see Section 14.1. - -[[spec]] -level = "SHOULD" -quote = ''' -Clients that support -multiple QUIC versions SHOULD ensure that the first UDP datagram they -send is sized to the largest of the minimum datagram sizes from all -versions they support, using PADDING frames (Section 19.1) as -necessary. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.2.toml deleted file mode 100644 index c3c4574e99..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.2.toml +++ /dev/null @@ -1,115 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.2" - -# 7.2. Negotiating Connection IDs -# -# A connection ID is used to ensure consistent routing of packets, as -# described in Section 5.1. The long header contains two connection -# IDs: the Destination Connection ID is chosen by the recipient of the -# packet and is used to provide consistent routing; the Source -# Connection ID is used to set the Destination Connection ID used by -# the peer. -# -# During the handshake, packets with the long header (Section 17.2) are -# used to establish the connection IDs used by both endpoints. Each -# endpoint uses the Source Connection ID field to specify the -# connection ID that is used in the Destination Connection ID field of -# packets being sent to them. After processing the first Initial -# packet, each endpoint sets the Destination Connection ID field in -# subsequent packets it sends to the value of the Source Connection ID -# field that it received. -# -# When an Initial packet is sent by a client that has not previously -# received an Initial or Retry packet from the server, the client -# populates the Destination Connection ID field with an unpredictable -# value. This Destination Connection ID MUST be at least 8 bytes in -# length. Until a packet is received from the server, the client MUST -# use the same Destination Connection ID value on all packets in this -# connection. -# -# The Destination Connection ID field from the first Initial packet -# sent by a client is used to determine packet protection keys for -# Initial packets. These keys change after receiving a Retry packet; -# see Section 5.2 of [QUIC-TLS]. -# -# The client populates the Source Connection ID field with a value of -# its choosing and sets the Source Connection ID Length field to -# indicate the length. -# -# 0-RTT packets in the first flight use the same Destination Connection -# ID and Source Connection ID values as the client's first Initial -# packet. -# -# Upon first receiving an Initial or Retry packet from the server, the -# client uses the Source Connection ID supplied by the server as the -# Destination Connection ID for subsequent packets, including any 0-RTT -# packets. This means that a client might have to change the -# connection ID it sets in the Destination Connection ID field twice -# during connection establishment: once in response to a Retry packet -# and once in response to an Initial packet from the server. Once a -# client has received a valid Initial packet from the server, it MUST -# discard any subsequent packet it receives on that connection with a -# different Source Connection ID. -# -# A client MUST change the Destination Connection ID it uses for -# sending packets in response to only the first received Initial or -# Retry packet. A server MUST set the Destination Connection ID it -# uses for sending packets based on the first received Initial packet. -# Any further changes to the Destination Connection ID are only -# permitted if the values are taken from NEW_CONNECTION_ID frames; if -# subsequent Initial packets include a different Source Connection ID, -# they MUST be discarded. This avoids unpredictable outcomes that -# might otherwise result from stateless processing of multiple Initial -# packets with different Source Connection IDs. -# -# The Destination Connection ID that an endpoint sends can change over -# the lifetime of a connection, especially in response to connection -# migration (Section 9); see Section 5.1.1 for details. - -[[spec]] -level = "MUST" -quote = ''' -This Destination Connection ID MUST be at least 8 bytes in -length. -''' - -[[spec]] -level = "MUST" -quote = ''' -Until a packet is received from the server, the client MUST -use the same Destination Connection ID value on all packets in this -connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -Once a -client has received a valid Initial packet from the server, it MUST -discard any subsequent packet it receives on that connection with a -different Source Connection ID. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST change the Destination Connection ID it uses for -sending packets in response to only the first received Initial or -Retry packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST set the Destination Connection ID it -uses for sending packets based on the first received Initial packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -Any further changes to the Destination Connection ID are only -permitted if the values are taken from NEW_CONNECTION_ID frames; if -subsequent Initial packets include a different Source Connection ID, -they MUST be discarded. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.3.toml deleted file mode 100644 index 3a95575a1d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.3.toml +++ /dev/null @@ -1,130 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.3" - -# 7.3. Authenticating Connection IDs -# -# The choice each endpoint makes about connection IDs during the -# handshake is authenticated by including all values in transport -# parameters; see Section 7.4. This ensures that all connection IDs -# used for the handshake are also authenticated by the cryptographic -# handshake. -# -# Each endpoint includes the value of the Source Connection ID field -# from the first Initial packet it sent in the -# initial_source_connection_id transport parameter; see Section 18.2. -# A server includes the Destination Connection ID field from the first -# Initial packet it received from the client in the -# original_destination_connection_id transport parameter; if the server -# sent a Retry packet, this refers to the first Initial packet received -# before sending the Retry packet. If it sends a Retry packet, a -# server also includes the Source Connection ID field from the Retry -# packet in the retry_source_connection_id transport parameter. -# -# The values provided by a peer for these transport parameters MUST -# match the values that an endpoint used in the Destination and Source -# Connection ID fields of Initial packets that it sent (and received, -# for servers). Endpoints MUST validate that received transport -# parameters match received connection ID values. Including connection -# ID values in transport parameters and verifying them ensures that an -# attacker cannot influence the choice of connection ID for a -# successful connection by injecting packets carrying attacker-chosen -# connection IDs during the handshake. -# -# An endpoint MUST treat the absence of the -# initial_source_connection_id transport parameter from either endpoint -# or the absence of the original_destination_connection_id transport -# parameter from the server as a connection error of type -# TRANSPORT_PARAMETER_ERROR. -# -# An endpoint MUST treat the following as a connection error of type -# TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: -# -# * absence of the retry_source_connection_id transport parameter from -# the server after receiving a Retry packet, -# -# * presence of the retry_source_connection_id transport parameter -# when no Retry packet was received, or -# -# * a mismatch between values received from a peer in these transport -# parameters and the value sent in the corresponding Destination or -# Source Connection ID fields of Initial packets. -# -# If a zero-length connection ID is selected, the corresponding -# transport parameter is included with a zero-length value. -# -# Figure 7 shows the connection IDs (with DCID=Destination Connection -# ID, SCID=Source Connection ID) that are used in a complete handshake. -# The exchange of Initial packets is shown, plus the later exchange of -# 1-RTT packets that includes the connection ID established during the -# handshake. -# -# Client Server -# -# Initial: DCID=S1, SCID=C1 -> -# <- Initial: DCID=C1, SCID=S3 -# ... -# 1-RTT: DCID=S3 -> -# <- 1-RTT: DCID=C1 -# -# Figure 7: Use of Connection IDs in a Handshake -# -# Figure 8 shows a similar handshake that includes a Retry packet. -# -# Client Server -# -# Initial: DCID=S1, SCID=C1 -> -# <- Retry: DCID=C1, SCID=S2 -# Initial: DCID=S2, SCID=C1 -> -# <- Initial: DCID=C1, SCID=S3 -# ... -# 1-RTT: DCID=S3 -> -# <- 1-RTT: DCID=C1 -# -# Figure 8: Use of Connection IDs in a Handshake with Retry -# -# In both cases (Figures 7 and 8), the client sets the value of the -# initial_source_connection_id transport parameter to "C1". -# -# When the handshake does not include a Retry (Figure 7), the server -# sets original_destination_connection_id to "S1" (note that this value -# is chosen by the client) and initial_source_connection_id to "S3". -# In this case, the server does not include a -# retry_source_connection_id transport parameter. -# -# When the handshake includes a Retry (Figure 8), the server sets -# original_destination_connection_id to "S1", -# retry_source_connection_id to "S2", and initial_source_connection_id -# to "S3". - -[[spec]] -level = "MUST" -quote = ''' -The values provided by a peer for these transport parameters MUST -match the values that an endpoint used in the Destination and Source -Connection ID fields of Initial packets that it sent (and received, -for servers). -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST validate that received transport -parameters match received connection ID values. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat the absence of the -initial_source_connection_id transport parameter from either endpoint -or the absence of the original_destination_connection_id transport -parameter from the server as a connection error of type -TRANSPORT_PARAMETER_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat the following as a connection error of type -TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.4.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.4.1.toml deleted file mode 100644 index 8b0a1b8793..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.4.1.toml +++ /dev/null @@ -1,192 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.4.1" - -# 7.4.1. Values of Transport Parameters for 0-RTT -# -# Using 0-RTT depends on both client and server using protocol -# parameters that were negotiated from a previous connection. To -# enable 0-RTT, endpoints store the values of the server transport -# parameters with any session tickets it receives on the connection. -# Endpoints also store any information required by the application -# protocol or cryptographic handshake; see Section 4.6 of [QUIC-TLS]. -# The values of stored transport parameters are used when attempting -# 0-RTT using the session tickets. -# -# Remembered transport parameters apply to the new connection until the -# handshake completes and the client starts sending 1-RTT packets. -# Once the handshake completes, the client uses the transport -# parameters established in the handshake. Not all transport -# parameters are remembered, as some do not apply to future connections -# or they have no effect on the use of 0-RTT. -# -# The definition of a new transport parameter (Section 7.4.2) MUST -# specify whether storing the transport parameter for 0-RTT is -# mandatory, optional, or prohibited. A client need not store a -# transport parameter it cannot process. -# -# A client MUST NOT use remembered values for the following parameters: -# ack_delay_exponent, max_ack_delay, initial_source_connection_id, -# original_destination_connection_id, preferred_address, -# retry_source_connection_id, and stateless_reset_token. The client -# MUST use the server's new values in the handshake instead; if the -# server does not provide new values, the default values are used. -# -# A client that attempts to send 0-RTT data MUST remember all other -# transport parameters used by the server that it is able to process. -# The server can remember these transport parameters or can store an -# integrity-protected copy of the values in the ticket and recover the -# information when accepting 0-RTT data. A server uses the transport -# parameters in determining whether to accept 0-RTT data. -# -# If 0-RTT data is accepted by the server, the server MUST NOT reduce -# any limits or alter any values that might be violated by the client -# with its 0-RTT data. In particular, a server that accepts 0-RTT data -# MUST NOT set values for the following parameters (Section 18.2) that -# are smaller than the remembered values of the parameters. -# -# * active_connection_id_limit -# -# * initial_max_data -# -# * initial_max_stream_data_bidi_local -# -# * initial_max_stream_data_bidi_remote -# -# * initial_max_stream_data_uni -# -# * initial_max_streams_bidi -# -# * initial_max_streams_uni -# -# Omitting or setting a zero value for certain transport parameters can -# result in 0-RTT data being enabled but not usable. The applicable -# subset of transport parameters that permit the sending of application -# data SHOULD be set to non-zero values for 0-RTT. This includes -# initial_max_data and either (1) initial_max_streams_bidi and -# initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni -# and initial_max_stream_data_uni. -# -# A server might provide larger initial stream flow control limits for -# streams than the remembered values that a client applies when sending -# 0-RTT. Once the handshake completes, the client updates the flow -# control limits on all sending streams using the updated values of -# initial_max_stream_data_bidi_remote and initial_max_stream_data_uni. -# -# A server MAY store and recover the previously sent values of the -# max_idle_timeout, max_udp_payload_size, and disable_active_migration -# parameters and reject 0-RTT if it selects smaller values. Lowering -# the values of these parameters while also accepting 0-RTT data could -# degrade the performance of the connection. Specifically, lowering -# the max_udp_payload_size could result in dropped packets, leading to -# worse performance compared to rejecting 0-RTT data outright. -# -# A server MUST reject 0-RTT data if the restored values for transport -# parameters cannot be supported. -# -# When sending frames in 0-RTT packets, a client MUST only use -# remembered transport parameters; importantly, it MUST NOT use updated -# values that it learns from the server's updated transport parameters -# or from frames received in 1-RTT packets. Updated values of -# transport parameters from the handshake apply only to 1-RTT packets. -# For instance, flow control limits from remembered transport -# parameters apply to all 0-RTT packets even if those values are -# increased by the handshake or by frames sent in 1-RTT packets. A -# server MAY treat the use of updated transport parameters in 0-RTT as -# a connection error of type PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -The definition of a new transport parameter (Section 7.4.2) MUST -specify whether storing the transport parameter for 0-RTT is -mandatory, optional, or prohibited. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT use remembered values for the following parameters: -ack_delay_exponent, max_ack_delay, initial_source_connection_id, -original_destination_connection_id, preferred_address, -retry_source_connection_id, and stateless_reset_token. -''' - -[[spec]] -level = "MUST" -quote = ''' -The client -MUST use the server's new values in the handshake instead; if the -server does not provide new values, the default values are used. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client that attempts to send 0-RTT data MUST remember all other -transport parameters used by the server that it is able to process. -''' - -[[spec]] -level = "MUST" -quote = ''' -If 0-RTT data is accepted by the server, the server MUST NOT reduce -any limits or alter any values that might be violated by the client -with its 0-RTT data. -''' - -[[spec]] -level = "MUST" -quote = ''' -In particular, a server that accepts 0-RTT data -MUST NOT set values for the following parameters (Section 18.2) that -are smaller than the remembered values of the parameters. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The applicable -subset of transport parameters that permit the sending of application -data SHOULD be set to non-zero values for 0-RTT. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY store and recover the previously sent values of the -max_idle_timeout, max_udp_payload_size, and disable_active_migration -parameters and reject 0-RTT if it selects smaller values. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST reject 0-RTT data if the restored values for transport -parameters cannot be supported. -''' - -[[spec]] -level = "MUST" -quote = ''' -When sending frames in 0-RTT packets, a client MUST only use -remembered transport parameters; importantly, it MUST NOT use updated -values that it learns from the server's updated transport parameters -or from frames received in 1-RTT packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -When sending frames in 0-RTT packets, a client MUST only use -remembered transport parameters; importantly, it MUST NOT use updated -values that it learns from the server's updated transport parameters -or from frames received in 1-RTT packets. -''' - -[[spec]] -level = "MAY" -quote = ''' -A -server MAY treat the use of updated transport parameters in 0-RTT as -a connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.4.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.4.2.toml deleted file mode 100644 index 95bba05132..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.4.2.toml +++ /dev/null @@ -1,30 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.4.2" - -# 7.4.2. New Transport Parameters -# -# New transport parameters can be used to negotiate new protocol -# behavior. An endpoint MUST ignore transport parameters that it does -# not support. The absence of a transport parameter therefore disables -# any optional protocol feature that is negotiated using the parameter. -# As described in Section 18.1, some identifiers are reserved in order -# to exercise this requirement. -# -# A client that does not understand a transport parameter can discard -# it and attempt 0-RTT on subsequent connections. However, if the -# client adds support for a discarded transport parameter, it risks -# violating the constraints that the transport parameter establishes if -# it attempts 0-RTT. New transport parameters can avoid this problem -# by setting a default of the most conservative value. Clients can -# avoid this problem by remembering all parameters, even those not -# currently supported. -# -# New transport parameters can be registered according to the rules in -# Section 22.3. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST ignore transport parameters that it does -not support. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.4.toml deleted file mode 100644 index b4301e5bc5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.4.toml +++ /dev/null @@ -1,68 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.4" - -# 7.4. Transport Parameters -# -# During connection establishment, both endpoints make authenticated -# declarations of their transport parameters. Endpoints are required -# to comply with the restrictions that each parameter defines; the -# description of each parameter includes rules for its handling. -# -# Transport parameters are declarations that are made unilaterally by -# each endpoint. Each endpoint can choose values for transport -# parameters independent of the values chosen by its peer. -# -# The encoding of the transport parameters is detailed in Section 18. -# -# QUIC includes the encoded transport parameters in the cryptographic -# handshake. Once the handshake completes, the transport parameters -# declared by the peer are available. Each endpoint validates the -# values provided by its peer. -# -# Definitions for each of the defined transport parameters are included -# in Section 18.2. -# -# An endpoint MUST treat receipt of a transport parameter with an -# invalid value as a connection error of type -# TRANSPORT_PARAMETER_ERROR. -# -# An endpoint MUST NOT send a parameter more than once in a given -# transport parameters extension. An endpoint SHOULD treat receipt of -# duplicate transport parameters as a connection error of type -# TRANSPORT_PARAMETER_ERROR. -# -# Endpoints use transport parameters to authenticate the negotiation of -# connection IDs during the handshake; see Section 7.3. -# -# ALPN (see [ALPN]) allows clients to offer multiple application -# protocols during connection establishment. The transport parameters -# that a client includes during the handshake apply to all application -# protocols that the client offers. Application protocols can -# recommend values for transport parameters, such as the initial flow -# control limits. However, application protocols that set constraints -# on values for transport parameters could make it impossible for a -# client to offer multiple application protocols if these constraints -# conflict. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST treat receipt of a transport parameter with an -invalid value as a connection error of type -TRANSPORT_PARAMETER_ERROR. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send a parameter more than once in a given -transport parameters extension. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD treat receipt of -duplicate transport parameters as a connection error of type -TRANSPORT_PARAMETER_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.5.toml deleted file mode 100644 index 1a49b43a65..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.5.toml +++ /dev/null @@ -1,78 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7.5" - -# 7.5. Cryptographic Message Buffering -# -# Implementations need to maintain a buffer of CRYPTO data received out -# of order. Because there is no flow control of CRYPTO frames, an -# endpoint could potentially force its peer to buffer an unbounded -# amount of data. -# -# Implementations MUST support buffering at least 4096 bytes of data -# received in out-of-order CRYPTO frames. Endpoints MAY choose to -# allow more data to be buffered during the handshake. A larger limit -# during the handshake could allow for larger keys or credentials to be -# exchanged. An endpoint's buffer size does not need to remain -# constant during the life of the connection. -# -# Being unable to buffer CRYPTO frames during the handshake can lead to -# a connection failure. If an endpoint's buffer is exceeded during the -# handshake, it can expand its buffer temporarily to complete the -# handshake. If an endpoint does not expand its buffer, it MUST close -# the connection with a CRYPTO_BUFFER_EXCEEDED error code. -# -# Once the handshake completes, if an endpoint is unable to buffer all -# data in a CRYPTO frame, it MAY discard that CRYPTO frame and all -# CRYPTO frames received in the future, or it MAY close the connection -# with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing -# discarded CRYPTO frames MUST be acknowledged because the packet has -# been received and processed by the transport even though the CRYPTO -# frame was discarded. - -[[spec]] -level = "MUST" -quote = ''' -Implementations MUST support buffering at least 4096 bytes of data -received in out-of-order CRYPTO frames. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY choose to -allow more data to be buffered during the handshake. -''' - -[[spec]] -level = "MUST" -quote = ''' -If an endpoint does not expand its buffer, it MUST close -the connection with a CRYPTO_BUFFER_EXCEEDED error code. -''' - -[[spec]] -level = "MAY" -quote = ''' -Once the handshake completes, if an endpoint is unable to buffer all -data in a CRYPTO frame, it MAY discard that CRYPTO frame and all -CRYPTO frames received in the future, or it MAY close the connection -with a CRYPTO_BUFFER_EXCEEDED error code. -''' - -[[spec]] -level = "MAY" -quote = ''' -Once the handshake completes, if an endpoint is unable to buffer all -data in a CRYPTO frame, it MAY discard that CRYPTO frame and all -CRYPTO frames received in the future, or it MAY close the connection -with a CRYPTO_BUFFER_EXCEEDED error code. -''' - -[[spec]] -level = "MUST" -quote = ''' -Packets containing -discarded CRYPTO frames MUST be acknowledged because the packet has -been received and processed by the transport even though the CRYPTO -frame was discarded. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/7.toml b/specs/www.rfc-editor.org/rfc/rfc9000/7.toml deleted file mode 100644 index 048f08ad93..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/7.toml +++ /dev/null @@ -1,85 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-7" - -# 7. Cryptographic and Transport Handshake -# -# QUIC relies on a combined cryptographic and transport handshake to -# minimize connection establishment latency. QUIC uses the CRYPTO -# frame (Section 19.6) to transmit the cryptographic handshake. The -# version of QUIC defined in this document is identified as 0x00000001 -# and uses TLS as described in [QUIC-TLS]; a different QUIC version -# could indicate that a different cryptographic handshake protocol is -# in use. -# -# QUIC provides reliable, ordered delivery of the cryptographic -# handshake data. QUIC packet protection is used to encrypt as much of -# the handshake protocol as possible. The cryptographic handshake MUST -# provide the following properties: -# -# * authenticated key exchange, where -# -# - a server is always authenticated, -# -# - a client is optionally authenticated, -# -# - every connection produces distinct and unrelated keys, and -# -# - keying material is usable for packet protection for both 0-RTT -# and 1-RTT packets. -# -# * authenticated exchange of values for transport parameters of both -# endpoints, and confidentiality protection for server transport -# parameters (see Section 7.4). -# -# * authenticated negotiation of an application protocol (TLS uses -# Application-Layer Protocol Negotiation (ALPN) [ALPN] for this -# purpose). -# -# The CRYPTO frame can be sent in different packet number spaces -# (Section 12.3). The offsets used by CRYPTO frames to ensure ordered -# delivery of cryptographic handshake data start from zero in each -# packet number space. -# -# Figure 4 shows a simplified handshake and the exchange of packets and -# frames that are used to advance the handshake. Exchange of -# application data during the handshake is enabled where possible, -# shown with an asterisk ("*"). Once the handshake is complete, -# endpoints are able to exchange application data freely. -# -# Client Server -# -# Initial (CRYPTO) -# 0-RTT (*) ----------> -# Initial (CRYPTO) -# Handshake (CRYPTO) -# <---------- 1-RTT (*) -# Handshake (CRYPTO) -# 1-RTT (*) ----------> -# <---------- 1-RTT (HANDSHAKE_DONE) -# -# 1-RTT <=========> 1-RTT -# -# Figure 4: Simplified QUIC Handshake -# -# Endpoints can use packets sent during the handshake to test for -# Explicit Congestion Notification (ECN) support; see Section 13.4. An -# endpoint validates support for ECN by observing whether the ACK -# frames acknowledging the first packets it sends carry ECN counts, as -# described in Section 13.4.2. -# -# Endpoints MUST explicitly negotiate an application protocol. This -# avoids situations where there is a disagreement about the protocol -# that is in use. - -[[spec]] -level = "MUST" -quote = ''' -The cryptographic handshake MUST -provide the following properties: -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST explicitly negotiate an application protocol. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.1.1.toml deleted file mode 100644 index e08b73d501..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.1.toml +++ /dev/null @@ -1,17 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.1" - -# 8.1.1. Token Construction -# -# A token sent in a NEW_TOKEN frame or a Retry packet MUST be -# constructed in a way that allows the server to identify how it was -# provided to a client. These tokens are carried in the same field but -# require different handling from servers. - -[[spec]] -level = "MUST" -quote = ''' -A token sent in a NEW_TOKEN frame or a Retry packet MUST be -constructed in a way that allows the server to identify how it was -provided to a client. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.1.2.toml deleted file mode 100644 index 10307e245b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.2.toml +++ /dev/null @@ -1,71 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.2" - -# 8.1.2. Address Validation Using Retry Packets -# -# Upon receiving the client's Initial packet, the server can request -# address validation by sending a Retry packet (Section 17.2.5) -# containing a token. This token MUST be repeated by the client in all -# Initial packets it sends for that connection after it receives the -# Retry packet. -# -# In response to processing an Initial packet containing a token that -# was provided in a Retry packet, a server cannot send another Retry -# packet; it can only refuse the connection or permit it to proceed. -# -# As long as it is not possible for an attacker to generate a valid -# token for its own address (see Section 8.1.4) and the client is able -# to return that token, it proves to the server that it received the -# token. -# -# A server can also use a Retry packet to defer the state and -# processing costs of connection establishment. Requiring the server -# to provide a different connection ID, along with the -# original_destination_connection_id transport parameter defined in -# Section 18.2, forces the server to demonstrate that it, or an entity -# it cooperates with, received the original Initial packet from the -# client. Providing a different connection ID also grants a server -# some control over how subsequent packets are routed. This can be -# used to direct connections to a different server instance. -# -# If a server receives a client Initial that contains an invalid Retry -# token but is otherwise valid, it knows the client will not accept -# another Retry token. The server can discard such a packet and allow -# the client to time out to detect handshake failure, but that could -# impose a significant latency penalty on the client. Instead, the -# server SHOULD immediately close (Section 10.2) the connection with an -# INVALID_TOKEN error. Note that a server has not established any -# state for the connection at this point and so does not enter the -# closing period. -# -# A flow showing the use of a Retry packet is shown in Figure 9. -# -# Client Server -# -# Initial[0]: CRYPTO[CH] -> -# -# <- Retry+Token -# -# Initial+Token[1]: CRYPTO[CH] -> -# -# Initial[0]: CRYPTO[SH] ACK[1] -# Handshake[0]: CRYPTO[EE, CERT, CV, FIN] -# <- 1-RTT[0]: STREAM[1, "..."] -# -# Figure 9: Example Handshake with Retry - -[[spec]] -level = "MUST" -quote = ''' -This token MUST be repeated by the client in all -Initial packets it sends for that connection after it receives the -Retry packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Instead, the -server SHOULD immediately close (Section 10.2) the connection with an -INVALID_TOKEN error. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.1.3.toml deleted file mode 100644 index baca09c0f2..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.3.toml +++ /dev/null @@ -1,241 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.3" - -# 8.1.3. Address Validation for Future Connections -# -# A server MAY provide clients with an address validation token during -# one connection that can be used on a subsequent connection. Address -# validation is especially important with 0-RTT because a server -# potentially sends a significant amount of data to a client in -# response to 0-RTT data. -# -# The server uses the NEW_TOKEN frame (Section 19.7) to provide the -# client with an address validation token that can be used to validate -# future connections. In a future connection, the client includes this -# token in Initial packets to provide address validation. The client -# MUST include the token in all Initial packets it sends, unless a -# Retry replaces the token with a newer one. The client MUST NOT use -# the token provided in a Retry for future connections. Servers MAY -# discard any Initial packet that does not carry the expected token. -# -# Unlike the token that is created for a Retry packet, which is used -# immediately, the token sent in the NEW_TOKEN frame can be used after -# some period of time has passed. Thus, a token SHOULD have an -# expiration time, which could be either an explicit expiration time or -# an issued timestamp that can be used to dynamically calculate the -# expiration time. A server can store the expiration time or include -# it in an encrypted form in the token. -# -# A token issued with NEW_TOKEN MUST NOT include information that would -# allow values to be linked by an observer to the connection on which -# it was issued. For example, it cannot include the previous -# connection ID or addressing information, unless the values are -# encrypted. A server MUST ensure that every NEW_TOKEN frame it sends -# is unique across all clients, with the exception of those sent to -# repair losses of previously sent NEW_TOKEN frames. Information that -# allows the server to distinguish between tokens from Retry and -# NEW_TOKEN MAY be accessible to entities other than the server. -# -# It is unlikely that the client port number is the same on two -# different connections; validating the port is therefore unlikely to -# be successful. -# -# A token received in a NEW_TOKEN frame is applicable to any server -# that the connection is considered authoritative for (e.g., server -# names included in the certificate). When connecting to a server for -# which the client retains an applicable and unused token, it SHOULD -# include that token in the Token field of its Initial packet. -# Including a token might allow the server to validate the client -# address without an additional round trip. A client MUST NOT include -# a token that is not applicable to the server that it is connecting -# to, unless the client has the knowledge that the server that issued -# the token and the server the client is connecting to are jointly -# managing the tokens. A client MAY use a token from any previous -# connection to that server. -# -# A token allows a server to correlate activity between the connection -# where the token was issued and any connection where it is used. -# Clients that want to break continuity of identity with a server can -# discard tokens provided using the NEW_TOKEN frame. In comparison, a -# token obtained in a Retry packet MUST be used immediately during the -# connection attempt and cannot be used in subsequent connection -# attempts. -# -# A client SHOULD NOT reuse a token from a NEW_TOKEN frame for -# different connection attempts. Reusing a token allows connections to -# be linked by entities on the network path; see Section 9.5. -# -# Clients might receive multiple tokens on a single connection. Aside -# from preventing linkability, any token can be used in any connection -# attempt. Servers can send additional tokens to either enable address -# validation for multiple connection attempts or replace older tokens -# that might become invalid. For a client, this ambiguity means that -# sending the most recent unused token is most likely to be effective. -# Though saving and using older tokens have no negative consequences, -# clients can regard older tokens as being less likely to be useful to -# the server for address validation. -# -# When a server receives an Initial packet with an address validation -# token, it MUST attempt to validate the token, unless it has already -# completed address validation. If the token is invalid, then the -# server SHOULD proceed as if the client did not have a validated -# address, including potentially sending a Retry packet. Tokens -# provided with NEW_TOKEN frames and Retry packets can be distinguished -# by servers (see Section 8.1.1), and the latter can be validated more -# strictly. If the validation succeeds, the server SHOULD then allow -# the handshake to proceed. -# -# | Note: The rationale for treating the client as unvalidated -# | rather than discarding the packet is that the client might have -# | received the token in a previous connection using the NEW_TOKEN -# | frame, and if the server has lost state, it might be unable to -# | validate the token at all, leading to connection failure if the -# | packet is discarded. -# -# In a stateless design, a server can use encrypted and authenticated -# tokens to pass information to clients that the server can later -# recover and use to validate a client address. Tokens are not -# integrated into the cryptographic handshake, and so they are not -# authenticated. For instance, a client might be able to reuse a -# token. To avoid attacks that exploit this property, a server can -# limit its use of tokens to only the information needed to validate -# client addresses. -# -# Clients MAY use tokens obtained on one connection for any connection -# attempt using the same version. When selecting a token to use, -# clients do not need to consider other properties of the connection -# that is being attempted, including the choice of possible application -# protocols, session tickets, or other connection properties. - -[[spec]] -level = "MAY" -quote = ''' -A server MAY provide clients with an address validation token during -one connection that can be used on a subsequent connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -The client -MUST include the token in all Initial packets it sends, unless a -Retry replaces the token with a newer one. -''' - -[[spec]] -level = "MUST" -quote = ''' -The client MUST NOT use -the token provided in a Retry for future connections. -''' - -[[spec]] -level = "MAY" -quote = ''' -Servers MAY -discard any Initial packet that does not carry the expected token. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Thus, a token SHOULD have an -expiration time, which could be either an explicit expiration time or -an issued timestamp that can be used to dynamically calculate the -expiration time. -''' - -[[spec]] -level = "MUST" -quote = ''' -A token issued with NEW_TOKEN MUST NOT include information that would -allow values to be linked by an observer to the connection on which -it was issued. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST ensure that every NEW_TOKEN frame it sends -is unique across all clients, with the exception of those sent to -repair losses of previously sent NEW_TOKEN frames. -''' - -[[spec]] -level = "MAY" -quote = ''' -Information that -allows the server to distinguish between tokens from Retry and -NEW_TOKEN MAY be accessible to entities other than the server. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When connecting to a server for -which the client retains an applicable and unused token, it SHOULD -include that token in the Token field of its Initial packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT include -a token that is not applicable to the server that it is connecting -to, unless the client has the knowledge that the server that issued -the token and the server the client is connecting to are jointly -managing the tokens. -''' - -[[spec]] -level = "MAY" -quote = ''' -A client MAY use a token from any previous -connection to that server. -''' - -[[spec]] -level = "MUST" -quote = ''' -In comparison, a -token obtained in a Retry packet MUST be used immediately during the -connection attempt and cannot be used in subsequent connection -attempts. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A client SHOULD NOT reuse a token from a NEW_TOKEN frame for -different connection attempts. -''' - -[[spec]] -level = "MUST" -quote = ''' -When a server receives an Initial packet with an address validation -token, it MUST attempt to validate the token, unless it has already -completed address validation. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If the token is invalid, then the -server SHOULD proceed as if the client did not have a validated -address, including potentially sending a Retry packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If the validation succeeds, the server SHOULD then allow -the handshake to proceed. -''' - -[[spec]] -level = "MAY" -quote = ''' -Clients MAY use tokens obtained on one connection for any connection -attempt using the same version. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.1.4.toml deleted file mode 100644 index 0f563c7c81..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.4.toml +++ /dev/null @@ -1,114 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1.4" - -# 8.1.4. Address Validation Token Integrity -# -# An address validation token MUST be difficult to guess. Including a -# random value with at least 128 bits of entropy in the token would be -# sufficient, but this depends on the server remembering the value it -# sends to clients. -# -# A token-based scheme allows the server to offload any state -# associated with validation to the client. For this design to work, -# the token MUST be covered by integrity protection against -# modification or falsification by clients. Without integrity -# protection, malicious clients could generate or guess values for -# tokens that would be accepted by the server. Only the server -# requires access to the integrity protection key for tokens. -# -# There is no need for a single well-defined format for the token -# because the server that generates the token also consumes it. Tokens -# sent in Retry packets SHOULD include information that allows the -# server to verify that the source IP address and port in client -# packets remain constant. -# -# Tokens sent in NEW_TOKEN frames MUST include information that allows -# the server to verify that the client IP address has not changed from -# when the token was issued. Servers can use tokens from NEW_TOKEN -# frames in deciding not to send a Retry packet, even if the client -# address has changed. If the client IP address has changed, the -# server MUST adhere to the anti-amplification limit; see Section 8. -# Note that in the presence of NAT, this requirement might be -# insufficient to protect other hosts that share the NAT from -# amplification attacks. -# -# Attackers could replay tokens to use servers as amplifiers in DDoS -# attacks. To protect against such attacks, servers MUST ensure that -# replay of tokens is prevented or limited. Servers SHOULD ensure that -# tokens sent in Retry packets are only accepted for a short time, as -# they are returned immediately by clients. Tokens that are provided -# in NEW_TOKEN frames (Section 19.7) need to be valid for longer but -# SHOULD NOT be accepted multiple times. Servers are encouraged to -# allow tokens to be used only once, if possible; tokens MAY include -# additional information about clients to further narrow applicability -# or reuse. - -[[spec]] -level = "MUST" -quote = ''' -An address validation token MUST be difficult to guess. -''' - -[[spec]] -level = "MUST" -quote = ''' -For this design to work, -the token MUST be covered by integrity protection against -modification or falsification by clients. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Tokens -sent in Retry packets SHOULD include information that allows the -server to verify that the source IP address and port in client -packets remain constant. -''' - -[[spec]] -level = "MUST" -quote = ''' -Tokens sent in NEW_TOKEN frames MUST include information that allows -the server to verify that the client IP address has not changed from -when the token was issued. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the client IP address has changed, the -server MUST adhere to the anti-amplification limit; see Section 8. -''' - -[[spec]] -level = "MUST" -quote = ''' -To protect against such attacks, servers MUST ensure that -replay of tokens is prevented or limited. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Servers SHOULD ensure that -tokens sent in Retry packets are only accepted for a short time, as -they are returned immediately by clients. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Tokens that are provided -in NEW_TOKEN frames (Section 19.7) need to be valid for longer but -SHOULD NOT be accepted multiple times. -''' - -[[spec]] -level = "MAY" -quote = ''' -Servers are encouraged to -allow tokens to be used only once, if possible; tokens MAY include -additional information about clients to further narrow applicability -or reuse. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.1.toml deleted file mode 100644 index 806ae9206f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.1.toml +++ /dev/null @@ -1,113 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1" - -# 8.1. Address Validation during Connection Establishment -# -# Connection establishment implicitly provides address validation for -# both endpoints. In particular, receipt of a packet protected with -# Handshake keys confirms that the peer successfully processed an -# Initial packet. Once an endpoint has successfully processed a -# Handshake packet from the peer, it can consider the peer address to -# have been validated. -# -# Additionally, an endpoint MAY consider the peer address validated if -# the peer uses a connection ID chosen by the endpoint and the -# connection ID contains at least 64 bits of entropy. -# -# For the client, the value of the Destination Connection ID field in -# its first Initial packet allows it to validate the server address as -# a part of successfully processing any packet. Initial packets from -# the server are protected with keys that are derived from this value -# (see Section 5.2 of [QUIC-TLS]). Alternatively, the value is echoed -# by the server in Version Negotiation packets (Section 6) or included -# in the Integrity Tag in Retry packets (Section 5.8 of [QUIC-TLS]). -# -# Prior to validating the client address, servers MUST NOT send more -# than three times as many bytes as the number of bytes they have -# received. This limits the magnitude of any amplification attack that -# can be mounted using spoofed source addresses. For the purposes of -# avoiding amplification prior to address validation, servers MUST -# count all of the payload bytes received in datagrams that are -# uniquely attributed to a single connection. This includes datagrams -# that contain packets that are successfully processed and datagrams -# that contain packets that are all discarded. -# -# Clients MUST ensure that UDP datagrams containing Initial packets -# have UDP payloads of at least 1200 bytes, adding PADDING frames as -# necessary. A client that sends padded datagrams allows the server to -# send more data prior to completing address validation. -# -# Loss of an Initial or Handshake packet from the server can cause a -# deadlock if the client does not send additional Initial or Handshake -# packets. A deadlock could occur when the server reaches its anti- -# amplification limit and the client has received acknowledgments for -# all the data it has sent. In this case, when the client has no -# reason to send additional packets, the server will be unable to send -# more data because it has not validated the client's address. To -# prevent this deadlock, clients MUST send a packet on a Probe Timeout -# (PTO); see Section 6.2 of [QUIC-RECOVERY]. Specifically, the client -# MUST send an Initial packet in a UDP datagram that contains at least -# 1200 bytes if it does not have Handshake keys, and otherwise send a -# Handshake packet. -# -# A server might wish to validate the client address before starting -# the cryptographic handshake. QUIC uses a token in the Initial packet -# to provide address validation prior to completing the handshake. -# This token is delivered to the client during connection establishment -# with a Retry packet (see Section 8.1.2) or in a previous connection -# using the NEW_TOKEN frame (see Section 8.1.3). -# -# In addition to sending limits imposed prior to address validation, -# servers are also constrained in what they can send by the limits set -# by the congestion controller. Clients are only constrained by the -# congestion controller. - -[[spec]] -level = "MAY" -quote = ''' -Additionally, an endpoint MAY consider the peer address validated if -the peer uses a connection ID chosen by the endpoint and the -connection ID contains at least 64 bits of entropy. -''' - -[[spec]] -level = "MUST" -quote = ''' -Prior to validating the client address, servers MUST NOT send more -than three times as many bytes as the number of bytes they have -received. -''' - -[[spec]] -level = "MUST" -quote = ''' -For the purposes of -avoiding amplification prior to address validation, servers MUST -count all of the payload bytes received in datagrams that are -uniquely attributed to a single connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -Clients MUST ensure that UDP datagrams containing Initial packets -have UDP payloads of at least 1200 bytes, adding PADDING frames as -necessary. -''' - -[[spec]] -level = "MUST" -quote = ''' -To -prevent this deadlock, clients MUST send a packet on a Probe Timeout -(PTO); see Section 6.2 of [QUIC-RECOVERY]. -''' - -[[spec]] -level = "MUST" -quote = ''' -Specifically, the client -MUST send an Initial packet in a UDP datagram that contains at least -1200 bytes if it does not have Handshake keys, and otherwise send a -Handshake packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.2.1.toml deleted file mode 100644 index 5e3892b771..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.1.toml +++ /dev/null @@ -1,96 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.1" - -# 8.2.1. Initiating Path Validation -# -# To initiate path validation, an endpoint sends a PATH_CHALLENGE frame -# containing an unpredictable payload on the path to be validated. -# -# An endpoint MAY send multiple PATH_CHALLENGE frames to guard against -# packet loss. However, an endpoint SHOULD NOT send multiple -# PATH_CHALLENGE frames in a single packet. -# -# An endpoint SHOULD NOT probe a new path with packets containing a -# PATH_CHALLENGE frame more frequently than it would send an Initial -# packet. This ensures that connection migration is no more load on a -# new path than establishing a new connection. -# -# The endpoint MUST use unpredictable data in every PATH_CHALLENGE -# frame so that it can associate the peer's response with the -# corresponding PATH_CHALLENGE. -# -# An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame -# to at least the smallest allowed maximum datagram size of 1200 bytes, -# unless the anti-amplification limit for the path does not permit -# sending a datagram of this size. Sending UDP datagrams of this size -# ensures that the network path from the endpoint to the peer can be -# used for QUIC; see Section 14. -# -# When an endpoint is unable to expand the datagram size to 1200 bytes -# due to the anti-amplification limit, the path MTU will not be -# validated. To ensure that the path MTU is large enough, the endpoint -# MUST perform a second path validation by sending a PATH_CHALLENGE -# frame in a datagram of at least 1200 bytes. This additional -# validation can be performed after a PATH_RESPONSE is successfully -# received or when enough bytes have been received on the path that -# sending the larger datagram will not result in exceeding the anti- -# amplification limit. -# -# Unlike other cases where datagrams are expanded, endpoints MUST NOT -# discard datagrams that appear to be too small when they contain -# PATH_CHALLENGE or PATH_RESPONSE. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY send multiple PATH_CHALLENGE frames to guard against -packet loss. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -However, an endpoint SHOULD NOT send multiple -PATH_CHALLENGE frames in a single packet. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD NOT probe a new path with packets containing a -PATH_CHALLENGE frame more frequently than it would send an Initial -packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -The endpoint MUST use unpredictable data in every PATH_CHALLENGE -frame so that it can associate the peer's response with the -corresponding PATH_CHALLENGE. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame -to at least the smallest allowed maximum datagram size of 1200 bytes, -unless the anti-amplification limit for the path does not permit -sending a datagram of this size. -''' - -[[spec]] -level = "MUST" -quote = ''' -To ensure that the path MTU is large enough, the endpoint -MUST perform a second path validation by sending a PATH_CHALLENGE -frame in a datagram of at least 1200 bytes. -''' - -[[spec]] -level = "MUST" -quote = ''' -Unlike other cases where datagrams are expanded, endpoints MUST NOT -discard datagrams that appear to be too small when they contain -PATH_CHALLENGE or PATH_RESPONSE. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.2.2.toml deleted file mode 100644 index 451c7cb2bb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.2.toml +++ /dev/null @@ -1,83 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.2" - -# 8.2.2. Path Validation Responses -# -# On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by -# echoing the data contained in the PATH_CHALLENGE frame in a -# PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a -# packet containing a PATH_RESPONSE frame unless constrained by -# congestion control. -# -# A PATH_RESPONSE frame MUST be sent on the network path where the -# PATH_CHALLENGE frame was received. This ensures that path validation -# by a peer only succeeds if the path is functional in both directions. -# This requirement MUST NOT be enforced by the endpoint that initiates -# path validation, as that would enable an attack on migration; see -# Section 9.3.3. -# -# An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame -# to at least the smallest allowed maximum datagram size of 1200 bytes. -# This verifies that the path is able to carry datagrams of this size -# in both directions. However, an endpoint MUST NOT expand the -# datagram containing the PATH_RESPONSE if the resulting data exceeds -# the anti-amplification limit. This is expected to only occur if the -# received PATH_CHALLENGE was not sent in an expanded datagram. -# -# An endpoint MUST NOT send more than one PATH_RESPONSE frame in -# response to one PATH_CHALLENGE frame; see Section 13.3. The peer is -# expected to send more PATH_CHALLENGE frames as necessary to evoke -# additional PATH_RESPONSE frames. - -[[spec]] -level = "MUST" -quote = ''' -On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by -echoing the data contained in the PATH_CHALLENGE frame in a -PATH_RESPONSE frame. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT delay transmission of a -packet containing a PATH_RESPONSE frame unless constrained by -congestion control. -''' - -[[spec]] -level = "MUST" -quote = ''' -A PATH_RESPONSE frame MUST be sent on the network path where the -PATH_CHALLENGE frame was received. -''' - -[[spec]] -level = "MUST" -quote = ''' -This requirement MUST NOT be enforced by the endpoint that initiates -path validation, as that would enable an attack on migration; see -Section 9.3.3. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame -to at least the smallest allowed maximum datagram size of 1200 bytes. -''' - -[[spec]] -level = "MUST" -quote = ''' -However, an endpoint MUST NOT expand the -datagram containing the PATH_RESPONSE if the resulting data exceeds -the anti-amplification limit. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send more than one PATH_RESPONSE frame in -response to one PATH_CHALLENGE frame; see Section 13.3. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.2.3.toml deleted file mode 100644 index 5395a0c964..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.3.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.3" - -# 8.2.3. Successful Path Validation -# -# Path validation succeeds when a PATH_RESPONSE frame is received that -# contains the data that was sent in a previous PATH_CHALLENGE frame. -# A PATH_RESPONSE frame received on any network path validates the path -# on which the PATH_CHALLENGE was sent. -# -# If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not -# expanded to at least 1200 bytes and if the response to it validates -# the peer address, the path is validated but not the path MTU. As a -# result, the endpoint can now send more than three times the amount of -# data that has been received. However, the endpoint MUST initiate -# another path validation with an expanded datagram to verify that the -# path supports the required MTU. -# -# Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE -# frame is not adequate validation, since the acknowledgment can be -# spoofed by a malicious peer. - -[[spec]] -level = "MUST" -quote = ''' -However, the endpoint MUST initiate -another path validation with an expanded datagram to verify that the -path supports the required MTU. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.2.4.toml deleted file mode 100644 index 0170ca2a91..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.4.toml +++ /dev/null @@ -1,60 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2.4" - -# 8.2.4. Failed Path Validation -# -# Path validation only fails when the endpoint attempting to validate -# the path abandons its attempt to validate the path. -# -# Endpoints SHOULD abandon path validation based on a timer. When -# setting this timer, implementations are cautioned that the new path -# could have a longer round-trip time than the original. A value of -# three times the larger of the current PTO or the PTO for the new path -# (using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED. -# -# This timeout allows for multiple PTOs to expire prior to failing path -# validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE -# frame does not cause path validation failure. -# -# Note that the endpoint might receive packets containing other frames -# on the new path, but a PATH_RESPONSE frame with appropriate data is -# required for path validation to succeed. -# -# When an endpoint abandons path validation, it determines that the -# path is unusable. This does not necessarily imply a failure of the -# connection -- endpoints can continue sending packets over other paths -# as appropriate. If no paths are available, an endpoint can wait for -# a new path to become available or close the connection. An endpoint -# that has no valid network path to its peer MAY signal this using the -# NO_VIABLE_PATH connection error, noting that this is only possible if -# the network path exists but does not support the required MTU -# (Section 14). -# -# A path validation might be abandoned for other reasons besides -# failure. Primarily, this happens if a connection migration to a new -# path is initiated while a path validation on the old path is in -# progress. - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD abandon path validation based on a timer. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A value of -three times the larger of the current PTO or the PTO for the new path -(using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint -that has no valid network path to its peer MAY signal this using the -NO_VIABLE_PATH connection error, noting that this is only possible if -the network path exists but does not support the required MTU -(Section 14). -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.2.toml deleted file mode 100644 index 6c31e1fa58..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.2.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.2" - -# 8.2. Path Validation -# -# Path validation is used by both peers during connection migration -# (see Section 9) to verify reachability after a change of address. In -# path validation, endpoints test reachability between a specific local -# address and a specific peer address, where an address is the 2-tuple -# of IP address and port. -# -# Path validation tests that packets sent on a path to a peer are -# received by that peer. Path validation is used to ensure that -# packets received from a migrating peer do not carry a spoofed source -# address. -# -# Path validation does not validate that a peer can send in the return -# direction. Acknowledgments cannot be used for return path validation -# because they contain insufficient entropy and might be spoofed. -# Endpoints independently determine reachability on each direction of a -# path, and therefore return reachability can only be established by -# the peer. -# -# Path validation can be used at any time by either endpoint. For -# instance, an endpoint might check that a peer is still in possession -# of its address after a period of quiescence. -# -# Path validation is not designed as a NAT traversal mechanism. Though -# the mechanism described here might be effective for the creation of -# NAT bindings that support NAT traversal, the expectation is that one -# endpoint is able to receive packets without first having sent a -# packet on that path. Effective NAT traversal needs additional -# synchronization mechanisms that are not provided here. -# -# An endpoint MAY include other frames with the PATH_CHALLENGE and -# PATH_RESPONSE frames used for path validation. In particular, an -# endpoint can include PADDING frames with a PATH_CHALLENGE frame for -# Path Maximum Transmission Unit Discovery (PMTUD); see Section 14.2.1. -# An endpoint can also include its own PATH_CHALLENGE frame when -# sending a PATH_RESPONSE frame. -# -# An endpoint uses a new connection ID for probes sent from a new local -# address; see Section 9.5. When probing a new path, an endpoint can -# ensure that its peer has an unused connection ID available for -# responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in -# the same packet, if the peer's active_connection_id_limit permits, -# ensures that an unused connection ID will be available to the peer -# when sending a response. -# -# An endpoint can choose to simultaneously probe multiple paths. The -# number of simultaneous paths used for probes is limited by the number -# of extra connection IDs its peer has previously supplied, since each -# new local address used for a probe requires a previously unused -# connection ID. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY include other frames with the PATH_CHALLENGE and -PATH_RESPONSE frames used for path validation. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/8.toml b/specs/www.rfc-editor.org/rfc/rfc9000/8.toml deleted file mode 100644 index fb5fb6318c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/8.toml +++ /dev/null @@ -1,31 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-8" - -# 8. Address Validation -# -# Address validation ensures that an endpoint cannot be used for a -# traffic amplification attack. In such an attack, a packet is sent to -# a server with spoofed source address information that identifies a -# victim. If a server generates more or larger packets in response to -# that packet, the attacker can use the server to send more data toward -# the victim than it would be able to send on its own. -# -# The primary defense against amplification attacks is verifying that a -# peer is able to receive packets at the transport address that it -# claims. Therefore, after receiving packets from an address that is -# not yet validated, an endpoint MUST limit the amount of data it sends -# to the unvalidated address to three times the amount of data received -# from that address. This limit on the size of responses is known as -# the anti-amplification limit. -# -# Address validation is performed both during connection establishment -# (see Section 8.1) and during connection migration (see Section 8.2). - -[[spec]] -level = "MUST" -quote = ''' -Therefore, after receiving packets from an address that is -not yet validated, an endpoint MUST limit the amount of data it sends -to the unvalidated address to three times the amount of data received -from that address. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.1.toml deleted file mode 100644 index 901a4b4d1c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.1.toml +++ /dev/null @@ -1,24 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.1" - -# 9.1. Probing a New Path -# -# An endpoint MAY probe for peer reachability from a new local address -# using path validation (Section 8.2) prior to migrating the connection -# to the new local address. Failure of path validation simply means -# that the new path is not usable for this connection. Failure to -# validate a path does not cause the connection to end unless there are -# no valid alternative paths available. -# -# PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames -# are "probing frames", and all other frames are "non-probing frames". -# A packet containing only probing frames is a "probing packet", and a -# packet containing any other frame is a "non-probing packet". - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY probe for peer reachability from a new local address -using path validation (Section 8.2) prior to migrating the connection -to the new local address. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.2.toml deleted file mode 100644 index d3e2bd2d0a..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.2.toml +++ /dev/null @@ -1,33 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.2" - -# 9.2. Initiating Connection Migration -# -# An endpoint can migrate a connection to a new local address by -# sending packets containing non-probing frames from that address. -# -# Each endpoint validates its peer's address during connection -# establishment. Therefore, a migrating endpoint can send to its peer -# knowing that the peer is willing to receive at the peer's current -# address. Thus, an endpoint can migrate to a new local address -# without first validating the peer's address. -# -# To establish reachability on the new path, an endpoint initiates path -# validation (Section 8.2) on the new path. An endpoint MAY defer path -# validation until after a peer sends the next non-probing frame to its -# new address. -# -# When migrating, the new path might not support the endpoint's current -# sending rate. Therefore, the endpoint resets its congestion -# controller and RTT estimate, as described in Section 9.4. -# -# The new path might not have the same ECN capability. Therefore, the -# endpoint validates ECN capability as described in Section 13.4. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY defer path -validation until after a peer sends the next non-probing frame to its -new address. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.3.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.3.2.toml deleted file mode 100644 index 01b3d764e6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.3.2.toml +++ /dev/null @@ -1,52 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.3.2" - -# 9.3.2. On-Path Address Spoofing -# -# An on-path attacker could cause a spurious connection migration by -# copying and forwarding a packet with a spoofed address such that it -# arrives before the original packet. The packet with the spoofed -# address will be seen to come from a migrating connection, and the -# original packet will be seen as a duplicate and dropped. After a -# spurious migration, validation of the source address will fail -# because the entity at the source address does not have the necessary -# cryptographic keys to read or respond to the PATH_CHALLENGE frame -# that is sent to it even if it wanted to. -# -# To protect the connection from failing due to such a spurious -# migration, an endpoint MUST revert to using the last validated peer -# address when validation of a new peer address fails. Additionally, -# receipt of packets with higher packet numbers from the legitimate -# peer address will trigger another connection migration. This will -# cause the validation of the address of the spurious migration to be -# abandoned, thus containing migrations initiated by the attacker -# injecting a single packet. -# -# If an endpoint has no state about the last validated peer address, it -# MUST close the connection silently by discarding all connection -# state. This results in new packets on the connection being handled -# generically. For instance, an endpoint MAY send a Stateless Reset in -# response to any further incoming packets. - -[[spec]] -level = "MUST" -quote = ''' -To protect the connection from failing due to such a spurious -migration, an endpoint MUST revert to using the last validated peer -address when validation of a new peer address fails. -''' - -[[spec]] -level = "MUST" -quote = ''' -If an endpoint has no state about the last validated peer address, it -MUST close the connection silently by discarding all connection -state. -''' - -[[spec]] -level = "MAY" -quote = ''' -For instance, an endpoint MAY send a Stateless Reset in -response to any further incoming packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.3.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.3.3.toml deleted file mode 100644 index f698c2169e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.3.3.toml +++ /dev/null @@ -1,63 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.3.3" - -# 9.3.3. Off-Path Packet Forwarding -# -# An off-path attacker that can observe packets might forward copies of -# genuine packets to endpoints. If the copied packet arrives before -# the genuine packet, this will appear as a NAT rebinding. Any genuine -# packet will be discarded as a duplicate. If the attacker is able to -# continue forwarding packets, it might be able to cause migration to a -# path via the attacker. This places the attacker on-path, giving it -# the ability to observe or drop all subsequent packets. -# -# This style of attack relies on the attacker using a path that has -# approximately the same characteristics as the direct path between -# endpoints. The attack is more reliable if relatively few packets are -# sent or if packet loss coincides with the attempted attack. -# -# A non-probing packet received on the original path that increases the -# maximum received packet number will cause the endpoint to move back -# to that path. Eliciting packets on this path increases the -# likelihood that the attack is unsuccessful. Therefore, mitigation of -# this attack relies on triggering the exchange of packets. -# -# In response to an apparent migration, endpoints MUST validate the -# previously active path using a PATH_CHALLENGE frame. This induces -# the sending of new packets on that path. If the path is no longer -# viable, the validation attempt will time out and fail; if the path is -# viable but no longer desired, the validation will succeed but only -# results in probing packets being sent on the path. -# -# An endpoint that receives a PATH_CHALLENGE on an active path SHOULD -# send a non-probing packet in response. If the non-probing packet -# arrives before any copy made by an attacker, this results in the -# connection being migrated back to the original path. Any subsequent -# migration to another path restarts this entire process. -# -# This defense is imperfect, but this is not considered a serious -# problem. If the path via the attack is reliably faster than the -# original path despite multiple attempts to use that original path, it -# is not possible to distinguish between an attack and an improvement -# in routing. -# -# An endpoint could also use heuristics to improve detection of this -# style of attack. For instance, NAT rebinding is improbable if -# packets were recently received on the old path; similarly, rebinding -# is rare on IPv6 paths. Endpoints can also look for duplicated -# packets. Conversely, a change in connection ID is more likely to -# indicate an intentional migration rather than an attack. - -[[spec]] -level = "MUST" -quote = ''' -In response to an apparent migration, endpoints MUST validate the -previously active path using a PATH_CHALLENGE frame. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint that receives a PATH_CHALLENGE on an active path SHOULD -send a non-probing packet in response. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.3.toml deleted file mode 100644 index a6097013d7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.3.toml +++ /dev/null @@ -1,77 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.3" - -# 9.3. Responding to Connection Migration -# -# Receiving a packet from a new peer address containing a non-probing -# frame indicates that the peer has migrated to that address. -# -# If the recipient permits the migration, it MUST send subsequent -# packets to the new peer address and MUST initiate path validation -# (Section 8.2) to verify the peer's ownership of the address if -# validation is not already underway. If the recipient has no unused -# connection IDs from the peer, it will not be able to send anything on -# the new path until the peer provides one; see Section 9.5. -# -# An endpoint only changes the address to which it sends packets in -# response to the highest-numbered non-probing packet. This ensures -# that an endpoint does not send packets to an old peer address in the -# case that it receives reordered packets. -# -# An endpoint MAY send data to an unvalidated peer address, but it MUST -# protect against potential attacks as described in Sections 9.3.1 and -# 9.3.2. An endpoint MAY skip validation of a peer address if that -# address has been seen recently. In particular, if an endpoint -# returns to a previously validated path after detecting some form of -# spurious migration, skipping address validation and restoring loss -# detection and congestion state can reduce the performance impact of -# the attack. -# -# After changing the address to which it sends non-probing packets, an -# endpoint can abandon any path validation for other addresses. -# -# Receiving a packet from a new peer address could be the result of a -# NAT rebinding at the peer. -# -# After verifying a new client address, the server SHOULD send new -# address validation tokens (Section 8) to the client. - -[[spec]] -level = "MUST" -quote = ''' -If the recipient permits the migration, it MUST send subsequent -packets to the new peer address and MUST initiate path validation -(Section 8.2) to verify the peer's ownership of the address if -validation is not already underway. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the recipient permits the migration, it MUST send subsequent -packets to the new peer address and MUST initiate path validation -(Section 8.2) to verify the peer's ownership of the address if -validation is not already underway. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MAY send data to an unvalidated peer address, but it MUST -protect against potential attacks as described in Sections 9.3.1 and -9.3.2. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY skip validation of a peer address if that -address has been seen recently. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -After verifying a new client address, the server SHOULD send new -address validation tokens (Section 8) to the client. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.4.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.4.toml deleted file mode 100644 index b2b0b0c89d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.4.toml +++ /dev/null @@ -1,78 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.4" - -# 9.4. Loss Detection and Congestion Control -# -# The capacity available on the new path might not be the same as the -# old path. Packets sent on the old path MUST NOT contribute to -# congestion control or RTT estimation for the new path. -# -# On confirming a peer's ownership of its new address, an endpoint MUST -# immediately reset the congestion controller and round-trip time -# estimator for the new path to initial values (see Appendices A.3 and -# B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address -# is its port number. Because port-only changes are commonly the -# result of NAT rebinding or other middlebox activity, the endpoint MAY -# instead retain its congestion control state and round-trip estimate -# in those cases instead of reverting to initial values. In cases -# where congestion control state retained from an old path is used on a -# new path with substantially different characteristics, a sender could -# transmit too aggressively until the congestion controller and the RTT -# estimator have adapted. Generally, implementations are advised to be -# cautious when using previous values on a new path. -# -# There could be apparent reordering at the receiver when an endpoint -# sends data and probes from/to multiple addresses during the migration -# period, since the two resulting paths could have different round-trip -# times. A receiver of packets on multiple paths will still send ACK -# frames covering all received packets. -# -# While multiple paths might be used during connection migration, a -# single congestion control context and a single loss recovery context -# (as described in [QUIC-RECOVERY]) could be adequate. For instance, -# an endpoint might delay switching to a new congestion control context -# until it is confirmed that an old path is no longer needed (such as -# the case described in Section 9.3.3). -# -# A sender can make exceptions for probe packets so that their loss -# detection is independent and does not unduly cause the congestion -# controller to reduce its sending rate. An endpoint might set a -# separate timer when a PATH_CHALLENGE is sent, which is canceled if -# the corresponding PATH_RESPONSE is received. If the timer fires -# before the PATH_RESPONSE is received, the endpoint might send a new -# PATH_CHALLENGE and restart the timer for a longer period of time. -# This timer SHOULD be set as described in Section 6.2.1 of -# [QUIC-RECOVERY] and MUST NOT be more aggressive. - -[[spec]] -level = "MUST" -quote = ''' -Packets sent on the old path MUST NOT contribute to -congestion control or RTT estimation for the new path. -''' - -[[spec]] -level = "MUST" -quote = ''' -On confirming a peer's ownership of its new address, an endpoint MUST -immediately reset the congestion controller and round-trip time -estimator for the new path to initial values (see Appendices A.3 and -B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address -is its port number. -''' - -[[spec]] -level = "MAY" -quote = ''' -Because port-only changes are commonly the -result of NAT rebinding or other middlebox activity, the endpoint MAY -instead retain its congestion control state and round-trip estimate -in those cases instead of reverting to initial values. -''' - -[[spec]] -level = "MUST" -quote = ''' -This timer SHOULD be set as described in Section 6.2.1 of -[QUIC-RECOVERY] and MUST NOT be more aggressive. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.5.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.5.toml deleted file mode 100644 index c8c6aaeab0..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.5.toml +++ /dev/null @@ -1,133 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.5" - -# 9.5. Privacy Implications of Connection Migration -# -# Using a stable connection ID on multiple network paths would allow a -# passive observer to correlate activity between those paths. An -# endpoint that moves between networks might not wish to have their -# activity correlated by any entity other than their peer, so different -# connection IDs are used when sending from different local addresses, -# as discussed in Section 5.1. For this to be effective, endpoints -# need to ensure that connection IDs they provide cannot be linked by -# any other entity. -# -# At any time, endpoints MAY change the Destination Connection ID they -# transmit with to a value that has not been used on another path. -# -# An endpoint MUST NOT reuse a connection ID when sending from more -# than one local address -- for example, when initiating connection -# migration as described in Section 9.2 or when probing a new network -# path as described in Section 9.1. -# -# Similarly, an endpoint MUST NOT reuse a connection ID when sending to -# more than one destination address. Due to network changes outside -# the control of its peer, an endpoint might receive packets from a new -# source address with the same Destination Connection ID field value, -# in which case it MAY continue to use the current connection ID with -# the new remote address while still sending from the same local -# address. -# -# These requirements regarding connection ID reuse apply only to the -# sending of packets, as unintentional changes in path without a change -# in connection ID are possible. For example, after a period of -# network inactivity, NAT rebinding might cause packets to be sent on a -# new path when the client resumes sending. An endpoint responds to -# such an event as described in Section 9.3. -# -# Using different connection IDs for packets sent in both directions on -# each new network path eliminates the use of the connection ID for -# linking packets from the same connection across different network -# paths. Header protection ensures that packet numbers cannot be used -# to correlate activity. This does not prevent other properties of -# packets, such as timing and size, from being used to correlate -# activity. -# -# An endpoint SHOULD NOT initiate migration with a peer that has -# requested a zero-length connection ID, because traffic over the new -# path might be trivially linkable to traffic over the old one. If the -# server is able to associate packets with a zero-length connection ID -# to the right connection, it means that the server is using other -# information to demultiplex packets. For example, a server might -# provide a unique address to every client -- for instance, using HTTP -# alternative services [ALTSVC]. Information that might allow correct -# routing of packets across multiple network paths will also allow -# activity on those paths to be linked by entities other than the peer. -# -# A client might wish to reduce linkability by switching to a new -# connection ID, source UDP port, or IP address (see [RFC8981]) when -# sending traffic after a period of inactivity. Changing the address -# from which it sends packets at the same time might cause the server -# to detect a connection migration. This ensures that the mechanisms -# that support migration are exercised even for clients that do not -# experience NAT rebindings or genuine migrations. Changing address -# can cause a peer to reset its congestion control state (see -# Section 9.4), so addresses SHOULD only be changed infrequently. -# -# An endpoint that exhausts available connection IDs cannot probe new -# paths or initiate migration, nor can it respond to probes or attempts -# by its peer to migrate. To ensure that migration is possible and -# packets sent on different paths cannot be correlated, endpoints -# SHOULD provide new connection IDs before peers migrate; see -# Section 5.1.1. If a peer might have exhausted available connection -# IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in -# all packets sent on a new network path. - -[[spec]] -level = "MAY" -quote = ''' -At any time, endpoints MAY change the Destination Connection ID they -transmit with to a value that has not been used on another path. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT reuse a connection ID when sending from more -than one local address -- for example, when initiating connection -migration as described in Section 9.2 or when probing a new network -path as described in Section 9.1. -''' - -[[spec]] -level = "MUST" -quote = ''' -Similarly, an endpoint MUST NOT reuse a connection ID when sending to -more than one destination address. -''' - -[[spec]] -level = "MAY" -quote = ''' -Due to network changes outside -the control of its peer, an endpoint might receive packets from a new -source address with the same Destination Connection ID field value, -in which case it MAY continue to use the current connection ID with -the new remote address while still sending from the same local -address. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD NOT initiate migration with a peer that has -requested a zero-length connection ID, because traffic over the new -path might be trivially linkable to traffic over the old one. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Changing address -can cause a peer to reset its congestion control state (see -Section 9.4), so addresses SHOULD only be changed infrequently. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -To ensure that migration is possible and -packets sent on different paths cannot be correlated, endpoints -SHOULD provide new connection IDs before peers migrate; see -Section 5.1.1. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.1.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.6.1.toml deleted file mode 100644 index 3f7f767b70..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.1.toml +++ /dev/null @@ -1,55 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6.1" - -# 9.6.1. Communicating a Preferred Address -# -# A server conveys a preferred address by including the -# preferred_address transport parameter in the TLS handshake. -# -# Servers MAY communicate a preferred address of each address family -# (IPv4 and IPv6) to allow clients to pick the one most suited to their -# network attachment. -# -# Once the handshake is confirmed, the client SHOULD select one of the -# two addresses provided by the server and initiate path validation -# (see Section 8.2). A client constructs packets using any previously -# unused active connection ID, taken from either the preferred_address -# transport parameter or a NEW_CONNECTION_ID frame. -# -# As soon as path validation succeeds, the client SHOULD begin sending -# all future packets to the new server address using the new connection -# ID and discontinue use of the old server address. If path validation -# fails, the client MUST continue sending all future packets to the -# server's original IP address. - -[[spec]] -level = "MAY" -quote = ''' -Servers MAY communicate a preferred address of each address family -(IPv4 and IPv6) to allow clients to pick the one most suited to their -network attachment. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Once the handshake is confirmed, the client SHOULD select one of the -two addresses provided by the server and initiate path validation -(see Section 8.2). -''' - -[[spec]] -level = "SHOULD" -quote = ''' -As soon as path validation succeeds, the client SHOULD begin sending -all future packets to the new server address using the new connection -ID and discontinue use of the old server address. -''' - -[[spec]] -level = "MUST" -quote = ''' -If path validation -fails, the client MUST continue sending all future packets to the -server's original IP address. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.2.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.6.2.toml deleted file mode 100644 index 54e1f81887..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.2.toml +++ /dev/null @@ -1,77 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6.2" - -# 9.6.2. Migration to a Preferred Address -# -# A client that migrates to a preferred address MUST validate the -# address it chooses before migrating; see Section 21.5.3. -# -# A server might receive a packet addressed to its preferred IP address -# at any time after it accepts a connection. If this packet contains a -# PATH_CHALLENGE frame, the server sends a packet containing a -# PATH_RESPONSE frame as per Section 8.2. The server MUST send non- -# probing packets from its original address until it receives a non- -# probing packet from the client at its preferred address and until the -# server has validated the new path. -# -# The server MUST probe on the path toward the client from its -# preferred address. This helps to guard against spurious migration -# initiated by an attacker. -# -# Once the server has completed its path validation and has received a -# non-probing packet with a new largest packet number on its preferred -# address, the server begins sending non-probing packets to the client -# exclusively from its preferred IP address. The server SHOULD drop -# newer packets for this connection that are received on the old IP -# address. The server MAY continue to process delayed packets that are -# received on the old IP address. -# -# The addresses that a server provides in the preferred_address -# transport parameter are only valid for the connection in which they -# are provided. A client MUST NOT use these for other connections, -# including connections that are resumed from the current connection. - -[[spec]] -level = "MUST" -quote = ''' -A client that migrates to a preferred address MUST validate the -address it chooses before migrating; see Section 21.5.3. -''' - -[[spec]] -level = "MUST" -quote = ''' -The server MUST send non- -probing packets from its original address until it receives a non- -probing packet from the client at its preferred address and until the -server has validated the new path. -''' - -[[spec]] -level = "MUST" -quote = ''' -The server MUST probe on the path toward the client from its -preferred address. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The server SHOULD drop -newer packets for this connection that are received on the old IP -address. -''' - -[[spec]] -level = "MAY" -quote = ''' -The server MAY continue to process delayed packets that are -received on the old IP address. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT use these for other connections, -including connections that are resumed from the current connection. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.3.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.6.3.toml deleted file mode 100644 index d037b682d4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.3.toml +++ /dev/null @@ -1,95 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6.3" - -# 9.6.3. Interaction of Client Migration and Preferred Address -# -# A client might need to perform a connection migration before it has -# migrated to the server's preferred address. In this case, the client -# SHOULD perform path validation to both the original and preferred -# server address from the client's new address concurrently. -# -# If path validation of the server's preferred address succeeds, the -# client MUST abandon validation of the original address and migrate to -# using the server's preferred address. If path validation of the -# server's preferred address fails but validation of the server's -# original address succeeds, the client MAY migrate to its new address -# and continue sending to the server's original address. -# -# If packets received at the server's preferred address have a -# different source address than observed from the client during the -# handshake, the server MUST protect against potential attacks as -# described in Sections 9.3.1 and 9.3.2. In addition to intentional -# simultaneous migration, this might also occur because the client's -# access network used a different NAT binding for the server's -# preferred address. -# -# Servers SHOULD initiate path validation to the client's new address -# upon receiving a probe packet from a different address; see -# Section 8. -# -# A client that migrates to a new address SHOULD use a preferred -# address from the same address family for the server. -# -# The connection ID provided in the preferred_address transport -# parameter is not specific to the addresses that are provided. This -# connection ID is provided to ensure that the client has a connection -# ID available for migration, but the client MAY use this connection ID -# on any path. - -[[spec]] -level = "SHOULD" -quote = ''' -In this case, the client -SHOULD perform path validation to both the original and preferred -server address from the client's new address concurrently. -''' - -[[spec]] -level = "MUST" -quote = ''' -If path validation of the server's preferred address succeeds, the -client MUST abandon validation of the original address and migrate to -using the server's preferred address. -''' - -[[spec]] -level = "MAY" -quote = ''' -If path validation of the -server's preferred address fails but validation of the server's -original address succeeds, the client MAY migrate to its new address -and continue sending to the server's original address. -''' - -[[spec]] -level = "MUST" -quote = ''' -If packets received at the server's preferred address have a -different source address than observed from the client during the -handshake, the server MUST protect against potential attacks as -described in Sections 9.3.1 and 9.3.2. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Servers SHOULD initiate path validation to the client's new address -upon receiving a probe packet from a different address; see -Section 8. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A client that migrates to a new address SHOULD use a preferred -address from the same address family for the server. -''' - -[[spec]] -level = "MAY" -quote = ''' -This -connection ID is provided to ensure that the client has a connection -ID available for migration, but the client MAY use this connection ID -on any path. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.6.toml deleted file mode 100644 index f6787d7810..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.6.toml +++ /dev/null @@ -1,27 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.6" - -# 9.6. Server's Preferred Address -# -# QUIC allows servers to accept connections on one IP address and -# attempt to transfer these connections to a more preferred address -# shortly after the handshake. This is particularly useful when -# clients initially connect to an address shared by multiple servers -# but would prefer to use a unicast address to ensure connection -# stability. This section describes the protocol for migrating a -# connection to a preferred server address. -# -# Migrating a connection to a new server address mid-connection is not -# supported by the version of QUIC specified in this document. If a -# client receives packets from a new server address when the client has -# not initiated a migration to that address, the client SHOULD discard -# these packets. - -[[spec]] -level = "SHOULD" -quote = ''' -If a -client receives packets from a new server address when the client has -not initiated a migration to that address, the client SHOULD discard -these packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.7.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.7.toml deleted file mode 100644 index 1d8e384529..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.7.toml +++ /dev/null @@ -1,36 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.7" - -# 9.7. Use of IPv6 Flow Label and Migration -# -# Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label -# in compliance with [RFC6437], unless the local API does not allow -# setting IPv6 flow labels. -# -# The flow label generation MUST be designed to minimize the chances of -# linkability with a previously used flow label, as a stable flow label -# would enable correlating activity on multiple paths; see Section 9.5. -# -# [RFC6437] suggests deriving values using a pseudorandom function to -# generate flow labels. Including the Destination Connection ID field -# in addition to source and destination addresses when generating flow -# labels ensures that changes are synchronized with changes in other -# observable identifiers. A cryptographic hash function that combines -# these inputs with a local secret is one way this might be -# implemented. - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label -in compliance with [RFC6437], unless the local API does not allow -setting IPv6 flow labels. -''' - -[[spec]] -level = "MUST" -quote = ''' -The flow label generation MUST be designed to minimize the chances of -linkability with a previously used flow label, as a stable flow label -would enable correlating activity on multiple paths; see Section 9.5. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9000/9.toml b/specs/www.rfc-editor.org/rfc/rfc9000/9.toml deleted file mode 100644 index bcb135a9f8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9000/9.toml +++ /dev/null @@ -1,104 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9000#section-9" - -# 9. Connection Migration -# -# The use of a connection ID allows connections to survive changes to -# endpoint addresses (IP address and port), such as those caused by an -# endpoint migrating to a new network. This section describes the -# process by which an endpoint migrates to a new address. -# -# The design of QUIC relies on endpoints retaining a stable address for -# the duration of the handshake. An endpoint MUST NOT initiate -# connection migration before the handshake is confirmed, as defined in -# Section 4.1.2 of [QUIC-TLS]. -# -# If the peer sent the disable_active_migration transport parameter, an -# endpoint also MUST NOT send packets (including probing packets; see -# Section 9.1) from a different local address to the address the peer -# used during the handshake, unless the endpoint has acted on a -# preferred_address transport parameter from the peer. If the peer -# violates this requirement, the endpoint MUST either drop the incoming -# packets on that path without generating a Stateless Reset or proceed -# with path validation and allow the peer to migrate. Generating a -# Stateless Reset or closing the connection would allow third parties -# in the network to cause connections to close by spoofing or otherwise -# manipulating observed traffic. -# -# Not all changes of peer address are intentional, or active, -# migrations. The peer could experience NAT rebinding: a change of -# address due to a middlebox, usually a NAT, allocating a new outgoing -# port or even a new outgoing IP address for a flow. An endpoint MUST -# perform path validation (Section 8.2) if it detects any change to a -# peer's address, unless it has previously validated that address. -# -# When an endpoint has no validated path on which to send packets, it -# MAY discard connection state. An endpoint capable of connection -# migration MAY wait for a new path to become available before -# discarding connection state. -# -# This document limits migration of connections to new client -# addresses, except as described in Section 9.6. Clients are -# responsible for initiating all migrations. Servers do not send non- -# probing packets (see Section 9.1) toward a client address until they -# see a non-probing packet from that address. If a client receives -# packets from an unknown server address, the client MUST discard these -# packets. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT initiate -connection migration before the handshake is confirmed, as defined in -Section 4.1.2 of [QUIC-TLS]. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the peer sent the disable_active_migration transport parameter, an -endpoint also MUST NOT send packets (including probing packets; see -Section 9.1) from a different local address to the address the peer -used during the handshake, unless the endpoint has acted on a -preferred_address transport parameter from the peer. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the peer -violates this requirement, the endpoint MUST either drop the incoming -packets on that path without generating a Stateless Reset or proceed -with path validation and allow the peer to migrate. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST -perform path validation (Section 8.2) if it detects any change to a -peer's address, unless it has previously validated that address. -''' - -[[spec]] -level = "MAY" -quote = ''' -When an endpoint has no validated path on which to send packets, it -MAY discard connection state. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint capable of connection -migration MAY wait for a new path to become available before -discarding connection state. -''' - -[[spec]] -level = "MUST" -quote = ''' -If a client receives -packets from an unknown server address, the client MUST discard these -packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.1.2.toml deleted file mode 100644 index 09a47ccd52..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.1.2.toml +++ /dev/null @@ -1,31 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.2" - -# 4.1.2. Handshake Confirmed -# -# In this document, the TLS handshake is considered confirmed at the -# server when the handshake completes. The server MUST send a -# HANDSHAKE_DONE frame as soon as the handshake is complete. At the -# client, the handshake is considered confirmed when a HANDSHAKE_DONE -# frame is received. -# -# Additionally, a client MAY consider the handshake to be confirmed -# when it receives an acknowledgment for a 1-RTT packet. This can be -# implemented by recording the lowest packet number sent with 1-RTT -# keys and comparing it to the Largest Acknowledged field in any -# received 1-RTT ACK frame: once the latter is greater than or equal to -# the former, the handshake is confirmed. - -[[spec]] -level = "MUST" -quote = ''' -The server MUST send a -HANDSHAKE_DONE frame as soon as the handshake is complete. -''' - -[[spec]] -level = "MAY" -quote = ''' -Additionally, a client MAY consider the handshake to be confirmed -when it receives an acknowledgment for a 1-RTT packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.1.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.1.3.toml deleted file mode 100644 index 60e6ecee25..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.1.3.toml +++ /dev/null @@ -1,123 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.3" - -# 4.1.3. Sending and Receiving Handshake Messages -# -# In order to drive the handshake, TLS depends on being able to send -# and receive handshake messages. There are two basic functions on -# this interface: one where QUIC requests handshake messages and one -# where QUIC provides bytes that comprise handshake messages. -# -# Before starting the handshake, QUIC provides TLS with the transport -# parameters (see Section 8.2) that it wishes to carry. -# -# A QUIC client starts TLS by requesting TLS handshake bytes from TLS. -# The client acquires handshake bytes before sending its first packet. -# A QUIC server starts the process by providing TLS with the client's -# handshake bytes. -# -# At any time, the TLS stack at an endpoint will have a current sending -# encryption level and a receiving encryption level. TLS encryption -# levels determine the QUIC packet type and keys that are used for -# protecting data. -# -# Each encryption level is associated with a different sequence of -# bytes, which is reliably transmitted to the peer in CRYPTO frames. -# When TLS provides handshake bytes to be sent, they are appended to -# the handshake bytes for the current encryption level. The encryption -# level then determines the type of packet that the resulting CRYPTO -# frame is carried in; see Table 1. -# -# Four encryption levels are used, producing keys for Initial, 0-RTT, -# Handshake, and 1-RTT packets. CRYPTO frames are carried in just -# three of these levels, omitting the 0-RTT level. These four levels -# correspond to three packet number spaces: Initial and Handshake -# encrypted packets use their own separate spaces; 0-RTT and 1-RTT -# packets use the application data packet number space. -# -# QUIC takes the unprotected content of TLS handshake records as the -# content of CRYPTO frames. TLS record protection is not used by QUIC. -# QUIC assembles CRYPTO frames into QUIC packets, which are protected -# using QUIC packet protection. -# -# QUIC CRYPTO frames only carry TLS handshake messages. TLS alerts are -# turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8. TLS -# application data and other content types cannot be carried by QUIC at -# any encryption level; it is an error if they are received from the -# TLS stack. -# -# When an endpoint receives a QUIC packet containing a CRYPTO frame -# from the network, it proceeds as follows: -# -# * If the packet uses the current TLS receiving encryption level, -# sequence the data into the input flow as usual. As with STREAM -# frames, the offset is used to find the proper location in the data -# sequence. If the result of this process is that new data is -# available, then it is delivered to TLS in order. -# -# * If the packet is from a previously installed encryption level, it -# MUST NOT contain data that extends past the end of previously -# received data in that flow. Implementations MUST treat any -# violations of this requirement as a connection error of type -# PROTOCOL_VIOLATION. -# -# * If the packet is from a new encryption level, it is saved for -# later processing by TLS. Once TLS moves to receiving from this -# encryption level, saved data can be provided to TLS. When TLS -# provides keys for a higher encryption level, if there is data from -# a previous encryption level that TLS has not consumed, this MUST -# be treated as a connection error of type PROTOCOL_VIOLATION. -# -# Each time that TLS is provided with new data, new handshake bytes are -# requested from TLS. TLS might not provide any bytes if the handshake -# messages it has received are incomplete or it has no data to send. -# -# The content of CRYPTO frames might either be processed incrementally -# by TLS or buffered until complete messages or flights are available. -# TLS is responsible for buffering handshake bytes that have arrived in -# order. QUIC is responsible for buffering handshake bytes that arrive -# out of order or for encryption levels that are not yet ready. QUIC -# does not provide any means of flow control for CRYPTO frames; see -# Section 7.5 of [QUIC-TRANSPORT]. -# -# Once the TLS handshake is complete, this is indicated to QUIC along -# with any final handshake bytes that TLS needs to send. At this -# stage, the transport parameters that the peer advertised during the -# handshake are authenticated; see Section 8.2. -# -# Once the handshake is complete, TLS becomes passive. TLS can still -# receive data from its peer and respond in kind, but it will not need -# to send more data unless specifically requested -- either by an -# application or QUIC. One reason to send data is that the server -# might wish to provide additional or updated session tickets to a -# client. -# -# When the handshake is complete, QUIC only needs to provide TLS with -# any data that arrives in CRYPTO streams. In the same manner that is -# used during the handshake, new data is requested from TLS after -# providing received data. - -[[spec]] -level = "MUST" -quote = ''' -* If the packet is from a previously installed encryption level, it -MUST NOT contain data that extends past the end of previously -received data in that flow. -''' - -[[spec]] -level = "MUST" -quote = ''' -Implementations MUST treat any -violations of this requirement as a connection error of type -PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -When TLS -provides keys for a higher encryption level, if there is data from -a previous encryption level that TLS has not consumed, this MUST -be treated as a connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.1.4.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.1.4.toml deleted file mode 100644 index 6960b02ab5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.1.4.toml +++ /dev/null @@ -1,84 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.4" - -# 4.1.4. Encryption Level Changes -# -# As keys at a given encryption level become available to TLS, TLS -# indicates to QUIC that reading or writing keys at that encryption -# level are available. -# -# The availability of new keys is always a result of providing inputs -# to TLS. TLS only provides new keys after being initialized (by a -# client) or when provided with new handshake data. -# -# However, a TLS implementation could perform some of its processing -# asynchronously. In particular, the process of validating a -# certificate can take some time. While waiting for TLS processing to -# complete, an endpoint SHOULD buffer received packets if they might be -# processed using keys that are not yet available. These packets can -# be processed once keys are provided by TLS. An endpoint SHOULD -# continue to respond to packets that can be processed during this -# time. -# -# After processing inputs, TLS might produce handshake bytes, keys for -# new encryption levels, or both. -# -# TLS provides QUIC with three items as a new encryption level becomes -# available: -# -# * A secret -# -# * An Authenticated Encryption with Associated Data (AEAD) function -# -# * A Key Derivation Function (KDF) -# -# These values are based on the values that TLS negotiates and are used -# by QUIC to generate packet and header protection keys; see Section 5 -# and Section 5.4. -# -# If 0-RTT is possible, it is ready after the client sends a TLS -# ClientHello message or the server receives that message. After -# providing a QUIC client with the first handshake bytes, the TLS stack -# might signal the change to 0-RTT keys. On the server, after -# receiving handshake bytes that contain a ClientHello message, a TLS -# server might signal that 0-RTT keys are available. -# -# Although TLS only uses one encryption level at a time, QUIC may use -# more than one level. For instance, after sending its Finished -# message (using a CRYPTO frame at the Handshake encryption level) an -# endpoint can send STREAM data (in 1-RTT encryption). If the Finished -# message is lost, the endpoint uses the Handshake encryption level to -# retransmit the lost message. Reordering or loss of packets can mean -# that QUIC will need to handle packets at multiple encryption levels. -# During the handshake, this means potentially handling packets at -# higher and lower encryption levels than the current encryption level -# used by TLS. -# -# In particular, server implementations need to be able to read packets -# at the Handshake encryption level at the same time as the 0-RTT -# encryption level. A client could interleave ACK frames that are -# protected with Handshake keys with 0-RTT data, and the server needs -# to process those acknowledgments in order to detect lost Handshake -# packets. -# -# QUIC also needs access to keys that might not ordinarily be available -# to a TLS implementation. For instance, a client might need to -# acknowledge Handshake packets before it is ready to send CRYPTO -# frames at that encryption level. TLS therefore needs to provide keys -# to QUIC before it might produce them for its own use. - -[[spec]] -level = "SHOULD" -quote = ''' -While waiting for TLS processing to -complete, an endpoint SHOULD buffer received packets if they might be -processed using keys that are not yet available. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD -continue to respond to packets that can be processed during this -time. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.2.toml deleted file mode 100644 index b14a885058..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.2.toml +++ /dev/null @@ -1,30 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.2" - -# 4.2. TLS Version -# -# This document describes how TLS 1.3 [TLS13] is used with QUIC. -# -# In practice, the TLS handshake will negotiate a version of TLS to -# use. This could result in a version of TLS newer than 1.3 being -# negotiated if both endpoints support that version. This is -# acceptable provided that the features of TLS 1.3 that are used by -# QUIC are supported by the newer version. -# -# Clients MUST NOT offer TLS versions older than 1.3. A badly -# configured TLS implementation could negotiate TLS 1.2 or another -# older version of TLS. An endpoint MUST terminate the connection if a -# version of TLS older than 1.3 is negotiated. - -[[spec]] -level = "MUST" -quote = ''' -Clients MUST NOT offer TLS versions older than 1.3. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST terminate the connection if a -version of TLS older than 1.3 is negotiated. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.3.toml deleted file mode 100644 index 70ccf89167..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.3.toml +++ /dev/null @@ -1,53 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.3" - -# 4.3. ClientHello Size -# -# The first Initial packet from a client contains the start or all of -# its first cryptographic handshake message, which for TLS is the -# ClientHello. Servers might need to parse the entire ClientHello -# (e.g., to access extensions such as Server Name Identification (SNI) -# or Application-Layer Protocol Negotiation (ALPN)) in order to decide -# whether to accept the new incoming QUIC connection. If the -# ClientHello spans multiple Initial packets, such servers would need -# to buffer the first received fragments, which could consume excessive -# resources if the client's address has not yet been validated. To -# avoid this, servers MAY use the Retry feature (see Section 8.1 of -# [QUIC-TRANSPORT]) to only buffer partial ClientHello messages from -# clients with a validated address. -# -# QUIC packet and framing add at least 36 bytes of overhead to the -# ClientHello message. That overhead increases if the client chooses a -# Source Connection ID field longer than zero bytes. Overheads also do -# not include the token or a Destination Connection ID longer than 8 -# bytes, both of which might be required if a server sends a Retry -# packet. -# -# A typical TLS ClientHello can easily fit into a 1200-byte packet. -# However, in addition to the overheads added by QUIC, there are -# several variables that could cause this limit to be exceeded. Large -# session tickets, multiple or large key shares, and long lists of -# supported ciphers, signature algorithms, versions, QUIC transport -# parameters, and other negotiable parameters and extensions could -# cause this message to grow. -# -# For servers, in addition to connection IDs and tokens, the size of -# TLS session tickets can have an effect on a client's ability to -# connect efficiently. Minimizing the size of these values increases -# the probability that clients can use them and still fit their entire -# ClientHello message in their first Initial packet. -# -# The TLS implementation does not need to ensure that the ClientHello -# is large enough to meet QUIC's requirements for datagrams that carry -# Initial packets; see Section 14.1 of [QUIC-TRANSPORT]. QUIC -# implementations use PADDING frames or packet coalescing to ensure -# that datagrams are large enough. - -[[spec]] -level = "MAY" -quote = ''' -To -avoid this, servers MAY use the Retry feature (see Section 8.1 of -[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from -clients with a validated address. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.4.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.4.toml deleted file mode 100644 index f6af118014..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.4.toml +++ /dev/null @@ -1,86 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.4" - -# 4.4. Peer Authentication -# -# The requirements for authentication depend on the application -# protocol that is in use. TLS provides server authentication and -# permits the server to request client authentication. -# -# A client MUST authenticate the identity of the server. This -# typically involves verification that the identity of the server is -# included in a certificate and that the certificate is issued by a -# trusted entity (see for example [RFC2818]). -# -# | Note: Where servers provide certificates for authentication, -# | the size of the certificate chain can consume a large number of -# | bytes. Controlling the size of certificate chains is critical -# | to performance in QUIC as servers are limited to sending 3 -# | bytes for every byte received prior to validating the client -# | address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a -# | certificate chain can be managed by limiting the number of -# | names or extensions; using keys with small public key -# | representations, like ECDSA; or by using certificate -# | compression [COMPRESS]. -# -# A server MAY request that the client authenticate during the -# handshake. A server MAY refuse a connection if the client is unable -# to authenticate when requested. The requirements for client -# authentication vary based on application protocol and deployment. -# -# A server MUST NOT use post-handshake client authentication (as -# defined in Section 4.6.2 of [TLS13]) because the multiplexing offered -# by QUIC prevents clients from correlating the certificate request -# with the application-level event that triggered it (see -# [HTTP2-TLS13]). More specifically, servers MUST NOT send post- -# handshake TLS CertificateRequest messages, and clients MUST treat -# receipt of such messages as a connection error of type -# PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -A client MUST authenticate the identity of the server. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY request that the client authenticate during the -handshake. -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY refuse a connection if the client is unable -to authenticate when requested. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST NOT use post-handshake client authentication (as -defined in Section 4.6.2 of [TLS13]) because the multiplexing offered -by QUIC prevents clients from correlating the certificate request -with the application-level event that triggered it (see -[HTTP2-TLS13]). -''' - -[[spec]] -level = "MUST" -quote = ''' -More specifically, servers MUST NOT send post- -handshake TLS CertificateRequest messages, and clients MUST treat -receipt of such messages as a connection error of type -PROTOCOL_VIOLATION. -''' - -[[spec]] -level = "MUST" -quote = ''' -More specifically, servers MUST NOT send post- -handshake TLS CertificateRequest messages, and clients MUST treat -receipt of such messages as a connection error of type -PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.5.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.5.toml deleted file mode 100644 index a7f5b1d7e8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.5.toml +++ /dev/null @@ -1,37 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.5" - -# 4.5. Session Resumption -# -# QUIC can use the session resumption feature of TLS 1.3. It does this -# by carrying NewSessionTicket messages in CRYPTO frames after the -# handshake is complete. Session resumption can be used to provide -# 0-RTT and can also be used when 0-RTT is disabled. -# -# Endpoints that use session resumption might need to remember some -# information about the current connection when creating a resumed -# connection. TLS requires that some information be retained; see -# Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state -# being retained when resuming a connection unless 0-RTT is also used; -# see Section 7.4.1 of [QUIC-TRANSPORT] and Section 4.6.1. Application -# protocols could depend on state that is retained between resumed -# connections. -# -# Clients can store any state required for resumption along with the -# session ticket. Servers can use the session ticket to help carry -# state. -# -# Session resumption allows servers to link activity on the original -# connection with the resumed connection, which might be a privacy -# issue for clients. Clients can choose not to enable resumption to -# avoid creating this correlation. Clients SHOULD NOT reuse tickets as -# that allows entities other than the server to correlate connections; -# see Appendix C.4 of [TLS13]. - -[[spec]] -level = "SHOULD" -quote = ''' -Clients SHOULD NOT reuse tickets as -that allows entities other than the server to correlate connections; -see Appendix C.4 of [TLS13]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.6.1.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.6.1.toml deleted file mode 100644 index 86fb189196..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.6.1.toml +++ /dev/null @@ -1,47 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.6.1" - -# 4.6.1. Enabling 0-RTT -# -# The TLS early_data extension in the NewSessionTicket message is -# defined to convey (in the max_early_data_size parameter) the amount -# of TLS 0-RTT data the server is willing to accept. QUIC does not use -# TLS early data. QUIC uses 0-RTT packets to carry early data. -# Accordingly, the max_early_data_size parameter is repurposed to hold -# a sentinel value 0xffffffff to indicate that the server is willing to -# accept QUIC 0-RTT data. To indicate that the server does not accept -# 0-RTT data, the early_data extension is omitted from the -# NewSessionTicket. The amount of data that the client can send in -# QUIC 0-RTT is controlled by the initial_max_data transport parameter -# supplied by the server. -# -# Servers MUST NOT send the early_data extension with a -# max_early_data_size field set to any value other than 0xffffffff. A -# client MUST treat receipt of a NewSessionTicket that contains an -# early_data extension with any other value as a connection error of -# type PROTOCOL_VIOLATION. -# -# A client that wishes to send 0-RTT packets uses the early_data -# extension in the ClientHello message of a subsequent handshake; see -# Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT -# packets. -# -# A client that attempts 0-RTT might also provide an address validation -# token if the server has sent a NEW_TOKEN frame; see Section 8.1 of -# [QUIC-TRANSPORT]. - -[[spec]] -level = "MUST" -quote = ''' -Servers MUST NOT send the early_data extension with a -max_early_data_size field set to any value other than 0xffffffff. -''' - -[[spec]] -level = "MUST" -quote = ''' -A -client MUST treat receipt of a NewSessionTicket that contains an -early_data extension with any other value as a connection error of -type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.6.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.6.2.toml deleted file mode 100644 index cdac74f663..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.6.2.toml +++ /dev/null @@ -1,55 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.6.2" - -# 4.6.2. Accepting and Rejecting 0-RTT -# -# A server accepts 0-RTT by sending an early_data extension in the -# EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then -# processes and acknowledges the 0-RTT packets that it receives. -# -# A server rejects 0-RTT by sending the EncryptedExtensions without an -# early_data extension. A server will always reject 0-RTT if it sends -# a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT -# process any 0-RTT packets, even if it could. When 0-RTT was -# rejected, a client SHOULD treat receipt of an acknowledgment for a -# 0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it -# is able to detect the condition. -# -# When 0-RTT is rejected, all connection characteristics that the -# client assumed might be incorrect. This includes the choice of -# application protocol, transport parameters, and any application -# configuration. The client therefore MUST reset the state of all -# streams, including application state bound to those streams. -# -# A client MAY reattempt 0-RTT if it receives a Retry or Version -# Negotiation packet. These packets do not signify rejection of 0-RTT. - -[[spec]] -level = "MUST" -quote = ''' -When rejecting 0-RTT, a server MUST NOT -process any 0-RTT packets, even if it could. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When 0-RTT was -rejected, a client SHOULD treat receipt of an acknowledgment for a -0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it -is able to detect the condition. -''' - -[[spec]] -level = "MUST" -quote = ''' -The client therefore MUST reset the state of all -streams, including application state bound to those streams. -''' - -[[spec]] -level = "MAY" -quote = ''' -A client MAY reattempt 0-RTT if it receives a Retry or Version -Negotiation packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.7.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.7.toml deleted file mode 100644 index a7e7480999..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.7.toml +++ /dev/null @@ -1,21 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.7" - -# 4.7. HelloRetryRequest -# -# The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be -# used to request that a client provide new information, such as a key -# share, or to validate some characteristic of the client. From the -# perspective of QUIC, HelloRetryRequest is not differentiated from -# other cryptographic handshake messages that are carried in Initial -# packets. Although it is in principle possible to use this feature -# for address verification, QUIC implementations SHOULD instead use the -# Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. - -[[spec]] -level = "SHOULD" -quote = ''' -Although it is in principle possible to use this feature -for address verification, QUIC implementations SHOULD instead use the -Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.8.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.8.toml deleted file mode 100644 index fc77efd324..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.8.toml +++ /dev/null @@ -1,42 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.8" - -# 4.8. TLS Errors -# -# If TLS experiences an error, it generates an appropriate alert as -# defined in Section 6 of [TLS13]. -# -# A TLS alert is converted into a QUIC connection error. The -# AlertDescription value is added to 0x0100 to produce a QUIC error -# code from the range reserved for CRYPTO_ERROR; see Section 20.1 of -# [QUIC-TRANSPORT]. The resulting value is sent in a QUIC -# CONNECTION_CLOSE frame of type 0x1c. -# -# QUIC is only able to convey an alert level of "fatal". In TLS 1.3, -# the only existing uses for the "warning" level are to signal -# connection close; see Section 6.1 of [TLS13]. As QUIC provides -# alternative mechanisms for connection termination and the TLS -# connection is only closed if an error is encountered, a QUIC endpoint -# MUST treat any alert from TLS as if it were at the "fatal" level. -# -# QUIC permits the use of a generic code in place of a specific error -# code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this -# includes replacing any alert with a generic alert, such as -# handshake_failure (0x0128 in QUIC). Endpoints MAY use a generic -# error code to avoid possibly exposing confidential information. - -[[spec]] -level = "MUST" -quote = ''' -As QUIC provides -alternative mechanisms for connection termination and the TLS -connection is only closed if an error is encountered, a QUIC endpoint -MUST treat any alert from TLS as if it were at the "fatal" level. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY use a generic -error code to avoid possibly exposing confidential information. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.1.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.9.1.toml deleted file mode 100644 index b56f90eb92..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.1.toml +++ /dev/null @@ -1,44 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9.1" - -# 4.9.1. Discarding Initial Keys -# -# Packets protected with Initial secrets (Section 5.2) are not -# authenticated, meaning that an attacker could spoof packets with the -# intent to disrupt a connection. To limit these attacks, Initial -# packet protection keys are discarded more aggressively than other -# keys. -# -# The successful use of Handshake packets indicates that no more -# Initial packets need to be exchanged, as these keys can only be -# produced after receiving all CRYPTO frames from Initial packets. -# Thus, a client MUST discard Initial keys when it first sends a -# Handshake packet and a server MUST discard Initial keys when it first -# successfully processes a Handshake packet. Endpoints MUST NOT send -# Initial packets after this point. -# -# This results in abandoning loss recovery state for the Initial -# encryption level and ignoring any outstanding Initial packets. - -[[spec]] -level = "MUST" -quote = ''' -Thus, a client MUST discard Initial keys when it first sends a -Handshake packet and a server MUST discard Initial keys when it first -successfully processes a Handshake packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -Thus, a client MUST discard Initial keys when it first sends a -Handshake packet and a server MUST discard Initial keys when it first -successfully processes a Handshake packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST NOT send -Initial packets after this point. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.9.3.toml deleted file mode 100644 index 8767f38fa9..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.3.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9.3" - -# 4.9.3. Discarding 0-RTT Keys -# -# 0-RTT and 1-RTT packets share the same packet number space, and -# clients do not send 0-RTT packets after sending a 1-RTT packet -# (Section 5.6). -# -# Therefore, a client SHOULD discard 0-RTT keys as soon as it installs -# 1-RTT keys as they have no use after that moment. -# -# Additionally, a server MAY discard 0-RTT keys as soon as it receives -# a 1-RTT packet. However, due to packet reordering, a 0-RTT packet -# could arrive after a 1-RTT packet. Servers MAY temporarily retain -# 0-RTT keys to allow decrypting reordered packets without requiring -# their contents to be retransmitted with 1-RTT keys. After receiving -# a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; -# the RECOMMENDED time period is three times the Probe Timeout (PTO, -# see [QUIC-RECOVERY]). A server MAY discard 0-RTT keys earlier if it -# determines that it has received all 0-RTT packets, which can be done -# by keeping track of missing packet numbers. - -[[spec]] -level = "SHOULD" -quote = ''' -Therefore, a client SHOULD discard 0-RTT keys as soon as it installs -1-RTT keys as they have no use after that moment. -''' - -[[spec]] -level = "MAY" -quote = ''' -Additionally, a server MAY discard 0-RTT keys as soon as it receives -a 1-RTT packet. -''' - -[[spec]] -level = "MAY" -quote = ''' -Servers MAY temporarily retain -0-RTT keys to allow decrypting reordered packets without requiring -their contents to be retransmitted with 1-RTT keys. -''' - -[[spec]] -level = "MUST" -quote = ''' -After receiving -a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; -the RECOMMENDED time period is three times the Probe Timeout (PTO, -see [QUIC-RECOVERY]). -''' - -[[spec]] -level = "MAY" -quote = ''' -A server MAY discard 0-RTT keys earlier if it -determines that it has received all 0-RTT packets, which can be done -by keeping track of missing packet numbers. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.9.toml deleted file mode 100644 index f8e0f6dac5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.9.toml +++ /dev/null @@ -1,53 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.9" - -# 4.9. Discarding Unused Keys -# -# After QUIC has completed a move to a new encryption level, packet -# protection keys for previous encryption levels can be discarded. -# This occurs several times during the handshake, as well as when keys -# are updated; see Section 6. -# -# Packet protection keys are not discarded immediately when new keys -# are available. If packets from a lower encryption level contain -# CRYPTO frames, frames that retransmit that data MUST be sent at the -# same encryption level. Similarly, an endpoint generates -# acknowledgments for packets at the same encryption level as the -# packet being acknowledged. Thus, it is possible that keys for a -# lower encryption level are needed for a short time after keys for a -# newer encryption level are available. -# -# An endpoint cannot discard keys for a given encryption level unless -# it has received all the cryptographic handshake messages from its -# peer at that encryption level and its peer has done the same. -# Different methods for determining this are provided for Initial keys -# (Section 4.9.1) and Handshake keys (Section 4.9.2). These methods do -# not prevent packets from being received or sent at that encryption -# level because a peer might not have received all the acknowledgments -# necessary. -# -# Though an endpoint might retain older keys, new data MUST be sent at -# the highest currently available encryption level. Only ACK frames -# and retransmissions of data in CRYPTO frames are sent at a previous -# encryption level. These packets MAY also include PADDING frames. - -[[spec]] -level = "MUST" -quote = ''' -If packets from a lower encryption level contain -CRYPTO frames, frames that retransmit that data MUST be sent at the -same encryption level. -''' - -[[spec]] -level = "MUST" -quote = ''' -Though an endpoint might retain older keys, new data MUST be sent at -the highest currently available encryption level. -''' - -[[spec]] -level = "MAY" -quote = ''' -These packets MAY also include PADDING frames. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/4.toml b/specs/www.rfc-editor.org/rfc/rfc9001/4.toml deleted file mode 100644 index 28cbfb209b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/4.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-4" - -# 4. Carrying TLS Messages -# -# QUIC carries TLS handshake data in CRYPTO frames, each of which -# consists of a contiguous block of handshake data identified by an -# offset and length. Those frames are packaged into QUIC packets and -# encrypted under the current encryption level. As with TLS over TCP, -# once TLS handshake data has been delivered to QUIC, it is QUIC's -# responsibility to deliver it reliably. Each chunk of data that is -# produced by TLS is associated with the set of keys that TLS is -# currently using. If QUIC needs to retransmit that data, it MUST use -# the same keys even if TLS has already updated to newer keys. -# -# Each encryption level corresponds to a packet number space. The -# packet number space that is used determines the semantics of frames. -# Some frames are prohibited in different packet number spaces; see -# Section 12.5 of [QUIC-TRANSPORT]. -# -# Because packets could be reordered on the wire, QUIC uses the packet -# type to indicate which keys were used to protect a given packet, as -# shown in Table 1. When packets of different types need to be sent, -# endpoints SHOULD use coalesced packets to send them in the same UDP -# datagram. -# -# +=====================+=================+==================+ -# | Packet Type | Encryption Keys | PN Space | -# +=====================+=================+==================+ -# | Initial | Initial secrets | Initial | -# +=====================+-----------------+------------------+ -# | 0-RTT Protected | 0-RTT | Application data | -# +=====================+-----------------+------------------+ -# | Handshake | Handshake | Handshake | -# +=====================+-----------------+------------------+ -# | Retry | Retry | N/A | -# +=====================+-----------------+------------------+ -# | Version Negotiation | N/A | N/A | -# +=====================+-----------------+------------------+ -# | Short Header | 1-RTT | Application data | -# +=====================+-----------------+------------------+ -# -# Table 1: Encryption Keys by Packet Type -# -# Section 17 of [QUIC-TRANSPORT] shows how packets at the various -# encryption levels fit into the handshake process. - -[[spec]] -level = "MUST" -quote = ''' -If QUIC needs to retransmit that data, it MUST use -the same keys even if TLS has already updated to newer keys. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When packets of different types need to be sent, -endpoints SHOULD use coalesced packets to send them in the same UDP -datagram. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.1.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.1.toml deleted file mode 100644 index 19fe0d3676..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.1.toml +++ /dev/null @@ -1,49 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.1" - -# 5.1. Packet Protection Keys -# -# QUIC derives packet protection keys in the same way that TLS derives -# record protection keys. -# -# Each encryption level has separate secret values for protection of -# packets sent in each direction. These traffic secrets are derived by -# TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all -# encryption levels except the Initial encryption level. The secrets -# for the Initial encryption level are computed based on the client's -# initial Destination Connection ID, as described in Section 5.2. -# -# The keys used for packet protection are computed from the TLS secrets -# using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label -# function described in Section 7.1 of [TLS13] is used with the hash -# function from the negotiated cipher suite. All uses of HKDF-Expand- -# Label in QUIC use a zero-length Context. -# -# Note that labels, which are described using strings, are encoded as -# bytes using ASCII [ASCII] without quotes or any trailing NUL byte. -# -# Other versions of TLS MUST provide a similar function in order to be -# used with QUIC. -# -# The current encryption level secret and the label "quic key" are -# input to the KDF to produce the AEAD key; the label "quic iv" is used -# to derive the Initialization Vector (IV); see Section 5.3. The -# header protection key uses the "quic hp" label; see Section 5.4. -# Using these labels provides key separation between QUIC and TLS; see -# Section 9.6. -# -# Both "quic key" and "quic hp" are used to produce keys, so the Length -# provided to HKDF-Expand-Label along with these labels is determined -# by the size of keys in the AEAD or header protection algorithm. The -# Length provided with "quic iv" is the minimum length of the AEAD -# nonce or 8 bytes if that is larger; see [AEAD]. -# -# The KDF used for initial secrets is always the HKDF-Expand-Label -# function from TLS 1.3; see Section 5.2. - -[[spec]] -level = "MUST" -quote = ''' -Other versions of TLS MUST provide a similar function in order to be -used with QUIC. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.2.toml deleted file mode 100644 index cc26cf7f66..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.2.toml +++ /dev/null @@ -1,80 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.2" - -# 5.2. Initial Secrets -# -# Initial packets apply the packet protection process, but use a secret -# derived from the Destination Connection ID field from the client's -# first Initial packet. -# -# This secret is determined by using HKDF-Extract (see Section 2.2 of -# [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and -# the input keying material (IKM) of the Destination Connection ID -# field. This produces an intermediate pseudorandom key (PRK) that is -# used to derive two separate secrets for sending and receiving. -# -# The secret used by clients to construct Initial packets uses the PRK -# and the label "client in" as input to the HKDF-Expand-Label function -# from TLS [TLS13] to produce a 32-byte secret. Packets constructed by -# the server use the same process with the label "server in". The hash -# function for HKDF when deriving initial secrets and keys is SHA-256 -# [SHA]. -# -# This process in pseudocode is: -# -# initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a -# initial_secret = HKDF-Extract(initial_salt, -# client_dst_connection_id) -# -# client_initial_secret = HKDF-Expand-Label(initial_secret, -# "client in", "", -# Hash.length) -# server_initial_secret = HKDF-Expand-Label(initial_secret, -# "server in", "", -# Hash.length) -# -# The connection ID used with HKDF-Expand-Label is the Destination -# Connection ID in the Initial packet sent by the client. This will be -# a randomly selected value unless the client creates the Initial -# packet after receiving a Retry packet, where the Destination -# Connection ID is selected by the server. -# -# Future versions of QUIC SHOULD generate a new salt value, thus -# ensuring that the keys are different for each version of QUIC. This -# prevents a middlebox that recognizes only one version of QUIC from -# seeing or modifying the contents of packets from future versions. -# -# The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for -# Initial packets even where the TLS versions offered do not include -# TLS 1.3. -# -# The secrets used for constructing subsequent Initial packets change -# when a server sends a Retry packet to use the connection ID value -# selected by the server. The secrets do not change when a client -# changes the Destination Connection ID it uses in response to an -# Initial packet from the server. -# -# | Note: The Destination Connection ID field could be any length -# | up to 20 bytes, including zero length if the server sends a -# | Retry packet with a zero-length Source Connection ID field. -# | After a Retry, the Initial keys provide the client no assurance -# | that the server received its packet, so the client has to rely -# | on the exchange that included the Retry packet to validate the -# | server address; see Section 8.1 of [QUIC-TRANSPORT]. -# -# Appendix A contains sample Initial packets. - -[[spec]] -level = "SHOULD" -quote = ''' -Future versions of QUIC SHOULD generate a new salt value, thus -ensuring that the keys are different for each version of QUIC. -''' - -[[spec]] -level = "MUST" -quote = ''' -The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for -Initial packets even where the TLS versions offered do not include -TLS 1.3. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.3.toml deleted file mode 100644 index d2250f6de5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.3.toml +++ /dev/null @@ -1,74 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.3" - -# 5.3. AEAD Usage -# -# The Authenticated Encryption with Associated Data (AEAD) function -# (see [AEAD]) used for QUIC packet protection is the AEAD that is -# negotiated for use with the TLS connection. For example, if TLS is -# using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM -# function is used. -# -# QUIC can use any of the cipher suites defined in [TLS13] with the -# exception of TLS_AES_128_CCM_8_SHA256. A cipher suite MUST NOT be -# negotiated unless a header protection scheme is defined for the -# cipher suite. This document defines a header protection scheme for -# all cipher suites defined in [TLS13] aside from -# TLS_AES_128_CCM_8_SHA256. These cipher suites have a 16-byte -# authentication tag and produce an output 16 bytes larger than their -# input. -# -# An endpoint MUST NOT reject a ClientHello that offers a cipher suite -# that it does not support, or it would be impossible to deploy a new -# cipher suite. This also applies to TLS_AES_128_CCM_8_SHA256. -# -# When constructing packets, the AEAD function is applied prior to -# applying header protection; see Section 5.4. The unprotected packet -# header is part of the associated data (A). When processing packets, -# an endpoint first removes the header protection. -# -# The key and IV for the packet are computed as described in -# Section 5.1. The nonce, N, is formed by combining the packet -# protection IV with the packet number. The 62 bits of the -# reconstructed QUIC packet number in network byte order are left- -# padded with zeros to the size of the IV. The exclusive OR of the -# padded packet number and the IV forms the AEAD nonce. -# -# The associated data, A, for the AEAD is the contents of the QUIC -# header, starting from the first byte of either the short or long -# header, up to and including the unprotected packet number. -# -# The input plaintext, P, for the AEAD is the payload of the QUIC -# packet, as described in [QUIC-TRANSPORT]. -# -# The output ciphertext, C, of the AEAD is transmitted in place of P. -# -# Some AEAD functions have limits for how many packets can be encrypted -# under the same key and IV; see Section 6.6. This might be lower than -# the packet number limit. An endpoint MUST initiate a key update -# (Section 6) prior to exceeding any limit set for the AEAD that is in -# use. - -[[spec]] -level = "MUST" -quote = ''' -A cipher suite MUST NOT be -negotiated unless a header protection scheme is defined for the -cipher suite. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT reject a ClientHello that offers a cipher suite -that it does not support, or it would be impossible to deploy a new -cipher suite. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST initiate a key update -(Section 6) prior to exceeding any limit set for the AEAD that is in -use. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.4.1.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.4.1.toml deleted file mode 100644 index bf866673c5..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.4.1.toml +++ /dev/null @@ -1,95 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.4.1" - -# 5.4.1. Header Protection Application -# -# Header protection is applied after packet protection is applied (see -# Section 5.3). The ciphertext of the packet is sampled and used as -# input to an encryption algorithm. The algorithm used depends on the -# negotiated AEAD. -# -# The output of this algorithm is a 5-byte mask that is applied to the -# protected header fields using exclusive OR. The least significant -# bits of the first byte of the packet are masked by the least -# significant bits of the first mask byte, and the packet number is -# masked with the remaining bytes. Any unused bytes of mask that might -# result from a shorter packet number encoding are unused. -# -# Figure 6 shows a sample algorithm for applying header protection. -# Removing header protection only differs in the order in which the -# packet number length (pn_length) is determined (here "^" is used to -# represent exclusive OR). -# -# mask = header_protection(hp_key, sample) -# -# pn_length = (packet[0] & 0x03) + 1 -# if (packet[0] & 0x80) == 0x80: -# # Long header: 4 bits masked -# packet[0] ^= mask[0] & 0x0f -# else: -# # Short header: 5 bits masked -# packet[0] ^= mask[0] & 0x1f -# -# # pn_offset is the start of the Packet Number field. -# packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] -# -# Figure 6: Header Protection Pseudocode -# -# Specific header protection functions are defined based on the -# selected cipher suite; see Section 5.4.3 and Section 5.4.4. -# -# Figure 7 shows an example long header packet (Initial) and a short -# header packet (1-RTT). Figure 7 shows the fields in each header that -# are covered by header protection and the portion of the protected -# packet payload that is sampled. -# -# Initial Packet { -# Header Form (1) = 1, -# Fixed Bit (1) = 1, -# Long Packet Type (2) = 0, -# Reserved Bits (2), # Protected -# Packet Number Length (2), # Protected -# Version (32), -# DCID Len (8), -# Destination Connection ID (0..160), -# SCID Len (8), -# Source Connection ID (0..160), -# Token Length (i), -# Token (..), -# Length (i), -# Packet Number (8..32), # Protected -# Protected Payload (0..24), # Skipped Part -# Protected Payload (128), # Sampled Part -# Protected Payload (..) # Remainder -# } -# -# 1-RTT Packet { -# Header Form (1) = 0, -# Fixed Bit (1) = 1, -# Spin Bit (1), -# Reserved Bits (2), # Protected -# Key Phase (1), # Protected -# Packet Number Length (2), # Protected -# Destination Connection ID (0..160), -# Packet Number (8..32), # Protected -# Protected Payload (0..24), # Skipped Part -# Protected Payload (128), # Sampled Part -# Protected Payload (..), # Remainder -# } -# -# Figure 7: Header Protection and Ciphertext Sample -# -# Before a TLS cipher suite can be used with QUIC, a header protection -# algorithm MUST be specified for the AEAD used with that cipher suite. -# This document defines algorithms for AEAD_AES_128_GCM, -# AEAD_AES_128_CCM, AEAD_AES_256_GCM (all these AES AEADs are defined -# in [AEAD]), and AEAD_CHACHA20_POLY1305 (defined in [CHACHA]). Prior -# to TLS selecting a cipher suite, AES header protection is used -# (Section 5.4.3), matching the AEAD_AES_128_GCM packet protection. - -[[spec]] -level = "MUST" -quote = ''' -Before a TLS cipher suite can be used with QUIC, a header protection -algorithm MUST be specified for the AEAD used with that cipher suite. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.4.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.4.2.toml deleted file mode 100644 index aea20482f6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.4.2.toml +++ /dev/null @@ -1,65 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.4.2" - -# 5.4.2. Header Protection Sample -# -# The header protection algorithm uses both the header protection key -# and a sample of the ciphertext from the packet Payload field. -# -# The same number of bytes are always sampled, but an allowance needs -# to be made for the removal of protection by a receiving endpoint, -# which will not know the length of the Packet Number field. The -# sample of ciphertext is taken starting from an offset of 4 bytes -# after the start of the Packet Number field. That is, in sampling -# packet ciphertext for header protection, the Packet Number field is -# assumed to be 4 bytes long (its maximum possible encoded length). -# -# An endpoint MUST discard packets that are not long enough to contain -# a complete sample. -# -# To ensure that sufficient data is available for sampling, packets are -# padded so that the combined lengths of the encoded packet number and -# protected payload is at least 4 bytes longer than the sample required -# for header protection. The cipher suites defined in [TLS13] -- other -# than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme -# is not defined in this document -- have 16-byte expansions and -# 16-byte header protection samples. This results in needing at least -# 3 bytes of frames in the unprotected payload if the packet number is -# encoded on a single byte, or 2 bytes of frames for a 2-byte packet -# number encoding. -# -# The sampled ciphertext can be determined by the following pseudocode: -# -# # pn_offset is the start of the Packet Number field. -# sample_offset = pn_offset + 4 -# -# sample = packet[sample_offset..sample_offset+sample_length] -# -# Where the packet number offset of a short header packet can be -# calculated as: -# -# pn_offset = 1 + len(connection_id) -# -# And the packet number offset of a long header packet can be -# calculated as: -# -# pn_offset = 7 + len(destination_connection_id) + -# len(source_connection_id) + -# len(payload_length) -# if packet_type == Initial: -# pn_offset += len(token_length) + -# len(token) -# -# For example, for a packet with a short header, an 8-byte connection -# ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to -# 28 inclusive (using zero-based indexing). -# -# Multiple QUIC packets might be included in the same UDP datagram. -# Each packet is handled separately. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST discard packets that are not long enough to contain -a complete sample. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.5.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.5.toml deleted file mode 100644 index 69aec63512..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.5.toml +++ /dev/null @@ -1,35 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.5" - -# 5.5. Receiving Protected Packets -# -# Once an endpoint successfully receives a packet with a given packet -# number, it MUST discard all packets in the same packet number space -# with higher packet numbers if they cannot be successfully unprotected -# with either the same key, or -- if there is a key update -- a -# subsequent packet protection key; see Section 6. Similarly, a packet -# that appears to trigger a key update but cannot be unprotected -# successfully MUST be discarded. -# -# Failure to unprotect a packet does not necessarily indicate the -# existence of a protocol error in a peer or an attack. The truncated -# packet number encoding used in QUIC can cause packet numbers to be -# decoded incorrectly if they are delayed significantly. - -[[spec]] -level = "MUST" -quote = ''' -Once an endpoint successfully receives a packet with a given packet -number, it MUST discard all packets in the same packet number space -with higher packet numbers if they cannot be successfully unprotected -with either the same key, or -- if there is a key update -- a -subsequent packet protection key; see Section 6. -''' - -[[spec]] -level = "MUST" -quote = ''' -Similarly, a packet -that appears to trigger a key update but cannot be unprotected -successfully MUST be discarded. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.6.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.6.toml deleted file mode 100644 index f3859142eb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.6.toml +++ /dev/null @@ -1,117 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.6" - -# 5.6. Use of 0-RTT Keys -# -# If 0-RTT keys are available (see Section 4.6.1), the lack of replay -# protection means that restrictions on their use are necessary to -# avoid replay attacks on the protocol. -# -# Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM, -# STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for -# use with 0-RTT as they carry application data. Application data that -# is received in 0-RTT could cause an application at the server to -# process the data multiple times rather than just once. Additional -# actions taken by a server as a result of processing replayed -# application data could have unwanted consequences. A client -# therefore MUST NOT use 0-RTT for application data unless specifically -# requested by the application that is in use. -# -# An application protocol that uses QUIC MUST include a profile that -# defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to -# carry QUIC frames that do not carry application data. For example, a -# profile for HTTP is described in [HTTP-REPLAY] and used for HTTP/3; -# see Section 10.9 of [QUIC-HTTP]. -# -# Though replaying packets might result in additional connection -# attempts, the effect of processing replayed frames that do not carry -# application data is limited to changing the state of the affected -# connection. A TLS handshake cannot be successfully completed using -# replayed packets. -# -# A client MAY wish to apply additional restrictions on what data it -# sends prior to the completion of the TLS handshake. -# -# A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys, -# except that it cannot send certain frames with 0-RTT keys; see -# Section 12.5 of [QUIC-TRANSPORT]. -# -# A client that receives an indication that its 0-RTT data has been -# accepted by a server can send 0-RTT data until it receives all of the -# server's handshake messages. A client SHOULD stop sending 0-RTT data -# if it receives an indication that 0-RTT data has been rejected. -# -# A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT -# keys to protect acknowledgments of 0-RTT packets. A client MUST NOT -# attempt to decrypt 0-RTT packets it receives and instead MUST discard -# them. -# -# Once a client has installed 1-RTT keys, it MUST NOT send any more -# 0-RTT packets. -# -# | Note: 0-RTT data can be acknowledged by the server as it -# | receives it, but any packets containing acknowledgments of -# | 0-RTT data cannot have packet protection removed by the client -# | until the TLS handshake is complete. The 1-RTT keys necessary -# | to remove packet protection cannot be derived until the client -# | receives all server handshake messages. - -[[spec]] -level = "MUST" -quote = ''' -A client -therefore MUST NOT use 0-RTT for application data unless specifically -requested by the application that is in use. -''' - -[[spec]] -level = "MUST" -quote = ''' -An application protocol that uses QUIC MUST include a profile that -defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to -carry QUIC frames that do not carry application data. -''' - -[[spec]] -level = "MAY" -quote = ''' -A client MAY wish to apply additional restrictions on what data it -sends prior to the completion of the TLS handshake. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A client SHOULD stop sending 0-RTT data -if it receives an indication that 0-RTT data has been rejected. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT -keys to protect acknowledgments of 0-RTT packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT -attempt to decrypt 0-RTT packets it receives and instead MUST discard -them. -''' - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT -attempt to decrypt 0-RTT packets it receives and instead MUST discard -them. -''' - -[[spec]] -level = "MUST" -quote = ''' -Once a client has installed 1-RTT keys, it MUST NOT send any more -0-RTT packets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/5.7.toml b/specs/www.rfc-editor.org/rfc/rfc9001/5.7.toml deleted file mode 100644 index a05faa7f9e..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/5.7.toml +++ /dev/null @@ -1,95 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-5.7" - -# 5.7. Receiving Out-of-Order Protected Packets -# -# Due to reordering and loss, protected packets might be received by an -# endpoint before the final TLS handshake messages are received. A -# client will be unable to decrypt 1-RTT packets from the server, -# whereas a server will be able to decrypt 1-RTT packets from the -# client. Endpoints in either role MUST NOT decrypt 1-RTT packets from -# their peer prior to completing the handshake. -# -# Even though 1-RTT keys are available to a server after receiving the -# first handshake messages from a client, it is missing assurances on -# the client state: -# -# * The client is not authenticated, unless the server has chosen to -# use a pre-shared key and validated the client's pre-shared key -# binder; see Section 4.2.11 of [TLS13]. -# -# * The client has not demonstrated liveness, unless the server has -# validated the client's address with a Retry packet or other means; -# see Section 8.1 of [QUIC-TRANSPORT]. -# -# * Any received 0-RTT data that the server responds to might be due -# to a replay attack. -# -# Therefore, the server's use of 1-RTT keys before the handshake is -# complete is limited to sending data. A server MUST NOT process -# incoming 1-RTT protected packets before the TLS handshake is -# complete. Because sending acknowledgments indicates that all frames -# in a packet have been processed, a server cannot send acknowledgments -# for 1-RTT packets until the TLS handshake is complete. Received -# packets protected with 1-RTT keys MAY be stored and later decrypted -# and used once the handshake is complete. -# -# | Note: TLS implementations might provide all 1-RTT secrets prior -# | to handshake completion. Even where QUIC implementations have -# | 1-RTT read keys, those keys are not to be used prior to -# | completing the handshake. -# -# The requirement for the server to wait for the client Finished -# message creates a dependency on that message being delivered. A -# client can avoid the potential for head-of-line blocking that this -# implies by sending its 1-RTT packets coalesced with a Handshake -# packet containing a copy of the CRYPTO frame that carries the -# Finished message, until one of the Handshake packets is acknowledged. -# This enables immediate server processing for those packets. -# -# A server could receive packets protected with 0-RTT keys prior to -# receiving a TLS ClientHello. The server MAY retain these packets for -# later decryption in anticipation of receiving a ClientHello. -# -# A client generally receives 1-RTT keys at the same time as the -# handshake completes. Even if it has 1-RTT secrets, a client MUST NOT -# process incoming 1-RTT protected packets before the TLS handshake is -# complete. - -[[spec]] -level = "MUST" -quote = ''' -Endpoints in either role MUST NOT decrypt 1-RTT packets from -their peer prior to completing the handshake. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST NOT process -incoming 1-RTT protected packets before the TLS handshake is -complete. -''' - -[[spec]] -level = "MAY" -quote = ''' -Received -packets protected with 1-RTT keys MAY be stored and later decrypted -and used once the handshake is complete. -''' - -[[spec]] -level = "MAY" -quote = ''' -The server MAY retain these packets for -later decryption in anticipation of receiving a ClientHello. -''' - -[[spec]] -level = "MUST" -quote = ''' -Even if it has 1-RTT secrets, a client MUST NOT -process incoming 1-RTT protected packets before the TLS handshake is -complete. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.1.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.1.toml deleted file mode 100644 index f203bbcd15..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.1.toml +++ /dev/null @@ -1,78 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.1" - -# 6.1. Initiating a Key Update -# -# Endpoints maintain separate read and write secrets for packet -# protection. An endpoint initiates a key update by updating its -# packet protection write secret and using that to protect new packets. -# The endpoint creates a new write secret from the existing write -# secret as performed in Section 7.2 of [TLS13]. This uses the KDF -# function provided by TLS with a label of "quic ku". The -# corresponding key and IV are created from that secret as defined in -# Section 5.1. The header protection key is not updated. -# -# For example, to update write keys with TLS 1.3, HKDF-Expand-Label is -# used as: -# -# secret_ = HKDF-Expand-Label(secret_, "quic ku", -# "", Hash.length) -# -# The endpoint toggles the value of the Key Phase bit and uses the -# updated key and IV to protect all subsequent packets. -# -# An endpoint MUST NOT initiate a key update prior to having confirmed -# the handshake (Section 4.1.2). An endpoint MUST NOT initiate a -# subsequent key update unless it has received an acknowledgment for a -# packet that was sent protected with keys from the current key phase. -# This ensures that keys are available to both peers before another key -# update can be initiated. This can be implemented by tracking the -# lowest packet number sent with each key phase and the highest -# acknowledged packet number in the 1-RTT space: once the latter is -# higher than or equal to the former, another key update can be -# initiated. -# -# | Note: Keys of packets other than the 1-RTT packets are never -# | updated; their keys are derived solely from the TLS handshake -# | state. -# -# The endpoint that initiates a key update also updates the keys that -# it uses for receiving packets. These keys will be needed to process -# packets the peer sends after updating. -# -# An endpoint MUST retain old keys until it has successfully -# unprotected a packet sent using the new keys. An endpoint SHOULD -# retain old keys for some time after unprotecting a packet sent using -# the new keys. Discarding old keys too early can cause delayed -# packets to be discarded. Discarding packets will be interpreted as -# packet loss by the peer and could adversely affect performance. - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT initiate a key update prior to having confirmed -the handshake (Section 4.1.2). -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT initiate a -subsequent key update unless it has received an acknowledgment for a -packet that was sent protected with keys from the current key phase. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST retain old keys until it has successfully -unprotected a packet sent using the new keys. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD -retain old keys for some time after unprotecting a packet sent using -the new keys. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.2.toml deleted file mode 100644 index bce2a4cddd..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.2.toml +++ /dev/null @@ -1,72 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.2" - -# 6.2. Responding to a Key Update -# -# A peer is permitted to initiate a key update after receiving an -# acknowledgment of a packet in the current key phase. An endpoint -# detects a key update when processing a packet with a key phase that -# differs from the value used to protect the last packet it sent. To -# process this packet, the endpoint uses the next packet protection key -# and IV. See Section 6.3 for considerations about generating these -# keys. -# -# If a packet is successfully processed using the next key and IV, then -# the peer has initiated a key update. The endpoint MUST update its -# send keys to the corresponding key phase in response, as described in -# Section 6.1. Sending keys MUST be updated before sending an -# acknowledgment for the packet that was received with updated keys. -# By acknowledging the packet that triggered the key update in a packet -# protected with the updated keys, the endpoint signals that the key -# update is complete. -# -# An endpoint can defer sending the packet or acknowledgment according -# to its normal packet sending behavior; it is not necessary to -# immediately generate a packet in response to a key update. The next -# packet sent by the endpoint will use the updated keys. The next -# packet that contains an acknowledgment will cause the key update to -# be completed. If an endpoint detects a second update before it has -# sent any packets with updated keys containing an acknowledgment for -# the packet that initiated the key update, it indicates that its peer -# has updated keys twice without awaiting confirmation. An endpoint -# MAY treat such consecutive key updates as a connection error of type -# KEY_UPDATE_ERROR. -# -# An endpoint that receives an acknowledgment that is carried in a -# packet protected with old keys where any acknowledged packet was -# protected with newer keys MAY treat that as a connection error of -# type KEY_UPDATE_ERROR. This indicates that a peer has received and -# acknowledged a packet that initiates a key update, but has not -# updated keys in response. - -[[spec]] -level = "MUST" -quote = ''' -The endpoint MUST update its -send keys to the corresponding key phase in response, as described in -Section 6.1. -''' - -[[spec]] -level = "MUST" -quote = ''' -Sending keys MUST be updated before sending an -acknowledgment for the packet that was received with updated keys. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint -MAY treat such consecutive key updates as a connection error of type -KEY_UPDATE_ERROR. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint that receives an acknowledgment that is carried in a -packet protected with old keys where any acknowledged packet was -protected with newer keys MAY treat that as a connection error of -type KEY_UPDATE_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.3.toml deleted file mode 100644 index 520e0d0252..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.3.toml +++ /dev/null @@ -1,76 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.3" - -# 6.3. Timing of Receive Key Generation -# -# Endpoints responding to an apparent key update MUST NOT generate a -# timing side-channel signal that might indicate that the Key Phase bit -# was invalid (see Section 9.5). Endpoints can use randomized packet -# protection keys in place of discarded keys when key updates are not -# yet permitted. Using randomized keys ensures that attempting to -# remove packet protection does not result in timing variations, and -# results in packets with an invalid Key Phase bit being rejected. -# -# The process of creating new packet protection keys for receiving -# packets could reveal that a key update has occurred. An endpoint MAY -# generate new keys as part of packet processing, but this creates a -# timing signal that could be used by an attacker to learn when key -# updates happen and thus leak the value of the Key Phase bit. -# -# Endpoints are generally expected to have current and next receive -# packet protection keys available. For a short period after a key -# update completes, up to the PTO, endpoints MAY defer generation of -# the next set of receive packet protection keys. This allows -# endpoints to retain only two sets of receive keys; see Section 6.5. -# -# Once generated, the next set of packet protection keys SHOULD be -# retained, even if the packet that was received was subsequently -# discarded. Packets containing apparent key updates are easy to -# forge, and while the process of key update does not require -# significant effort, triggering this process could be used by an -# attacker for DoS. -# -# For this reason, endpoints MUST be able to retain two sets of packet -# protection keys for receiving packets: the current and the next. -# Retaining the previous keys in addition to these might improve -# performance, but this is not essential. - -[[spec]] -level = "MUST" -quote = ''' -Endpoints responding to an apparent key update MUST NOT generate a -timing side-channel signal that might indicate that the Key Phase bit -was invalid (see Section 9.5). -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY -generate new keys as part of packet processing, but this creates a -timing signal that could be used by an attacker to learn when key -updates happen and thus leak the value of the Key Phase bit. -''' - -[[spec]] -level = "MAY" -quote = ''' -For a short period after a key -update completes, up to the PTO, endpoints MAY defer generation of -the next set of receive packet protection keys. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Once generated, the next set of packet protection keys SHOULD be -retained, even if the packet that was received was subsequently -discarded. -''' - -[[spec]] -level = "MUST" -quote = ''' -For this reason, endpoints MUST be able to retain two sets of packet -protection keys for receiving packets: the current and the next. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.4.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.4.toml deleted file mode 100644 index 4ceaf0001f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.4.toml +++ /dev/null @@ -1,30 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.4" - -# 6.4. Sending with Updated Keys -# -# An endpoint never sends packets that are protected with old keys. -# Only the current keys are used. Keys used for protecting packets can -# be discarded immediately after switching to newer keys. -# -# Packets with higher packet numbers MUST be protected with either the -# same or newer packet protection keys than packets with lower packet -# numbers. An endpoint that successfully removes protection with old -# keys when newer keys were used for packets with lower packet numbers -# MUST treat this as a connection error of type KEY_UPDATE_ERROR. - -[[spec]] -level = "MUST" -quote = ''' -Packets with higher packet numbers MUST be protected with either the -same or newer packet protection keys than packets with lower packet -numbers. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint that successfully removes protection with old -keys when newer keys were used for packets with lower packet numbers -MUST treat this as a connection error of type KEY_UPDATE_ERROR. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.5.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.5.toml deleted file mode 100644 index 4807a4fb77..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.5.toml +++ /dev/null @@ -1,91 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.5" - -# 6.5. Receiving with Different Keys -# -# For receiving packets during a key update, packets protected with -# older keys might arrive if they were delayed by the network. -# Retaining old packet protection keys allows these packets to be -# successfully processed. -# -# As packets protected with keys from the next key phase use the same -# Key Phase value as those protected with keys from the previous key -# phase, it is necessary to distinguish between the two if packets -# protected with old keys are to be processed. This can be done using -# packet numbers. A recovered packet number that is lower than any -# packet number from the current key phase uses the previous packet -# protection keys; a recovered packet number that is higher than any -# packet number from the current key phase requires the use of the next -# packet protection keys. -# -# Some care is necessary to ensure that any process for selecting -# between previous, current, and next packet protection keys does not -# expose a timing side channel that might reveal which keys were used -# to remove packet protection. See Section 9.5 for more information. -# -# Alternatively, endpoints can retain only two sets of packet -# protection keys, swapping previous for next after enough time has -# passed to allow for reordering in the network. In this case, the Key -# Phase bit alone can be used to select keys. -# -# An endpoint MAY allow a period of approximately the Probe Timeout -# (PTO; see [QUIC-RECOVERY]) after promoting the next set of receive -# keys to be current before it creates the subsequent set of packet -# protection keys. These updated keys MAY replace the previous keys at -# that time. With the caveat that PTO is a subjective measure -- that -# is, a peer could have a different view of the RTT -- this time is -# expected to be long enough that any reordered packets would be -# declared lost by a peer even if they were acknowledged and short -# enough to allow a peer to initiate further key updates. -# -# Endpoints need to allow for the possibility that a peer might not be -# able to decrypt packets that initiate a key update during the period -# when the peer retains old keys. Endpoints SHOULD wait three times -# the PTO before initiating a key update after receiving an -# acknowledgment that confirms that the previous key update was -# received. Failing to allow sufficient time could lead to packets -# being discarded. -# -# An endpoint SHOULD retain old read keys for no more than three times -# the PTO after having received a packet protected using the new keys. -# After this period, old read keys and their corresponding secrets -# SHOULD be discarded. - -[[spec]] -level = "MAY" -quote = ''' -An endpoint MAY allow a period of approximately the Probe Timeout -(PTO; see [QUIC-RECOVERY]) after promoting the next set of receive -keys to be current before it creates the subsequent set of packet -protection keys. -''' - -[[spec]] -level = "MAY" -quote = ''' -These updated keys MAY replace the previous keys at -that time. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD wait three times -the PTO before initiating a key update after receiving an -acknowledgment that confirms that the previous key update was -received. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD retain old read keys for no more than three times -the PTO after having received a packet protected using the new keys. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -After this period, old read keys and their corresponding secrets -SHOULD be discarded. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.6.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.6.toml deleted file mode 100644 index 3ada677696..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.6.toml +++ /dev/null @@ -1,164 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.6" - -# 6.6. Limits on AEAD Usage -# -# This document sets usage limits for AEAD algorithms to ensure that -# overuse does not give an adversary a disproportionate advantage in -# attacking the confidentiality and integrity of communications when -# using QUIC. -# -# The usage limits defined in TLS 1.3 exist for protection against -# attacks on confidentiality and apply to successful applications of -# AEAD protection. The integrity protections in authenticated -# encryption also depend on limiting the number of attempts to forge -# packets. TLS achieves this by closing connections after any record -# fails an authentication check. In comparison, QUIC ignores any -# packet that cannot be authenticated, allowing multiple forgery -# attempts. -# -# QUIC accounts for AEAD confidentiality and integrity limits -# separately. The confidentiality limit applies to the number of -# packets encrypted with a given key. The integrity limit applies to -# the number of packets decrypted within a given connection. Details -# on enforcing these limits for each AEAD algorithm follow below. -# -# Endpoints MUST count the number of encrypted packets for each set of -# keys. If the total number of encrypted packets with the same key -# exceeds the confidentiality limit for the selected AEAD, the endpoint -# MUST stop using those keys. Endpoints MUST initiate a key update -# before sending more protected packets than the confidentiality limit -# for the selected AEAD permits. If a key update is not possible or -# integrity limits are reached, the endpoint MUST stop using the -# connection and only send stateless resets in response to receiving -# packets. It is RECOMMENDED that endpoints immediately close the -# connection with a connection error of type AEAD_LIMIT_REACHED before -# reaching a state where key updates are not possible. -# -# For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit -# is 2^23 encrypted packets; see Appendix B.1. For -# AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the -# number of possible packets (2^62) and so can be disregarded. For -# AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted -# packets; see Appendix B.2. Applying a limit reduces the probability -# that an attacker can distinguish the AEAD in use from a random -# permutation; see [AEBounds], [ROBUST], and [GCM-MU]. -# -# In addition to counting packets sent, endpoints MUST count the number -# of received packets that fail authentication during the lifetime of a -# connection. If the total number of received packets that fail -# authentication within the connection, across all keys, exceeds the -# integrity limit for the selected AEAD, the endpoint MUST immediately -# close the connection with a connection error of type -# AEAD_LIMIT_REACHED and not process any more packets. -# -# For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is -# 2^52 invalid packets; see Appendix B.1. For AEAD_CHACHA20_POLY1305, -# the integrity limit is 2^36 invalid packets; see [AEBounds]. For -# AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see -# Appendix B.2. Applying this limit reduces the probability that an -# attacker can successfully forge a packet; see [AEBounds], [ROBUST], -# and [GCM-MU]. -# -# Endpoints that limit the size of packets MAY use higher -# confidentiality and integrity limits; see Appendix B for details. -# -# Future analyses and specifications MAY relax confidentiality or -# integrity limits for an AEAD. -# -# Any TLS cipher suite that is specified for use with QUIC MUST define -# limits on the use of the associated AEAD function that preserves -# margins for confidentiality and integrity. That is, limits MUST be -# specified for the number of packets that can be authenticated and for -# the number of packets that can fail authentication. Providing a -# reference to any analysis upon which values are based -- and any -# assumptions used in that analysis -- allows limits to be adapted to -# varying usage conditions. - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST count the number of encrypted packets for each set of -keys. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the total number of encrypted packets with the same key -exceeds the confidentiality limit for the selected AEAD, the endpoint -MUST stop using those keys. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST initiate a key update -before sending more protected packets than the confidentiality limit -for the selected AEAD permits. -''' - -[[spec]] -level = "MUST" -quote = ''' -If a key update is not possible or -integrity limits are reached, the endpoint MUST stop using the -connection and only send stateless resets in response to receiving -packets. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -It is RECOMMENDED that endpoints immediately close the -connection with a connection error of type AEAD_LIMIT_REACHED before -reaching a state where key updates are not possible. -''' - -[[spec]] -level = "MUST" -quote = ''' -In addition to counting packets sent, endpoints MUST count the number -of received packets that fail authentication during the lifetime of a -connection. -''' - -[[spec]] -level = "MUST" -quote = ''' -If the total number of received packets that fail -authentication within the connection, across all keys, exceeds the -integrity limit for the selected AEAD, the endpoint MUST immediately -close the connection with a connection error of type -AEAD_LIMIT_REACHED and not process any more packets. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints that limit the size of packets MAY use higher -confidentiality and integrity limits; see Appendix B for details. -''' - -[[spec]] -level = "MAY" -quote = ''' -Future analyses and specifications MAY relax confidentiality or -integrity limits for an AEAD. -''' - -[[spec]] -level = "MUST" -quote = ''' -Any TLS cipher suite that is specified for use with QUIC MUST define -limits on the use of the associated AEAD function that preserves -margins for confidentiality and integrity. -''' - -[[spec]] -level = "MUST" -quote = ''' -That is, limits MUST be -specified for the number of packets that can be authenticated and for -the number of packets that can fail authentication. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/6.toml b/specs/www.rfc-editor.org/rfc/rfc9001/6.toml deleted file mode 100644 index d78d9baebd..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/6.toml +++ /dev/null @@ -1,77 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-6" - -# 6. Key Update -# -# Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY -# initiate a key update. -# -# The Key Phase bit indicates which packet protection keys are used to -# protect the packet. The Key Phase bit is initially set to 0 for the -# first set of 1-RTT packets and toggled to signal each subsequent key -# update. -# -# The Key Phase bit allows a recipient to detect a change in keying -# material without needing to receive the first packet that triggered -# the change. An endpoint that notices a changed Key Phase bit updates -# keys and decrypts the packet that contains the changed value. -# -# Initiating a key update results in both endpoints updating keys. -# This differs from TLS where endpoints can update keys independently. -# -# This mechanism replaces the key update mechanism of TLS, which relies -# on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints -# MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the -# receipt of a TLS KeyUpdate message as a connection error of type -# 0x010a, equivalent to a fatal TLS alert of unexpected_message; see -# Section 4.8. -# -# Figure 9 shows a key update process, where the initial set of keys -# used (identified with @M) are replaced by updated keys (identified -# with @N). The value of the Key Phase bit is indicated in brackets -# []. -# -# Initiating Peer Responding Peer -# -# @M [0] QUIC Packets -# -# ... Update to @N -# @N [1] QUIC Packets -# --------> -# Update to @N ... -# QUIC Packets [1] @N -# <-------- -# QUIC Packets [1] @N -# containing ACK -# <-------- -# ... Key Update Permitted -# -# @N [1] QUIC Packets -# containing ACK for @N packets -# --------> -# Key Update Permitted ... -# -# Figure 9: Key Update - -[[spec]] -level = "MAY" -quote = ''' -Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY -initiate a key update. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints -MUST NOT send a TLS KeyUpdate message. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST treat the -receipt of a TLS KeyUpdate message as a connection error of type -0x010a, equivalent to a fatal TLS alert of unexpected_message; see -Section 4.8. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/7.toml b/specs/www.rfc-editor.org/rfc/rfc9001/7.toml deleted file mode 100644 index 446ad922ff..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/7.toml +++ /dev/null @@ -1,33 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-7" - -# 7. Security of Initial Messages -# -# Initial packets are not protected with a secret key, so they are -# subject to potential tampering by an attacker. QUIC provides -# protection against attackers that cannot read packets but does not -# attempt to provide additional protection against attacks where the -# attacker can observe and inject packets. Some forms of tampering -- -# such as modifying the TLS messages themselves -- are detectable, but -# some -- such as modifying ACKs -- are not. -# -# For example, an attacker could inject a packet containing an ACK -# frame to make it appear that a packet had not been received or to -# create a false impression of the state of the connection (e.g., by -# modifying the ACK Delay). Note that such a packet could cause a -# legitimate packet to be dropped as a duplicate. Implementations -# SHOULD use caution in relying on any data that is contained in -# Initial packets that is not otherwise authenticated. -# -# It is also possible for the attacker to tamper with data that is -# carried in Handshake packets, but because that sort of tampering -# requires modifying TLS handshake messages, any such tampering will -# cause the TLS handshake to fail. - -[[spec]] -level = "SHOULD" -quote = ''' -Implementations -SHOULD use caution in relying on any data that is contained in -Initial packets that is not otherwise authenticated. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/8.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/8.2.toml deleted file mode 100644 index cfe6e9bac6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/8.2.toml +++ /dev/null @@ -1,81 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.2" - -# 8.2. QUIC Transport Parameters Extension -# -# QUIC transport parameters are carried in a TLS extension. Different -# versions of QUIC might define a different method for negotiating -# transport configuration. -# -# Including transport parameters in the TLS handshake provides -# integrity protection for these values. -# -# enum { -# quic_transport_parameters(0x39), (65535) -# } ExtensionType; -# -# The extension_data field of the quic_transport_parameters extension -# contains a value that is defined by the version of QUIC that is in -# use. -# -# The quic_transport_parameters extension is carried in the ClientHello -# and the EncryptedExtensions messages during the handshake. Endpoints -# MUST send the quic_transport_parameters extension; endpoints that -# receive ClientHello or EncryptedExtensions messages without the -# quic_transport_parameters extension MUST close the connection with an -# error of type 0x016d (equivalent to a fatal TLS missing_extension -# alert, see Section 4.8). -# -# Transport parameters become available prior to the completion of the -# handshake. A server might use these values earlier than handshake -# completion. However, the value of transport parameters is not -# authenticated until the handshake completes, so any use of these -# parameters cannot depend on their authenticity. Any tampering with -# transport parameters will cause the handshake to fail. -# -# Endpoints MUST NOT send this extension in a TLS connection that does -# not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A -# fatal unsupported_extension alert MUST be sent by an implementation -# that supports this extension if the extension is received when the -# transport is not QUIC. -# -# Negotiating the quic_transport_parameters extension causes the -# EndOfEarlyData to be removed; see Section 8.3. - -[[spec]] -level = "MUST" -quote = ''' -Endpoints -MUST send the quic_transport_parameters extension; endpoints that -receive ClientHello or EncryptedExtensions messages without the -quic_transport_parameters extension MUST close the connection with an -error of type 0x016d (equivalent to a fatal TLS missing_extension -alert, see Section 4.8). -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints -MUST send the quic_transport_parameters extension; endpoints that -receive ClientHello or EncryptedExtensions messages without the -quic_transport_parameters extension MUST close the connection with an -error of type 0x016d (equivalent to a fatal TLS missing_extension -alert, see Section 4.8). -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST NOT send this extension in a TLS connection that does -not use QUIC (such as the use of TLS with TCP defined in [TLS13]). -''' - -[[spec]] -level = "MUST" -quote = ''' -A -fatal unsupported_extension alert MUST be sent by an implementation -that supports this extension if the extension is received when the -transport is not QUIC. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/8.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/8.3.toml deleted file mode 100644 index e8f6287d23..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/8.3.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.3" - -# 8.3. Removing the EndOfEarlyData Message -# -# The TLS EndOfEarlyData message is not used with QUIC. QUIC does not -# rely on this message to mark the end of 0-RTT data or to signal the -# change to Handshake keys. -# -# Clients MUST NOT send the EndOfEarlyData message. A server MUST -# treat receipt of a CRYPTO frame in a 0-RTT packet as a connection -# error of type PROTOCOL_VIOLATION. -# -# As a result, EndOfEarlyData does not appear in the TLS handshake -# transcript. - -[[spec]] -level = "MUST" -quote = ''' -Clients MUST NOT send the EndOfEarlyData message. -''' - -[[spec]] -level = "MUST" -quote = ''' -A server MUST -treat receipt of a CRYPTO frame in a 0-RTT packet as a connection -error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/8.4.toml b/specs/www.rfc-editor.org/rfc/rfc9001/8.4.toml deleted file mode 100644 index 0b4908971a..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/8.4.toml +++ /dev/null @@ -1,33 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-8.4" - -# 8.4. Prohibit TLS Middlebox Compatibility Mode -# -# Appendix D.4 of [TLS13] describes an alteration to the TLS 1.3 -# handshake as a workaround for bugs in some middleboxes. The TLS 1.3 -# middlebox compatibility mode involves setting the legacy_session_id -# field to a 32-byte value in the ClientHello and ServerHello, then -# sending a change_cipher_spec record. Both field and record carry no -# semantic content and are ignored. -# -# This mode has no use in QUIC as it only applies to middleboxes that -# interfere with TLS over TCP. QUIC also provides no means to carry a -# change_cipher_spec record. A client MUST NOT request the use of the -# TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a -# TLS ClientHello with a non-empty legacy_session_id field as a -# connection error of type PROTOCOL_VIOLATION. - -[[spec]] -level = "MUST" -quote = ''' -A client MUST NOT request the use of the -TLS 1.3 compatibility mode. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A server SHOULD treat the receipt of a -TLS ClientHello with a non-empty legacy_session_id field as a -connection error of type PROTOCOL_VIOLATION. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/9.2.toml b/specs/www.rfc-editor.org/rfc/rfc9001/9.2.toml deleted file mode 100644 index 9a7a7f30de..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/9.2.toml +++ /dev/null @@ -1,99 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.2" - -# 9.2. Replay Attacks with 0-RTT -# -# As described in Section 8 of [TLS13], use of TLS early data comes -# with an exposure to replay attack. The use of 0-RTT in QUIC is -# similarly vulnerable to replay attack. -# -# Endpoints MUST implement and use the replay protections described in -# [TLS13], however it is recognized that these protections are -# imperfect. Therefore, additional consideration of the risk of replay -# is needed. -# -# QUIC is not vulnerable to replay attack, except via the application -# protocol information it might carry. The management of QUIC protocol -# state based on the frame types defined in [QUIC-TRANSPORT] is not -# vulnerable to replay. Processing of QUIC frames is idempotent and -# cannot result in invalid connection states if frames are replayed, -# reordered, or lost. QUIC connections do not produce effects that -# last beyond the lifetime of the connection, except for those produced -# by the application protocol that QUIC serves. -# -# TLS session tickets and address validation tokens are used to carry -# QUIC configuration information between connections, specifically, to -# enable a server to efficiently recover state that is used in -# connection establishment and address validation. These MUST NOT be -# used to communicate application semantics between endpoints; clients -# MUST treat them as opaque values. The potential for reuse of these -# tokens means that they require stronger protections against replay. -# -# A server that accepts 0-RTT on a connection incurs a higher cost than -# accepting a connection without 0-RTT. This includes higher -# processing and computation costs. Servers need to consider the -# probability of replay and all associated costs when accepting 0-RTT. -# -# Ultimately, the responsibility for managing the risks of replay -# attacks with 0-RTT lies with an application protocol. An application -# protocol that uses QUIC MUST describe how the protocol uses 0-RTT and -# the measures that are employed to protect against replay attack. An -# analysis of replay risk needs to consider all QUIC protocol features -# that carry application semantics. -# -# Disabling 0-RTT entirely is the most effective defense against replay -# attack. -# -# QUIC extensions MUST either describe how replay attacks affect their -# operation or prohibit the use of the extension in 0-RTT. Application -# protocols MUST either prohibit the use of extensions that carry -# application semantics in 0-RTT or provide replay mitigation -# strategies. - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST implement and use the replay protections described in -[TLS13], however it is recognized that these protections are -imperfect. -''' - -[[spec]] -level = "MUST" -quote = ''' -These MUST NOT be -used to communicate application semantics between endpoints; clients -MUST treat them as opaque values. -''' - -[[spec]] -level = "MUST" -quote = ''' -These MUST NOT be -used to communicate application semantics between endpoints; clients -MUST treat them as opaque values. -''' - -[[spec]] -level = "MUST" -quote = ''' -An application -protocol that uses QUIC MUST describe how the protocol uses 0-RTT and -the measures that are employed to protect against replay attack. -''' - -[[spec]] -level = "MUST" -quote = ''' -QUIC extensions MUST either describe how replay attacks affect their -operation or prohibit the use of the extension in 0-RTT. -''' - -[[spec]] -level = "MUST" -quote = ''' -Application -protocols MUST either prohibit the use of extensions that carry -application semantics in 0-RTT or provide replay mitigation -strategies. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/9.3.toml b/specs/www.rfc-editor.org/rfc/rfc9001/9.3.toml deleted file mode 100644 index 5f48ae7dbc..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/9.3.toml +++ /dev/null @@ -1,24 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.3" - -# 9.3. Packet Reflection Attack Mitigation -# -# A small ClientHello that results in a large block of handshake -# messages from a server can be used in packet reflection attacks to -# amplify the traffic generated by an attacker. -# -# QUIC includes three defenses against this attack. First, the packet -# containing a ClientHello MUST be padded to a minimum size. Second, -# if responding to an unverified source address, the server is -# forbidden to send more than three times as many bytes as the number -# of bytes it has received (see Section 8.1 of [QUIC-TRANSPORT]). -# Finally, because acknowledgments of Handshake packets are -# authenticated, a blind attacker cannot forge them. Put together, -# these defenses limit the level of amplification. - -[[spec]] -level = "MUST" -quote = ''' -First, the packet -containing a ClientHello MUST be padded to a minimum size. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/9.4.toml b/specs/www.rfc-editor.org/rfc/rfc9001/9.4.toml deleted file mode 100644 index 34df82689c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/9.4.toml +++ /dev/null @@ -1,46 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.4" - -# 9.4. Header Protection Analysis -# -# [NAN] analyzes authenticated encryption algorithms that provide nonce -# privacy, referred to as "Hide Nonce" (HN) transforms. The general -# header protection construction in this document is one of those -# algorithms (HN1). Header protection is applied after the packet -# protection AEAD, sampling a set of bytes ("sample") from the AEAD -# output and encrypting the header field using a pseudorandom function -# (PRF) as follows: -# -# protected_field = field XOR PRF(hp_key, sample) -# -# The header protection variants in this document use a pseudorandom -# permutation (PRP) in place of a generic PRF. However, since all PRPs -# are also PRFs [IMC], these variants do not deviate from the HN1 -# construction. -# -# As "hp_key" is distinct from the packet protection key, it follows -# that header protection achieves AE2 security as defined in [NAN] and -# therefore guarantees privacy of "field", the protected packet header. -# Future header protection variants based on this construction MUST use -# a PRF to ensure equivalent security guarantees. -# -# Use of the same key and ciphertext sample more than once risks -# compromising header protection. Protecting two different headers -# with the same key and ciphertext sample reveals the exclusive OR of -# the protected fields. Assuming that the AEAD acts as a PRF, if L -# bits are sampled, the odds of two ciphertext samples being identical -# approach 2^(-L/2), that is, the birthday bound. For the algorithms -# described in this document, that probability is one in 2^64. -# -# To prevent an attacker from modifying packet headers, the header is -# transitively authenticated using packet protection; the entire packet -# header is part of the authenticated additional data. Protected -# fields that are falsified or modified can only be detected once the -# packet protection is removed. - -[[spec]] -level = "MUST" -quote = ''' -Future header protection variants based on this construction MUST use -a PRF to ensure equivalent security guarantees. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/9.5.toml b/specs/www.rfc-editor.org/rfc/rfc9001/9.5.toml deleted file mode 100644 index 78fbf54219..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/9.5.toml +++ /dev/null @@ -1,62 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.5" - -# 9.5. Header Protection Timing Side Channels -# -# An attacker could guess values for packet numbers or Key Phase and -# have an endpoint confirm guesses through timing side channels. -# Similarly, guesses for the packet number length can be tried and -# exposed. If the recipient of a packet discards packets with -# duplicate packet numbers without attempting to remove packet -# protection, they could reveal through timing side channels that the -# packet number matches a received packet. For authentication to be -# free from side channels, the entire process of header protection -# removal, packet number recovery, and packet protection removal MUST -# be applied together without timing and other side channels. -# -# For the sending of packets, construction and protection of packet -# payloads and packet numbers MUST be free from side channels that -# would reveal the packet number or its encoded size. -# -# During a key update, the time taken to generate new keys could reveal -# through timing side channels that a key update has occurred. -# Alternatively, where an attacker injects packets, this side channel -# could reveal the value of the Key Phase on injected packets. After -# receiving a key update, an endpoint SHOULD generate and save the next -# set of receive packet protection keys, as described in Section 6.3. -# By generating new keys before a key update is received, receipt of -# packets will not create timing signals that leak the value of the Key -# Phase. -# -# This depends on not doing this key generation during packet -# processing, and it can require that endpoints maintain three sets of -# packet protection keys for receiving: for the previous key phase, for -# the current key phase, and for the next key phase. Endpoints can -# instead choose to defer generation of the next receive packet -# protection keys until they discard old keys so that only two sets of -# receive keys need to be retained at any point in time. - -[[spec]] -level = "MUST" -quote = ''' -For authentication to be -free from side channels, the entire process of header protection -removal, packet number recovery, and packet protection removal MUST -be applied together without timing and other side channels. -''' - -[[spec]] -level = "MUST" -quote = ''' -For the sending of packets, construction and protection of packet -payloads and packet numbers MUST be free from side channels that -would reveal the packet number or its encoded size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -After -receiving a key update, an endpoint SHOULD generate and save the next -set of receive packet protection keys, as described in Section 6.3. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9001/9.6.toml b/specs/www.rfc-editor.org/rfc/rfc9001/9.6.toml deleted file mode 100644 index ff3e11fa87..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9001/9.6.toml +++ /dev/null @@ -1,40 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9001#section-9.6" - -# 9.6. Key Diversity -# -# In using TLS, the central key schedule of TLS is used. As a result -# of the TLS handshake messages being integrated into the calculation -# of secrets, the inclusion of the QUIC transport parameters extension -# ensures that the handshake and 1-RTT keys are not the same as those -# that might be produced by a server running TLS over TCP. To avoid -# the possibility of cross-protocol key synchronization, additional -# measures are provided to improve key separation. -# -# The QUIC packet protection keys and IVs are derived using a different -# label than the equivalent keys in TLS. -# -# To preserve this separation, a new version of QUIC SHOULD define new -# labels for key derivation for packet protection key and IV, plus the -# header protection keys. This version of QUIC uses the string "quic". -# Other versions can use a version-specific label in place of that -# string. -# -# The initial secrets use a key that is specific to the negotiated QUIC -# version. New QUIC versions SHOULD define a new salt value used in -# calculating initial secrets. - -[[spec]] -level = "SHOULD" -quote = ''' -To preserve this separation, a new version of QUIC SHOULD define new -labels for key derivation for packet protection key and IV, plus the -header protection keys. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -New QUIC versions SHOULD define a new salt value used in -calculating initial secrets. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/5.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/5.1.toml deleted file mode 100644 index 342db93922..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/5.1.toml +++ /dev/null @@ -1,56 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-5.1" - -# 5.1. Generating RTT Samples -# -# An endpoint generates an RTT sample on receiving an ACK frame that -# meets the following two conditions: -# -# * the largest acknowledged packet number is newly acknowledged, and -# -# * at least one of the newly acknowledged packets was ack-eliciting. -# -# The RTT sample, latest_rtt, is generated as the time elapsed since -# the largest acknowledged packet was sent: -# -# latest_rtt = ack_time - send_time_of_largest_acked -# -# An RTT sample is generated using only the largest acknowledged packet -# in the received ACK frame. This is because a peer reports -# acknowledgment delays for only the largest acknowledged packet in an -# ACK frame. While the reported acknowledgment delay is not used by -# the RTT sample measurement, it is used to adjust the RTT sample in -# subsequent computations of smoothed_rtt and rttvar (Section 5.3). -# -# To avoid generating multiple RTT samples for a single packet, an ACK -# frame SHOULD NOT be used to update RTT estimates if it does not newly -# acknowledge the largest acknowledged packet. -# -# An RTT sample MUST NOT be generated on receiving an ACK frame that -# does not newly acknowledge at least one ack-eliciting packet. A peer -# usually does not send an ACK frame when only non-ack-eliciting -# packets are received. Therefore, an ACK frame that contains -# acknowledgments for only non-ack-eliciting packets could include an -# arbitrarily large ACK Delay value. Ignoring such ACK frames avoids -# complications in subsequent smoothed_rtt and rttvar computations. -# -# A sender might generate multiple RTT samples per RTT when multiple -# ACK frames are received within an RTT. As suggested in [RFC6298], -# doing so might result in inadequate history in smoothed_rtt and -# rttvar. Ensuring that RTT estimates retain sufficient history is an -# open research question. - -[[spec]] -level = "SHOULD" -quote = ''' -To avoid generating multiple RTT samples for a single packet, an ACK -frame SHOULD NOT be used to update RTT estimates if it does not newly -acknowledge the largest acknowledged packet. -''' - -[[spec]] -level = "MUST" -quote = ''' -An RTT sample MUST NOT be generated on receiving an ACK frame that -does not newly acknowledge at least one ack-eliciting packet. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/5.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/5.2.toml deleted file mode 100644 index e8799a8a15..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/5.2.toml +++ /dev/null @@ -1,73 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-5.2" - -# 5.2. Estimating min_rtt -# -# min_rtt is the sender's estimate of the minimum RTT observed for a -# given network path over a period of time. In this document, min_rtt -# is used by loss detection to reject implausibly small RTT samples. -# -# min_rtt MUST be set to the latest_rtt on the first RTT sample. -# min_rtt MUST be set to the lesser of min_rtt and latest_rtt -# (Section 5.1) on all other samples. -# -# An endpoint uses only locally observed times in computing the min_rtt -# and does not adjust for acknowledgment delays reported by the peer. -# Doing so allows the endpoint to set a lower bound for the -# smoothed_rtt based entirely on what it observes (see Section 5.3) and -# limits potential underestimation due to erroneously reported delays -# by the peer. -# -# The RTT for a network path may change over time. If a path's actual -# RTT decreases, the min_rtt will adapt immediately on the first low -# sample. If the path's actual RTT increases, however, the min_rtt -# will not adapt to it, allowing future RTT samples that are smaller -# than the new RTT to be included in smoothed_rtt. -# -# Endpoints SHOULD set the min_rtt to the newest RTT sample after -# persistent congestion is established. This avoids repeatedly -# declaring persistent congestion when the RTT increases. This also -# allows a connection to reset its estimate of min_rtt and smoothed_rtt -# after a disruptive network event; see Section 5.3. -# -# Endpoints MAY reestablish the min_rtt at other times in the -# connection, such as when traffic volume is low and an acknowledgment -# is received with a low acknowledgment delay. Implementations SHOULD -# NOT refresh the min_rtt value too often since the actual minimum RTT -# of the path is not frequently observable. - -[[spec]] -level = "MUST" -quote = ''' -min_rtt MUST be set to the latest_rtt on the first RTT sample. -''' - -[[spec]] -level = "MUST" -quote = ''' -min_rtt MUST be set to the lesser of min_rtt and latest_rtt -(Section 5.1) on all other samples. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD set the min_rtt to the newest RTT sample after -persistent congestion is established. -''' - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY reestablish the min_rtt at other times in the -connection, such as when traffic volume is low and an acknowledgment -is received with a low acknowledgment delay. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Implementations SHOULD -NOT refresh the min_rtt value too often since the actual minimum RTT -of the path is not frequently observable. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/5.3.toml b/specs/www.rfc-editor.org/rfc/rfc9002/5.3.toml deleted file mode 100644 index fc9fd84a15..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/5.3.toml +++ /dev/null @@ -1,157 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-5.3" - -# 5.3. Estimating smoothed_rtt and rttvar -# -# smoothed_rtt is an exponentially weighted moving average of an -# endpoint's RTT samples, and rttvar estimates the variation in the RTT -# samples using a mean variation. -# -# The calculation of smoothed_rtt uses RTT samples after adjusting them -# for acknowledgment delays. These delays are decoded from the ACK -# Delay field of ACK frames as described in Section 19.3 of -# [QUIC-TRANSPORT]. -# -# The peer might report acknowledgment delays that are larger than the -# peer's max_ack_delay during the handshake (Section 13.2.1 of -# [QUIC-TRANSPORT]). To account for this, the endpoint SHOULD ignore -# max_ack_delay until the handshake is confirmed, as defined in -# Section 4.1.2 of [QUIC-TLS]. When they occur, these large -# acknowledgment delays are likely to be non-repeating and limited to -# the handshake. The endpoint can therefore use them without limiting -# them to the max_ack_delay, avoiding unnecessary inflation of the RTT -# estimate. -# -# Note that a large acknowledgment delay can result in a substantially -# inflated smoothed_rtt if there is an error either in the peer's -# reporting of the acknowledgment delay or in the endpoint's min_rtt -# estimate. Therefore, prior to handshake confirmation, an endpoint -# MAY ignore RTT samples if adjusting the RTT sample for acknowledgment -# delay causes the sample to be less than the min_rtt. -# -# After the handshake is confirmed, any acknowledgment delays reported -# by the peer that are greater than the peer's max_ack_delay are -# attributed to unintentional but potentially repeating delays, such as -# scheduler latency at the peer or loss of previous acknowledgments. -# Excess delays could also be due to a noncompliant receiver. -# Therefore, these extra delays are considered effectively part of path -# delay and incorporated into the RTT estimate. -# -# Therefore, when adjusting an RTT sample using peer-reported -# acknowledgment delays, an endpoint: -# -# * MAY ignore the acknowledgment delay for Initial packets, since -# these acknowledgments are not delayed by the peer (Section 13.2.1 -# of [QUIC-TRANSPORT]); -# -# * SHOULD ignore the peer's max_ack_delay until the handshake is -# confirmed; -# -# * MUST use the lesser of the acknowledgment delay and the peer's -# max_ack_delay after the handshake is confirmed; and -# -# * MUST NOT subtract the acknowledgment delay from the RTT sample if -# the resulting value is smaller than the min_rtt. This limits the -# underestimation of the smoothed_rtt due to a misreporting peer. -# -# Additionally, an endpoint might postpone the processing of -# acknowledgments when the corresponding decryption keys are not -# immediately available. For example, a client might receive an -# acknowledgment for a 0-RTT packet that it cannot decrypt because -# 1-RTT packet protection keys are not yet available to it. In such -# cases, an endpoint SHOULD subtract such local delays from its RTT -# sample until the handshake is confirmed. -# -# Similar to [RFC6298], smoothed_rtt and rttvar are computed as -# follows. -# -# An endpoint initializes the RTT estimator during connection -# establishment and when the estimator is reset during connection -# migration; see Section 9.4 of [QUIC-TRANSPORT]. Before any RTT -# samples are available for a new path or when the estimator is reset, -# the estimator is initialized using the initial RTT; see -# Section 6.2.2. -# -# smoothed_rtt and rttvar are initialized as follows, where kInitialRtt -# contains the initial RTT value: -# -# smoothed_rtt = kInitialRtt -# rttvar = kInitialRtt / 2 -# -# RTT samples for the network path are recorded in latest_rtt; see -# Section 5.1. On the first RTT sample after initialization, the -# estimator is reset using that sample. This ensures that the -# estimator retains no history of past samples. Packets sent on other -# paths do not contribute RTT samples to the current path, as described -# in Section 9.4 of [QUIC-TRANSPORT]. -# -# On the first RTT sample after initialization, smoothed_rtt and rttvar -# are set as follows: -# -# smoothed_rtt = latest_rtt -# rttvar = latest_rtt / 2 -# -# On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: -# -# ack_delay = decoded acknowledgment delay from ACK frame -# if (handshake confirmed): -# ack_delay = min(ack_delay, max_ack_delay) -# adjusted_rtt = latest_rtt -# if (latest_rtt >= min_rtt + ack_delay): -# adjusted_rtt = latest_rtt - ack_delay -# smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt -# rttvar_sample = abs(smoothed_rtt - adjusted_rtt) -# rttvar = 3/4 * rttvar + 1/4 * rttvar_sample - -[[spec]] -level = "SHOULD" -quote = ''' -To account for this, the endpoint SHOULD ignore -max_ack_delay until the handshake is confirmed, as defined in -Section 4.1.2 of [QUIC-TLS]. -''' - -[[spec]] -level = "MAY" -quote = ''' -Therefore, prior to handshake confirmation, an endpoint -MAY ignore RTT samples if adjusting the RTT sample for acknowledgment -delay causes the sample to be less than the min_rtt. -''' - -[[spec]] -level = "MAY" -quote = ''' -* MAY ignore the acknowledgment delay for Initial packets, since -these acknowledgments are not delayed by the peer (Section 13.2.1 -of [QUIC-TRANSPORT]); -''' - -[[spec]] -level = "SHOULD" -quote = ''' -* SHOULD ignore the peer's max_ack_delay until the handshake is -confirmed; -''' - -[[spec]] -level = "MUST" -quote = ''' -* MUST use the lesser of the acknowledgment delay and the peer's -max_ack_delay after the handshake is confirmed; and -''' - -[[spec]] -level = "MUST" -quote = ''' -* MUST NOT subtract the acknowledgment delay from the RTT sample if -the resulting value is smaller than the min_rtt. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In such -cases, an endpoint SHOULD subtract such local delays from its RTT -sample until the handshake is confirmed. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.1.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.1.1.toml deleted file mode 100644 index 5bad70eef4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.1.1.toml +++ /dev/null @@ -1,35 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.1.1" - -# 6.1.1. Packet Threshold -# -# The RECOMMENDED initial value for the packet reordering threshold -# (kPacketThreshold) is 3, based on best practices for TCP loss -# detection [RFC5681] [RFC6675]. In order to remain similar to TCP, -# implementations SHOULD NOT use a packet threshold less than 3; see -# [RFC5681]. -# -# Some networks may exhibit higher degrees of packet reordering, -# causing a sender to detect spurious losses. Additionally, packet -# reordering could be more common with QUIC than TCP because network -# elements that could observe and reorder TCP packets cannot do that -# for QUIC and also because QUIC packet numbers are encrypted. -# Algorithms that increase the reordering threshold after spuriously -# detecting losses, such as RACK [RFC8985], have proven to be useful in -# TCP and are expected to be at least as useful in QUIC. - -[[spec]] -level = "SHOULD" -quote = ''' -The RECOMMENDED initial value for the packet reordering threshold -(kPacketThreshold) is 3, based on best practices for TCP loss -detection [RFC5681] [RFC6675]. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In order to remain similar to TCP, -implementations SHOULD NOT use a packet threshold less than 3; see -[RFC5681]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.1.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.1.2.toml deleted file mode 100644 index 8d40f0134c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.1.2.toml +++ /dev/null @@ -1,86 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.1.2" - -# 6.1.2. Time Threshold -# -# Once a later packet within the same packet number space has been -# acknowledged, an endpoint SHOULD declare an earlier packet lost if it -# was sent a threshold amount of time in the past. To avoid declaring -# packets as lost too early, this time threshold MUST be set to at -# least the local timer granularity, as indicated by the kGranularity -# constant. The time threshold is: -# -# max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity) -# -# If packets sent prior to the largest acknowledged packet cannot yet -# be declared lost, then a timer SHOULD be set for the remaining time. -# -# Using max(smoothed_rtt, latest_rtt) protects from the two following -# cases: -# -# * the latest RTT sample is lower than the smoothed RTT, perhaps due -# to reordering where the acknowledgment encountered a shorter path; -# -# * the latest RTT sample is higher than the smoothed RTT, perhaps due -# to a sustained increase in the actual RTT, but the smoothed RTT -# has not yet caught up. -# -# The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT -# multiplier, is 9/8. The RECOMMENDED value of the timer granularity -# (kGranularity) is 1 millisecond. -# -# | Note: TCP's RACK [RFC8985] specifies a slightly larger -# | threshold, equivalent to 5/4, for a similar purpose. -# | Experience with QUIC shows that 9/8 works well. -# -# Implementations MAY experiment with absolute thresholds, thresholds -# from previous connections, adaptive thresholds, or the including of -# RTT variation. Smaller thresholds reduce reordering resilience and -# increase spurious retransmissions, and larger thresholds increase -# loss detection delay. - -[[spec]] -level = "SHOULD" -quote = ''' -Once a later packet within the same packet number space has been -acknowledged, an endpoint SHOULD declare an earlier packet lost if it -was sent a threshold amount of time in the past. -''' - -[[spec]] -level = "MUST" -quote = ''' -To avoid declaring -packets as lost too early, this time threshold MUST be set to at -least the local timer granularity, as indicated by the kGranularity -constant. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If packets sent prior to the largest acknowledged packet cannot yet -be declared lost, then a timer SHOULD be set for the remaining time. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT -multiplier, is 9/8. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The RECOMMENDED value of the timer granularity -(kGranularity) is 1 millisecond. -''' - -[[spec]] -level = "MAY" -quote = ''' -Implementations MAY experiment with absolute thresholds, thresholds -from previous connections, adaptive thresholds, or the including of -RTT variation. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.1.toml deleted file mode 100644 index 8e59bfbc99..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.1.toml +++ /dev/null @@ -1,41 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.1" - -# 6.1. Acknowledgment-Based Detection -# -# Acknowledgment-based loss detection implements the spirit of TCP's -# Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward -# Acknowledgment [FACK], SACK loss recovery [RFC6675], and RACK-TLP -# [RFC8985]. This section provides an overview of how these algorithms -# are implemented in QUIC. -# -# A packet is declared lost if it meets all of the following -# conditions: -# -# * The packet is unacknowledged, in flight, and was sent prior to an -# acknowledged packet. -# -# * The packet was sent kPacketThreshold packets before an -# acknowledged packet (Section 6.1.1), or it was sent long enough in -# the past (Section 6.1.2). -# -# The acknowledgment indicates that a packet sent later was delivered, -# and the packet and time thresholds provide some tolerance for packet -# reordering. -# -# Spuriously declaring packets as lost leads to unnecessary -# retransmissions and may result in degraded performance due to the -# actions of the congestion controller upon detecting loss. -# Implementations can detect spurious retransmissions and increase the -# packet or time reordering threshold to reduce future spurious -# retransmissions and loss events. Implementations with adaptive time -# thresholds MAY choose to start with smaller initial reordering -# thresholds to minimize recovery latency. - -[[spec]] -level = "MAY" -quote = ''' -Implementations with adaptive time -thresholds MAY choose to start with smaller initial reordering -thresholds to minimize recovery latency. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.2.1.toml deleted file mode 100644 index bd6670c358..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.1.toml +++ /dev/null @@ -1,116 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.1" - -# 6.2.1. Computing PTO -# -# When an ack-eliciting packet is transmitted, the sender schedules a -# timer for the PTO period as follows: -# -# PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay -# -# The PTO period is the amount of time that a sender ought to wait for -# an acknowledgment of a sent packet. This time period includes the -# estimated network RTT (smoothed_rtt), the variation in the estimate -# (4*rttvar), and max_ack_delay, to account for the maximum time by -# which a receiver might delay sending an acknowledgment. -# -# When the PTO is armed for Initial or Handshake packet number spaces, -# the max_ack_delay in the PTO period computation is set to 0, since -# the peer is expected to not delay these packets intentionally; see -# Section 13.2.1 of [QUIC-TRANSPORT]. -# -# The PTO period MUST be at least kGranularity to avoid the timer -# expiring immediately. -# -# When ack-eliciting packets in multiple packet number spaces are in -# flight, the timer MUST be set to the earlier value of the Initial and -# Handshake packet number spaces. -# -# An endpoint MUST NOT set its PTO timer for the Application Data -# packet number space until the handshake is confirmed. Doing so -# prevents the endpoint from retransmitting information in packets when -# either the peer does not yet have the keys to process them or the -# endpoint does not yet have the keys to process their acknowledgments. -# For example, this can happen when a client sends 0-RTT packets to the -# server; it does so without knowing whether the server will be able to -# decrypt them. Similarly, this can happen when a server sends 1-RTT -# packets before confirming that the client has verified the server's -# certificate and can therefore read these 1-RTT packets. -# -# A sender SHOULD restart its PTO timer every time an ack-eliciting -# packet is sent or acknowledged, or when Initial or Handshake keys are -# discarded (Section 4.9 of [QUIC-TLS]). This ensures the PTO is -# always set based on the latest estimate of the RTT and for the -# correct packet across packet number spaces. -# -# When a PTO timer expires, the PTO backoff MUST be increased, -# resulting in the PTO period being set to twice its current value. -# The PTO backoff factor is reset when an acknowledgment is received, -# except in the following case. A server might take longer to respond -# to packets during the handshake than otherwise. To protect such a -# server from repeated client probes, the PTO backoff is not reset at a -# client that is not yet certain that the server has finished -# validating the client's address. That is, a client does not reset -# the PTO backoff factor on receiving acknowledgments in Initial -# packets. -# -# This exponential reduction in the sender's rate is important because -# consecutive PTOs might be caused by loss of packets or -# acknowledgments due to severe congestion. Even when there are ack- -# eliciting packets in flight in multiple packet number spaces, the -# exponential increase in PTO occurs across all spaces to prevent -# excess load on the network. For example, a timeout in the Initial -# packet number space doubles the length of the timeout in the -# Handshake packet number space. -# -# The total length of time over which consecutive PTOs expire is -# limited by the idle timeout. -# -# The PTO timer MUST NOT be set if a timer is set for time threshold -# loss detection; see Section 6.1.2. A timer that is set for time -# threshold loss detection will expire earlier than the PTO timer in -# most cases and is less likely to spuriously retransmit data. - -[[spec]] -level = "MUST" -quote = ''' -The PTO period MUST be at least kGranularity to avoid the timer -expiring immediately. -''' - -[[spec]] -level = "MUST" -quote = ''' -When ack-eliciting packets in multiple packet number spaces are in -flight, the timer MUST be set to the earlier value of the Initial and -Handshake packet number spaces. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT set its PTO timer for the Application Data -packet number space until the handshake is confirmed. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD restart its PTO timer every time an ack-eliciting -packet is sent or acknowledged, or when Initial or Handshake keys are -discarded (Section 4.9 of [QUIC-TLS]). -''' - -[[spec]] -level = "MUST" -quote = ''' -When a PTO timer expires, the PTO backoff MUST be increased, -resulting in the PTO period being set to twice its current value. -''' - -[[spec]] -level = "MUST" -quote = ''' -The PTO timer MUST NOT be set if a timer is set for time threshold -loss detection; see Section 6.1.2. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.1.toml deleted file mode 100644 index 70907c4e6d..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.1.toml +++ /dev/null @@ -1,68 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.2.1" - -# 6.2.2.1. Before Address Validation -# -# Until the server has validated the client's address on the path, the -# amount of data it can send is limited to three times the amount of -# data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. If -# no additional data can be sent, the server's PTO timer MUST NOT be -# armed until datagrams have been received from the client because -# packets sent on PTO count against the anti-amplification limit. -# -# When the server receives a datagram from the client, the -# amplification limit is increased and the server resets the PTO timer. -# If the PTO timer is then set to a time in the past, it is executed -# immediately. Doing so avoids sending new 1-RTT packets prior to -# packets critical to the completion of the handshake. In particular, -# this can happen when 0-RTT is accepted but the server fails to -# validate the client's address. -# -# Since the server could be blocked until more datagrams are received -# from the client, it is the client's responsibility to send packets to -# unblock the server until it is certain that the server has finished -# its address validation (see Section 8 of [QUIC-TRANSPORT]). That is, -# the client MUST set the PTO timer if the client has not received an -# acknowledgment for any of its Handshake packets and the handshake is -# not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no -# packets in flight. When the PTO fires, the client MUST send a -# Handshake packet if it has Handshake keys, otherwise it MUST send an -# Initial packet in a UDP datagram with a payload of at least 1200 -# bytes. - -[[spec]] -level = "MUST" -quote = ''' -If -no additional data can be sent, the server's PTO timer MUST NOT be -armed until datagrams have been received from the client because -packets sent on PTO count against the anti-amplification limit. -''' - -[[spec]] -level = "MUST" -quote = ''' -That is, -the client MUST set the PTO timer if the client has not received an -acknowledgment for any of its Handshake packets and the handshake is -not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no -packets in flight. -''' - -[[spec]] -level = "MUST" -quote = ''' -When the PTO fires, the client MUST send a -Handshake packet if it has Handshake keys, otherwise it MUST send an -Initial packet in a UDP datagram with a payload of at least 1200 -bytes. -''' - -[[spec]] -level = "MUST" -quote = ''' -When the PTO fires, the client MUST send a -Handshake packet if it has Handshake keys, otherwise it MUST send an -Initial packet in a UDP datagram with a payload of at least 1200 -bytes. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.toml deleted file mode 100644 index 4b3af79a47..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.2.toml +++ /dev/null @@ -1,58 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.2" - -# 6.2.2. Handshakes and New Paths -# -# Resumed connections over the same network MAY use the previous -# connection's final smoothed RTT value as the resumed connection's -# initial RTT. When no previous RTT is available, the initial RTT -# SHOULD be set to 333 milliseconds. This results in handshakes -# starting with a PTO of 1 second, as recommended for TCP's initial -# RTO; see Section 2 of [RFC6298]. -# -# A connection MAY use the delay between sending a PATH_CHALLENGE and -# receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in -# Appendix A.2) for a new path, but the delay SHOULD NOT be considered -# an RTT sample. -# -# When the Initial keys and Handshake keys are discarded (see -# Section 6.4), any Initial packets and Handshake packets can no longer -# be acknowledged, so they are removed from bytes in flight. When -# Initial or Handshake keys are discarded, the PTO and loss detection -# timers MUST be reset, because discarding keys indicates forward -# progress and the loss detection timer might have been set for a now- -# discarded packet number space. - -[[spec]] -level = "MAY" -quote = ''' -Resumed connections over the same network MAY use the previous -connection's final smoothed RTT value as the resumed connection's -initial RTT. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When no previous RTT is available, the initial RTT -SHOULD be set to 333 milliseconds. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A connection MAY use the delay between sending a PATH_CHALLENGE and -receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in -Appendix A.2) for a new path, but the delay SHOULD NOT be considered -an RTT sample. -''' - -[[spec]] -level = "MUST" -quote = ''' -When -Initial or Handshake keys are discarded, the PTO and loss detection -timers MUST be reset, because discarding keys indicates forward -progress and the loss detection timer might have been set for a now- -discarded packet number space. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.3.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.2.3.toml deleted file mode 100644 index ec7eaf26fb..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.3.toml +++ /dev/null @@ -1,37 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.3" - -# 6.2.3. Speeding up Handshake Completion -# -# When a server receives an Initial packet containing duplicate CRYPTO -# data, it can assume the client did not receive all of the server's -# CRYPTO data sent in Initial packets, or the client's estimated RTT is -# too small. When a client receives Handshake or 1-RTT packets prior -# to obtaining Handshake keys, it may assume some or all of the -# server's Initial packets were lost. -# -# To speed up handshake completion under these conditions, an endpoint -# MAY, for a limited number of times per connection, send a packet -# containing unacknowledged CRYPTO data earlier than the PTO expiry, -# subject to the address validation limits in Section 8.1 of -# [QUIC-TRANSPORT]. Doing so at most once for each connection is -# adequate to quickly recover from a single packet loss. An endpoint -# that always retransmits packets in response to receiving packets that -# it cannot process risks creating an infinite exchange of packets. -# -# Endpoints can also use coalesced packets (see Section 12.2 of -# [QUIC-TRANSPORT]) to ensure that each datagram elicits at least one -# acknowledgment. For example, a client can coalesce an Initial packet -# containing PING and PADDING frames with a 0-RTT data packet, and a -# server can coalesce an Initial packet containing a PING frame with -# one or more packets in its first flight. - -[[spec]] -level = "MAY" -quote = ''' -To speed up handshake completion under these conditions, an endpoint -MAY, for a limited number of times per connection, send a packet -containing unacknowledged CRYPTO data earlier than the PTO expiry, -subject to the address validation limits in Section 8.1 of -[QUIC-TRANSPORT]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.4.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.2.4.toml deleted file mode 100644 index d19a00ccd0..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.4.toml +++ /dev/null @@ -1,124 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2.4" - -# 6.2.4. Sending Probe Packets -# -# When a PTO timer expires, a sender MUST send at least one ack- -# eliciting packet in the packet number space as a probe. An endpoint -# MAY send up to two full-sized datagrams containing ack-eliciting -# packets to avoid an expensive consecutive PTO expiration due to a -# single lost datagram or to transmit data from multiple packet number -# spaces. All probe packets sent on a PTO MUST be ack-eliciting. -# -# In addition to sending data in the packet number space for which the -# timer expired, the sender SHOULD send ack-eliciting packets from -# other packet number spaces with in-flight data, coalescing packets if -# possible. This is particularly valuable when the server has both -# Initial and Handshake data in flight or when the client has both -# Handshake and Application Data in flight because the peer might only -# have receive keys for one of the two packet number spaces. -# -# If the sender wants to elicit a faster acknowledgment on PTO, it can -# skip a packet number to eliminate the acknowledgment delay. -# -# An endpoint SHOULD include new data in packets that are sent on PTO -# expiration. Previously sent data MAY be sent if no new data can be -# sent. Implementations MAY use alternative strategies for determining -# the content of probe packets, including sending new or retransmitted -# data based on the application's priorities. -# -# It is possible the sender has no new or previously sent data to send. -# As an example, consider the following sequence of events: new -# application data is sent in a STREAM frame, deemed lost, then -# retransmitted in a new packet, and then the original transmission is -# acknowledged. When there is no data to send, the sender SHOULD send -# a PING or other ack-eliciting frame in a single packet, rearming the -# PTO timer. -# -# Alternatively, instead of sending an ack-eliciting packet, the sender -# MAY mark any packets still in flight as lost. Doing so avoids -# sending an additional packet but increases the risk that loss is -# declared too aggressively, resulting in an unnecessary rate reduction -# by the congestion controller. -# -# Consecutive PTO periods increase exponentially, and as a result, -# connection recovery latency increases exponentially as packets -# continue to be dropped in the network. Sending two packets on PTO -# expiration increases resilience to packet drops, thus reducing the -# probability of consecutive PTO events. -# -# When the PTO timer expires multiple times and new data cannot be -# sent, implementations must choose between sending the same payload -# every time or sending different payloads. Sending the same payload -# may be simpler and ensures the highest priority frames arrive first. -# Sending different payloads each time reduces the chances of spurious -# retransmission. - -[[spec]] -level = "MUST" -quote = ''' -When a PTO timer expires, a sender MUST send at least one ack- -eliciting packet in the packet number space as a probe. -''' - -[[spec]] -level = "MAY" -quote = ''' -An endpoint -MAY send up to two full-sized datagrams containing ack-eliciting -packets to avoid an expensive consecutive PTO expiration due to a -single lost datagram or to transmit data from multiple packet number -spaces. -''' - -[[spec]] -level = "MUST" -quote = ''' -All probe packets sent on a PTO MUST be ack-eliciting. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -In addition to sending data in the packet number space for which the -timer expired, the sender SHOULD send ack-eliciting packets from -other packet number spaces with in-flight data, coalescing packets if -possible. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -An endpoint SHOULD include new data in packets that are sent on PTO -expiration. -''' - -[[spec]] -level = "MAY" -quote = ''' -Previously sent data MAY be sent if no new data can be -sent. -''' - -[[spec]] -level = "MAY" -quote = ''' -Implementations MAY use alternative strategies for determining -the content of probe packets, including sending new or retransmitted -data based on the application's priorities. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -When there is no data to send, the sender SHOULD send -a PING or other ack-eliciting frame in a single packet, rearming the -PTO timer. -''' - -[[spec]] -level = "MAY" -quote = ''' -Alternatively, instead of sending an ack-eliciting packet, the sender -MAY mark any packets still in flight as lost. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.2.toml deleted file mode 100644 index c2a734580b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.2.toml +++ /dev/null @@ -1,31 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.2" - -# 6.2. Probe Timeout -# -# A Probe Timeout (PTO) triggers the sending of one or two probe -# datagrams when ack-eliciting packets are not acknowledged within the -# expected period of time or the server may not have validated the -# client's address. A PTO enables a connection to recover from loss of -# tail packets or acknowledgments. -# -# As with loss detection, the PTO is per packet number space. That is, -# a PTO value is computed per packet number space. -# -# A PTO timer expiration event does not indicate packet loss and MUST -# NOT cause prior unacknowledged packets to be marked as lost. When an -# acknowledgment is received that newly acknowledges packets, loss -# detection proceeds as dictated by the packet and time threshold -# mechanisms; see Section 6.1. -# -# The PTO algorithm used in QUIC implements the reliability functions -# of Tail Loss Probe [RFC8985], RTO [RFC5681], and F-RTO algorithms for -# TCP [RFC5682]. The timeout computation is based on TCP's RTO period -# [RFC6298]. - -[[spec]] -level = "MUST" -quote = ''' -A PTO timer expiration event does not indicate packet loss and MUST -NOT cause prior unacknowledged packets to be marked as lost. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.3.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.3.toml deleted file mode 100644 index 1aa10c36e4..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.3.toml +++ /dev/null @@ -1,36 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.3" - -# 6.3. Handling Retry Packets -# -# A Retry packet causes a client to send another Initial packet, -# effectively restarting the connection process. A Retry packet -# indicates that the Initial packet was received but not processed. A -# Retry packet cannot be treated as an acknowledgment because it does -# not indicate that a packet was processed or specify the packet -# number. -# -# Clients that receive a Retry packet reset congestion control and loss -# recovery state, including resetting any pending timers. Other -# connection state, in particular cryptographic handshake messages, is -# retained; see Section 17.2.5 of [QUIC-TRANSPORT]. -# -# The client MAY compute an RTT estimate to the server as the time -# period from when the first Initial packet was sent to when a Retry or -# a Version Negotiation packet is received. The client MAY use this -# value in place of its default for the initial RTT estimate. - -[[spec]] -level = "MAY" -quote = ''' -The client MAY compute an RTT estimate to the server as the time -period from when the first Initial packet was sent to when a Retry or -a Version Negotiation packet is received. -''' - -[[spec]] -level = "MAY" -quote = ''' -The client MAY use this -value in place of its default for the initial RTT estimate. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/6.4.toml b/specs/www.rfc-editor.org/rfc/rfc9002/6.4.toml deleted file mode 100644 index a940cd5df9..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/6.4.toml +++ /dev/null @@ -1,45 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-6.4" - -# 6.4. Discarding Keys and Packet State -# -# When Initial and Handshake packet protection keys are discarded (see -# Section 4.9 of [QUIC-TLS]), all packets that were sent with those -# keys can no longer be acknowledged because their acknowledgments -# cannot be processed. The sender MUST discard all recovery state -# associated with those packets and MUST remove them from the count of -# bytes in flight. -# -# Endpoints stop sending and receiving Initial packets once they start -# exchanging Handshake packets; see Section 17.2.2.1 of -# [QUIC-TRANSPORT]. At this point, recovery state for all in-flight -# Initial packets is discarded. -# -# When 0-RTT is rejected, recovery state for all in-flight 0-RTT -# packets is discarded. -# -# If a server accepts 0-RTT, but does not buffer 0-RTT packets that -# arrive before Initial packets, early 0-RTT packets will be declared -# lost, but that is expected to be infrequent. -# -# It is expected that keys are discarded at some time after the packets -# encrypted with them are either acknowledged or declared lost. -# However, Initial and Handshake secrets are discarded as soon as -# Handshake and 1-RTT keys are proven to be available to both client -# and server; see Section 4.9.1 of [QUIC-TLS]. - -[[spec]] -level = "MUST" -quote = ''' -The sender MUST discard all recovery state -associated with those packets and MUST remove them from the count of -bytes in flight. -''' - -[[spec]] -level = "MUST" -quote = ''' -The sender MUST discard all recovery state -associated with those packets and MUST remove them from the count of -bytes in flight. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.2.toml deleted file mode 100644 index 4a4190800f..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.2.toml +++ /dev/null @@ -1,61 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.2" - -# 7.2. Initial and Minimum Congestion Window -# -# QUIC begins every connection in slow start with the congestion window -# set to an initial value. Endpoints SHOULD use an initial congestion -# window of ten times the maximum datagram size (max_datagram_size), -# while limiting the window to the larger of 14,720 bytes or twice the -# maximum datagram size. This follows the analysis and recommendations -# in [RFC6928], increasing the byte limit to account for the smaller -# 8-byte overhead of UDP compared to the 20-byte overhead for TCP. -# -# If the maximum datagram size changes during the connection, the -# initial congestion window SHOULD be recalculated with the new size. -# If the maximum datagram size is decreased in order to complete the -# handshake, the congestion window SHOULD be set to the new initial -# congestion window. -# -# Prior to validating the client's address, the server can be further -# limited by the anti-amplification limit as specified in Section 8.1 -# of [QUIC-TRANSPORT]. Though the anti-amplification limit can prevent -# the congestion window from being fully utilized and therefore slow -# down the increase in congestion window, it does not directly affect -# the congestion window. -# -# The minimum congestion window is the smallest value the congestion -# window can attain in response to loss, an increase in the peer- -# reported ECN-CE count, or persistent congestion. The RECOMMENDED -# value is 2 * max_datagram_size. - -[[spec]] -level = "SHOULD" -quote = ''' -Endpoints SHOULD use an initial congestion -window of ten times the maximum datagram size (max_datagram_size), -while limiting the window to the larger of 14,720 bytes or twice the -maximum datagram size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If the maximum datagram size changes during the connection, the -initial congestion window SHOULD be recalculated with the new size. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -If the maximum datagram size is decreased in order to complete the -handshake, the congestion window SHOULD be set to the new initial -congestion window. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The RECOMMENDED -value is 2 * max_datagram_size. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.3.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.3.1.toml deleted file mode 100644 index a40aa1da7b..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.3.1.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.3.1" - -# 7.3.1. Slow Start -# -# A NewReno sender is in slow start any time the congestion window is -# below the slow start threshold. A sender begins in slow start -# because the slow start threshold is initialized to an infinite value. -# -# While a sender is in slow start, the congestion window increases by -# the number of bytes acknowledged when each acknowledgment is -# processed. This results in exponential growth of the congestion -# window. -# -# The sender MUST exit slow start and enter a recovery period when a -# packet is lost or when the ECN-CE count reported by its peer -# increases. -# -# A sender reenters slow start any time the congestion window is less -# than the slow start threshold, which only occurs after persistent -# congestion is declared. - -[[spec]] -level = "MUST" -quote = ''' -The sender MUST exit slow start and enter a recovery period when a -packet is lost or when the ECN-CE count reported by its peer -increases. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.3.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.3.2.toml deleted file mode 100644 index e741abc11c..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.3.2.toml +++ /dev/null @@ -1,57 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.3.2" - -# 7.3.2. Recovery -# -# A NewReno sender enters a recovery period when it detects the loss of -# a packet or when the ECN-CE count reported by its peer increases. A -# sender that is already in a recovery period stays in it and does not -# reenter it. -# -# On entering a recovery period, a sender MUST set the slow start -# threshold to half the value of the congestion window when loss is -# detected. The congestion window MUST be set to the reduced value of -# the slow start threshold before exiting the recovery period. -# -# Implementations MAY reduce the congestion window immediately upon -# entering a recovery period or use other mechanisms, such as -# Proportional Rate Reduction [PRR], to reduce the congestion window -# more gradually. If the congestion window is reduced immediately, a -# single packet can be sent prior to reduction. This speeds up loss -# recovery if the data in the lost packet is retransmitted and is -# similar to TCP as described in Section 5 of [RFC6675]. -# -# The recovery period aims to limit congestion window reduction to once -# per round trip. Therefore, during a recovery period, the congestion -# window does not change in response to new losses or increases in the -# ECN-CE count. -# -# A recovery period ends and the sender enters congestion avoidance -# when a packet sent during the recovery period is acknowledged. This -# is slightly different from TCP's definition of recovery, which ends -# when the lost segment that started recovery is acknowledged -# [RFC5681]. - -[[spec]] -level = "MUST" -quote = ''' -On entering a recovery period, a sender MUST set the slow start -threshold to half the value of the congestion window when loss is -detected. -''' - -[[spec]] -level = "MUST" -quote = ''' -The congestion window MUST be set to the reduced value of -the slow start threshold before exiting the recovery period. -''' - -[[spec]] -level = "MAY" -quote = ''' -Implementations MAY reduce the congestion window immediately upon -entering a recovery period or use other mechanisms, such as -Proportional Rate Reduction [PRR], to reduce the congestion window -more gradually. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.3.3.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.3.3.toml deleted file mode 100644 index 48c24421f6..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.3.3.toml +++ /dev/null @@ -1,26 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.3.3" - -# 7.3.3. Congestion Avoidance -# -# A NewReno sender is in congestion avoidance any time the congestion -# window is at or above the slow start threshold and not in a recovery -# period. -# -# A sender in congestion avoidance uses an Additive Increase -# Multiplicative Decrease (AIMD) approach that MUST limit the increase -# to the congestion window to at most one maximum datagram size for -# each congestion window that is acknowledged. -# -# The sender exits congestion avoidance and enters a recovery period -# when a packet is lost or when the ECN-CE count reported by its peer -# increases. - -[[spec]] -level = "MUST" -quote = ''' -A sender in congestion avoidance uses an Additive Increase -Multiplicative Decrease (AIMD) approach that MUST limit the increase -to the congestion window to at most one maximum datagram size for -each congestion window that is acknowledged. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.4.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.4.toml deleted file mode 100644 index 7dc52fe272..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.4.toml +++ /dev/null @@ -1,29 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.4" - -# 7.4. Ignoring Loss of Undecryptable Packets -# -# During the handshake, some packet protection keys might not be -# available when a packet arrives, and the receiver can choose to drop -# the packet. In particular, Handshake and 0-RTT packets cannot be -# processed until the Initial packets arrive, and 1-RTT packets cannot -# be processed until the handshake completes. Endpoints MAY ignore the -# loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived -# before the peer had packet protection keys to process those packets. -# Endpoints MUST NOT ignore the loss of packets that were sent after -# the earliest acknowledged packet in a given packet number space. - -[[spec]] -level = "MAY" -quote = ''' -Endpoints MAY ignore the -loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived -before the peer had packet protection keys to process those packets. -''' - -[[spec]] -level = "MUST" -quote = ''' -Endpoints MUST NOT ignore the loss of packets that were sent after -the earliest acknowledged packet in a given packet number space. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.5.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.5.toml deleted file mode 100644 index e9c55578b7..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.5.toml +++ /dev/null @@ -1,27 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.5" - -# 7.5. Probe Timeout -# -# Probe packets MUST NOT be blocked by the congestion controller. A -# sender MUST however count these packets as being additionally in -# flight, since these packets add network load without establishing -# packet loss. Note that sending probe packets might cause the -# sender's bytes in flight to exceed the congestion window until an -# acknowledgment is received that establishes loss or delivery of -# packets. - -[[spec]] -level = "MUST" -quote = ''' -Probe packets MUST NOT be blocked by the congestion controller. -''' - -[[spec]] -level = "MUST" -quote = ''' -A -sender MUST however count these packets as being additionally in -flight, since these packets add network load without establishing -packet loss. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.6.1.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.6.1.toml deleted file mode 100644 index ee7e273eea..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.6.1.toml +++ /dev/null @@ -1,45 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.6.1" - -# 7.6.1. Duration -# -# The persistent congestion duration is computed as follows: -# -# (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) * -# kPersistentCongestionThreshold -# -# Unlike the PTO computation in Section 6.2, this duration includes the -# max_ack_delay irrespective of the packet number spaces in which -# losses are established. -# -# This duration allows a sender to send as many packets before -# establishing persistent congestion, including some in response to PTO -# expiration, as TCP does with Tail Loss Probes [RFC8985] and an RTO -# [RFC5681]. -# -# Larger values of kPersistentCongestionThreshold cause the sender to -# become less responsive to persistent congestion in the network, which -# can result in aggressive sending into a congested network. Too small -# a value can result in a sender declaring persistent congestion -# unnecessarily, resulting in reduced throughput for the sender. -# -# The RECOMMENDED value for kPersistentCongestionThreshold is 3, which -# results in behavior that is approximately equivalent to a TCP sender -# declaring an RTO after two TLPs. -# -# This design does not use consecutive PTO events to establish -# persistent congestion, since application patterns impact PTO -# expiration. For example, a sender that sends small amounts of data -# with silence periods between them restarts the PTO timer every time -# it sends, potentially preventing the PTO timer from expiring for a -# long period of time, even when no acknowledgments are being received. -# The use of a duration enables a sender to establish persistent -# congestion without depending on PTO expiration. - -[[spec]] -level = "SHOULD" -quote = ''' -The RECOMMENDED value for kPersistentCongestionThreshold is 3, which -results in behavior that is approximately equivalent to a TCP sender -declaring an RTO after two TLPs. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.6.2.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.6.2.toml deleted file mode 100644 index db4790a2be..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.6.2.toml +++ /dev/null @@ -1,82 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.6.2" - -# 7.6.2. Establishing Persistent Congestion -# -# A sender establishes persistent congestion after the receipt of an -# acknowledgment if two packets that are ack-eliciting are declared -# lost, and: -# -# * across all packet number spaces, none of the packets sent between -# the send times of these two packets are acknowledged; -# -# * the duration between the send times of these two packets exceeds -# the persistent congestion duration (Section 7.6.1); and -# -# * a prior RTT sample existed when these two packets were sent. -# -# These two packets MUST be ack-eliciting, since a receiver is required -# to acknowledge only ack-eliciting packets within its maximum -# acknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT]. -# -# The persistent congestion period SHOULD NOT start until there is at -# least one RTT sample. Before the first RTT sample, a sender arms its -# PTO timer based on the initial RTT (Section 6.2.2), which could be -# substantially larger than the actual RTT. Requiring a prior RTT -# sample prevents a sender from establishing persistent congestion with -# potentially too few probes. -# -# Since network congestion is not affected by packet number spaces, -# persistent congestion SHOULD consider packets sent across packet -# number spaces. A sender that does not have state for all packet -# number spaces or an implementation that cannot compare send times -# across packet number spaces MAY use state for just the packet number -# space that was acknowledged. This might result in erroneously -# declaring persistent congestion, but it will not lead to a failure to -# detect persistent congestion. -# -# When persistent congestion is declared, the sender's congestion -# window MUST be reduced to the minimum congestion window -# (kMinimumWindow), similar to a TCP sender's response on an RTO -# [RFC5681]. - -[[spec]] -level = "MUST" -quote = ''' -These two packets MUST be ack-eliciting, since a receiver is required -to acknowledge only ack-eliciting packets within its maximum -acknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT]. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -The persistent congestion period SHOULD NOT start until there is at -least one RTT sample. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Since network congestion is not affected by packet number spaces, -persistent congestion SHOULD consider packets sent across packet -number spaces. -''' - -[[spec]] -level = "MAY" -quote = ''' -A sender that does not have state for all packet -number spaces or an implementation that cannot compare send times -across packet number spaces MAY use state for just the packet number -space that was acknowledged. -''' - -[[spec]] -level = "MUST" -quote = ''' -When persistent congestion is declared, the sender's congestion -window MUST be reduced to the minimum congestion window -(kMinimumWindow), similar to a TCP sender's response on an RTO -[RFC5681]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.7.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.7.toml deleted file mode 100644 index 11741b66e3..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.7.toml +++ /dev/null @@ -1,84 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.7" - -# 7.7. Pacing -# -# A sender SHOULD pace sending of all in-flight packets based on input -# from the congestion controller. -# -# Sending multiple packets into the network without any delay between -# them creates a packet burst that might cause short-term congestion -# and losses. Senders MUST either use pacing or limit such bursts. -# Senders SHOULD limit bursts to the initial congestion window; see -# Section 7.2. A sender with knowledge that the network path to the -# receiver can absorb larger bursts MAY use a higher limit. -# -# An implementation should take care to architect its congestion -# controller to work well with a pacer. For instance, a pacer might -# wrap the congestion controller and control the availability of the -# congestion window, or a pacer might pace out packets handed to it by -# the congestion controller. -# -# Timely delivery of ACK frames is important for efficient loss -# recovery. To avoid delaying their delivery to the peer, packets -# containing only ACK frames SHOULD therefore not be paced. -# -# Endpoints can implement pacing as they choose. A perfectly paced -# sender spreads packets exactly evenly over time. For a window-based -# congestion controller, such as the one in this document, that rate -# can be computed by averaging the congestion window over the RTT. -# Expressed as a rate in units of bytes per time, where -# congestion_window is in bytes: -# -# rate = N * congestion_window / smoothed_rtt -# -# Or expressed as an inter-packet interval in units of time: -# -# interval = ( smoothed_rtt * packet_size / congestion_window ) / N -# -# Using a value for "N" that is small, but at least 1 (for example, -# 1.25) ensures that variations in RTT do not result in -# underutilization of the congestion window. -# -# Practical considerations, such as packetization, scheduling delays, -# and computational efficiency, can cause a sender to deviate from this -# rate over time periods that are much shorter than an RTT. -# -# One possible implementation strategy for pacing uses a leaky bucket -# algorithm, where the capacity of the "bucket" is limited to the -# maximum burst size and the rate the "bucket" fills is determined by -# the above function. - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD pace sending of all in-flight packets based on input -from the congestion controller. -''' - -[[spec]] -level = "MUST" -quote = ''' -Senders MUST either use pacing or limit such bursts. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -Senders SHOULD limit bursts to the initial congestion window; see -Section 7.2. -''' - -[[spec]] -level = "MAY" -quote = ''' -A sender with knowledge that the network path to the -receiver can absorb larger bursts MAY use a higher limit. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -To avoid delaying their delivery to the peer, packets -containing only ACK frames SHOULD therefore not be paced. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.8.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.8.toml deleted file mode 100644 index 29b36a64a1..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.8.toml +++ /dev/null @@ -1,41 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.8" - -# 7.8. Underutilizing the Congestion Window -# -# When bytes in flight is smaller than the congestion window and -# sending is not pacing limited, the congestion window is -# underutilized. This can happen due to insufficient application data -# or flow control limits. When this occurs, the congestion window -# SHOULD NOT be increased in either slow start or congestion avoidance. -# -# A sender that paces packets (see Section 7.7) might delay sending -# packets and not fully utilize the congestion window due to this -# delay. A sender SHOULD NOT consider itself application limited if it -# would have fully utilized the congestion window without pacing delay. -# -# A sender MAY implement alternative mechanisms to update its -# congestion window after periods of underutilization, such as those -# proposed for TCP in [RFC7661]. - -[[spec]] -level = "SHOULD" -quote = ''' -When this occurs, the congestion window -SHOULD NOT be increased in either slow start or congestion avoidance. -''' - -[[spec]] -level = "SHOULD" -quote = ''' -A sender SHOULD NOT consider itself application limited if it -would have fully utilized the congestion window without pacing delay. -''' - -[[spec]] -level = "MAY" -quote = ''' -A sender MAY implement alternative mechanisms to update its -congestion window after periods of underutilization, such as those -proposed for TCP in [RFC7661]. -''' - diff --git a/specs/www.rfc-editor.org/rfc/rfc9002/7.toml b/specs/www.rfc-editor.org/rfc/rfc9002/7.toml deleted file mode 100644 index ccf4ba84d8..0000000000 --- a/specs/www.rfc-editor.org/rfc/rfc9002/7.toml +++ /dev/null @@ -1,62 +0,0 @@ -target = "https://www.rfc-editor.org/rfc/rfc9002#section-7" - -# 7. Congestion Control -# -# This document specifies a sender-side congestion controller for QUIC -# similar to TCP NewReno [RFC6582]. -# -# The signals QUIC provides for congestion control are generic and are -# designed to support different sender-side algorithms. A sender can -# unilaterally choose a different algorithm to use, such as CUBIC -# [RFC8312]. -# -# If a sender uses a different controller than that specified in this -# document, the chosen controller MUST conform to the congestion -# control guidelines specified in Section 3.1 of [RFC8085]. -# -# Similar to TCP, packets containing only ACK frames do not count -# toward bytes in flight and are not congestion controlled. Unlike -# TCP, QUIC can detect the loss of these packets and MAY use that -# information to adjust the congestion controller or the rate of ACK- -# only packets being sent, but this document does not describe a -# mechanism for doing so. -# -# The congestion controller is per path, so packets sent on other paths -# do not alter the current path's congestion controller, as described -# in Section 9.4 of [QUIC-TRANSPORT]. -# -# The algorithm in this document specifies and uses the controller's -# congestion window in bytes. -# -# An endpoint MUST NOT send a packet if it would cause bytes_in_flight -# (see Appendix B.2) to be larger than the congestion window, unless -# the packet is sent on a PTO timer expiration (see Section 6.2) or -# when entering recovery (see Section 7.3.2). - -[[spec]] -level = "MUST" -quote = ''' -If a sender uses a different controller than that specified in this -document, the chosen controller MUST conform to the congestion -control guidelines specified in Section 3.1 of [RFC8085]. -''' - -[[spec]] -level = "MAY" -quote = ''' -Unlike -TCP, QUIC can detect the loss of these packets and MAY use that -information to adjust the congestion controller or the rate of ACK- -only packets being sent, but this document does not describe a -mechanism for doing so. -''' - -[[spec]] -level = "MUST" -quote = ''' -An endpoint MUST NOT send a packet if it would cause bytes_in_flight -(see Appendix B.2) to be larger than the congestion window, unless -the packet is sent on a PTO timer expiration (see Section 6.2) or -when entering recovery (see Section 7.3.2). -''' -