| sfc | R. Maglione |
| Internet-Draft | G. Trueba |
| Intended status: Standards Track | C. Pignataro |
| Expires: May 4, 2017 | Cisco Systems |
| October 31, 2016 |
RADIUS Attributes for NSH
draft-maglione-sfc-nsh-radius-01
Network Service Header (NSH) protocol defines the Service Function Chaining (SFC) encapsulation required to support the Service Function Chaining (SFC) Architecture. One of the components of the Network Service Header (NSH) protocol is the Service Path Identifier (SPI), which identifies a service path, another important element of the NSH protocol is the Service Index (SI), which provides location within the Service Path.
When Service Providers would like to deliver customized services offers requiring Service Functions Chains, a different service chain may be required for each subscriber or group of subscribers. In order to simplify the service provisioning in this scenario, it would be useful to be able to associate the Service Path Identifier (SPI), identifying the service chain, and the appropriate Service Index (SI), identifying the location in the service path, with the customer profile.
In some Broadband networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers. This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes to carry the Service Path Identifier (SPI) and the Service Index (SI).
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 May 4, 2017.
Copyright (c) 2016 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.
Network Service Header (NSH) protocol [I-D.ietf-sfc-nsh] defines the Service Function Chaining (SFC) encapsulation required to support the Service Function Chaining (SFC) Architecture [RFC7665]. One of the components of the Network Service Header (NSH) protocol is the Service Path Identifier (SPI), which identifies a service path, another important element of the NSH protocol is the Service Index (SI), which provides location within the Service Path.
When Service Providers would like to deliver customized services offers requiring Service Functions Chains, a different service chain may be required for each subscriber or group of subscribers. In order to simplify the service provisioning in this scenario, it would be useful to be able to associate the Service Path Identifier (SPI), identifying the service chain, and the appropriate Service Index (SI) identifying the location in the service path, with the customer profile.
In some Broadband networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers. This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes to carry the Service Path Identifier (SPI) and the Service Index (SI).
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].
Figure 1 illustrates the network reference model for a Broadband access scenario where a NAS, acting as RADIUS Client, performs both the Service Classification and Service Forwarder Function.
The Service Functions which make up the Service Chaining are part of the SP network and they are not depicted in Figure 1
+-----+
| AAA |
| | ,--------.
+--+--+ / \
^ | Internet |
. | Access |
RADIUS . / \ /
. / '--------'
. /
v / ,------.
+------+ +---+---+ / \
+------+ | | | NAS | / \
| RG/ +-------| AN +-----+-------+ SCF |----( SP )
| host | | | | SFF | \ Network /
+------+ +------+ (Ethernet) +-------+ \ /
. . ?------?
. PPPoE or IPoE Session .
. <-------------------------------> .
Figure 1: Network Reference Model
Here there is a brief description of the Authentication/Authorization process between the NAS and the AAA Server.
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 AAA 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 NSH Service Path Identifier (NSH-SPI) and the NSH Service Index (NSH-SI) attributes used to identify a specific service path and the location in the service path.
The NSH SPI attribute returned by AAA Server in the Access-Accept is used by the NAS to insert the traffic of the subscriber in the correct service path. A classification rule, to be associated with the SPI, can also be sent by the AAA Server as part of the list of attribute-value pairs.
This section defines the NSH Service Path Identifier (SPI) and the NSH Service Index (SI) attributes that are used in the above-mentioned scenario. The attributes design follows [RFC6158] and refers to [RFC6929] and [I-D.ietf-radext-datatypes].
The NSH Service Path Identifier (NSH-SPI) RADIUS attribute contains the value which identifies a specific service path to be associated to a subscriber.
When the NAS receives from the AAA Server the NSH-SPI attribute, the NAS MUST use the value contained in this attribute to populate the Service Path Identifier (SPI) field in the NSH Service Path header defined in [I-D.ietf-sfc-nsh].
If the NAS is pre-configured with a default NSH SPI value, this value MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different NSH SPI.
If the NAS includes the NSH-SPI attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server. If the NAS does not receive the NSH-SPI attribute in the Access-Accept message, it MAY fall back to a pre-configured default NSH SPI, if any. If the NAS receives the NSH-SI attribute, but it does not receives the NSH-SPI attribute from the AAA Server and the NAS does not have any pre-configured SPI, the traffic generated by that specific subscriber MUST be dropped as this is an error condition. If the NAS does not receive the NSH-SPI attribute and it does not receive the NSH-SI attribute in the Access-Accept message and the NAS does not have any pre-configured NSH SPI and NSH SI, the traffic generated by that specific subscriber does not have to be sent across any service chain.
If the NAS is pre-provisioned with a default NSH SPI and the NSH-SPI received in the Access-Accept message is different from the configured default, then the NSH-SPI received in the Access-Accept message MUST be used for the session.
If an implementation includes Change-of-Authorization (CoA) messages [RFC5176], they could be used to modify the current specified SPI. When the NAS receives a CoA Request message containing the NSH-SPI attribute, the NAS MUST use the received NSH SPI value to re-configure the the Service Path Identifier (SPI) field in the NSH Service Path header. This allows the network administrator to modify the forwarding of the traffic of a specific subscriber. By changing the SPI value the service path used for the subscriber is modified, thus the traffic of the selected subscriber is sent across a different service chain.
The NSH-SPI RADIUS attribute MUST NOT appear more than once in a message.
A summary of the NSH-SPI 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NSH-SPI RADIUS Attribute
The NSH Service Index (NSH-SI) RADIUS attribute contains the value which identifies the location in the service path. According to [I-D.ietf-sfc-nsh] , the initial SI value SHOULD default to 255.
When the NAS receives from the AAA Server the NSH-SI attribute, the NAS MUST use the value contained in this attribute to populate the Service Index (SI) field in the NSH Service Path header defined in [I-D.ietf-sfc-nsh].
If the NAS is pre-configured with a default NSH SI value, this value MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different NSH SI.
If the NAS includes the NSH-SI attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server. If the NAS does not receive the NSH-SI attribute in the Access-Accept message, but it receives the NSH-SPI attribute, it MAY fall back to a pre-configured default NSH SI, if any. If the NAS receives the NSH-SPI attribute, but it does not receives the NSH-SI attribute from the AAA Server and the NAS does not have any pre-configured SI, the traffic generated by that specific subscriber MUST be dropped as this is an error condition.
If the NAS is pre-provisioned with a default NSH SI and the NSH-SI received in the Access-Accept message is different from the configured default, then the NSH-SI received in the Access-Accept message MUST be used for the session.
If an implementation includes Change-of-Authorization (CoA) messages [RFC5176], they could be used to modify the current specified NSH SI. When the NAS receives a CoA Request message containing the NSH-SI attribute, the NAS MUST use the received NSH SI value to re-configure the the Service Index (SI) field in the NSH Service Path header.
The NSH-SI RADIUS attribute MUST NOT appear more than once in a message.
A summary of the NSH-SI 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH-SI RADIUS Attribute
The following tables provide a guide to which attributes may be found in which kinds of packets, and in what quantity.
Access- Access- Access- Challenge Accounting # Attribute Request Accept Reject Request 0-1 0-1 0 0 0-1 TBD NSH-SPI 0-1 0-1 0 0 0-1 TBD NSH-SI CoA-Request CoA-ACK CoA-NACK # Attribute 0-1 0 0 TBD NSH-SPI 0-1 0 0 TBD NSH-SI
The following table defines the meaning of the above table entries.
These attributes are usable within either RADIUS or Diameter [RFC6733]. Since the attributes defined in this document have been allocated from the standard RADIUS type space, no special handling is required by Diameter entities.
The authors would like to thank Jim Guichard and Mohamed Boucadair for their valuable comments and inputs to this document.
Per this document, IANA is requested to assign two new RADIUS Attribute Type in the "Radius Types" registry (currently located at http://www.iana.org/assignments/radius-types) for the following attributes:
TBD NSH-SPI integer
TBD NSH-SI integer
This document has no additional security considerations beyond those already identified in [RFC2865] for the RADIUS protocol and in [RFC5176] for CoA messages.
The security considerations for NSH protocol are described in section 9 of [I-D.ietf-sfc-nsh]
| [RFC5176] | Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |
| [I-D.ietf-radext-datatypes] | DeKok, A., "Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)", Internet-Draft draft-ietf-radext-datatypes-08, October 2016. |
| [I-D.ietf-sfc-nsh] | Quinn, P. and U. Elzur, "Network Service Header", Internet-Draft draft-ietf-sfc-nsh-10, September 2016. |
| [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. |
| [RFC6733] | Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012. |
| [RFC6929] | DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013. |