| Network Working Group | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Intended status: Standards Track | Orange |
| Expires: April 9, 2020 | October 7, 2019 |
RADIUS Extensions for 0-RTT TCP Converters
draft-boucadair-opsawg-tcpm-converter-00
Because of the lack of important TCP extensions, e.g., Multipath TCP support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Transport Converters. For example, network-assisted Multipath TCP deployment models are designed to facilitate the adoption of Multipath TCP for the establishment of multi-path communications without making any assumption about the support of Multipath TCP by the remote servers. Transport Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of Multipath TCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management.
This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple Converters.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 9, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
One of the promising deployment scenarios for Multipath TCP (MPTCP, [RFC6824]) is to enable a host or a Customer Premises Equipment (CPE) connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of such resources. A deployment scenario relies on MPTCP Conversion Points (called, Transport Converters [I-D.ietf-tcpm-converters]). A Converter terminates the extended TCP (e.g., MPTCP, TCPinc) sessions established from a host, before redirecting traffic into a legacy TCP session. Further Network-Assisted MPTCP deployment and operational considerations are discussed in [I-D.nam-mptcp-deployment-considerations].
Figure 1 shows a deployment example of the Converters to assist establishing MPTCP connections.
+------------+ _--------_ +----------------+ | | ( LTE ) | | | Host +=======+ +===+ Backbone | | | (_ _) | Network | | | (_______) |+--------------+| | | IP Network #1 || Converter ||------> Internet | | || || | | |+--------------+| | | IP Network #2 | | | | _--------_ | | | | ( DSL ) | | | +=======+ +==+ | | | (_ _) | | +------------+ (_______) +----------------+
Figure 1: “Network-Assisted” MPTCP Design
[I-D.ietf-tcpm-converters] specifies the Converter as a function that is installed by a network operator to aid the deployment of TCP extensions and to provide the benefits of such extensions to clients. A Transport Converter supports one or more TCP extensions.
Within this document, a Converter refers to a function that terminates a transport flow and relays all data received over it over another transport flow. This element is located upstream in the network. One or multiple Converters can be deployed in the network side. The Converter achieves the following:
The Converter element is located in the network. One or multiple Converters can be deployed.
This document specifies two new Remote Authentication Dial-In User Service (RADIUS, [RFC2865]) attributes that carry the Converter IP address list (Section 3). In order to accommodate both IPv4 and IPv6 deployment contexts, and given the constraints in Section 3.4 of [RFC6158], two attributes are specified. Note that one or multiple IPv4 and/or IPv6 addresses may be returned to a requesting CPE. A sample use case is described in Section 4.
This document assumes that the Converter(s) reachability information can be stored in Authentication, Authorization, and Accounting (AAA) servers while the CPE configuration is usually provided by means of DHCP ([RFC2131][RFC8415]). Further Network-Assisted MPTCP deployment and operational considerations are discussed in [I-D.nam-mptcp-deployment-considerations].
This specification assumes a Converter is reachable through one or multiple IP addresses. As such, a list of IP addresses can be communicated via RADIUS. Also, it assumes the various network attachments provided to an MPTCP-enabled host are managed by the same administrative entity.
This document adheres to [RFC8044] for defining the new attributes.
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.
Description
Type
Length
Data Type
Value
Description
Type
Length
Data Type
Value
This section does not aim to provide an exhaustive list of deployment scenarios where the use of the RADIUS CONVERT-IPv6 and CONVERT-IPv4 attributes can be helpful. Typical deployment scenarios are described, for instance, in [RFC6911].
Figure 2 shows an example where a CPE is assigned a Converter. This example assumes that the Network Access Server (NAS) embeds both RADIUS client and DHCPv6 server capabilities.
CPE NAS AAA
DHCPv6 client DHCPv6 server server
| | |
|---------DHCPv6 Solicit-------->| |
| |----Access-Request ---->|
| | |
| |<----Access-Accept------|
| | CONVERT-IPv6 |
|<-------DHCPv6 Advertisement----| |
| (OPTION_V6_CONVERT) | |
| | |
|---------DHCPv6 Request-------->| |
| | |
|<---------DHCPv6 Reply----------| |
| (OPTION_V6_CONVERT) | |
DHCPv6 RADIUS
Figure 2: Sample Flow Example (1)
Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends a RADIUS Access-Request message to the AAA server. Once the AAA server receives the request, it replies with an Access-Accept message (possibly after having sent a RADIUS Access-Challenge message and assuming the CPE is entitled to connect to the network) that carries a list of parameters to be used for this session, and which include Converter reachability information (namely a list of IP addresses).
The content of the CONVERT-IPv6 attribute is then used by the NAS to complete the DHCPv6 procedure that the CPE initiated to retrieve information about the Converter it has been assigned.
Upon change of the Converter assigned to a CPE, the RADIUS server sends a RADIUS CoA message [RFC5176] that carries the RADIUS CONVERT-IPv6 attribute to the NAS. Once that message is accepted by the NAS, it replies with a RADIUS CoA ACK message. The NAS replaces the old Converter with the new one.
Figure 3 shows another example where a CPE is assigned a Converter, but the CPE uses DHCPv6 to retrieve a list of IP addresses of a Converter.
CPE NAS AAA
DHCPv4 client DHCPv4 server server
| | |
|-----------DHCPDISCOVER---------->| |
| |----Access-Request ---->|
| | |
| |<----Access-Accept------|
| | CONVERT-IPv4 |
|<------------DHCPOFFER------------| |
| (OPTION_V4_CONVERT) | |
| | |
|------------DHCPREQUEST---------->| |
| (OPTION_V4_CONVERT) | |
| | |
|<-----------DHCPACK---------------| |
| (OPTION_V4_CONVERT) | |
DHCPv4 RADIUS
Figure 3: Sample Flow Example (2)
Some deployments may rely on the mechanisms defined in [RFC4014] or [RFC7037], which allows a NAS to pass attributes obtained from a RADIUS server to a DHCP server.
RADIUS-related security considerations are discussed in [RFC2865].
Generic Convert security considerations are discussed in [I-D.ietf-tcpm-converters].
MPTCP-related security considerations are discussed in [RFC6824] and [RFC6181].
Traffic theft is a risk if an illegitimate Converter is inserted in the path. Indeed, inserting an illegitimate Converter in the forwarding path allows to intercept traffic and can therefore provide access to sensitive data issued by or destined to a host. To mitigate this threat, secure means to discover a Converter should be enabled.
The following table provides a guide as what type of RADIUS packets that may contain these attributes, and in what quantity.
Access- Access- Access- Challenge Acct. # Attribute Request Accept Reject Request 0+ 0+ 0 0 0+ TBA1 CONVERT-IPv4 0+ 0+ 0 0 0+ TBA2 CONVERT-IPv6 CoA-Request CoA-ACK CoA-NACK # Attribute 0+ 0 0 TBA1 CONVERT-IPv4 0+ 0 0 TBA2 CONVERT-IPv6
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet.
The following table defines the meaning of the above table entries:
IANA is requested to assign two new RADIUS attribute types from the IANA registry "Radius Attribute Types" located at http://www.iana.org/assignments/radius-types:
Thanks to Alan DeKok for the comments.
| [I-D.ietf-tcpm-converters] | Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S. and B. Hesmans, "0-RTT TCP Convert Protocol", Internet-Draft draft-ietf-tcpm-converters-12, October 2019. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2865] | Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000. |
| [RFC6158] | DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011. |
| [RFC6890] | Cotton, M., Vegoda, L., Bonica, R. and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013. |
| [RFC8044] | DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, January 2017. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |