idnits 2.17.1 draft-boucadair-opsawg-tcpm-converter-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2019) is 1663 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) == Unused Reference: 'RFC4908' is defined on line 453, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-tcpm-converters (ref. 'I-D.ietf-tcpm-converters') -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track Orange 5 Expires: April 9, 2020 October 7, 2019 7 RADIUS Extensions for 0-RTT TCP Converters 8 draft-boucadair-opsawg-tcpm-converter-00 10 Abstract 12 Because of the lack of important TCP extensions, e.g., Multipath TCP 13 support at the server side, some service providers now consider a 14 network-assisted model that relies upon the activation of a dedicated 15 function called Transport Converters. For example, network-assisted 16 Multipath TCP deployment models are designed to facilitate the 17 adoption of Multipath TCP for the establishment of multi-path 18 communications without making any assumption about the support of 19 Multipath TCP by the remote servers. Transport Converters located in 20 the network are responsible for establishing multi-path 21 communications on behalf of endpoints, thereby taking advantage of 22 Multipath TCP capabilities to achieve different goals that include 23 (but are not limited to) optimization of resource usage (e.g., 24 bandwidth aggregation), of resiliency (e.g., primary/backup 25 communication paths), and traffic offload management. 27 This document specifies a new Remote Authentication Dial-In User 28 Service (RADIUS) attributes that carry the IP addresses that will be 29 returned to authorized users to reach one or multiple Converters. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 9, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. CONVERT RADIUS Attributes . . . . . . . . . . . . . . . . . . 4 68 3.1. CONVERT-IPv4 . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. CONVERT-IPv6 . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Sample Use Case . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 One of the promising deployment scenarios for Multipath TCP (MPTCP, 83 [RFC6824]) is to enable a host or a Customer Premises Equipment (CPE) 84 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 85 usage of such resources. A deployment scenario relies on MPTCP 86 Conversion Points (called, Transport Converters 87 [I-D.ietf-tcpm-converters]). A Converter terminates the extended TCP 88 (e.g., MPTCP, TCPinc) sessions established from a host, before 89 redirecting traffic into a legacy TCP session. Further Network- 90 Assisted MPTCP deployment and operational considerations are 91 discussed in [I-D.nam-mptcp-deployment-considerations]. 93 Figure 1 shows a deployment example of the Converters to assist 94 establishing MPTCP connections. 96 +------------+ _--------_ +----------------+ 97 | | ( LTE ) | | 98 | Host +=======+ +===+ Backbone | 99 | | (_ _) | Network | 100 | | (_______) |+--------------+| 101 | | IP Network #1 || Converter ||------> Internet 102 | | || || 103 | | |+--------------+| 104 | | IP Network #2 | | 105 | | _--------_ | | 106 | | ( DSL ) | | 107 | +=======+ +==+ | 108 | | (_ _) | | 109 +------------+ (_______) +----------------+ 111 Figure 1: "Network-Assisted" MPTCP Design 113 [I-D.ietf-tcpm-converters] specifies the Converter as a function that 114 is installed by a network operator to aid the deployment of TCP 115 extensions and to provide the benefits of such extensions to clients. 116 A Transport Converter supports one or more TCP extensions. 118 Within this document, a Converter refers to a function that 119 terminates a transport flow and relays all data received over it over 120 another transport flow. This element is located upstream in the 121 network. One or multiple Converters can be deployed in the network 122 side. The Converter achieves the following: 124 o Listen for client sessions; 126 o Receive from a client the address of the final target server; 128 o Setup a session to the final server; 130 o Relay control messages and data between the client and the server; 132 o Perform access controls according to local policies. 134 The Converter element is located in the network. One or multiple 135 Converters can be deployed. 137 This document specifies two new Remote Authentication Dial-In User 138 Service (RADIUS, [RFC2865]) attributes that carry the Converter IP 139 address list (Section 3). In order to accommodate both IPv4 and IPv6 140 deployment contexts, and given the constraints in Section 3.4 of 141 [RFC6158], two attributes are specified. Note that one or multiple 142 IPv4 and/or IPv6 addresses may be returned to a requesting CPE. A 143 sample use case is described in Section 4. 145 This document assumes that the Converter(s) reachability information 146 can be stored in Authentication, Authorization, and Accounting (AAA) 147 servers while the CPE configuration is usually provided by means of 148 DHCP ([RFC2131][RFC8415]). Further Network-Assisted MPTCP deployment 149 and operational considerations are discussed in 150 [I-D.nam-mptcp-deployment-considerations]. 152 This specification assumes a Converter is reachable through one or 153 multiple IP addresses. As such, a list of IP addresses can be 154 communicated via RADIUS. Also, it assumes the various network 155 attachments provided to an MPTCP-enabled host are managed by the same 156 administrative entity. 158 This document adheres to [RFC8044] for defining the new attributes. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119][RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 3. CONVERT RADIUS Attributes 170 3.1. CONVERT-IPv4 172 Description 174 The RADIUS CONVERT-IPv4 attribute contains the IPv4 address of a 175 Converter that is assigned to a host. 177 Because multiple Converters IP addresses may be provisioned to an 178 authorised host (that is a host entitled to solicit the resources 179 of a Converter), multiple instances of the CONVERT-IPv4 attribute 180 MAY be included; each instance of the attribute carries a distinct 181 IP address. 183 Both CONVERT-IPv4 and CONVERT-IPv6 attributes MAY be present in a 184 RADIUS message. 186 The CONVERT-IPv4 Attribute MAY appear in a RADIUS Access-Accept 187 packet. It MAY also appear in a RADIUS Access-Request packet as a 188 hint to the RADIUS server to indicate a preference, although the 189 server is not required to honor such a hint. 191 The CONVERT-IPv4 Attribute MAY appear in a CoA-Request packet. 193 The CONVERT-IPv4 Attribute MAY appear in a RADIUS Accounting- 194 Request packet. 196 The CONVERT-IPv4 Attribute MUST NOT appear in any other RADIUS 197 packet. 199 Type 201 TBA1 (see Section 7). 203 Length 205 6 207 Data Type 209 The attribute CONVERT-IPv4 is of type ip4addr (Section 3.3 of 210 [RFC8044]). 212 Value 214 This field includes an IPv4 address (32 bits) of the Converter. 216 The CONVERT-IPv4 attribute MUST NOT include multicast and host 217 loopback addresses [RFC6890]. Anycast addresses are allowed to be 218 included in a CONVERT-IPv4 attribute. 220 3.2. CONVERT-IPv6 222 Description 224 The RADIUS CONVERT-IPv6 attribute contains the IPv6 address of a 225 Converter that is assigned to a host. 227 Because multiple Converter IP addresses may be provisioned to an 228 authorised CPE (that is a host entitled to solicit the resources 229 of a Converter), multiple instances of the CONVERT-IPv6 attribute 230 MAY be included; each instance of the attribute carries a distinct 231 IP address. 233 Both CONVERT-IPv4 and CONVERT-IPv6 attributes MAY be present in a 234 RADIUS message. 236 The CONVERT-IPv6 Attribute MAY appear in a RADIUS Access-Accept 237 packet. It MAY also appear in a RADIUS Access-Request packet as a 238 hint to the RADIUS server to indicate a preference, although the 239 server is not required to honor such a hint. 241 The CONVERT-IPv6 Attribute MAY appear in a CoA-Request packet. 243 The CONVERT-IPv6 Attribute MAY appear in a RADIUS Accounting- 244 Request packet. 246 The CONVERT-IPv6 Attribute MUST NOT appear in any other RADIUS 247 packet. 249 Type 251 TBA2 (see Section 7). 253 Length 255 18 257 Data Type 259 The attribute CONVERT-IPv6 is of type ip6addr (Section 3.9 of 260 [RFC8044]). 262 Value 264 This field includes an IPv6 address (128 bits) of the Converter. 266 The CONVERT-IPv6 attribute MUST NOT include multicast and host 267 loopback addresses [RFC6890]. Anycast addresses are allowed to be 268 included in an CONVERT-IPv6 attribute. 270 4. Sample Use Case 272 This section does not aim to provide an exhaustive list of deployment 273 scenarios where the use of the RADIUS CONVERT-IPv6 and CONVERT-IPv4 274 attributes can be helpful. Typical deployment scenarios are 275 described, for instance, in [RFC6911]. 277 Figure 2 shows an example where a CPE is assigned a Converter. This 278 example assumes that the Network Access Server (NAS) embeds both 279 RADIUS client and DHCPv6 server capabilities. 281 CPE NAS AAA 282 DHCPv6 client DHCPv6 server server 283 | | | 284 |---------DHCPv6 Solicit-------->| | 285 | |----Access-Request ---->| 286 | | | 287 | |<----Access-Accept------| 288 | | CONVERT-IPv6 | 289 |<-------DHCPv6 Advertisement----| | 290 | (OPTION_V6_CONVERT) | | 291 | | | 292 |---------DHCPv6 Request-------->| | 293 | | | 294 |<---------DHCPv6 Reply----------| | 295 | (OPTION_V6_CONVERT) | | 297 DHCPv6 RADIUS 299 Figure 2: Sample Flow Example (1) 301 Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends 302 a RADIUS Access-Request message to the AAA server. Once the AAA 303 server receives the request, it replies with an Access-Accept message 304 (possibly after having sent a RADIUS Access-Challenge message and 305 assuming the CPE is entitled to connect to the network) that carries 306 a list of parameters to be used for this session, and which include 307 Converter reachability information (namely a list of IP addresses). 309 The content of the CONVERT-IPv6 attribute is then used by the NAS to 310 complete the DHCPv6 procedure that the CPE initiated to retrieve 311 information about the Converter it has been assigned. 313 Upon change of the Converter assigned to a CPE, the RADIUS server 314 sends a RADIUS CoA message [RFC5176] that carries the RADIUS CONVERT- 315 IPv6 attribute to the NAS. Once that message is accepted by the NAS, 316 it replies with a RADIUS CoA ACK message. The NAS replaces the old 317 Converter with the new one. 319 Figure 3 shows another example where a CPE is assigned a Converter, 320 but the CPE uses DHCPv6 to retrieve a list of IP addresses of a 321 Converter. 323 CPE NAS AAA 324 DHCPv4 client DHCPv4 server server 325 | | | 326 |-----------DHCPDISCOVER---------->| | 327 | |----Access-Request ---->| 328 | | | 329 | |<----Access-Accept------| 330 | | CONVERT-IPv4 | 331 |<------------DHCPOFFER------------| | 332 | (OPTION_V4_CONVERT) | | 333 | | | 334 |------------DHCPREQUEST---------->| | 335 | (OPTION_V4_CONVERT) | | 336 | | | 337 |<-----------DHCPACK---------------| | 338 | (OPTION_V4_CONVERT) | | 340 DHCPv4 RADIUS 342 Figure 3: Sample Flow Example (2) 344 Some deployments may rely on the mechanisms defined in [RFC4014] or 345 [RFC7037], which allows a NAS to pass attributes obtained from a 346 RADIUS server to a DHCP server. 348 5. Security Considerations 350 RADIUS-related security considerations are discussed in [RFC2865]. 352 Generic Convert security considerations are discussed in 353 [I-D.ietf-tcpm-converters]. 355 MPTCP-related security considerations are discussed in [RFC6824] and 356 [RFC6181]. 358 Traffic theft is a risk if an illegitimate Converter is inserted in 359 the path. Indeed, inserting an illegitimate Converter in the 360 forwarding path allows to intercept traffic and can therefore provide 361 access to sensitive data issued by or destined to a host. To 362 mitigate this threat, secure means to discover a Converter should be 363 enabled. 365 6. Table of Attributes 367 The following table provides a guide as what type of RADIUS packets 368 that may contain these attributes, and in what quantity. 370 Access- Access- Access- Challenge Acct. # Attribute 371 Request Accept Reject Request 372 0+ 0+ 0 0 0+ TBA1 CONVERT-IPv4 373 0+ 0+ 0 0 0+ TBA2 CONVERT-IPv6 375 CoA-Request CoA-ACK CoA-NACK # Attribute 376 0+ 0 0 TBA1 CONVERT-IPv4 377 0+ 0 0 TBA2 CONVERT-IPv6 379 The following table defines the meaning of the above table entries: 381 0 This attribute MUST NOT be present in packet. 382 0+ Zero or more instances of this attribute MAY be present in packet. 384 7. IANA Considerations 386 IANA is requested to assign two new RADIUS attribute types from the 387 IANA registry "Radius Attribute Types" located at 388 http://www.iana.org/assignments/radius-types: 390 CONVERT-IPv4 (TBA1) 392 CONVERT-IPv6 (TBA2) 394 8. Acknowledgements 396 Thanks to Alan DeKok for the comments. 398 9. References 400 9.1. Normative References 402 [I-D.ietf-tcpm-converters] 403 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 404 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 405 tcpm-converters-12 (work in progress), October 2019. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 413 "Remote Authentication Dial In User Service (RADIUS)", 414 RFC 2865, DOI 10.17487/RFC2865, June 2000, 415 . 417 [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", 418 BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, 419 . 421 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 422 "Special-Purpose IP Address Registries", BCP 153, 423 RFC 6890, DOI 10.17487/RFC6890, April 2013, 424 . 426 [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, 427 DOI 10.17487/RFC8044, January 2017, 428 . 430 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 431 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 432 May 2017, . 434 9.2. Informative References 436 [I-D.nam-mptcp-deployment-considerations] 437 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 438 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 439 Deployment Scenarios and Operational Considerations", 440 draft-nam-mptcp-deployment-considerations-01 (work in 441 progress), December 2016. 443 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 444 RFC 2131, DOI 10.17487/RFC2131, March 1997, 445 . 447 [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication Dial- 448 In User Service (RADIUS) Attributes Suboption for the 449 Dynamic Host Configuration Protocol (DHCP) Relay Agent 450 Information Option", RFC 4014, DOI 10.17487/RFC4014, 451 February 2005, . 453 [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, 454 R., and H. Ohnishi, "Multi-homing for small scale fixed 455 network Using Mobile IP and NEMO", RFC 4908, 456 DOI 10.17487/RFC4908, June 2007, 457 . 459 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 460 Aboba, "Dynamic Authorization Extensions to Remote 461 Authentication Dial In User Service (RADIUS)", RFC 5176, 462 DOI 10.17487/RFC5176, January 2008, 463 . 465 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 466 Multipath Operation with Multiple Addresses", RFC 6181, 467 DOI 10.17487/RFC6181, March 2011, 468 . 470 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 471 "TCP Extensions for Multipath Operation with Multiple 472 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 473 . 475 [RFC6911] Dec, W., Ed., Sarikaya, B., Zorn, G., Ed., Miles, D., and 476 B. Lourdelet, "RADIUS Attributes for IPv6 Access 477 Networks", RFC 6911, DOI 10.17487/RFC6911, April 2013, 478 . 480 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 481 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 482 2013, . 484 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 485 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 486 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 487 RFC 8415, DOI 10.17487/RFC8415, November 2018, 488 . 490 Authors' Addresses 492 Mohamed Boucadair 493 Orange 494 Rennes 35000 495 France 497 Email: mohamed.boucadair@orange.com 499 Christian Jacquenet 500 Orange 501 Rennes 502 France 504 Email: christian.jacquenet@orange.com