idnits 2.17.00 (12 Aug 2021) /tmp/idnits29842/draft-ietf-pana-panaoverdsl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1131. 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 4, 2008) is 4946 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group L. Morand 3 Internet-Draft France Telecom R&D 4 Intended status: Informational A. Yegin 5 Expires: May 8, 2009 Samsung 6 Y. Ohba 7 Toshiba America Research, Inc. 8 J. Kaippallimalil 9 Huawei Technologies 10 November 4, 2008 12 Application of PANA framework to DSL networks 13 draft-ietf-pana-panaoverdsl-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 8, 2009. 40 Abstract 42 This document provides guidelines for PANA deployment over DSL access 43 networks. The document specifically describes the introduction of 44 PANA in DSL networks migrating from a traditional PPP access model to 45 a pure IP-based access environment. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. PANA Framework Overview . . . . . . . . . . . . . . . . . . . 3 53 5. PANA in DSL environment . . . . . . . . . . . . . . . . . . . 4 54 5.1. Evolution of DSL Environment . . . . . . . . . . . . . . . 4 55 5.2. Advisability of Introducing PANA in DSL Environment . . . 6 56 6. Applicability of PANA to IP Session based DSL Environment . . 7 57 6.1. Functional Architecture . . . . . . . . . . . . . . . . . 7 58 6.1.1. Location of PAA and EP . . . . . . . . . . . . . . . . 7 59 6.1.2. Location of the PaC . . . . . . . . . . . . . . . . . 7 60 6.2. IP Address Configuration . . . . . . . . . . . . . . . . . 9 61 6.3. Authorized Device ID . . . . . . . . . . . . . . . . . . . 10 62 6.4. Cryptographic Protection . . . . . . . . . . . . . . . . . 10 63 6.5. Implementation Options . . . . . . . . . . . . . . . . . . 10 64 6.5.1. Generic Message Flows . . . . . . . . . . . . . . . . 11 65 6.5.2. Use of IPv6 Link-Local Address . . . . . . . . . . . . 12 66 6.5.3. Use of IPv4 Link-Local Address . . . . . . . . . . . . 15 67 6.5.4. Use of Unspecified IPv4 Address . . . . . . . . . . . 19 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 75 Intellectual Property and Copyright Statements . . . . . . . . . . 26 77 1. Introduction 79 PANA (Protocol for carrying Authentication for Network Access) design 80 provides support for various types of deployments. DSL networks were 81 identified as a typical example of such a deployment. This document 82 provides guidelines for PANA deployment over DSL access networks. 83 The document specifically describes the introduction of PANA in DSL 84 networks migrating from a traditional PPP access model to a pure IP- 85 based access environment. In such environment, additional 86 authentication mechanisms are required to provide a complete secure 87 network access solution to Network Access Providers (NAP) willing to 88 overtake inadequate methods such as basic DSL link-layer 89 identification or application-layer ad-hoc authentication mechanisms 90 (e.g., HTTP redirects with web-based login). 92 2. Specification of Requirements 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Terminology 100 This document uses the PANA terminology defined in [RFC5191]. 101 This document uses the DSL Forum terminology defined in [TR25], 102 [TR59], [TR101] and [WT146]. 104 4. PANA Framework Overview 106 PANA (Protocol for carrying Authentication for Network Access) is a 107 link-layer agnostic transport for EAP [RFC3748] to enable network 108 access authentication between clients and access networks. 110 The motivation to define such a protocol and the requirements are 111 described in [RFC4058]. Protocol details are documented in 112 [RFC5191]. There are components that are part of a complete secure 113 network access solution but are outside of the PANA protocol 114 specification. These components include PANA Authentication Agent 115 (PAA) discovery mechanisms, based either on DHCP [RFC5192] or a 116 simple multicast-based protocol [I-D.fajardo-pana-paa-discovery], as 117 well as IP address configuration, authentication method choice, 118 filter rule installation, data traffic protection, and PAA-EP 119 protocol [RFC5193]. 121 Figure 1 illustrates the functional entities involved in the PANA 122 framework and the interfaces (protocols, APIs) among them. See 123 [RFC5191] and [RFC5193] for further details. 124 RADIUS/ 125 Diameter/ 126 +-----+ PANA +-----+ LDAP/ API +-----+ 127 | PaC |<----------------->| PAA |<---------------->| AS | 128 +-----+ +-----+ +-----+ 129 ^ ^ 130 | | 131 | +-----+ | 132 IKE/ +-------->| EP |<--------+ API/ Other 133 4-way handshake (*) +-----+ 135 Figure 1: PANA Functional Model 137 PaC: PANA Client 139 PAA: PANA Authentication Agent 141 AS: Authentication Server 143 EP: Enforcement Point 145 (*) PaC-EP secure association protocol is not needed in DSL networks unless 146 per-packet cryptographic security is needed. 148 The PANA design provides support for various types of deployments. 149 DSL networks were identified as a typical example of such a 150 deployment (see Appendix A of [RFC4058]). 152 5. PANA in DSL environment 154 5.1. Evolution of DSL Environment 156 Traditional DSL deployments followed the architectural guidelines 157 provided in [TR25] or [TR59]. Theses architectures use ATM to 158 aggregate the access networks into a regional broadband network. The 159 traffic aggregated from the access nodes (DSLAM) is steered to an IP 160 node, the Broadband Remote Access Server (BRAS). In this 161 environment, PPP sessions are set-up between the CPN (Customer 162 Premises Network) and the BRAS, which acts as either a PPP 163 termination point or a L2TP Access Concentrator (LAC) tunnelling 164 multiple subscriber PPP sessions directly to an Internet/Corporate 165 Service Provider. The CPN is usually defined as the combination of 166 the DSL Modem or Residential Gateway (RG), acting as termination 167 point of the physical DSL signal, and the subscriber's computers and 168 other devices (named hosts hereafter) connected to the DSL Modem/RG. 170 Host--+ +-- ISP1 171 | DSL link | 172 +-- DSL Modem/RG --- DSLAM --- BRAS --+-- ISP2 173 | | 174 Host--+ +-- ISP3 176 <------- CPN -------> <----- NAP ----> <-- ISP --> 178 Figure 2: DSL Model 179 The devices at the customer premises have been shown as "hosts" in 180 the above network. 182 DSL architectures are now emerging from a "low" speed best effort 183 delivery network to an infrastructure capable of supporting higher 184 subscriber bit rates. At the application layer, DSL service 185 providers are looking to support enhanced services layered on top of 186 basic Internet access, including entertainment video services 187 (Broadcast TV and VoD), video conferencing, VoIP, gaming, and 188 business class services (e.g. IP VPN), that have prohibitive 189 requirements to deploy them in a pure ATM based environment. Moving 190 to on a Gigabit Ethernet instead of an ATM aggregation network offers 191 an highly efficient transport technology for delivering large amounts 192 of bandwidth to a highly distributed access node topology. Migration 193 from ATM-based to an Ethernet based aggregation network in the 194 context of TR-25 and TR-59 based architectures is described in 195 [TR101]. 197 In this evolution path towards Giga Ethernet, there is in parallel a 198 growing interest in migrating from the traditional PPP access model 199 to one relying on an network access control of IP sessions 200 establishment. The "IP Sessions" model is a concept introduced in 201 DSL Forum that covers a cycle consisting of IP session Detection and 202 creation, application of IP session policies, and IP session 203 termination. Details of this work are documented in [WT146]. 204 Basically, an IP session represents subscriber IP traffic which is 205 associated with a subscriber's IP address parameters. A subscriber 206 may have multiple IP addresses (or sessions) in simultaneous use. An 207 IP session may in turn be associated with multiple IP flows. The 208 relation between subscribers and policies associated with it are 209 described in [WT134]. The policy relationships in this document show 210 that subscribers have services that are governed by policies. Thus, 211 the same subscriber policies govern all IP sessions/flows belonging 212 to the subscriber. 214 5.2. Advisability of Introducing PANA in DSL Environment 216 Among other challenges for DSL environment migrating from pure PPP 217 based networks, one is the need for the creation of an IP session 218 subscriber authentication model to secure network access and IP 219 address management provided by a DHCP infrastructure. Indeed, 220 contrary to PPP environment, an IP sessions model has no built-in 221 mechanisms for authentication purposes in a DHCP based environment. 222 If location-based authentication relying on access line 223 identification is actually possible (see in [TR101] the use of the 224 DHCP Relay Agent Information option, aka DHCP option 82 [RFC3046], 225 inserted by the Access Node), additional mechanisms are required to 226 provide Network Access Providers (NAP) with an explicit per- 227 subscriber access authentication solution, in order to . 229 Providing a native support of EAP frames over IP, PANA is therefore a 230 natural candidate to provide the protocol support of an IP subscriber 231 authentication model. Moreover, PANA provides functionalities 232 fulfilling basic and advanced security requirements within an IP 233 session based environment (as described in [WT146]) , such as: 235 o IP address based session management mechanisms, using an explicit 236 session identifier; 238 o Authentication mechanism independent of the physical medium type; 240 o Enabling per-session enforcement policies (i.e. filters) depending 241 on the creation and deletion of the PANA session; 243 o Enabling session keep-alive and session monitoring functionalities 244 to optimize the use of resources and provide an accurate picture 245 of the state of a subscriber session (as described in [WT146]). 247 In this new context for DSL networks, PANA may be introduced to 248 authenticate the credentials of a user prior to the setup of an IP 249 session. The user selects the service provider and authenticates 250 itself. During IP session setup, policies for the use of connection 251 resources related to the IP session are established in the BRAS. 252 These policies govern the subscriber's use of network resources. IP 253 flows are accounted for and associated with the IP session and the 254 service session that triggered it. 256 Based on the content of the Liaison Statement sent by the DSL Forum 257 to the IETF, the specific subscriber authentication requirements were 258 discussed at the PANA WG meeting at IETF70 in Vancouver (Dec 5, 259 2007). The result of this analysis confirmed the applicability of 260 the PANA protocol for the DSL Forum's subscriber authentication 261 requirements. PANA WG Meeting analysis can be found in the 70th IETF 262 meeting proceedings 263 (http://www.ietf.org/proceedings/07dec/slides/pana-3/sld1.htm). 265 6. Applicability of PANA to IP Session based DSL Environment 267 6.1. Functional Architecture 269 6.1.1. Location of PAA and EP 271 In a PPP based environment, the BRAS is in charge of interfacing with 272 CPE for authenticating and authorizing them for the network access 273 service as well as performing policy control by acting as en 274 enforcement point. In an IP session based environment, such 275 functionalities may be provided at the same level by locating the PAA 276 and EP entities in the BRAS. One advantage provided by this 277 implementation is to preserve a improved and well-established DSL 278 network configuration. Moreover, PAA and EP being collocated, there 279 is no need to rely on an external interface between them to carry the 280 authorized client attributes i.e. filters, an API being sufficient in 281 that case. 283 The PANA design providing also the support for network configuration 284 in which PAA and EP are not collocated, as described in [RFC5193], 285 the PAA may be located in the BRAS while the EP function is the 286 DSLAM. In that specific case, the PAA-EP interface implemented 287 between the BRAS and the DSLAM may be based on the current DHCP 288 triggering or on a dedicated API. 290 In an IP session based environment, the PAA will have to verify the 291 credentials provided by a PaC located in the CPN and authorize 292 network access to the host/gateway associated with the client. 294 6.1.2. Location of the PaC 296 6.1.2.1. Bridged Mode 298 In the Bridged mode, the DSL Modem/RG acts as a simple link-layer 299 bridge. The DSL Modem/RG is here transparent at the IP layer. The 300 hosts (e.g. PC) connected to the DSL Modem/RG in the CPN and the 301 BRAS are then on the same IP link. Hosts may have a statically 302 configured IP address or obtain an IP address from a DHCP server 303 through the DSLAM (acting as a Layer-2 DHCP Relay agent as described 304 in [TR101]) and the BRAS (filtering DHCP requests towards the DHCP 305 server). 307 In this model, the PaC can be easily implemented in the hosts. Any 308 host connected to the DSL Modem/RG will be authenticated by the PAA 309 locating in the BRAS. It is therefore possible to perform a network 310 access control on a per-host basis, as required by the IP session 311 model. 313 Host--+ 314 (PaC) | 315 +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP 316 | (Bridge) (PAA,EP) 317 Host--+ 318 (PaC) 320 Figure 3: Bridged Mode 322 6.1.2.2. Routed Mode 324 In the Routed mode, the DSL Modem/RG acts as an IP router for the 325 CPN. In this configuration, only the DSL Modem/RG and BRAS are on 326 the same IP link. The DSL Modem/RG may have a statically configured 327 IP address or obtain an IPv4 address or an IPv6 prefix from a DHCP 328 server through the DSLAM (acting as a Layer-2 DHCP-Relay agent as 329 described in [TR101]) and the BRAS (filtering DHCP requests towards 330 the DHCP server). Hosts connected to the DSL Modem/RG may use either 331 (1) either private IP addresses in an IPv4 environment with the DSL 332 Modem/RG implemented a Network Address Port Translation (NAPT) 333 function or (2) routable IP addresses if the modem is an IPv6 router. 335 Host--+ 336 | 337 +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP 338 | (Router, PaC) (PAA,EP) 339 Host--+ 340 IPv4 Case (1) 342 Host--+ 343 (PaC) | 344 +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP 345 | (Router, PaC) (PAA,EP) 346 Host--+ 347 (PaC) 348 IPv6 Case (2) 350 Figure 4: Routed Mode 352 In the IPv4 case (1), the simplest method is to implement the PaC in 353 the DSL Modem/RG. Only the DSL Modem/RG will be authenticated/ 354 authorized by the PAA. All hosts at the customer premises will then 355 have access to the service provider's network using private IP 356 addresses obtained from the DSL Modem/RG. 358 (NOTE: Per-host authentication may be achieved also in the Routed 359 mode if the EP function is performed by the DSL Modem/RG. However, 360 it is for further studies to see how to introduce such a 361 configuration in the global DSL Forum "IP Sessions" model.) 363 In the IPv6 case (2), the BRAS will detect any new IP address used by 364 the DSL Modem/RG and the hosts connected to the DSL Modem/RG when 365 using global scope IPv6 addresses. To allow a suitable network 366 access rights management based on the IP address, PANA clients will 367 have to be therefore implemented in the DSL Modem/RG and the hosts. 368 The network access control is therefore performed on a per-host 369 basis, in addition to the handling of the DSL Modem/RG 's own IP 370 sessions. 372 6.2. IP Address Configuration 374 In the context of PANA deployment in DSL environment based on the IP 375 Sessions model, the IP address configured by the PaC prior to PANA 376 execution (so-called Pre-PANA Address or PRPA) MAY be obtained by one 377 of the following methods: 379 1. Static IP Address confniguration: the PaC MAY be statically 380 configured with an IP address. This address is therefore used as 381 a PRPA. 383 2. DHCP-based IP Address Confirguration: the PaC MAY dynamically 384 configure the PRPA using DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. 386 3. IPv6 Global Adress Stateless Address Autoconfiguration: in IPv6 387 environment, the PaC MAY configure global address(es) using IPv6 388 stateless auto-configuration [RFC2462] if router advertisements 389 with prefixes are made available, as specified in [RFC2461]. 391 4. Dynamic Configuration of Link-Local Address: The PaC MAY 392 configure an IPv4 link-local address [RFC3927] and/or an IPv6 393 link-local address [RFC2462]. 395 5. Unspecified IPv4 Address: PaC MAY use an unspecified IPv4 address 396 (IPv4 address set to 0.0.0.0) as source IPv4 address. 398 After a successful authentication, the PaC MAY have to configure a 399 new IP address for communication with other nodes if the PRPA is an 400 unspecified IPv4 address, a local-use IP address (e.g., a link-local 401 or private IP address) or a temporarily allocated IP address. This 402 IP address is called a post-PANA address (POPA). An operator might 403 choose allocating a POPA only after successful PANA authorization 404 either to prevent waste of premium (e.g., globally routable) IP 405 resources until the PaC is authorized (especially in the IPv4 case), 406 or to enable PaC identity based address assignment. POPA can be 407 configured using DHCP [RFC2131] [RFC3315] or using IPv6 stateless 408 auto-configuration [RFC2462]. 410 6.3. Authorized Device ID 412 The MAC address of the PaC can be used as a session attribute of the 413 subscriber and used by the Enforcement Point (EP) for packet 414 filtering once the PANA authentication successfully completed. The 415 MAC address can also be used by the network to assign a subscriber- 416 dependent IP address using DHCP. Therefore, the association between 417 the subscriber ID that was used with the PANA authentication and the 418 session attributes (MAC address and IP address) can be formed. 420 6.4. Cryptographic Protection 422 DSL networks are protected by physical means. Eavesdropping and 423 spoofing attacks are prevented by keeping the unintended users 424 physically away from the network media. Therefore, generally 425 cryptographic protection of data traffic is not common. 426 Nevertheless, if enhanced security is deemed necessary for any 427 reason, IPsec-based access control can be enabled on DSL networks as 428 well by using the method described in [I-D.ietf-pana-ipsec]. 430 6.5. Implementation Options 432 This section provides possible implementation options of PANA in DSL 433 deployments. 435 Section 6.5.1 describes the basic components of generic message 436 flows. 438 Section 6.5.2 describes the specific use of IPv6 link-local address 439 as Pre-PANA Address (PRPA). 441 Section 6.5.3 describes the specific use of IPv4 link-local address 442 as PRPA. 444 Section 6.5.4 describes the specific use of unspecified IPv4 address 445 as PRPA. 447 For each specific scenario, the features required from various 448 network elements in DSL deployment are described. 450 6.5.1. Generic Message Flows 452 This is the description of the basic components of generic message 453 flows. 455 DSL Modem/RG, DSLAM BRAS AAA server 456 or Host 457 (PaC) (EP) (PAA) 459 | | | | 460 |<--1. PRPA configuration----------->| | 461 | | | | 462 | | | | 463 |<--2. PAA discovery---------------->| | 464 | | | | 465 | | | | 466 |<--3. PANA authentication---------->|<--RADIUS/Diameter->| 467 | | | authentication | 468 | | | | 469 |<--4. POPA configuration----------->| | 470 | | | | 471 | |<-5. EP Filter-->| | 472 | | setup | | 473 | | | | 474 |<--6. IP session data traffic----------------> | 475 | | | | 476 | | | | 478 Figure 5. Generic PANA over DSL call flow 480 Depending on the deployment, either the DSL Modem acts as a RG and 481 therefore only that node is authenticated; or the DSL Modem acts as a 482 bridge and hosts connected to that bridge gets individually 483 authenticated. 485 Step 1: The DSL Modem/RG or host, acting as PaC, configures a pre- 486 PANA IP address (PRPA).This step is skipped if the PaC is using an 487 unspecified IPv4 address. 489 Step 2: PaC discovers the IP address of the PAA. PaC may use DHCP 490 [RFC5192] or the discovery mechanism provided by PANA 491 [I-D.fajardo-pana-paa-discovery]. 493 Step 3: PaC and PAA performs authentication using EAP and AAA 494 protocols (RADIUS, Diameter, etc.) 496 Step 4: In case the PRPA was an unspecified IPv4 address, 497 temporary IP address or limited-use IP address, the PaC configures 498 a post-PANA IP address (POPA). This is the service IP address. 500 Step 5: PAA instructs the EP to allow authorized IP traffic of 501 PaC. This step may be implicitly part of step 4 (e.g. DHCPACK 502 with IP address configuration) or performed using a specific API. 504 Step 6: PaC can transmit and receive IP data packets. 506 Note that the step 4 is optional. Depending on the network 507 configuration and the IP address resource management, it may not be 508 needed for the PaC to configure a new IP address after the PANA 509 authentication. 511 6.5.2. Use of IPv6 Link-Local Address 513 In this example, the following configuration is considered: 515 o The DSL modem/RG is authenticated;. 517 o PRPA is an IPv6 link-local address obtained by using IPv6 518 stateless auto-configuration [RFC2462]; 520 o PAA discovery is based on PAA responding to the PANA Client 521 Initiation request sent to a multicast address; 523 o Authentication method used is EAP-MD5; 525 o POPA is configured using DHCPv6 after successful authentication; 527 o EP is triggered by the DHCREPLY sent by the DHCP server, including 528 the assigned IPv6 address in the option 'OPTION_IAADDR'. 530 6.5.2.1. Message Flows 532 This section describes the message flows for a DSL modem/RG using an 533 IPv6 link-local address as PRPA. 535 DSL Modem/RG DSLAM BRAS AAA server 536 (PaC) (EP) (PAA) 538 | | | | 539 1. Link-local PRPA config | | 540 | | | | 541 | | | | 542 |--2. PANA Client initiation-------->| | 543 | | | | 544 |<-3. PANA Auth Req (EAP-MD5 chal)---| | 545 | | | | 546 |--4. PANA Auth Ans (EAP-MD5 resp)-->| | 547 | | | | 548 | | |-5. RADIUS Access ->| 549 | | | Request (EAP) | 550 | | | | 551 | | |<-6. RADIUS Access--| 552 | | | (EAP Success) | 553 |<-7. PANA Auth Req (EAP Success)----| | 554 | | | | 555 |--8. PANA Auth Ans (Ack)----------->| | 556 | | | | 557 |--9. DHCPSOLICIT------------------->| | 558 | | | | 559 |<-10. DHCPADVERTISE-----------------| | 560 | | | | 561 |--11. DHCPREQUEST------------------>| | 562 | | | | 563 |<-12. DHCPREPLY---*-----------------| | 564 | | | | 565 |<-13. IP session data traffic----------------> | 566 | | | | 568 Figure 6. Specific use of IPv6 link-local address as Pre-PANA Address (PRPA) 570 Depending on the deployment, either the DSL Modem acts as a RG and 571 therefore only that node is authenticated; or the DSL Modem acts as a 572 bridge and hosts connected to that bridge gets individually 573 authenticated. 575 Step 1: The DSL Modem/RG configures an IPv6 link-local address 576 [RFC2462]. It is assumed that, if the DSL network does not allow 577 modems sending and receiving Neighbor Disovery messages to each 578 other, then the network allows IP address collision among the 579 modems and deals with it by using auxiliary information such as 580 MAC address, VLAN, etc. 582 Step 2: The DSL Modem/RG initiates PANA by sending a PCI. 584 The source IPv6 address of the PCI is the IPv6 link-local address 585 configured in Step 1. The destination IPv6 address is set to a 586 reserved multicast address. This message is transparently 587 forwarded to the BRAS. 589 Step 3: PAA responds with a PANA-Authentication-Request message, 590 including its own IPv6 address as source IPv6 address. 592 PaC discovers the PAA's IPv6 address when it receives the PAR 593 message. 595 Step 4: PaC sends the PANA-Authentication-Answer message to the 596 PAA's newly discovered IPv6 address. 598 Steps 5-8: PANA and RADIUS carrying out EAP-MD5 authentication. 599 Note that it is possible to translate EAP-MD5/PANA to CHAP/RADIUS 600 and eliminate the need to support EAP/RADIUS. But the details of 601 such translation is outside the scope of this I-D. 603 Steps 9-12: Now that the DSL Modem/RG is authenticated, it 604 proceeds to configuring a global (service) IPv6 address using 605 DHCPv6. As soon as the gloabl IPv6 address is confirmed by the 606 DHCPREPLY, the DSL Modem/RG stops using the link-local address. 607 In Step 12, the DHCPREPLY message carrying the IPv6 address 608 triggers the DSLAM to update its filters with the authorized IP/ 609 MAC address of the DSL Modem/RG. 611 Step 13: The DSL Modem/RG can transmit and receive IP data packets 612 using the service IP address. 614 Note that, during steps 1-12, the DSLAM (acting as EP) allows only 615 DHCP and PANA messages and, depending on network configuration, 616 address resolution messages such as IPv6 Neighbor Discovery messages. 618 A variation of this call flow can be generated by using DHCP-based 619 PAA discovery [RFC5192] instead of the multicasted PCI (Step 2). If 620 DHCP Option 82 value is needed by the BRAS, it can be inserted at 621 this stage by the DSLAM. 623 6.5.2.2. Required Support from DSL Environment 625 This section describes the features required from various network 626 elements in DSL deployment in order to realize the described call 627 flow. Note that not all requirements are imposed due to choice of 628 PANA and some are already available irrespective of the 629 authentication protocol used (e.g., insertion of DHCP Option 82 by 630 the DSLAM). 632 6.5.2.2.1. Required Support from the DSL Modem/RG 634 The DSL modem/RG must host the PANA client (PAC). 636 The DSL modem/RG must configure an IPv6 link-local address before 637 sending PANA messages. 639 The PaC of the DSL modem/RG must be prepared to receive unsollicited 640 PANA-Authentication-Request, following a first DHCP Discover. 642 The DHCP client of the DSL modem/RG must be triggered by a successful 643 PANA authentication to configure a global IP address used as service 644 IP address. 646 6.5.2.2.2. Required Support from the DSLAM 648 The DSLAM must be configured to act as an Enforcement Point and 649 authorize only DHCP messages and PANA messages before successful PANA 650 authentication. 652 The DSLAM must be configured to snoop DHCP messages and insert DHCP 653 option 82 in DHCP messages sent by the DSL modem/RG and use the IP 654 address found in the DHCPREPLY received from the DHCP server to 655 update its IP filters for authorized IPaddress/MAC address. 657 6.5.2.2.3. Required Support from the BRAS 659 The BRAS should host the PANA Authentication Agent (PAA), the DHCP 660 relay or server, and the AAA client. A given deployment can choose 661 to host these implementations on separate nodes as long as it defines 662 interfaces among them to pass information. 664 The reception of DHCP Solicit message from an unauthenticated MAC 665 address should trigger a PAA-initiated PANA authentication procedure. 667 The DHCP server should allocate global IP addresses only to 668 authenticated MAC addresses. 670 6.5.3. Use of IPv4 Link-Local Address 672 In this example, the following configuration is considered: 674 o DSL modem/RG is authenticated, 675 o PRPA is a IPv4 link-local address, 677 o PAA discovery is based on DHCP, 679 o Authentication method used is EAP-MD5, 681 o POPA is configured using DHCPv4 after successful authentication, 683 o EP is triggered by DHCPACK whose 'yiaddr' field is filled. 685 6.5.3.1. Message Flows 687 This section describes the message flows for a DSL modem/RG using a 688 IPv4 link-local address as PRPA. 690 DSL Modem/RG DSLAM BRAS AAA server 691 (PaC) (EP) (PAA) 693 | | | | 694 1. IPv4 Link-local PRPA config | | 695 | | | | 696 | | | | 697 |--2. DHCPINFORM *(req.PAA opt.)-->| | 698 | | | | 699 |<-3. DHCPACK (PAA option)-----------| | 700 | | | | 701 |--4. PANA Client initiation-------->| | 702 | | | | 703 |<-5. PANA Auth Req (EAP-MD5 chal)---| | 704 | | | | 705 |--6. PANA Auth Ans (EAP-MD5 resp)-->| | 706 | | | | 707 | | |-7. RADIUS Access ->| 708 | | | Request (EAP) | 709 | | | | 710 | | |<-8. RADIUS Access--| 711 | | | (EAP Success) | 712 |<-9. PANA Auth Req (EAP Success)----| | 713 | | | | 714 |--10. PANA Auth Ans (Ack)---------->| | 715 | | | | 716 |--11. DHCPDISCOVER----------------->| | 717 | | | | 718 |<-12. DHCPOFFER---------------------| | 719 | | | | 720 |--13. DHCPREQUEST------------------>| | 721 | | | | 722 |<-14. DHCPACK-----*-----------------| | 723 | | | | 724 |<-15. IP session data traffic----------------> | 725 | | | | 727 Figure 7. Specific use of IPv4 link-local address as PRPA.. 729 Step 1: The DSL Modem/RG configures an IPv4 link-local address 730 [RFC3927]. It is assumed that, if the DSL network does not allow 731 modems sending and receiving ARP requests/responses to each other, 732 then the network allows IP address collision among the modems and 733 deals with it by using auxiliary information such as MAC address, 734 VLAN, etc. 736 Steps 2-3: the DSL Modem/RG discovers the IPv4 address of the PAA 737 using the PANA Authentication Agent DHCPv4 Option [RFC5192]. The 738 DSL Modem/RG uses its IPv4 link-local address with DHCP and it 739 does not request IP address allocation (i.e., DHCP server will not 740 fill 'yiaddr' in DHCP ACK in response to DHCP Inform). the DHCP 741 Option 82 is inserted into the DHCP Inform message by the DSLAM. 743 Step 4: The DSL Modem/RG initiates PANA with the newly-discovered 744 PAA. Alternatively, the PAA could initiate PANA in unsolicited 745 fashion. In that latter case, Step 4 may be skipped or run in 746 parallel with Step 5. 748 Steps 5-10: PANA and RADIUS carrying out EAP-MD5 authentication. 749 BRAS can utilize the Option 82 value discovered during Step 2. 751 Steps 11-14: Now that the DSL Modem/RG is authenticated, it 752 proceeds to configuring service IP address using DHCPv4. As soon 753 as the new IP address is confirmed by the DHCP ACK, the DSL 754 Modem/RG can stop using the IPv4 link-local address. In Step 14, 755 the DHCP ACK message carrying the IP address triggers the DSLAM to 756 update its filters with the authorized IP/MAC address of the DSL 757 Modem/RG. 759 Step 15: The DSL Modem/RG can transmit and receive IP data packets 760 using the service IP address. 762 Note that, during steps 1-14, the DSLAM (acting as EP) allows only 763 DHCP and PANA messages,and depending on deployment, address 764 resolution messages such as ARP. 766 A variation of this call flow can be generated using PANA-based PAA 767 discovery [I-D.fajardo-pana-paa-discovery] instead of DHCP for the 768 Steps 2 and 3. If DHCP Option 82 value is needed by the BRAS, it can 769 be inserted into the PANA messages as they go through the DSLAM. 771 6.5.3.2. Required Support from DSL Environment 773 This section describes the features required from various network 774 elements in DSL deployment in order to realize the described call 775 flow. Note that not all requirements are imposed due to choice of 776 PANA and some are already available irrespective of the 777 authentication protocol used (e.g., insertion of DHCP Option 82 by 778 the DSLAM). 780 6.5.3.2.1. Required Support from DSL Modem/RG 782 The DSL modem/RG must host the PANA client (PAC). 784 The DSL modem/RG must configure an IPv4 link-local address as 785 described in [RFC3927] 787 The DSL modem/RG must perform two DHCP procedures: one to discover 788 the PAA, another one to be allocated with a service/routable IP 789 address after successful PANA authentication. 791 6.5.3.2.2. Required Support from DSLAM 793 The DSLAM must be configured to act as an Enforcement Point and 794 authorize only DHCP messages and PANA messages before successful PANA 795 authentication. 797 The DSLAM must be configured to snoop DHCP messages and insert DHCP 798 option 82 in DHCP messages sent by the DSL modem/RG and use the IP 799 address found in the 'yiaddr' field of the DHCP ACK received from the 800 DHCP server to update its IP filters for authorized IPaddress/MAC 801 address. 803 6.5.3.2.3. Required Support from BRAS 805 The BRAS should host the PANA Authentication Agent (PAA), the DHCP 806 relay or server, and the AAA client. A given deployment can choose 807 to host these implementations on separate nodes as long as it defines 808 interfaces among them to pass information. 810 The reception of DHCP Discover message from an unauthenticated MAC 811 address should trigger a PAA-initiated PANA authentication procedure. 813 The DHCP server should allocate global IP addresses only to 814 authenticated MAC addresses. 816 6.5.4. Use of Unspecified IPv4 Address 818 This is a similar example to the previous one with the exception 819 that: 821 o PRPA is the unspecified IPv4 address, 823 o PAA discovery is based on PAA responding to broadcast PCI. 825 6.5.4.1. Message Flows 827 This section describes the message flows for a DSL modem/RG using an 828 unspecified IPv4 address as PRPA. 830 DSL Modem/RG DSLAM BRAS AAA server 831 (PaC) (EP) (PAA) 833 | | | | 834 | | | | 835 | | | | 836 |--1. PANA Client initiation-------->| | 837 | | | | 838 |<-2. PANA Auth Req (EAP-MD5 chal)---| | 839 | | | | 840 |--3. PANA Auth Ans (EAP-MD5 resp)-->| | 841 | | | | 842 | | |-4. RADIUS Access ->| 843 | | | Request (EAP) | 844 | | | | 845 | | |<-5. RADIUS Access--| 846 | | | (EAP Success) | 847 |<-6. PANA Auth Req (EAP Success)----| | 848 | | | | 849 |--7. PANA Auth Ans (Ack)----------->| | 850 | | | | 851 |--8. DHCPDISCOVER------------------>| | 852 | | | | 853 |<-9. DHCPOFFER----------------------| | 854 | | | | 855 |--10. DHCPREQUEST------------------>| | 856 | | | | 857 |<-11. DHCPACK-----*-----------------| | 858 | | | | 859 |<-12. IP session data traffic----------------> | 860 | | | | 862 Figure 8. Specific use of unspecified IPv4 address as PRPA. 864 Step 1: The DSL Modem/RG initiates PANA by sending a broadcasted 865 PCI. 867 The source IPv4 address of the PCI is set to 0.0.0.0. The 868 destination IPv4 address is set to 255.255.255.255. 870 Step 2: PAA responds with a PAR message which has its source IPv4 871 address set to the PAA's IP address, and the destination IPv4 872 address is set to 255.255.255.255. If the PAA is capable of 873 retrieving the PaC's MAC address from incoming PCI, then the PAR 874 is L2-unicasted using that MAC address. Otherwise, the PAR 875 message will be L2-broadcasted. 877 PaC discovers the PAA's IPv4 address when it receives the PAR 878 message. 880 Step 3: PaC sends the PAN message to the PAA's newly discovered 881 IPv4 address. 883 Steps 4-7: PANA and RADIUS carrying out EAP-MD5 authentication. 884 Note that it is possible to translate EAP-MD5/PANA to CHAP/RADIUS 885 and eliminate the need to support EAP/RADIUS. But the details of 886 such translation is outside the scope of this I-D. 888 Steps 8-11: Now that the DSL Modem/RG is authenticated, it 889 proceeds to configuring service IP address using DHCPv4. As soon 890 as the new IPv4 address is confirmed by the DHCP ACK, the DSL 891 Modem/RG can stop using the unspecified address. In Step 11, the 892 DHCP ACK message carrying the IPv4 address triggers the DSLAM to 893 update its filters with the authorized IP/MAC address of the DSL 894 Modem/RG. 896 Step 12: The DSL Modem/RG can transmit and receive IP data packets 897 using the service IP address. 899 In case the deployment requires the DHCP Option 82 as a by-product of 900 DHCP-based PAA discovery, then Steps 2-3 from previous call flow can 901 be added to this one as well. 903 A PAA implementation may not be capable of retrieving the PaC's MAC 904 address from L2 header of the incoming PANA messages, or be able to 905 send a L2-unicast even if it could retrieve the address. In such a 906 case, the PAA sends PANA messages as L2-broadcast. In order to 907 prevent other PaCs from processing the messages destined for a 908 specific PaC, each PaC is required to supply its own MAC address as a 909 payload AVP to PCI and expect it to be echoed back by the PAA in the 910 initial PAR (TBD: Define an AVP for that). PaCs shall drop PARs with 911 mismatching MAC payloads. If the PAA is capable of L2-unicasting 912 PANA messages by using the MAC address learned from the PCI payload, 913 it can do so. 915 Note that any message beyond Step 2 would include the PAA-assigned 916 and PaC-acknowledged PANA Session Id, hence use of MAC address 917 payload is not needed for those messages. 919 6.5.4.2. Required Support from DSL Environment 921 This section describes the features required from various network 922 elements in DSL deployment in order to realize the described call 923 flow. Note that not all requirements are imposed due to choice of 924 PANA and some are already available irrespective of the 925 authentication protocol used (e.g., insertion of DHCP Option 82 by 926 the DSLAM). 928 6.5.4.2.1. Required Support from the DSL Modem/RG 930 The DSL modem/RG must host the PANA client (PAC). 932 The DSL modem/RG must use an unspecified IPv4 address to send PANA 933 messages. 935 The DHCP client of the DSL modem/RG must be triggered by a successful 936 PANA authentication to configure a global IP address used as service 937 IP address. 939 6.5.4.2.2. Required Support from the DSLAM 941 The DSLAM must be configured to act as an Enforcement Point and 942 authorize only DHCP messages and PANA messages before successful PANA 943 authentication. 945 The DSLAM must be configured to snoop DHCP messages and insert DHCP 946 option 82 in DHCP messages sent by the DSL modem/RG and use the IP 947 address found in the 'yiaddr' field of the DHCP ACK received from the 948 DHCP server to update its IP filters for authorized IPaddress/MAC 949 address. 951 6.5.4.2.3. Required Support from the BRAS 953 The BRAS should host the PANA Authentication Agent (PAA), the DHCP 954 relay or server, and the AAA client. A given deployment can choose 955 to host these implementations on separate nodes as long as it defines 956 interfaces among them to pass information. 958 The PAA must be capable of L2-unicasting PANA messages by using the 959 MAC address learned from the received DHCP Discover. 961 The reception of DHCP Discover from an unauthenticated MAC address 962 should trigger a PAA-initiated PANA authentication procedure. 964 The DHCP server should allocate IP addresses only to authenticated 965 MAC addresses. 967 7. Security Considerations 969 The DSL infrastructure that connects the CPE to the DSLAM/BRAS is 970 assumed to run over a physically-secured non-shared media. For that 971 reason, neither the use of a key-generating EAP method nor a secure 972 L2/L3 channel bootstrapped by PANA is required. The current DSL 973 deployments are satisfied by using non-key-generating client-only 974 authentication methods (e.g., CHAP and its EAP equivalent EAP-MD5). 975 The same model can be maintained even with the PANA-based 976 deployments. If next generation deployments prefer key-generating 977 mutual authentication methods, they can be naturally used with PANA 978 too. 980 8. IANA Considerations 982 This document has no actions for IANA. 984 9. Acknowledgements 986 We would like to thank to Ted Lemon, Peter Arberg, Iljitsch van 987 Beijnum, Friedrich Armbruster, Aurelien Violet and Blandine Cauwet 988 for their valuable comments that contribute to improve this document. 990 10. References 992 10.1. Normative References 994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 995 Requirement Levels", BCP 14, RFC 2119, March 1997. 997 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 998 RFC 2131, March 1997. 1000 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 1001 RFC 3046, January 2001. 1003 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1004 and M. Carney, "Dynamic Host Configuration Protocol for 1005 IPv6 (DHCPv6)", RFC 3315, July 2003. 1007 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1008 Levkowetz, "Extensible Authentication Protocol (EAP)", 1009 RFC 3748, June 2004. 1011 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1012 Yegin, "Protocol for Carrying Authentication for Network 1013 Access (PANA)", RFC 5191, May 2008. 1015 [RFC5192] Morand, L., Yegin, A., Kumar, S., and S. Madanapalli, 1016 "DHCP Options for Protocol for Carrying Authentication for 1017 Network Access (PANA) Authentication Agents", RFC 5192, 1018 May 2008. 1020 10.2. Informative References 1022 [I-D.fajardo-pana-paa-discovery] 1023 Fajardo, V., "Simple PANA PAA Discovery Protocol", 1024 draft-fajardo-pana-paa-discovery-00 (work in progress), 1025 January 2008. 1027 [I-D.ietf-pana-ipsec] 1028 Parthasarathy, M., "PANA Enabling IPsec based Access 1029 Control", draft-ietf-pana-ipsec-07 (work in progress), 1030 July 2005. 1032 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1033 Discovery for IP Version 6 (IPv6)", RFC 2461, 1034 December 1998. 1036 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1037 Autoconfiguration", RFC 2462, December 1998. 1039 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1040 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1041 May 2005. 1043 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1044 "Protocol for Carrying Authentication for Network Access 1045 (PANA) Requirements", RFC 4058, May 2005. 1047 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 1048 A. Yegin, "Protocol for Carrying Authentication for 1049 Network Access (PANA) Framework", RFC 5193, May 2008. 1051 [TR101] DSL Forum TR-101, "Migration to Ethernet Based DSL 1052 Aggregation", April 2006. 1054 [TR25] DSL Forum TR-025, "Core Network Architecture for Access to 1055 Legacy Data Network over ADSL", September 1999. 1057 [TR59] DSL Forum TR-059, "DSL Evolution - Architecture 1058 Requirements for the Support of QoS-Enabled IP Services", 1059 September 2003. 1061 [WT134] DSL Forum WT-134 Draft Version 1.0, "Policy Control 1062 Framework for DSL", April 2006. 1064 [WT146] DSL Forum WT-146 Draft Version 1.0, "IP Sessions", 1065 February 2006. 1067 Authors' Addresses 1069 Lionel Morand 1070 France Telecom R&D 1071 France 1073 Email: lionel.morand@orange-ftgroup.com 1075 Alper E. Yegin 1076 Samsung 1077 Turkey 1079 Email: a.yegin@partner.samsung.com 1081 Yoshihiro Ohba 1082 Toshiba America Research, Inc. 1083 USA 1085 Email: yohba@tari.toshiba.com 1087 John Kaippallimalil 1088 Huawei Technologies 1089 USA 1091 Email: jkaippal@huawei.com 1093 Full Copyright Statement 1095 Copyright (C) The IETF Trust (2008). 1097 This document is subject to the rights, licenses and restrictions 1098 contained in BCP 78, and except as set forth therein, the authors 1099 retain all their rights. 1101 This document and the information contained herein are provided on an 1102 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1103 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1104 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1105 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1106 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1107 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1109 Intellectual Property 1111 The IETF takes no position regarding the validity or scope of any 1112 Intellectual Property Rights or other rights that might be claimed to 1113 pertain to the implementation or use of the technology described in 1114 this document or the extent to which any license under such rights 1115 might or might not be available; nor does it represent that it has 1116 made any independent effort to identify any such rights. Information 1117 on the procedures with respect to rights in RFC documents can be 1118 found in BCP 78 and BCP 79. 1120 Copies of IPR disclosures made to the IETF Secretariat and any 1121 assurances of licenses to be made available, or the result of an 1122 attempt made to obtain a general license or permission for the use of 1123 such proprietary rights by implementers or users of this 1124 specification can be obtained from the IETF on-line IPR repository at 1125 http://www.ietf.org/ipr. 1127 The IETF invites any interested party to bring to its attention any 1128 copyrights, patents or patent applications, or other proprietary 1129 rights that may cover technology that may be required to implement 1130 this standard. Please address the information to the IETF at 1131 ietf-ipr@ietf.org.