idnits 2.17.1 draft-cms-masque-connect-ip-ext-routes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 August 2021) is 972 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-03 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE A. Chernyakhovsky 3 Internet-Draft D. McCall 4 Intended status: Standards Track D. Schinazi 5 Expires: 28 February 2022 Google LLC 6 27 August 2021 8 A Routing Extension to CONNECT-IP 9 draft-cms-masque-connect-ip-ext-routes-00 11 Abstract 13 This document describes an extension to the CONNECT-IP HTTP method. 14 This extension allows both endpoints to negotiate routes. This 15 enables split-tunnel VPN services, and network-to-network VPNs. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the Multiplexed 22 Application Substrate over QUIC Encryption Working Group mailing list 23 (masque@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/masque/. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 28 February 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 61 2. Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. ROUTE_ADVERTISEMENT Capsule . . . . . . . . . . . . . . . 3 64 3.2. ROUTE_REJECTION Capsule . . . . . . . . . . . . . . . . . 4 65 3.3. ROUTE_RESET Capsule . . . . . . . . . . . . . . . . . . . 5 66 3.4. ATOMIC_START Capsule . . . . . . . . . . . . . . . . . . 5 67 3.5. ATOMIC_END Capsule . . . . . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Capsule Type Registrations . . . . . . . . . . . . . . . 6 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 6.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 75 A.1. Consumer VPN . . . . . . . . . . . . . . . . . . . . . . 8 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 This document describes an extension to the CONNECT-IP HTTP method 82 [CONNECT-IP]. This extension allows both endpoints to negotiate 83 routes. This enables split-tunnel VPN services, and network-to- 84 network VPNs. 86 CONNECT-IP allows endpoints to set up an IP tunnel between one 87 another but does not allow exchanging which routes are supported 88 though the tunnel. This extension can be used to connect an endpoint 89 or network to another network without changing default routes. 91 1.1. Conventions and Definitions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 In this document, we use the term "proxy" to refer to the HTTP server 100 that responds to the CONNECT-IP request. If there are HTTP 101 intermediaries (as defined in Section 2.3 of [RFC7230]) between the 102 client and the proxy, those are referred to as "intermediaries" in 103 this document. 105 2. Routes 107 Endpoints have the ability to advertise and reject routes using the 108 ROUTE_ADVERTISEMENT (Section 3.1) and ROUTE_REJECTION (Section 3.1) 109 capsule. Note that these capsules are purely informational: receipt 110 of a ROUTE_ADVERTISEMENT capsule does not require the recipient to 111 start routing traffic to its peer. Additionally, if an endpoint 112 receives a ROUTE_REJECTION for a given prefix that it had previously 113 received a ROUTE_ADVERTISEMENT capsule for, then the two cancel out 114 and the endpoint MUST remove its state from the ROUTE_ADVERTISEMENT 115 capsule instead of installing new state for the ROUTE_REJECTION 116 capsule. Conversely, the same is true of a ROUTE_ADVERTISEMENT that 117 matches a previous ROUTE_REJECTION. Routes are handled via longest- 118 prefix-first preference, meaning that if a given IP prefix is covered 119 by multiple route advertisement and route rejections, the one with 120 the longest prefix is used. 122 When processing ROUTE_ADVERTISEMENT capsules, endpoints MUST check 123 their local policy before deciding whether to forward packets to 124 their peer. Since ignoring these capsules is allowed by the 125 protocol, such policy decisions will not prevent interoperability. 127 3. Capsules 129 3.1. ROUTE_ADVERTISEMENT Capsule 131 The ROUTE_ADVERTISEMENT capsule allows an endpoint to communicate to 132 its peer that it is willing to route traffic to a given prefix. This 133 indicates that the sender has an existing route to the prefix, and 134 notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT 135 capsule sends IP packets for this prefix in HTTP Datagrams, the 136 sender of the capsule will forward them along its preexisting route. 137 This capsule uses a Capsule Type of 0xfff102. Its value uses the 138 following format: 140 ROUTE_ADVERTISEMENT Capsule { 141 IP Version (8), 142 IP Address (32..128), 143 IP Prefix Length (8), 144 } 146 Figure 1: ROUTE_ADVERTISEMENT Capsule Format 148 IP Version: IP Version of this route advertisement. MUST be either 149 4 or 6. 151 IP Address: IP address of the advertised route. If the IP Version 152 field has value 4, the IP Address field SHALL have a length of 32 153 bits. If the IP Version field has value 6, the IP Address field 154 SHALL have a length of 128 bits. 156 IP Prefix Length: Length of the IP Prefix of the advertised route, 157 in bits. MUST be lesser or equal to the length of the IP Address 158 field, in bits. 160 Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start 161 routing IP packets in that prefix to its peer. 163 3.2. ROUTE_REJECTION Capsule 165 The ROUTE_REJECTION capsule allows an endpoint to communicate to its 166 peer that it is not willing to route traffic to a given prefix. This 167 capsule uses a Capsule Type of 0xfff103. Its value uses the 168 following format: 170 ROUTE_REJECTION Capsule { 171 IP Version (8), 172 IP Address (32..128), 173 IP Prefix Length (8), 174 } 176 Figure 2: ROUTE_REJECTION Capsule Format 178 IP Version: IP Version of this route rejection. MUST be either 4 or 179 6. 181 IP Address: IP address of the rejected route. If the IP Version 182 field has value 4, the IP Address field SHALL have a length of 32 183 bits. If the IP Version field has value 6, the IP Address field 184 SHALL have a length of 128 bits. 186 IP Prefix Length: Length of the IP Prefix of the advertised route, 187 in bits. MUST be lesser or equal to the length of the IP Address 188 field, in bits. 190 Upon receiving the ROUTE_REJECTION capsule, an endpoint MUST stop 191 routing IP packets in that prefix to its peer. Note that this 192 capsule can be reordered with DATAGRAM frames, and therefore an 193 endpoint that receives packets for routes it has rejected MUST NOT 194 treat that as an error. 196 3.3. ROUTE_RESET Capsule 198 The ROUTE_RESET capsule allows an endpoint to cancel any routes it 199 had previously advertised or denied. This capsule uses a Capsule 200 Type of 0xfff104. Its value uses the following format: 202 ROUTE_RESET Capsule { 203 } 205 Figure 3: ROUTE_RESET Capsule Format 207 Upon receiving the ROUTE_RESET capsule, an endpoint MUST stop routing 208 IP packets to its peer. Note that this capsule can be reordered with 209 DATAGRAM frames, and therefore an endpoint that receives packets for 210 routes it has rejected MUST NOT treat that as an error. 212 The main purpose of the ROUTE_RESET capsule is to allow endpoints to 213 not have to remember the full list of routes they have shared with 214 their peer. In practice, it is expected that ROUTE_RESET capsules 215 will be closely followed by ROUTE_ADVERTISEMENT capsules that will 216 refill the routing table that was just cleared. 218 3.4. ATOMIC_START Capsule 220 The ATOMIC_START capsule allows an endpoint to create an atomic set 221 of capsules. This capsule uses a Capsule Type of 0xfff106. Its 222 value uses the following format: 224 ATOMIC_START Capsule { 225 } 227 Figure 4: ATOMIC_START Capsule Format 229 Upon receiving an ATOMIC_START capsule, an endpoint MUST buffer all 230 incoming known CONNECT-IP-specific capsules (i.e., capsules defined 231 in this document) until it receives an ATOMIC_END capsule. Endpoints 232 MUST NOT send two ATOMIC_START capsules without an ATOMIC_END capsule 233 between them. 235 Endpoints MUST NOT buffer unknown capsules. Endpoints MAY choose to 236 immediately process IP_PACKET and SHUTDOWN capsules instead of 237 buffering them. Capsules defined in other documents are by default 238 not buffered by ATOMIC_START. Extensions that register new capsule 239 types MAY specify that these capsules should be buffered by 240 ATOMIC_START, and whether it is allowed to skip buffering for them. 242 The purpose of this frame is to avoid timing issues where an endpoint 243 installs a route before an important route rejection was received. 244 Endpoints SHOULD group their initial configuration into an atomic 245 block to allow their peer to mark the tunnel as operational once the 246 whole block is parsed. 248 3.5. ATOMIC_END Capsule 250 The ATOMIC_END capsule allows an endpoint to end an atomic set of 251 capsules. This capsule uses a Capsule Type of 0xfff107. Its value 252 uses the following format: 254 ATOMIC_END Capsule { 255 } 257 Figure 5: ATOMIC_END Capsule Format 259 Upon receiving an ATOMIC_END capsule, an endpoint MUST parse all 260 previously buffered capsules, in order of receipt. Endpoints MUST 261 NOT send an ATOMIC_END capsule without a preceding ATOMIC_START 262 capsule. 264 4. Security Considerations 266 In theory, endpoints could use ROUTE_ADVERTISEMENT capsules to divert 267 traffic from naive endpoints. To avoid this, receivers of 268 ROUTE_ADVERTISEMENT capsules MUST check their local policy before 269 acting on such capsules, see Section 2. 271 5. IANA Considerations 273 5.1. Capsule Type Registrations 275 This document will request IANA to add the following values to the 276 "HTTP Capsule Types" registry created by [HTTP-DGRAM]: 278 +----------+---------------------+---------------------+---------------+ 279 | Value | Type | Description | Reference | 280 +----------+---------------------+---------------------+---------------+ 281 | 0xfff102 | ROUTE_ADVERTISEMENT | Route Advertisement | This document | 282 | 0xfff103 | ROUTE_REJECTION | Route Rejection | This document | 283 | 0xfff104 | ROUTE_RESET | Route Reset | This document | 284 | 0xfff106 | ATOMIC_START | Atomic Start | This document | 285 | 0xfff107 | ATOMIC_END | Atomic End | This document | 286 +----------+---------------------+---------------------+---------------+ 288 6. References 290 6.1. Normative References 292 [HTTP-DGRAM] 293 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 294 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 295 datagram-03, 12 July 2021, 296 . 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 305 Protocol (HTTP/1.1): Message Syntax and Routing", 306 RFC 7230, DOI 10.17487/RFC7230, June 2014, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 6.2. Informative References 315 [CONNECT-IP] 316 Chernyakhovsky, A., McCall, D., and D. Schinazi, "The 317 CONNECT-IP HTTP Method", Work in Progress, Internet-Draft, 318 draft-cms-masque-connect-ip-02, 27 August 2021, 319 . 322 [REQS] Chernyakhovsky, A., McCall, D., and D. Schinazi, 323 "Requirements for a MASQUE Protocol to Proxy IP Traffic", 324 Work in Progress, Internet-Draft, draft-ietf-masque-ip- 325 proxy-reqs-03, 27 August 2021, 326 . 329 Appendix A. Examples 331 A.1. Consumer VPN 333 In this scenario, the client will typically receive a single IP 334 address that the proxy has picked from a pool of addresses it 335 maintains. The client will route all traffic through the tunnel. 336 The exchange could look as follows: 338 Client Server 340 ADDRESS_REQUEST --------> 341 IP Version = 4 342 IP Address = 0.0.0.0 343 IP Prefix Length = 0 345 <-------- ADDRESS_ASSIGN 346 IP Version = 4 347 IP Address = 192.0.2.42 348 IP Prefix Length = 32 350 <-------- ROUTE_ADVERTISEMENT 351 IP Version = 4 352 IP Address = 0.0.0.0 353 IP Prefix Length = 0 355 Acknowledgments 357 The design of CONNECT-IP was inspired by discussions in the MASQUE 358 working group around [REQS]. The authors would like to thank 359 participants in those discussions for their feedback. 361 Authors' Addresses 363 Alex Chernyakhovsky 364 Google LLC 365 1600 Amphitheatre Parkway 366 Mountain View, California 94043, 367 United States of America 369 Email: achernya@google.com 370 Dallas McCall 371 Google LLC 372 1600 Amphitheatre Parkway 373 Mountain View, California 94043, 374 United States of America 376 Email: dallasmccall@google.com 378 David Schinazi 379 Google LLC 380 1600 Amphitheatre Parkway 381 Mountain View, California 94043, 382 United States of America 384 Email: dschinazi.ietf@gmail.com