sfc R. Maglione
Internet-Draft G. Trueba
Intended status: Standards Track C. Pignataro
Expires: April 17, 2017 Cisco Systems
October 14, 2016
RADIUS Attributes for NSH
draft-maglione-sfc-nsh-radius-00
Abstract
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).
Status of This Memo
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
Maglione, et al. Expires April 17, 2017 [Page 1]
Internet-Draft Radius attributes for SPI October 2016
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 17, 2017.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 3
4. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 4
4.1. NSH Service Path Identifier . . . . . . . . . . . . . . . 5
4.2. NSH Service Index . . . . . . . . . . . . . . . . . . . . 6
5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 7
6. Diameter Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Informative References . . . . . . . . . . . . . . . . . 8
10.2. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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.
Maglione, et al. Expires April 17, 2017 [Page 2]
Internet-Draft Radius attributes for SPI October 2016
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).
1.1. Requirements Language
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].
2. Terminology
NSH Network Service Header
SFC Service Function Chaining
SFF Service Function Forwarder
SPI Service Path Identifier
SI Service Index
3. Architectural Model
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
Maglione, et al. Expires April 17, 2017 [Page 3]
Internet-Draft Radius attributes for SPI October 2016
+-----+
| 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.
4. RADIUS Attributes
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].
Maglione, et al. Expires April 17, 2017 [Page 4]
Internet-Draft Radius attributes for SPI October 2016
4.1. NSH Service Path Identifier
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 does not have any pre-configured NSH SPI, 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.
Maglione, et al. Expires April 17, 2017 [Page 5]
Internet-Draft Radius attributes for SPI October 2016
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
Type TBD - NSH-SPI
Length 5
Value The field is 3 octets, containing a 24-bit unsigned integer
Service Path Identifier. The NAS acting as classifier MUST copy
this value into the SPI field of the NSH Service Path Header.
4.2. NSH Service Index
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.
Maglione, et al. Expires April 17, 2017 [Page 6]
Internet-Draft Radius attributes for SPI October 2016
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH-SI RADIUS Attribute
Type TBD - NSH-SI
Length 3
Value The field is 1 octet, containing a 8-bit unsigned integer
Service Index. The NAS acting as classifier MUST copy this value
into the SI field of the NSH Service Path Header.
5. Table of Attributes
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.
0 This attribute MUST NOT be present in the packet.
0+ Zero or more instances of this attribute MAY be present in the
packet.
Maglione, et al. Expires April 17, 2017 [Page 7]
Internet-Draft Radius attributes for SPI October 2016
0-1 0-1 Zero or one instance of this attribute MAY be present in the
packet.
6. Diameter Considerations
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.
7. Acknowledgements
The authors would like to thank Jim Guichard for his valuable
comments and inputs to this document.
8. IANA Considerations
Per this document, IANA has assigned one new RADIUS Attribute Type in
the "Radius Types" registry (currently located at
http://www.iana.org/assignments/radius-types) for the following
attribute:
NSH-SPI TBD
NSH-SI TBD
9. Security Considerations
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]
10. References
10.1. Informative References
[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,
<http://www.rfc-editor.org/info/rfc5176>.
Maglione, et al. Expires April 17, 2017 [Page 8]
Internet-Draft Radius attributes for SPI October 2016
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
10.2. Normative References
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-10 (work in progress), 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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,
<http://www.rfc-editor.org/info/rfc6158>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<http://www.rfc-editor.org/info/rfc6929>.
Authors' Addresses
Roberta Maglione
Cisco Systems
Via Torri Bianche 8
Vimercate
Italy
Email: robmgl@cisco.com
Maglione, et al. Expires April 17, 2017 [Page 9]
Internet-Draft Radius attributes for SPI October 2016
Guillermo Trueba
Cisco Systems
Avenida Cortes Valencianas 58
Valencia 46015
Spain
Email: gtrueba@cisco.com
Carlos Pignataro
Cisco Systems
7200 Kit Creek Road
Research Triangle Park, NC 27709
USA
Email: cpignata@cisco.com
Maglione, et al. Expires April 17, 2017 [Page 10]