idnits 2.17.1 draft-maglione-sfc-nsh-radius-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 31, 2016) is 2727 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) == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sfc R. Maglione 3 Internet-Draft G. Trueba 4 Intended status: Standards Track C. Pignataro 5 Expires: May 4, 2017 Cisco Systems 6 October 31, 2016 8 RADIUS Attributes for NSH 9 draft-maglione-sfc-nsh-radius-01 11 Abstract 13 Network Service Header (NSH) protocol defines the Service Function 14 Chaining (SFC) encapsulation required to support the Service Function 15 Chaining (SFC) Architecture. One of the components of the Network 16 Service Header (NSH) protocol is the Service Path Identifier (SPI), 17 which identifies a service path, another important element of the NSH 18 protocol is the Service Index (SI), which provides location within 19 the Service Path. 21 When Service Providers would like to deliver customized services 22 offers requiring Service Functions Chains, a different service chain 23 may be required for each subscriber or group of subscribers. In 24 order to simplify the service provisioning in this scenario, it would 25 be useful to be able to associate the Service Path Identifier (SPI), 26 identifying the service chain, and the appropriate Service Index 27 (SI), identifying the location in the service path, with the customer 28 profile. 30 In some Broadband networks, the customer profile information may be 31 stored in Authentication, Authorization, and Accounting (AAA) 32 servers. This document specifies two new Remote Authentication Dial- 33 In User Service (RADIUS) attributes to carry the Service Path 34 Identifier (SPI) and the Service Index (SI). 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 http://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 May 4, 2017. 53 Copyright Notice 55 Copyright (c) 2016 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 (http://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 3 74 4. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 4 75 4.1. NSH Service Path Identifier . . . . . . . . . . . . . . . 5 76 4.2. NSH Service Index . . . . . . . . . . . . . . . . . . . . 6 77 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 7 78 6. Diameter Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10.1. Informative References . . . . . . . . . . . . . . . . . 9 84 10.2. Normative References . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 Network Service Header (NSH) protocol [I-D.ietf-sfc-nsh] defines the 90 Service Function Chaining (SFC) encapsulation required to support the 91 Service Function Chaining (SFC) Architecture [RFC7665]. One of the 92 components of the Network Service Header (NSH) protocol is the 93 Service Path Identifier (SPI), which identifies a service path, 94 another important element of the NSH protocol is the Service Index 95 (SI), which provides location within the Service Path. 97 When Service Providers would like to deliver customized services 98 offers requiring Service Functions Chains, a different service chain 99 may be required for each subscriber or group of subscribers. In 100 order to simplify the service provisioning in this scenario, it would 101 be useful to be able to associate the Service Path Identifier (SPI), 102 identifying the service chain, and the appropriate Service Index (SI) 103 identifying the location in the service path, with the customer 104 profile. 106 In some Broadband networks, the customer profile information may be 107 stored in Authentication, Authorization, and Accounting (AAA) 108 servers. This document specifies two new Remote Authentication Dial- 109 In User Service (RADIUS) attributes to carry the Service Path 110 Identifier (SPI) and the Service Index (SI). 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 2. Terminology 120 NSH Network Service Header 122 SFC Service Function Chaining 124 SFF Service Function Forwarder 126 SPI Service Path Identifier 128 SI Service Index 130 3. Architectural Model 132 Figure 1 illustrates the network reference model for a Broadband 133 access scenario where a NAS, acting as RADIUS Client, performs both 134 the Service Classification and Service Forwarder Function. 136 The Service Functions which make up the Service Chaining are part of 137 the SP network and they are not depicted in Figure 1 138 +-----+ 139 | AAA | 140 | | ,--------. 141 +--+--+ / \ 142 ^ | Internet | 143 . | Access | 144 RADIUS . / \ / 145 . / '--------' 146 . / 147 v / ,------. 148 +------+ +---+---+ / \ 149 +------+ | | | NAS | / \ 150 | RG/ +-------| AN +-----+-------+ SCF |----( SP ) 151 | host | | | | SFF | \ Network / 152 +------+ +------+ (Ethernet) +-------+ \ / 153 . . ?------? 154 . PPPoE or IPoE Session . 155 . <-------------------------------> . 157 Figure 1: Network Reference Model 159 Here there is a brief description of the Authentication/Authorization 160 process between the NAS and the AAA Server. 162 The NAS initially sends a RADIUS Access-Request message to the RADIUS 163 server, requesting authentication. Once the RADIUS server receives 164 the request, it validates the sending client, and if the request is 165 approved, the AAA server replies with an Access-Accept message 166 including a list of attribute-value pairs that describe the 167 parameters to be used for this session. This list MAY also contain 168 the NSH Service Path Identifier (NSH-SPI) and the NSH Service Index 169 (NSH-SI) attributes used to identify a specific service path and the 170 location in the service path. 172 The NSH SPI attribute returned by AAA Server in the Access-Accept is 173 used by the NAS to insert the traffic of the subscriber in the 174 correct service path. A classification rule, to be associated with 175 the SPI, can also be sent by the AAA Server as part of the list of 176 attribute-value pairs. 178 4. RADIUS Attributes 180 This section defines the NSH Service Path Identifier (SPI) and the 181 NSH Service Index (SI) attributes that are used in the above- 182 mentioned scenario. The attributes design follows [RFC6158] and 183 refers to [RFC6929] and [I-D.ietf-radext-datatypes]. 185 4.1. NSH Service Path Identifier 187 The NSH Service Path Identifier (NSH-SPI) RADIUS attribute contains 188 the value which identifies a specific service path to be associated 189 to a subscriber. 191 When the NAS receives from the AAA Server the NSH-SPI attribute, the 192 NAS MUST use the value contained in this attribute to populate the 193 Service Path Identifier (SPI) field in the NSH Service Path header 194 defined in [I-D.ietf-sfc-nsh]. 196 If the NAS is pre-configured with a default NSH SPI value, this value 197 MAY be inserted in the attribute. The RADIUS server MAY ignore the 198 hint sent by the NAS, and it MAY assign a different NSH SPI. 200 If the NAS includes the NSH-SPI attribute, but the AAA server does 201 not recognize it, this attribute MUST be ignored by the AAA server. 202 If the NAS does not receive the NSH-SPI attribute in the Access- 203 Accept message, it MAY fall back to a pre-configured default NSH SPI, 204 if any. If the NAS receives the NSH-SI attribute, but it does not 205 receives the NSH-SPI attribute from the AAA Server and the NAS does 206 not have any pre-configured SPI, the traffic generated by that 207 specific subscriber MUST be dropped as this is an error condition. 208 If the NAS does not receive the NSH-SPI attribute and it does not 209 receive the NSH-SI attribute in the Access-Accept message and the NAS 210 does not have any pre-configured NSH SPI and NSH SI, the traffic 211 generated by that specific subscriber does not have to be sent across 212 any service chain. 214 If the NAS is pre-provisioned with a default NSH SPI and the NSH-SPI 215 received in the Access-Accept message is different from the 216 configured default, then the NSH-SPI received in the Access-Accept 217 message MUST be used for the session. 219 If an implementation includes Change-of-Authorization (CoA) messages 220 [RFC5176], they could be used to modify the current specified SPI. 221 When the NAS receives a CoA Request message containing the NSH-SPI 222 attribute, the NAS MUST use the received NSH SPI value to re- 223 configure the the Service Path Identifier (SPI) field in the NSH 224 Service Path header. This allows the network administrator to modify 225 the forwarding of the traffic of a specific subscriber. By changing 226 the SPI value the service path used for the subscriber is modified, 227 thus the traffic of the selected subscriber is sent across a 228 different service chain. 230 The NSH-SPI RADIUS attribute MUST NOT appear more than once in a 231 message. 233 A summary of the NSH-SPI RADIUS attribute format is shown below. The 234 fields are transmitted from left to right. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Length | Value 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Value (cont) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: NSH-SPI RADIUS Attribute 246 Type TBD - NSH-SPI 248 Length 6 250 Value This field uses the integer data type, defined in 251 [I-D.ietf-radext-datatypes], which encodes a 32-bit unsigned 252 integer in network byte order. As the Service Path Identifier 253 field, defined in [I-D.ietf-sfc-nsh], is limited to 24 bits, only 254 24 bits of the value field in the RADIUS attribute are used to 255 encode the NSH-SPI value. The NAS acting as classifier MUST copy 256 this value into the SPI field of the NSH Service Path Header. 258 4.2. NSH Service Index 260 The NSH Service Index (NSH-SI) RADIUS attribute contains the value 261 which identifies the location in the service path. According to 262 [I-D.ietf-sfc-nsh] , the initial SI value SHOULD default to 255. 264 When the NAS receives from the AAA Server the NSH-SI attribute, the 265 NAS MUST use the value contained in this attribute to populate the 266 Service Index (SI) field in the NSH Service Path header defined in 267 [I-D.ietf-sfc-nsh]. 269 If the NAS is pre-configured with a default NSH SI value, this value 270 MAY be inserted in the attribute. The RADIUS server MAY ignore the 271 hint sent by the NAS, and it MAY assign a different NSH SI. 273 If the NAS includes the NSH-SI attribute, but the AAA server does not 274 recognize it, this attribute MUST be ignored by the AAA server. If 275 the NAS does not receive the NSH-SI attribute in the Access-Accept 276 message, but it receives the NSH-SPI attribute, it MAY fall back to a 277 pre-configured default NSH SI, if any. If the NAS receives the NSH- 278 SPI attribute, but it does not receives the NSH-SI attribute from the 279 AAA Server and the NAS does not have any pre-configured SI, the 280 traffic generated by that specific subscriber MUST be dropped as this 281 is an error condition. 283 If the NAS is pre-provisioned with a default NSH SI and the NSH-SI 284 received in the Access-Accept message is different from the 285 configured default, then the NSH-SI received in the Access-Accept 286 message MUST be used for the session. 288 If an implementation includes Change-of-Authorization (CoA) messages 289 [RFC5176], they could be used to modify the current specified NSH SI. 290 When the NAS receives a CoA Request message containing the NSH-SI 291 attribute, the NAS MUST use the received NSH SI value to re-configure 292 the the Service Index (SI) field in the NSH Service Path header. 294 The NSH-SI RADIUS attribute MUST NOT appear more than once in a 295 message. 297 A summary of the NSH-SI RADIUS attribute format is shown below. The 298 fields are transmitted from left to right. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Length | Value 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Value (cont) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 3: NSH-SI RADIUS Attribute 310 Type TBD - NSH-SI 312 Length 6 314 Value This field uses the integer data type defined in 315 [I-D.ietf-radext-datatypes], which encodes a 32-bit unsigned 316 integer in network byte order. As the Service Index field defined 317 in [I-D.ietf-sfc-nsh] is limited to 8 bits, only 8 bits of the 318 value field in the RADIUS attribute are used to encode the NSH-SI 319 value. The NAS acting as classifier MUST copy this value into the 320 SI field of the NSH Service Path Header. 322 5. Table of Attributes 324 The following tables provide a guide to which attributes may be found 325 in which kinds of packets, and in what quantity. 327 Access- Access- Access- Challenge Accounting # Attribute 328 Request Accept Reject Request 329 0-1 0-1 0 0 0-1 TBD NSH-SPI 330 0-1 0-1 0 0 0-1 TBD NSH-SI 332 CoA-Request CoA-ACK CoA-NACK # Attribute 333 0-1 0 0 TBD NSH-SPI 334 0-1 0 0 TBD NSH-SI 336 The following table defines the meaning of the above table entries. 338 0 This attribute MUST NOT be present in the packet. 340 0+ Zero or more instances of this attribute MAY be present in the 341 packet. 343 0-1 0-1 Zero or one instance of this attribute MAY be present in the 344 packet. 346 6. Diameter Considerations 348 These attributes are usable within either RADIUS or Diameter 349 [RFC6733]. Since the attributes defined in this document have been 350 allocated from the standard RADIUS type space, no special handling is 351 required by Diameter entities. 353 7. Acknowledgements 355 The authors would like to thank Jim Guichard and Mohamed Boucadair 356 for their valuable comments and inputs to this document. 358 8. IANA Considerations 360 Per this document, IANA is requested to assign two new RADIUS 361 Attribute Type in the "Radius Types" registry (currently located at 362 http://www.iana.org/assignments/radius-types) for the following 363 attributes: 365 TBD NSH-SPI integer 367 TBD NSH-SI integer 369 9. Security Considerations 371 This document has no additional security considerations beyond those 372 already identified in [RFC2865] for the RADIUS protocol and in 373 [RFC5176] for CoA messages. 375 The security considerations for NSH protocol are described in section 376 9 of [I-D.ietf-sfc-nsh] 378 10. References 380 10.1. Informative References 382 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 383 Aboba, "Dynamic Authorization Extensions to Remote 384 Authentication Dial In User Service (RADIUS)", RFC 5176, 385 DOI 10.17487/RFC5176, January 2008, 386 . 388 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 389 Chaining (SFC) Architecture", RFC 7665, 390 DOI 10.17487/RFC7665, October 2015, 391 . 393 10.2. Normative References 395 [I-D.ietf-radext-datatypes] 396 DeKok, A., "Data Types in the Remote Authentication Dial- 397 In User Service Protocol (RADIUS)", draft-ietf-radext- 398 datatypes-08 (work in progress), October 2016. 400 [I-D.ietf-sfc-nsh] 401 Quinn, P. and U. Elzur, "Network Service Header", draft- 402 ietf-sfc-nsh-10 (work in progress), September 2016. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 410 "Remote Authentication Dial In User Service (RADIUS)", 411 RFC 2865, DOI 10.17487/RFC2865, June 2000, 412 . 414 [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", 415 BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, 416 . 418 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 419 Ed., "Diameter Base Protocol", RFC 6733, 420 DOI 10.17487/RFC6733, October 2012, 421 . 423 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 424 Service (RADIUS) Protocol Extensions", RFC 6929, 425 DOI 10.17487/RFC6929, April 2013, 426 . 428 Authors' Addresses 430 Roberta Maglione 431 Cisco Systems 432 Via Torri Bianche 8 433 Vimercate 434 Italy 436 Email: robmgl@cisco.com 438 Guillermo Trueba 439 Cisco Systems 440 Avenida Cortes Valencianas 58 441 Valencia 46015 442 Spain 444 Email: gtrueba@cisco.com 446 Carlos Pignataro 447 Cisco Systems 448 7200 Kit Creek Road 449 Research Triangle Park, NC 27709 450 USA 452 Email: cpignata@cisco.com