idnits 2.17.1 draft-boucadair-radext-tcpm-converter-01.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 18, 2018) is 2016 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-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-tcpm-converters (ref. 'I-D.ietf-tcpm-converters') -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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 21, 2019 October 18, 2018 7 RADIUS Extensions for 0-RTT TCP Converters 8 draft-boucadair-radext-tcpm-converter-01 10 Abstract 12 Because of the lack of Multipath TCP (MPTCP) support at the server 13 side, some service providers now consider a network-assisted model 14 that relies upon the activation of a dedicated function called 15 Converters. Network-assisted MPTCP deployment models are designed to 16 facilitate the adoption of MPTCP for the establishment of multi-path 17 communications without making any assumption about the support of 18 MPTCP by the communicating peers. Converters located in the network 19 are responsible for establishing multi-path communications on behalf 20 of endpoints, thereby taking advantage of MPTCP capabilities to 21 achieve different goals that include (but are not limited to) 22 optimization of resource usage (e.g., bandwidth aggregation), of 23 resiliency (e.g., primary/backup communication paths), and traffic 24 offload management. 26 This document specifies a new Remote Authentication Dial-In User 27 Service (RADIUS) attributes that carry the IP addresses that will be 28 returned to authorized users to reach one or multiple Converters. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 21, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. CONVERT RADIUS Attributes . . . . . . . . . . . . . . . . . . 4 72 2.1. CONVERT-IPv4 . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2. CONVERT-IPv6 . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Sample Use Case . . . . . . . . . . . . . . . . . . . . . . . 6 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 8 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 8.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 One of the promising deployment scenarios for Multipath TCP (MPTCP, 87 [RFC6824]) is to enable a host or a Customer Premises Equipment (CPE) 88 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 89 usage of such resources. A deployment scenario relies on MPTCP 90 Conversion Points (Converters). A Converter terminates the MPTCP 91 sessions established from a host/CPE, before redirecting traffic into 92 a legacy TCP session [RFC0793]. Further Network-Assisted MPTCP 93 deployment and operational considerations are discussed in 94 [I-D.nam-mptcp-deployment-considerations]. 96 Figure 1 shows a deployment example of the Converters to assist 97 establishing MPTCP connections. 99 +------------+ _--------_ +----------------+ 100 | | ( LTE ) | | 101 | Host +=======+ +===+ Backbone | 102 | | (_ _) | Network | 103 | | (_______) |+--------------+| 104 | | IP Network #1 || Converter ||------> Internet 105 | | || || 106 | | |+--------------+| 107 | | IP Network #2 | | 108 | | _--------_ | | 109 | | ( DSL ) | | 110 | +=======+ +==+ | 111 | | (_ _) | | 112 +------------+ (_______) +----------------+ 114 Figure 1: "Network-Assisted" MPTCP Design 116 [I-D.ietf-tcpm-converters] specifies the Converter as a function that 117 is installed by a network operator to aid the deployment of TCP 118 extensions and to provide the benefits of such extensions to clients. 119 A Transport Converter supports one or more TCP extensions. 121 Within this document, a Converter refers to a function that 122 terminates a transport flow and relays all data received over it over 123 another transport flow. This element is located upstream in the 124 network. One or multiple Converters can be deployed in the network 125 side. The Converter achieves the following: 127 o Listen for client sessions; 129 o Receive from a client the address of the final target server; 131 o Setup a session to the final server; 133 o Relay control messages and data between the client and the server; 135 o Perform access controls according to local policies. 137 The Converter element is located in the network. One or multiple 138 Converters can be deployed. 140 This document specifies two new Remote Authentication Dial-In User 141 Service (RADIUS, [RFC2865]) attributes that carry the Converter IP 142 address list (Section 2). In order to accommodate both IPv4 and IPv6 143 deployment contexts, and given the constraints in Section 3.4 of 144 [RFC6158], two attributes are specified. Note that one or multiple 145 IPv4 and/or IPv6 addresses may be returned to a requesting CPE. A 146 sample use case is described in Section 3. 148 This document assumes that the Converter(s) reachability information 149 can be stored in Authentication, Authorization, and Accounting (AAA) 150 servers while the CPE configuration is usually provided by means of 151 DHCP ([RFC2131][RFC3315]). Further Network-Assisted MPTCP deployment 152 and operational considerations are discussed in 153 [I-D.nam-mptcp-deployment-considerations]. 155 This specification assumes a Converter is reachable through one or 156 multiple IP addresses. As such, a list of IP addresses can be 157 communicated via RADIUS. Also, it assumes the various network 158 attachments provided to an MPTCP-enabled CPE are managed by the same 159 administrative entity. 161 This document adheres to [RFC8044] for defining the new attributes. 163 2. CONVERT RADIUS Attributes 165 2.1. CONVERT-IPv4 167 Description 169 The RADIUS CONVERT-IPv4 attribute contains the IPv4 address of a 170 Converter that is assigned to a CPE. 172 Because multiple Converters IP addresses may be provisioned to an 173 authorised CPE (that is a CPE entitled to solicit the resources of 174 a Converter), multiple instances of the CONVERT-IPv4 attribute MAY 175 be included; each instance of the attribute carries a distinct IP 176 address. 178 Both CONVERT-IPv4 and CONVERT-IPv6 attributes MAY be present in a 179 RADIUS message. 181 The CONVERT-IPv4 Attribute MAY appear in a RADIUS Access-Accept 182 packet. It MAY also appear in a RADIUS Access-Request packet as a 183 hint to the RADIUS server to indicate a preference, although the 184 server is not required to honor such a hint. 186 The CONVERT-IPv4 Attribute MAY appear in a CoA-Request packet. 188 The CONVERT-IPv4 Attribute MAY appear in a RADIUS Accounting- 189 Request packet. 191 The CONVERT-IPv4 Attribute MUST NOT appear in any other RADIUS 192 packet. 194 Type 196 TBA (see Section 6). 198 Length 200 6 202 Data Type 204 The attribute CONVERT-IPv4 is of type ip4addr (Section 3.3 of 205 [RFC8044]). 207 Value 209 This field includes an IPv4 address (32 bits) of the Converter. 211 The CONVERT-IPv4 attribute MUST NOT include multicast and host 212 loopback addresses [RFC6890]. Anycast addresses are allowed to be 213 included in a CONVERT-IPv4 attribute. 215 2.2. CONVERT-IPv6 217 Description 219 The RADIUS CONVERT-IPv6 attribute contains the IPv6 address of a 220 Converter that is assigned to a CPE. 222 Because multiple Converter IP addresses may be provisioned to an 223 authorised CPE (that is a CPE entitled to solicit the resources of 224 a Converter), multiple instances of the CONVERT-IPv6 attribute MAY 225 be included; each instance of the attribute carries a distinct IP 226 address. 228 Both CONVERT-IPv4 and CONVERT-IPv6 attributes MAY be present in a 229 RADIUS message. 231 The CONVERT-IPv6 Attribute MAY appear in a RADIUS Access-Accept 232 packet. It MAY also appear in a RADIUS Access-Request packet as a 233 hint to the RADIUS server to indicate a preference, although the 234 server is not required to honor such a hint. 236 The CONVERT-IPv6 Attribute MAY appear in a CoA-Request packet. 238 The CONVERT-IPv6 Attribute MAY appear in a RADIUS Accounting- 239 Request packet. 241 The CONVERT-IPv6 Attribute MUST NOT appear in any other RADIUS 242 packet. 244 Type 246 TBA (see Section 6). 248 Length 250 18 252 Data Type 254 The attribute CONVERT-IPv6 is of type ip6addr (Section 3.9 of 255 [RFC8044]). 257 Value 259 This field includes an IPv6 address (128 bits) of the Converter. 261 The CONVERT-IPv6 attribute MUST NOT include multicast and host 262 loopback addresses [RFC6890]. Anycast addresses are allowed to be 263 included in an CONVERT-IPv6 attribute. 265 3. Sample Use Case 267 This section does not aim to provide an exhaustive list of deployment 268 scenarios where the use of the RADIUS CONVERT-IPv6 and CONVERT-IPv4 269 attributes can be helpful. Typical deployment scenarios are 270 described, for instance, in [RFC6911]. 272 Figure 2 shows an example where a CPE is assigned a Converter. This 273 example assumes that the Network Access Server (NAS) embeds both 274 RADIUS client and DHCPv6 server capabilities. 276 CPE NAS AAA 277 DHCPv6 client DHCPv6 server server 278 | | | 279 |---------DHCPv6 Solicit-------->| | 280 | |----Access-Request ---->| 281 | | | 282 | |<----Access-Accept------| 283 | | CONVERT-IPv6 | 284 |<-------DHCPv6 Advertisement----| | 285 | (OPTION_V6_CONVERT) | | 286 | | | 287 |---------DHCPv6 Request-------->| | 288 | | | 289 |<---------DHCPv6 Reply----------| | 290 | (OPTION_V6_CONVERT) | | 292 DHCPv6 RADIUS 294 Figure 2: Sample Flow Example (1) 296 Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends 297 a RADIUS Access-Request message to the AAA server. Once the AAA 298 server receives the request, it replies with an Access-Accept message 299 (possibly after having sent a RADIUS Access-Challenge message and 300 assuming the CPE is entitled to connect to the network) that carries 301 a list of parameters to be used for this session, and which include 302 Converter reachability information (namely a list of IP addresses). 304 The content of the CONVERT-IPv6 attribute is then used by the NAS to 305 complete the DHCPv6 procedure that the CPE initiated to retrieve 306 information about the Converter it has been assigned. 308 Upon change of the Converter assigned to a CPE, the RADIUS server 309 sends a RADIUS CoA message [RFC5176] that carries the RADIUS CONVERT- 310 IPv6 attribute to the NAS. Once that message is accepted by the NAS, 311 it replies with a RADIUS CoA ACK message. The NAS replaces the old 312 Converter with the new one. 314 Figure 3 shows another example where a CPE is assigned a Converter, 315 but the CPE uses DHCPv6 to retrieve a list of IP addresses of a 316 Converter. 318 CPE NAS AAA 319 DHCPv4 client DHCPv4 server server 320 | | | 321 |-----------DHCPDISCOVER---------->| | 322 | |----Access-Request ---->| 323 | | | 324 | |<----Access-Accept------| 325 | | CONVERT-IPv4 | 326 |<------------DHCPOFFER------------| | 327 | (OPTION_V4_CONVERT) | | 328 | | | 329 |------------DHCPREQUEST---------->| | 330 | (OPTION_V4_CONVERT) | | 331 | | | 332 |<-----------DHCPACK---------------| | 333 | (OPTION_V4_CONVERT) | | 335 DHCPv4 RADIUS 337 Figure 3: Sample Flow Example (2) 339 Some deployments may rely on the mechanisms defined in [RFC4014] or 340 [RFC7037], which allows a NAS to pass attributes obtained from a 341 RADIUS server to a DHCP server. 343 4. Security Considerations 345 RADIUS-related security considerations are discussed in [RFC2865]. 347 Generic Convert security considerations are discussed in 348 [I-D.ietf-tcpm-converters]. 350 MPTCP-related security considerations are discussed in [RFC6824] and 351 [RFC6181]. 353 Traffic theft is a risk if an illegitimate Converter is inserted in 354 the path. Indeed, inserting an illegitimate Converter in the 355 forwarding path allows to intercept traffic and can therefore provide 356 access to sensitive data issued by or destined to a host. To 357 mitigate this threat, secure means to discover a Converter should be 358 enabled. 360 5. Table of Attributes 362 The following table provides a guide as what type of RADIUS packets 363 that may contain these attributes, and in what quantity. 365 Access- Access- Access- Challenge Acct. # Attribute 366 Request Accept Reject Request 367 0+ 0+ 0 0 0+ TBA CONVERT-IPv4 368 0+ 0+ 0 0 0+ TBA CONVERT-IPv6 370 CoA-Request CoA-ACK CoA-NACK # Attribute 371 0+ 0 0 TBA CONVERT-IPv4 372 0+ 0 0 TBA CONVERT-IPv6 374 The following table defines the meaning of the above table entries: 376 0 This attribute MUST NOT be present in packet. 377 0+ Zero or more instances of this attribute MAY be present in packet. 379 6. IANA Considerations 381 IANA is requested to assign two new RADIUS attribute types from the 382 IANA registry "Radius Attribute Types" located at 383 http://www.iana.org/assignments/radius-types: 385 CONVERT-IPv4 (TBA) 387 CONVERT-IPv6 (TBA) 389 7. Acknowledgements 391 Thanks to Alan DeKok for the comments. 393 8. References 395 8.1. Normative References 397 [I-D.ietf-tcpm-converters] 398 Bonaventure, O., Boucadair, M., Gundavelli, S., and S. 399 Seo, "0-RTT TCP Convert Protocol", draft-ietf-tcpm- 400 converters-02 (work in progress), July 2018. 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 408 "Remote Authentication Dial In User Service (RADIUS)", 409 RFC 2865, DOI 10.17487/RFC2865, June 2000, 410 . 412 [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", 413 BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, 414 . 416 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 417 "Special-Purpose IP Address Registries", BCP 153, 418 RFC 6890, DOI 10.17487/RFC6890, April 2013, 419 . 421 [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, 422 DOI 10.17487/RFC8044, January 2017, 423 . 425 8.2. Informative References 427 [I-D.nam-mptcp-deployment-considerations] 428 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 429 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 430 Deployment Scenarios and Operational Considerations", 431 draft-nam-mptcp-deployment-considerations-01 (work in 432 progress), December 2016. 434 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 435 RFC 793, DOI 10.17487/RFC0793, September 1981, 436 . 438 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 439 RFC 2131, DOI 10.17487/RFC2131, March 1997, 440 . 442 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 443 C., and M. Carney, "Dynamic Host Configuration Protocol 444 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 445 2003, . 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 Authors' Addresses 486 Mohamed Boucadair 487 Orange 488 Rennes 35000 489 France 491 Email: mohamed.boucadair@orange.com 493 Christian Jacquenet 494 Orange 495 Rennes 496 France 498 Email: christian.jacquenet@orange.com