| pcp | R. Maglione |
| Internet-Draft | Telecom Italia |
| Intended status: Standards Track | D. Cheng |
| Expires: June 01, 2012 | Huawei Technologies |
| December 2011 |
RADIUS Extensions for Port Control Protocol
draft-maglione-pcp-radius-ext-03
This memo proposes a new Remote Authentication Dial In User Service (RADIUS) attribute to carry the Fully Qualified Domain Name (FQDN) of a Port Control Protocol (PCP) server, such that while the PCP server information is configured on a RADIUS server, the information can be conveyed to Network Access Server (NAS) via RADIUS protocol, and the co-located Dynamic Host Configuration Protocol (DHCP/DHCPv6) server can then populate the information to PCP client.
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 http://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 June 01, 2012.
Copyright (c) 2011 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 (http://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.
Port Control Protocol (PCP) [I-D.ietf-pcp-base] provides a mechanism to control how incoming packets are forwarded by upstream devices such as NATs and firewalls. PCP is a client-server protocol where a PCP client may reside on a host, a Customer Premises Equipment (CPE), etc., which communicates with a PCP server that may reside anywhere in a network.
A PCP client must know the Fully Qualified Domain Name (FQDN) of a PCP server, before it can communicate with the later in order to perform the relevant PCP functions.
[I-D.ietf-pcp-dhcp] defines DHCPv6 and DHCP options which are meant to be used by a PCP client to discover a PCP server name. However, provisioning for name of the PCP server is required on a DHCP/DHCPv6 server before it can populate these information.
Auto-configuration on a DHCP/DHCPv6 is possible in a broadband network, where typically, user profile is maintained on a Remote Authentication Dial In User Service (RADIUS) server and RADIUS protocol [RFC2865] is used to convey user related information to other network elements including a host and CPE. [I-D.ietf-radext-ipv6-access] describes a typical broadband network scenario in which the Network Access Server (NAS) acts as the access gateway for the users (hosts or CPEs) and the NAS embeds a DHCPv6 Server function that allows it to locally handle any DHCPv6 requests issued by the clients.
In such environment, PCP server’s name can be configured on a RADIUS server, which then passes the information to a NAS that co-locates with the DHCP/DHCPv6 server, which in turn populates the location of the PCP server.
This memo defines a new RADIUS attribute that can be used to carry the FQDN of a PCP server.
The approach described above is already used for providing the FQDN of the AFTR in the DS-Lite scenario and the equivalent RADIUS attribute for the DS-Lite Tunnel Name is defined [I-D.ietf-softwire-dslite-radius-ext].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The following terms are defined in [I-D.ietf-pcp-base]:
Figure 1 illustrates how RADIUS protocol works together with DHCPv6, to allow a host to learn automatically the FQDN of a PCP server in case of a PPP session that carries IPv6 traffic.
The Network Access Server (NAS) operates as a client of RADIUS and co-locates with a DHCPv6 Server for DHCPv6 protocol. The NAS initially sends a RADIUS Access Request message to the RADIUS server, requesting authentication. Once the RADIUS server receives the request, it validates the sending client and if the request is approved, the RADIUS server replies with an Access Accept message including a list of attribute-value pairs that describe the parameters to be used for this session. This list MAY also contain the name of a PCP server. When the co-located DHCPv6 server receives a DHCPv6 message containing the PCP Server Option, it SHALL use the name returned in the RADIUS attribute as defined in this memo to populate the DHCPv6 PCP Server option defined in [I-D.ietf-pcp-dhcp]
PCP/DHCPv6 NAS AAA
Client DHCPv6 Server Server
| | |
|----PPP LCP Config Request------> | |
| | |
| |----Access-Request ---->|
| | |
| |<-Access-Accept---------|
| | (PCP-server-name) |
|<-----PPP LCP Config ACK ----- | |
| | |
| | |
|------ PPP IPV6CP Config Req ---->| |
| | |
|<----- PPP IPV6CP Config ACK -----| |
| | |
|------- DHCPv6 Solicit -------->| |
| | |
|<-------DHCPv6 Advertisement------| |
| (PCP server FQDN DHCPv6 Option) | |
| | |
|------- DHCPv6 Request -------->| |
| (PCP server FQDN DHCPv6 Option) | |
| | |
|<-------- DHCPv6 Reply --------- | |
| (PCP server FQDN DHCPv6 Option) | |
| | |
DHCPv6 RADIUS
The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work together to accomplish PCP client configuration when DHCPv6 is used to provide connectivity to the user.
The difference between this message flow and previous one is that in this scenario the interaction between NAS and AAA/ RADIUS Server is triggered by the DHCPv6 Solicit message received by the NAS from the B4 acting as DHCPv6 client, while in case of a PPP Session the trigger is the PPP LCP Config Request message received by the NAS.
PCP/DHCPv6 NAS AAA
Client DHCPv6 Server Server
| | |
|------ DHCPv6 Solicit ---------> | |
| | |
| |----Access-Request ---->|
| | |
| |<-Access-Accept---------|
| | (PCP-server-name) |
| | |
|<-------DHCPv6 Advertisement------| |
| (PCP server FQDN DHCPv6 Option) | |
| | |
|------- DHCPv6 Request -------->| |
| (PCP server FQDN DHCPv6 Option) | |
| | |
| <-------- DHCPv6 Reply --------- | |
| (PCP server FQDN DHCPv6 Option) | |
DHCPv6 RADIUS
In the scenario depicted in Figure 2 the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17), thus according to [RFC5080] the Access-Request packet MUST contain a State attribute.
A similar message flow also applies to the IPv4 scenario when DHCPv4 is used to provide connectivity to the user (Figure 3).
PCP/DHCP NAS AAA
Client DHCP Server Server
| | |
|-------- DHCP Discovery --------> | |
| | |
| |----Access-Request ---->|
| | |
| |<-Access-Accept---------|
| | (PCP-server-name) |
| | |
|<--------- DHCP Offer ------------| |
| (PCP server FQDN Sub-Option) | |
| | |
|--------- DHCP Request -------->| |
| (PCP server FQDN Sub-Option) | |
| | |
| <--------- DHCP Ack -------------| |
| (PCP server FQDN Sub-Option) | |
DHCPv4 RADIUS
After receiving the PCP server name in the initial Access-Accept the NAS MUST store the received PCP Server Name locally. When the PCP Client sends a DHCP message to request an extension of the lifetimes for the assigned address or prefix, the NAS does not have to initiate a new Access-Request towards the AAA server to request the PCP server name. The NAS retrieves the previously stored PCP Server name and uses it in its reply.
If the DHCP server to which the DHCP Renew message was sent at time T1 has not responded, the DHCP client initiates a Rebind/Reply exchange with any available server. In this scenario the NAS MUST initiate a new Access-Request towards the AAA server, after the co-located DHCP server receives the DHCP message. The NAS MAY include the PCP Server Name attribute in its Access-Request.
If the NAS does not receive the PCP server name attribute in the Access-Accept it MAY fallback to a pre-configured default tunnel name, if any. If the NAS does not have any pre-configured default tunnel name or if the NAS receives an Access-Reject, the PCP client can not be configured by the NAS.
The scenario with PPP Session and IPv4 only connectivity does not require the DHCP protocol: the whole configuration of the client is performed by PPP. This case is out of scope of this document because in order to complete the configuration of the PCP client a new PPP IPC option would be required.
A new RADIUS attribute, called PCP-Server-Name, along with its format is defined below.
Description
The PCP-server-name attribute contains a Fully Qualified Domain Name (FQDN) that refers to a PCP server the client requests to establish a connection to for PCP related service. The NAS shall use the name returned in the RADIUS PCP-server-name attribute to populate the PCP Server FQDN DHCP Sub-Option in IPv4 addressing context, or the PCP Server FQDN DHCPv6 Option in IPv6 addressing context, as determined by the DHCP server [I-D.ietf-pcp-dhcp]
The PCP-server-name attribute MAY appear in an Access-Accept packet. This attribute MAY be used in Access-Request packets as a hint to the RADIUS server; for example if the NAS is pre-configured with a default PCP server name, this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a different PCP Server name. If the NAS includes the PCP Server Name attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA Server. If the NAS does not receive PCP Server Name attribute in the Access-Accept it MAY fallback to a pre-configured default PCP server name, if any. If the NAS is pre-provisioned with a default PCP server name and the PCP server name received in Access-Accept is different from the configured default, then the PCP server name received in the Access- Accept message MUST be used for the session.
The PCP server Name RADIUS attribute MAY be present in Accounting-Request records where the Acct-Status-Type is set to Start, Stop or Interim-Update. The PCP Server Name RADIUS attribute MUST NOT appear more than once in a message.
A summary of the PCP-Server-Name RADIUS attribute format is shown below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | PCP-Server-Name (FQDN) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Length:
PCP-Server-Name:
The data type of PCP Server Name is a string with opaque encapsulation, according to section 2.1 of [RFC6158]
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
| Request | Accept | Reject | Challenge | Accounting Request | # | Attribute |
|---|---|---|---|---|---|---|
| 0-1 | 0-1 | 0 | 0 | 0-1 | TBA1 | PCP-Server-Name |
The following table defines the meaning of the above table entries.
| 0 | This attribute MUST NOT be present in packet. |
| 0+ | Zero or more instances of this attribute MAY be present in packet. |
| 0-1 | Zero or one instance of this attribute MAY be present in packet. |
This document has no additional security considerations beyond those already identified in [RFC2865].
This document requests the allocation of a new Radius attribute types from the IANA registry "Radius Attribute Types" located at http://www.iana.org/assignments/radius-types
The authors would like to thank Mohamed Boucadair and Mario Ullio for their valuable comments.
| [I-D.ietf-radext-ipv6-access] | Lourdelet, B, Dec, W, Sarikaya, B, Zorn, G and D Miles, "RADIUS attributes for IPv6 Access Networks", Internet-Draft draft-ietf-radext-ipv6-access-06, November 2011. |