idnits 2.17.1 draft-ietf-pana-panaoverdsl-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 25, 2010) is 5202 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 (==), 4 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: July 29, 2010 Samsung 6 Y. Ohba 7 Toshiba America Research, Inc. 8 J. Kaippallimalil 9 Huawei Technologies 10 January 25, 2010 12 Application of PANA framework to DSL networks 13 draft-ietf-pana-panaoverdsl-01 15 Abstract 17 This document provides guidelines for PANA deployment over DSL access 18 networks. The document specifically describes the introduction of 19 PANA in DSL networks migrating from a traditional PPP access model to 20 a pure IP-based access environment. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on July 29, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. PANA Framework Overview . . . . . . . . . . . . . . . . . . . 3 66 5. PANA in DSL environment . . . . . . . . . . . . . . . . . . . 4 67 5.1. Evolution of DSL Environment . . . . . . . . . . . . . . . 4 68 5.2. Advisability of Introducing PANA in DSL Environment . . . 6 69 6. Applicability of PANA to IP Session based DSL Environment . . 7 70 6.1. Functional Architecture . . . . . . . . . . . . . . . . . 7 71 6.1.1. Location of PAA and EP . . . . . . . . . . . . . . . . 7 72 6.1.2. Location of the PaC . . . . . . . . . . . . . . . . . 7 73 6.2. IP Address Configuration . . . . . . . . . . . . . . . . . 9 74 6.3. Authorized Device ID . . . . . . . . . . . . . . . . . . . 10 75 6.4. Cryptographic Protection . . . . . . . . . . . . . . . . . 10 76 6.5. Implementation Options . . . . . . . . . . . . . . . . . . 10 77 6.5.1. Generic Message Flows . . . . . . . . . . . . . . . . 11 78 6.5.2. Use of IPv6 Link-Local Address . . . . . . . . . . . . 12 79 6.5.3. Use of IPv4 Link-Local Address . . . . . . . . . . . . 15 80 6.5.4. Use of Unspecified IPv4 Address . . . . . . . . . . . 19 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 PANA (Protocol for carrying Authentication for Network Access) design 92 provides support for various types of deployments. DSL networks were 93 identified as a typical example of such a deployment. This document 94 provides guidelines for PANA deployment over DSL access networks. 95 The document specifically describes the introduction of PANA in DSL 96 networks migrating from a traditional PPP access model to a pure IP- 97 based access environment. In such environment, additional 98 authentication mechanisms are required to provide a complete secure 99 network access solution to Network Access Providers (NAP) willing to 100 overtake inadequate methods such as basic DSL link-layer 101 identification or application-layer ad-hoc authentication mechanisms 102 (e.g., HTTP redirects with web-based login). 104 2. Specification of Requirements 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Terminology 112 This document uses the PANA terminology defined in [RFC5191]. 113 This document uses the DSL Forum terminology defined in [TR25], 114 [TR59], [TR101] and [WT146]. 116 4. PANA Framework Overview 118 PANA (Protocol for carrying Authentication for Network Access) is a 119 link-layer agnostic transport for EAP [RFC3748] to enable network 120 access authentication between clients and access networks. 122 The motivation to define such a protocol and the requirements are 123 described in [RFC4058]. Protocol details are documented in 124 [RFC5191]. There are components that are part of a complete secure 125 network access solution but are outside of the PANA protocol 126 specification. These components include PANA Authentication Agent 127 (PAA) discovery mechanisms, based either on DHCP [RFC5192] or a 128 simple multicast-based protocol [I-D.fajardo-pana-paa-discovery], as 129 well as IP address configuration, authentication method choice, 130 filter rule installation, data traffic protection, and PAA-EP 131 protocol [RFC5193]. 133 Figure 1 illustrates the functional entities involved in the PANA 134 framework and the interfaces (protocols, APIs) among them. See 135 [RFC5191] and [RFC5193] for further details. 136 RADIUS/ 137 Diameter/ 138 +-----+ PANA +-----+ LDAP/ API +-----+ 139 | PaC |<----------------->| PAA |<---------------->| AS | 140 +-----+ +-----+ +-----+ 141 ^ ^ 142 | | 143 | +-----+ | 144 IKE/ +-------->| EP |<--------+ API/ Other 145 4-way handshake (*) +-----+ 147 Figure 1: PANA Functional Model 149 PaC: PANA Client 151 PAA: PANA Authentication Agent 153 AS: Authentication Server 155 EP: Enforcement Point 157 (*) PaC-EP secure association protocol is not needed in DSL networks unless 158 per-packet cryptographic security is needed. 160 The PANA design provides support for various types of deployments. 161 DSL networks were identified as a typical example of such a 162 deployment (see Appendix A of [RFC4058]). 164 5. PANA in DSL environment 166 5.1. Evolution of DSL Environment 168 Traditional DSL deployments followed the architectural guidelines 169 provided in [TR25] or [TR59]. Theses architectures use ATM to 170 aggregate the access networks into a regional broadband network. The 171 traffic aggregated from the access nodes (DSLAM) is steered to an IP 172 node, the Broadband Remote Access Server (BRAS). In this 173 environment, PPP sessions are set-up between the CPN (Customer 174 Premises Network) and the BRAS, which acts as either a PPP 175 termination point or a L2TP Access Concentrator (LAC) tunnelling 176 multiple subscriber PPP sessions directly to an Internet/Corporate 177 Service Provider. The CPN is usually defined as the combination of 178 the DSL Modem or Residential Gateway (RG), acting as termination 179 point of the physical DSL signal, and the subscriber's computers and 180 other devices (named hosts hereafter) connected to the DSL Modem/RG. 182 Host--+ +-- ISP1 183 | DSL link | 184 +-- DSL Modem/RG --- DSLAM --- BRAS --+-- ISP2 185 | | 186 Host--+ +-- ISP3 188 <------- CPN -------> <----- NAP ----> <-- ISP --> 190 Figure 2: DSL Model 191 The devices at the customer premises have been shown as "hosts" in 192 the above network. 194 DSL architectures are now emerging from a "low" speed best effort 195 delivery network to an infrastructure capable of supporting higher 196 subscriber bit rates. At the application layer, DSL service 197 providers are looking to support enhanced services layered on top of 198 basic Internet access, including entertainment video services 199 (Broadcast TV and VoD), video conferencing, VoIP, gaming, and 200 business class services (e.g. IP VPN), that have prohibitive 201 requirements to deploy them in a pure ATM based environment. Moving 202 to on a Gigabit Ethernet instead of an ATM aggregation network offers 203 an highly efficient transport technology for delivering large amounts 204 of bandwidth to a highly distributed access node topology. Migration 205 from ATM-based to an Ethernet based aggregation network in the 206 context of TR-25 and TR-59 based architectures is described in 207 [TR101]. 209 In this evolution path towards Giga Ethernet, there is in parallel a 210 growing interest in migrating from the traditional PPP access model 211 to one relying on an network access control of IP sessions 212 establishment. The "IP Sessions" model is a concept introduced in 213 DSL Forum that covers a cycle consisting of IP session Detection and 214 creation, application of IP session policies, and IP session 215 termination. Details of this work are documented in [WT146]. 216 Basically, an IP session represents subscriber IP traffic which is 217 associated with a subscriber's IP address parameters. A subscriber 218 may have multiple IP addresses (or sessions) in simultaneous use. An 219 IP session may in turn be associated with multiple IP flows. The 220 relation between subscribers and policies associated with it are 221 described in [WT134]. The policy relationships in this document show 222 that subscribers have services that are governed by policies. Thus, 223 the same subscriber policies govern all IP sessions/flows belonging 224 to the subscriber. 226 5.2. Advisability of Introducing PANA in DSL Environment 228 Among other challenges for DSL environment migrating from pure PPP 229 based networks, one is the need for the creation of an IP session 230 subscriber authentication model to secure network access and IP 231 address management provided by a DHCP infrastructure. Indeed, 232 contrary to PPP environment, an IP sessions model has no built-in 233 mechanisms for authentication purposes in a DHCP based environment. 234 If location-based authentication relying on access line 235 identification is actually possible (see in [TR101] the use of the 236 DHCP Relay Agent Information option, aka DHCP option 82 [RFC3046], 237 inserted by the Access Node), additional mechanisms are required to 238 provide Network Access Providers (NAP) with an explicit per- 239 subscriber access authentication solution, in order to . 241 Providing a native support of EAP frames over IP, PANA is therefore a 242 natural candidate to provide the protocol support of an IP subscriber 243 authentication model. Moreover, PANA provides functionalities 244 fulfilling basic and advanced security requirements within an IP 245 session based environment (as described in [WT146]) , such as: 247 o IP address based session management mechanisms, using an explicit 248 session identifier; 250 o Authentication mechanism independent of the physical medium type; 252 o Enabling per-session enforcement policies (i.e. filters) depending 253 on the creation and deletion of the PANA session; 255 o Enabling session keep-alive and session monitoring functionalities 256 to optimize the use of resources and provide an accurate picture 257 of the state of a subscriber session (as described in [WT146]). 259 In this new context for DSL networks, PANA may be introduced to 260 authenticate the credentials of a user prior to the setup of an IP 261 session. The user selects the service provider and authenticates 262 itself. During IP session setup, policies for the use of connection 263 resources related to the IP session are established in the BRAS. 264 These policies govern the subscriber's use of network resources. IP 265 flows are accounted for and associated with the IP session and the 266 service session that triggered it. 268 Based on the content of the Liaison Statement sent by the DSL Forum 269 to the IETF, the specific subscriber authentication requirements were 270 discussed at the PANA WG meeting at IETF70 in Vancouver (Dec 5, 271 2007). The result of this analysis confirmed the applicability of 272 the PANA protocol for the DSL Forum's subscriber authentication 273 requirements. PANA WG Meeting analysis can be found in the 70th IETF 274 meeting proceedings 275 (http://www.ietf.org/proceedings/07dec/slides/pana-3/sld1.htm). 277 6. Applicability of PANA to IP Session based DSL Environment 279 6.1. Functional Architecture 281 6.1.1. Location of PAA and EP 283 In a PPP based environment, the BRAS is in charge of interfacing with 284 CPE for authenticating and authorizing them for the network access 285 service as well as performing policy control by acting as en 286 enforcement point. In an IP session based environment, such 287 functionalities may be provided at the same level by locating the PAA 288 and EP entities in the BRAS. One advantage provided by this 289 implementation is to preserve a improved and well-established DSL 290 network configuration. Moreover, PAA and EP being collocated, there 291 is no need to rely on an external interface between them to carry the 292 authorized client attributes i.e. filters, an API being sufficient in 293 that case. 295 The PANA design providing also the support for network configuration 296 in which PAA and EP are not collocated, as described in [RFC5193], 297 the PAA may be located in the BRAS while the EP function is the 298 DSLAM. In that specific case, the PAA-EP interface implemented 299 between the BRAS and the DSLAM may be based on the current DHCP 300 triggering or on a dedicated API. 302 In an IP session based environment, the PAA will have to verify the 303 credentials provided by a PaC located in the CPN and authorize 304 network access to the host/gateway associated with the client. 306 6.1.2. Location of the PaC 308 6.1.2.1. Bridged Mode 310 In the Bridged mode, the DSL Modem/RG acts as a simple link-layer 311 bridge. The DSL Modem/RG is here transparent at the IP layer. The 312 hosts (e.g. PC) connected to the DSL Modem/RG in the CPN and the 313 BRAS are then on the same IP link. Hosts may have a statically 314 configured IP address or obtain an IP address from a DHCP server 315 through the DSLAM (acting as a Layer-2 DHCP Relay agent as described 316 in [TR101]) and the BRAS (filtering DHCP requests towards the DHCP 317 server). 319 In this model, the PaC can be easily implemented in the hosts. Any 320 host connected to the DSL Modem/RG will be authenticated by the PAA 321 locating in the BRAS. It is therefore possible to perform a network 322 access control on a per-host basis, as required by the IP session 323 model. 325 Host--+ 326 (PaC) | 327 +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP 328 | (Bridge) (PAA,EP) 329 Host--+ 330 (PaC) 332 Figure 3: Bridged Mode 334 6.1.2.2. Routed Mode 336 In the Routed mode, the DSL Modem/RG acts as an IP router for the 337 CPN. In this configuration, only the DSL Modem/RG and BRAS are on 338 the same IP link. The DSL Modem/RG may have a statically configured 339 IP address or obtain an IPv4 address or an IPv6 prefix from a DHCP 340 server through the DSLAM (acting as a Layer-2 DHCP-Relay agent as 341 described in [TR101]) and the BRAS (filtering DHCP requests towards 342 the DHCP server). Hosts connected to the DSL Modem/RG may use either 343 (1) either private IP addresses in an IPv4 environment with the DSL 344 Modem/RG implemented a Network Address Port Translation (NAPT) 345 function or (2) routable IP addresses if the modem is an IPv6 router. 347 Host--+ 348 | 349 +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP 350 | (Router, PaC) (PAA,EP) 351 Host--+ 352 IPv4 Case (1) 354 Host--+ 355 (PaC) | 356 +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP 357 | (Router, PaC) (PAA,EP) 358 Host--+ 359 (PaC) 360 IPv6 Case (2) 362 Figure 4: Routed Mode 364 In the IPv4 case (1), the simplest method is to implement the PaC in 365 the DSL Modem/RG. Only the DSL Modem/RG will be authenticated/ 366 authorized by the PAA. All hosts at the customer premises will then 367 have access to the service provider's network using private IP 368 addresses obtained from the DSL Modem/RG. 370 (NOTE: Per-host authentication may be achieved also in the Routed 371 mode if the EP function is performed by the DSL Modem/RG. However, 372 it is for further studies to see how to introduce such a 373 configuration in the global DSL Forum "IP Sessions" model.) 375 In the IPv6 case (2), the BRAS will detect any new IP address used by 376 the DSL Modem/RG and the hosts connected to the DSL Modem/RG when 377 using global scope IPv6 addresses. To allow a suitable network 378 access rights management based on the IP address, PANA clients will 379 have to be therefore implemented in the DSL Modem/RG and the hosts. 380 The network access control is therefore performed on a per-host 381 basis, in addition to the handling of the DSL Modem/RG 's own IP 382 sessions. 384 6.2. IP Address Configuration 386 In the context of PANA deployment in DSL environment based on the IP 387 Sessions model, the IP address configured by the PaC prior to PANA 388 execution (so-called Pre-PANA Address or PRPA) MAY be obtained by one 389 of the following methods: 391 1. Static IP Address confniguration: the PaC MAY be statically 392 configured with an IP address. This address is therefore used as 393 a PRPA. 395 2. DHCP-based IP Address Confirguration: the PaC MAY dynamically 396 configure the PRPA using DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. 398 3. IPv6 Global Adress Stateless Address Autoconfiguration: in IPv6 399 environment, the PaC MAY configure global address(es) using IPv6 400 stateless auto-configuration [RFC2462] if router advertisements 401 with prefixes are made available, as specified in [RFC2461]. 403 4. Dynamic Configuration of Link-Local Address: The PaC MAY 404 configure an IPv4 link-local address [RFC3927] and/or an IPv6 405 link-local address [RFC2462]. 407 5. Unspecified IPv4 Address: PaC MAY use an unspecified IPv4 address 408 (IPv4 address set to 0.0.0.0) as source IPv4 address. 410 After a successful authentication, the PaC MAY have to configure a 411 new IP address for communication with other nodes if the PRPA is an 412 unspecified IPv4 address, a local-use IP address (e.g., a link-local 413 or private IP address) or a temporarily allocated IP address. This 414 IP address is called a post-PANA address (POPA). An operator might 415 choose allocating a POPA only after successful PANA authorization 416 either to prevent waste of premium (e.g., globally routable) IP 417 resources until the PaC is authorized (especially in the IPv4 case), 418 or to enable PaC identity based address assignment. POPA can be 419 configured using DHCP [RFC2131] [RFC3315] or using IPv6 stateless 420 auto-configuration [RFC2462]. 422 6.3. Authorized Device ID 424 The MAC address of the PaC can be used as a session attribute of the 425 subscriber and used by the Enforcement Point (EP) for packet 426 filtering once the PANA authentication successfully completed. The 427 MAC address can also be used by the network to assign a subscriber- 428 dependent IP address using DHCP. Therefore, the association between 429 the subscriber ID that was used with the PANA authentication and the 430 session attributes (MAC address and IP address) can be formed. 432 6.4. Cryptographic Protection 434 DSL networks are protected by physical means. Eavesdropping and 435 spoofing attacks are prevented by keeping the unintended users 436 physically away from the network media. Therefore, generally 437 cryptographic protection of data traffic is not common. 438 Nevertheless, if enhanced security is deemed necessary for any 439 reason, IPsec-based access control can be enabled on DSL networks as 440 well by using the method described in [I-D.ietf-pana-ipsec]. 442 6.5. Implementation Options 444 This section provides possible implementation options of PANA in DSL 445 deployments. 447 Section 6.5.1 describes the basic components of generic message 448 flows. 450 Section 6.5.2 describes the specific use of IPv6 link-local address 451 as Pre-PANA Address (PRPA). 453 Section 6.5.3 describes the specific use of IPv4 link-local address 454 as PRPA. 456 Section 6.5.4 describes the specific use of unspecified IPv4 address 457 as PRPA. 459 For each specific scenario, the features required from various 460 network elements in DSL deployment are described. 462 6.5.1. Generic Message Flows 464 This is the description of the basic components of generic message 465 flows. 467 DSL Modem/RG, DSLAM BRAS AAA server 468 or Host 469 (PaC) (EP) (PAA) 471 | | | | 472 |<--1. PRPA configuration----------->| | 473 | | | | 474 | | | | 475 |<--2. PAA discovery---------------->| | 476 | | | | 477 | | | | 478 |<--3. PANA authentication---------->|<--RADIUS/Diameter->| 479 | | | authentication | 480 | | | | 481 |<--4. POPA configuration----------->| | 482 | | | | 483 | |<-5. EP Filter-->| | 484 | | setup | | 485 | | | | 486 |<--6. IP session data traffic----------------> | 487 | | | | 488 | | | | 490 Figure 5. Generic PANA over DSL call flow 492 Depending on the deployment, either the DSL Modem acts as a RG and 493 therefore only that node is authenticated; or the DSL Modem acts as a 494 bridge and hosts connected to that bridge gets individually 495 authenticated. 497 Step 1: The DSL Modem/RG or host, acting as PaC, configures a pre- 498 PANA IP address (PRPA).This step is skipped if the PaC is using an 499 unspecified IPv4 address. 501 Step 2: PaC discovers the IP address of the PAA. PaC may use DHCP 502 [RFC5192] or the discovery mechanism provided by PANA 503 [I-D.fajardo-pana-paa-discovery]. 505 Step 3: PaC and PAA performs authentication using EAP and AAA 506 protocols (RADIUS, Diameter, etc.) 508 Step 4: In case the PRPA was an unspecified IPv4 address, 509 temporary IP address or limited-use IP address, the PaC configures 510 a post-PANA IP address (POPA). This is the service IP address. 512 Step 5: PAA instructs the EP to allow authorized IP traffic of 513 PaC. This step may be implicitly part of step 4 (e.g. DHCPACK 514 with IP address configuration) or performed using a specific API. 516 Step 6: PaC can transmit and receive IP data packets. 518 Note that the step 4 is optional. Depending on the network 519 configuration and the IP address resource management, it may not be 520 needed for the PaC to configure a new IP address after the PANA 521 authentication. 523 6.5.2. Use of IPv6 Link-Local Address 525 In this example, the following configuration is considered: 527 o The DSL modem/RG is authenticated;. 529 o PRPA is an IPv6 link-local address obtained by using IPv6 530 stateless auto-configuration [RFC2462]; 532 o PAA discovery is based on PAA responding to the PANA Client 533 Initiation request sent to a multicast address; 535 o Authentication method used is EAP-MD5; 537 o POPA is configured using DHCPv6 after successful authentication; 539 o EP is triggered by the DHCREPLY sent by the DHCP server, including 540 the assigned IPv6 address in the option 'OPTION_IAADDR'. 542 6.5.2.1. Message Flows 544 This section describes the message flows for a DSL modem/RG using an 545 IPv6 link-local address as PRPA. 547 DSL Modem/RG DSLAM BRAS AAA server 548 (PaC) (EP) (PAA) 550 | | | | 551 1. Link-local PRPA config | | 552 | | | | 553 | | | | 554 |--2. PANA Client initiation-------->| | 555 | | | | 556 |<-3. PANA Auth Req (EAP-MD5 chal)---| | 557 | | | | 558 |--4. PANA Auth Ans (EAP-MD5 resp)-->| | 559 | | | | 560 | | |-5. RADIUS Access ->| 561 | | | Request (EAP) | 562 | | | | 563 | | |<-6. RADIUS Access--| 564 | | | (EAP Success) | 565 |<-7. PANA Auth Req (EAP Success)----| | 566 | | | | 567 |--8. PANA Auth Ans (Ack)----------->| | 568 | | | | 569 |--9. DHCPSOLICIT------------------->| | 570 | | | | 571 |<-10. DHCPADVERTISE-----------------| | 572 | | | | 573 |--11. DHCPREQUEST------------------>| | 574 | | | | 575 |<-12. DHCPREPLY---*-----------------| | 576 | | | | 577 |<-13. IP session data traffic----------------> | 578 | | | | 580 Figure 6. Specific use of IPv6 link-local address as PRPA 582 Depending on the deployment, either the DSL Modem acts as a RG and 583 therefore only that node is authenticated; or the DSL Modem acts as a 584 bridge and hosts connected to that bridge gets individually 585 authenticated. 587 Step 1: The DSL Modem/RG configures an IPv6 link-local address 588 [RFC2462]. It is assumed that, if the DSL network does not allow 589 modems sending and receiving Neighbor Disovery messages to each 590 other, then the network allows IP address collision among the 591 modems and deals with it by using auxiliary information such as 592 MAC address, VLAN, etc. 594 Step 2: The DSL Modem/RG initiates PANA by sending a PCI. 596 The source IPv6 address of the PCI is the IPv6 link-local address 597 configured in Step 1. The destination IPv6 address is set to a 598 reserved multicast address. This message is transparently 599 forwarded to the BRAS. 601 Step 3: PAA responds with a PANA-Authentication-Request message, 602 including its own IPv6 address as source IPv6 address. 604 PaC discovers the PAA's IPv6 address when it receives the PAR 605 message. 607 Step 4: PaC sends the PANA-Authentication-Answer message to the 608 PAA's newly discovered IPv6 address. 610 Steps 5-8: PANA and RADIUS carrying out EAP-MD5 authentication. 611 Note that it is possible to translate EAP-MD5/PANA to CHAP/RADIUS 612 and eliminate the need to support EAP/RADIUS. But the details of 613 such translation is outside the scope of this I-D. 615 Steps 9-12: Now that the DSL Modem/RG is authenticated, it 616 proceeds to configuring a global (service) IPv6 address using 617 DHCPv6. As soon as the gloabl IPv6 address is confirmed by the 618 DHCPREPLY, the DSL Modem/RG stops using the link-local address. 619 In Step 12, the DHCPREPLY message carrying the IPv6 address 620 triggers the DSLAM to update its filters with the authorized IP/ 621 MAC address of the DSL Modem/RG. 623 Step 13: The DSL Modem/RG can transmit and receive IP data packets 624 using the service IP address. 626 Note that, during steps 1-12, the DSLAM (acting as EP) allows only 627 DHCP and PANA messages and, depending on network configuration, 628 address resolution messages such as IPv6 Neighbor Discovery messages. 630 A variation of this call flow can be generated by using DHCP-based 631 PAA discovery [RFC5192] instead of the multicasted PCI (Step 2). If 632 DHCP Option 82 value is needed by the BRAS, it can be inserted at 633 this stage by the DSLAM. 635 6.5.2.2. Required Support from DSL Environment 637 This section describes the features required from various network 638 elements in DSL deployment in order to realize the described call 639 flow. Note that not all requirements are imposed due to choice of 640 PANA and some are already available irrespective of the 641 authentication protocol used (e.g., insertion of DHCP Option 82 by 642 the DSLAM). 644 6.5.2.2.1. Required Support from the DSL Modem/RG 646 The DSL modem/RG must host the PANA client (PAC). 648 The DSL modem/RG must configure an IPv6 link-local address before 649 sending PANA messages. 651 The PaC of the DSL modem/RG must be prepared to receive unsollicited 652 PANA-Authentication-Request, following a first DHCP Discover. 654 The DHCP client of the DSL modem/RG must be triggered by a successful 655 PANA authentication to configure a global IP address used as service 656 IP address. 658 6.5.2.2.2. Required Support from the DSLAM 660 The DSLAM must be configured to act as an Enforcement Point and 661 authorize only DHCP messages and PANA messages before successful PANA 662 authentication. 664 The DSLAM must be configured to snoop DHCP messages and insert DHCP 665 option 82 in DHCP messages sent by the DSL modem/RG and use the IP 666 address found in the DHCPREPLY received from the DHCP server to 667 update its IP filters for authorized IPaddress/MAC address. 669 6.5.2.2.3. Required Support from the BRAS 671 The BRAS should host the PANA Authentication Agent (PAA), the DHCP 672 relay or server, and the AAA client. A given deployment can choose 673 to host these implementations on separate nodes as long as it defines 674 interfaces among them to pass information. 676 The reception of DHCP Solicit message from an unauthenticated MAC 677 address should trigger a PAA-initiated PANA authentication procedure. 679 The DHCP server should allocate global IP addresses only to 680 authenticated MAC addresses. 682 6.5.3. Use of IPv4 Link-Local Address 684 In this example, the following configuration is considered: 686 o DSL modem/RG is authenticated, 687 o PRPA is a IPv4 link-local address, 689 o PAA discovery is based on DHCP, 691 o Authentication method used is EAP-MD5, 693 o POPA is configured using DHCPv4 after successful authentication, 695 o EP is triggered by DHCPACK whose 'yiaddr' field is filled. 697 6.5.3.1. Message Flows 699 This section describes the message flows for a DSL modem/RG using a 700 IPv4 link-local address as PRPA. 702 DSL Modem/RG DSLAM BRAS AAA server 703 (PaC) (EP) (PAA) 705 | | | | 706 1. IPv4 Link-local PRPA config | | 707 | | | | 708 | | | | 709 |--2. DHCPINFORM *(req.PAA opt.)-->| | 710 | | | | 711 |<-3. DHCPACK (PAA option)-----------| | 712 | | | | 713 |--4. PANA Client initiation-------->| | 714 | | | | 715 |<-5. PANA Auth Req (EAP-MD5 chal)---| | 716 | | | | 717 |--6. PANA Auth Ans (EAP-MD5 resp)-->| | 718 | | | | 719 | | |-7. RADIUS Access ->| 720 | | | Request (EAP) | 721 | | | | 722 | | |<-8. RADIUS Access--| 723 | | | (EAP Success) | 724 |<-9. PANA Auth Req (EAP Success)----| | 725 | | | | 726 |--10. PANA Auth Ans (Ack)---------->| | 727 | | | | 728 |--11. DHCPDISCOVER----------------->| | 729 | | | | 730 |<-12. DHCPOFFER---------------------| | 731 | | | | 732 |--13. DHCPREQUEST------------------>| | 733 | | | | 734 |<-14. DHCPACK-----*-----------------| | 735 | | | | 736 |<-15. IP session data traffic----------------> | 737 | | | | 739 Figure 7. Specific use of IPv4 link-local address as PRPA. 741 Step 1: The DSL Modem/RG configures an IPv4 link-local address 742 [RFC3927]. It is assumed that, if the DSL network does not allow 743 modems sending and receiving ARP requests/responses to each other, 744 then the network allows IP address collision among the modems and 745 deals with it by using auxiliary information such as MAC address, 746 VLAN, etc. 748 Steps 2-3: the DSL Modem/RG discovers the IPv4 address of the PAA 749 using the PANA Authentication Agent DHCPv4 Option [RFC5192]. The 750 DSL Modem/RG uses its IPv4 link-local address with DHCP and it 751 does not request IP address allocation (i.e., DHCP server will not 752 fill 'yiaddr' in DHCP ACK in response to DHCP Inform). the DHCP 753 Option 82 is inserted into the DHCP Inform message by the DSLAM. 755 Step 4: The DSL Modem/RG initiates PANA with the newly-discovered 756 PAA. Alternatively, the PAA could initiate PANA in unsolicited 757 fashion. In that latter case, Step 4 may be skipped or run in 758 parallel with Step 5. 760 Steps 5-10: PANA and RADIUS carrying out EAP-MD5 authentication. 761 BRAS can utilize the Option 82 value discovered during Step 2. 763 Steps 11-14: Now that the DSL Modem/RG is authenticated, it 764 proceeds to configuring service IP address using DHCPv4. As soon 765 as the new IP address is confirmed by the DHCP ACK, the DSL 766 Modem/RG can stop using the IPv4 link-local address. In Step 14, 767 the DHCP ACK message carrying the IP address triggers the DSLAM to 768 update its filters with the authorized IP/MAC address of the DSL 769 Modem/RG. 771 Step 15: The DSL Modem/RG can transmit and receive IP data packets 772 using the service IP address. 774 Note that, during steps 1-14, the DSLAM (acting as EP) allows only 775 DHCP and PANA messages,and depending on deployment, address 776 resolution messages such as ARP. 778 A variation of this call flow can be generated using PANA-based PAA 779 discovery [I-D.fajardo-pana-paa-discovery] instead of DHCP for the 780 Steps 2 and 3. If DHCP Option 82 value is needed by the BRAS, it can 781 be inserted into the PANA messages as they go through the DSLAM. 783 6.5.3.2. Required Support from DSL Environment 785 This section describes the features required from various network 786 elements in DSL deployment in order to realize the described call 787 flow. Note that not all requirements are imposed due to choice of 788 PANA and some are already available irrespective of the 789 authentication protocol used (e.g., insertion of DHCP Option 82 by 790 the DSLAM). 792 6.5.3.2.1. Required Support from DSL Modem/RG 794 The DSL modem/RG must host the PANA client (PAC). 796 The DSL modem/RG must configure an IPv4 link-local address as 797 described in [RFC3927] 799 The DSL modem/RG must perform two DHCP procedures: one to discover 800 the PAA, another one to be allocated with a service/routable IP 801 address after successful PANA authentication. 803 6.5.3.2.2. Required Support from DSLAM 805 The DSLAM must be configured to act as an Enforcement Point and 806 authorize only DHCP messages and PANA messages before successful PANA 807 authentication. 809 The DSLAM must be configured to snoop DHCP messages and insert DHCP 810 option 82 in DHCP messages sent by the DSL modem/RG and use the IP 811 address found in the 'yiaddr' field of the DHCP ACK received from the 812 DHCP server to update its IP filters for authorized IPaddress/MAC 813 address. 815 6.5.3.2.3. Required Support from BRAS 817 The BRAS should host the PANA Authentication Agent (PAA), the DHCP 818 relay or server, and the AAA client. A given deployment can choose 819 to host these implementations on separate nodes as long as it defines 820 interfaces among them to pass information. 822 The reception of DHCP Discover message from an unauthenticated MAC 823 address should trigger a PAA-initiated PANA authentication procedure. 825 The DHCP server should allocate global IP addresses only to 826 authenticated MAC addresses. 828 6.5.4. Use of Unspecified IPv4 Address 830 This is a similar example to the previous one with the exception 831 that: 833 o PRPA is the unspecified IPv4 address, 835 o PAA discovery is based on PAA responding to broadcast PCI. 837 6.5.4.1. Message Flows 839 This section describes the message flows for a DSL modem/RG using an 840 unspecified IPv4 address as PRPA. 842 DSL Modem/RG DSLAM BRAS AAA server 843 (PaC) (EP) (PAA) 845 | | | | 846 | | | | 847 | | | | 848 |--1. PANA Client initiation-------->| | 849 | | | | 850 |<-2. PANA Auth Req (EAP-MD5 chal)---| | 851 | | | | 852 |--3. PANA Auth Ans (EAP-MD5 resp)-->| | 853 | | | | 854 | | |-4. RADIUS Access ->| 855 | | | Request (EAP) | 856 | | | | 857 | | |<-5. RADIUS Access--| 858 | | | (EAP Success) | 859 |<-6. PANA Auth Req (EAP Success)----| | 860 | | | | 861 |--7. PANA Auth Ans (Ack)----------->| | 862 | | | | 863 |--8. DHCPDISCOVER------------------>| | 864 | | | | 865 |<-9. DHCPOFFER----------------------| | 866 | | | | 867 |--10. DHCPREQUEST------------------>| | 868 | | | | 869 |<-11. DHCPACK-----*-----------------| | 870 | | | | 871 |<-12. IP session data traffic----------------> | 872 | | | | 874 Figure 8. Specific use of unspecified IPv4 address as PRPA. 876 Step 1: The DSL Modem/RG initiates PANA by sending a broadcasted 877 PCI. 879 The source IPv4 address of the PCI is set to 0.0.0.0. The 880 destination IPv4 address is set to 255.255.255.255. 882 Step 2: PAA responds with a PAR message which has its source IPv4 883 address set to the PAA's IP address, and the destination IPv4 884 address is set to 255.255.255.255. If the PAA is capable of 885 retrieving the PaC's MAC address from incoming PCI, then the PAR 886 is L2-unicasted using that MAC address. Otherwise, the PAR 887 message will be L2-broadcasted. 889 PaC discovers the PAA's IPv4 address when it receives the PAR 890 message. 892 Step 3: PaC sends the PAN message to the PAA's newly discovered 893 IPv4 address. 895 Steps 4-7: PANA and RADIUS carrying out EAP-MD5 authentication. 896 Note that it is possible to translate EAP-MD5/PANA to CHAP/RADIUS 897 and eliminate the need to support EAP/RADIUS. But the details of 898 such translation is outside the scope of this I-D. 900 Steps 8-11: Now that the DSL Modem/RG is authenticated, it 901 proceeds to configuring service IP address using DHCPv4. As soon 902 as the new IPv4 address is confirmed by the DHCP ACK, the DSL 903 Modem/RG can stop using the unspecified address. In Step 11, the 904 DHCP ACK message carrying the IPv4 address triggers the DSLAM to 905 update its filters with the authorized IP/MAC address of the DSL 906 Modem/RG. 908 Step 12: The DSL Modem/RG can transmit and receive IP data packets 909 using the service IP address. 911 In case the deployment requires the DHCP Option 82 as a by-product of 912 DHCP-based PAA discovery, then Steps 2-3 from previous call flow can 913 be added to this one as well. 915 A PAA implementation may not be capable of retrieving the PaC's MAC 916 address from L2 header of the incoming PANA messages, or be able to 917 send a L2-unicast even if it could retrieve the address. In such a 918 case, the PAA sends PANA messages as L2-broadcast. In order to 919 prevent other PaCs from processing the messages destined for a 920 specific PaC, each PaC is required to supply its own MAC address as a 921 payload AVP to PCI and expect it to be echoed back by the PAA in the 922 initial PAR (TBD: Define an AVP for that). PaCs shall drop PARs with 923 mismatching MAC payloads. If the PAA is capable of L2-unicasting 924 PANA messages by using the MAC address learned from the PCI payload, 925 it can do so. 927 Note that any message beyond Step 2 would include the PAA-assigned 928 and PaC-acknowledged PANA Session Id, hence use of MAC address 929 payload is not needed for those messages. 931 6.5.4.2. Required Support from DSL Environment 933 This section describes the features required from various network 934 elements in DSL deployment in order to realize the described call 935 flow. Note that not all requirements are imposed due to choice of 936 PANA and some are already available irrespective of the 937 authentication protocol used (e.g., insertion of DHCP Option 82 by 938 the DSLAM). 940 6.5.4.2.1. Required Support from the DSL Modem/RG 942 The DSL modem/RG must host the PANA client (PAC). 944 The DSL modem/RG must use an unspecified IPv4 address to send PANA 945 messages. 947 The DHCP client of the DSL modem/RG must be triggered by a successful 948 PANA authentication to configure a global IP address used as service 949 IP address. 951 6.5.4.2.2. Required Support from the DSLAM 953 The DSLAM must be configured to act as an Enforcement Point and 954 authorize only DHCP messages and PANA messages before successful PANA 955 authentication. 957 The DSLAM must be configured to snoop DHCP messages and insert DHCP 958 option 82 in DHCP messages sent by the DSL modem/RG and use the IP 959 address found in the 'yiaddr' field of the DHCP ACK received from the 960 DHCP server to update its IP filters for authorized IPaddress/MAC 961 address. 963 6.5.4.2.3. Required Support from the BRAS 965 The BRAS should host the PANA Authentication Agent (PAA), the DHCP 966 relay or server, and the AAA client. A given deployment can choose 967 to host these implementations on separate nodes as long as it defines 968 interfaces among them to pass information. 970 The PAA must be capable of L2-unicasting PANA messages by using the 971 MAC address learned from the received DHCP Discover. 973 The reception of DHCP Discover from an unauthenticated MAC address 974 should trigger a PAA-initiated PANA authentication procedure. 976 The DHCP server should allocate IP addresses only to authenticated 977 MAC addresses. 979 7. Security Considerations 981 The DSL infrastructure that connects the CPE to the DSLAM/BRAS is 982 assumed to run over a physically-secured non-shared media. For that 983 reason, neither the use of a key-generating EAP method nor a secure 984 L2/L3 channel bootstrapped by PANA is required. The current DSL 985 deployments are satisfied by using non-key-generating client-only 986 authentication methods (e.g., CHAP and its EAP equivalent EAP-MD5). 987 The same model can be maintained even with the PANA-based 988 deployments. If next generation deployments prefer key-generating 989 mutual authentication methods, they can be naturally used with PANA 990 too. 992 8. IANA Considerations 994 This document has no actions for IANA. 996 9. Acknowledgements 998 We would like to thank to Ted Lemon, Peter Arberg, Iljitsch van 999 Beijnum, Friedrich Armbruster, Aurelien Violet and Blandine Cauwet 1000 for their valuable comments that contribute to improve this document. 1002 10. References 1004 10.1. Normative References 1006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1007 Requirement Levels", BCP 14, RFC 2119, March 1997. 1009 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1010 RFC 2131, March 1997. 1012 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 1013 RFC 3046, January 2001. 1015 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1016 and M. Carney, "Dynamic Host Configuration Protocol for 1017 IPv6 (DHCPv6)", RFC 3315, July 2003. 1019 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1020 Levkowetz, "Extensible Authentication Protocol (EAP)", 1021 RFC 3748, June 2004. 1023 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1024 Yegin, "Protocol for Carrying Authentication for Network 1025 Access (PANA)", RFC 5191, May 2008. 1027 [RFC5192] Morand, L., Yegin, A., Kumar, S., and S. Madanapalli, 1028 "DHCP Options for Protocol for Carrying Authentication for 1029 Network Access (PANA) Authentication Agents", RFC 5192, 1030 May 2008. 1032 10.2. Informative References 1034 [I-D.fajardo-pana-paa-discovery] 1035 Fajardo, V., "Simple PANA PAA Discovery Protocol", 1036 draft-fajardo-pana-paa-discovery-00 (work in progress), 1037 January 2008. 1039 [I-D.ietf-pana-ipsec] 1040 Parthasarathy, M., "PANA Enabling IPsec based Access 1041 Control", draft-ietf-pana-ipsec-07 (work in progress), 1042 July 2005. 1044 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1045 Discovery for IP Version 6 (IPv6)", RFC 2461, 1046 December 1998. 1048 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1049 Autoconfiguration", RFC 2462, December 1998. 1051 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1052 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1053 May 2005. 1055 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1056 "Protocol for Carrying Authentication for Network Access 1057 (PANA) Requirements", RFC 4058, May 2005. 1059 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 1060 A. Yegin, "Protocol for Carrying Authentication for 1061 Network Access (PANA) Framework", RFC 5193, May 2008. 1063 [TR101] DSL Forum TR-101, "Migration to Ethernet Based DSL 1064 Aggregation", April 2006. 1066 [TR25] DSL Forum TR-025, "Core Network Architecture for Access to 1067 Legacy Data Network over ADSL", September 1999. 1069 [TR59] DSL Forum TR-059, "DSL Evolution - Architecture 1070 Requirements for the Support of QoS-Enabled IP Services", 1071 September 2003. 1073 [WT134] DSL Forum WT-134 Draft Version 1.0, "Policy Control 1074 Framework for DSL", April 2006. 1076 [WT146] DSL Forum WT-146 Draft Version 1.0, "IP Sessions", 1077 February 2006. 1079 Authors' Addresses 1081 Lionel Morand 1082 France Telecom R&D 1083 France 1085 Email: lionel.morand@orange-ftgroup.com 1087 Alper E. Yegin 1088 Samsung 1089 Turkey 1091 Email: alper.yegin@yegin.org 1093 Yoshihiro Ohba 1094 Toshiba America Research, Inc. 1095 USA 1097 Email: yohba@tari.toshiba.com 1099 John Kaippallimalil 1100 Huawei Technologies 1101 USA 1103 Email: jkaippal@huawei.com