idnits 2.17.1 draft-morand-pana-panaoverdsl-02.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 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 858. 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 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (May 16, 2008) is 5795 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) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: November 17, 2008 Samsung 6 Y. Ohba 7 Toshiba America Research, Inc. 8 J. Kaippallimalil 9 Huawei Technologies 10 May 16, 2008 12 Application of PANA framework to DSL networks 13 draft-morand-pana-panaoverdsl-02 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 November 17, 2008. 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. Message Flows . . . . . . . . . . . . . . . . . . . . . . 10 64 6.5.1. Generic Message Flows . . . . . . . . . . . . . . . . 10 65 6.5.2. Specific Example I . . . . . . . . . . . . . . . . . . 12 66 6.5.3. Specific Example II . . . . . . . . . . . . . . . . . 14 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 74 Intellectual Property and Copyright Statements . . . . . . . . . . 20 76 1. Introduction 78 PANA (Protocol for carrying Authentication for Network Access) design 79 provides support for various types of deployments. DSL networks were 80 identified as a typical example of such a deployment. This document 81 provides guidelines for PANA deployment over DSL access networks. 82 The document specifically describes the introduction of PANA in DSL 83 networks migrating from a traditional PPP access model to a pure IP- 84 based access environment. In such environment, additional 85 authentication mechanisms are required to provide a complete secure 86 network access solution to Network Access Providers (NAP) willing to 87 overtake inadequate methods such as basic DSL link-layer 88 identification or application-layer ad-hoc authentication mechanisms 89 (e.g., HTTP redirects with web-based login). 91 2. Specification of Requirements 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Terminology 99 This document uses the PANA terminology defined in 100 [I-D.ietf-pana-pana]. 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 [I-D.ietf-pana-pana]. There are components that are part of a 113 complete secure network access solution but are outside of the PANA 114 protocol specification. These components include PANA Authentication 115 Agent (PAA) discovery mechanisms, based either on DHCP 116 [I-D.ietf-dhc-paa-option] or a simple multicast-based protocol 117 [I-D.fajardo-pana-paa-discovery], as well as IP address 118 configuration, authentication method choice, filter rule 119 installation, data traffic protection, and PAA-EP protocol 120 [I-D.ietf-pana-framework]. 122 Figure 1 illustrates the functional entities involved in the PANA 123 framework and the interfaces (protocols, APIs) among them. See 124 [I-D.ietf-pana-pana] and [I-D.ietf-pana-framework] for further 125 details. 126 RADIUS/ 127 Diameter/ 128 +-----+ PANA +-----+ LDAP/ API +-----+ 129 | PaC |<----------------->| PAA |<---------------->| AS | 130 +-----+ +-----+ +-----+ 131 ^ ^ 132 | | 133 | +-----+ | 134 IKE/ +-------->| EP |<--------+ API/ Other 135 4-way handshake (*) +-----+ 137 Figure 1: PANA Functional Model 139 PaC: PANA Client 141 PAA: PANA Authentication Agent 143 AS: Authentication Server 145 EP: Enforcement Point 147 (*) PaC-EP secure association protocol is not needed in DSL networks unless 148 per-packet cryptographic security is needed. 150 The PANA design provides support for various types of deployments. 151 DSL networks were identified as a typical example of such a 152 deployment (see Appendix A of [RFC4058]). 154 5. PANA in DSL environment 156 5.1. Evolution of DSL Environment 158 Traditional DSL deployments followed the architectural guidelines 159 provided in [TR25] or [TR59]. Theses architectures use ATM to 160 aggregate the access networks into a regional broadband network. The 161 traffic aggregated from the access nodes (DSLAM) is steered to an IP 162 node, the Broadband Remote Access Server (BRAS). In this 163 environment, PPP sessions are set-up between the CPN (Customer 164 Premises Network) and the BRAS, which acts as either a PPP 165 termination point or a L2TP Access Concentrator (LAC) tunnelling 166 multiple subscriber PPP sessions directly to an Internet/Corporate 167 Service Provider. The CPN is usually defined as the combination of 168 the DSL Modem or Residential Gateway (RG), acting as termination 169 point of the physical DSL signal, and the subscriber's computers and 170 other devices (named hosts hereafter) connected to the DSL Modem/RG. 171 Host--+ +-- ISP1 172 | DSL link | 173 +-- DSL Modem/RG --- DSLAM --- BRAS --+-- ISP2 174 | | 175 Host--+ +-- ISP3 177 <------- CPN -------> <----- NAP ----> <-- ISP --> 179 Figure 2: DSL Model 180 The devices at the customer premises have been shown as "hosts" in 181 the above network. 183 DSL architectures are now emerging from a "low" speed best effort 184 delivery network to an infrastructure capable of supporting higher 185 subscriber bit rates. At the application layer, DSL service 186 providers are looking to support enhanced services layered on top of 187 basic Internet access, including entertainment video services 188 (Broadcast TV and VoD), video conferencing, VoIP, gaming, and 189 business class services (e.g. IP VPN), that have prohibitive 190 requirements to deploy them in a pure ATM based environment. Moving 191 to on a Gigabit Ethernet instead of an ATM aggregation network offers 192 an highly efficient transport technology for delivering large amounts 193 of bandwidth to a highly distributed access node topology. Migration 194 from ATM-based to an Ethernet based aggregation network in the 195 context of TR-25 and TR-59 based architectures is described in 196 [TR101]. 198 In this evolution path towards Giga Ethernet, there is in parallel a 199 growing interest in migrating from the traditional PPP access model 200 to one relying on an network access control of IP sessions 201 establishment. The "IP Sessions" model is a concept introduced in 202 DSL Forum that covers a cycle consisting of IP session Detection and 203 creation, application of IP session policies, and IP session 204 termination. Details of this work are documented in [WT146]. 205 Basically, an IP session represents subscriber IP traffic which is 206 associated with a subscriber's IP address parameters. A subscriber 207 may have multiple IP addresses (or sessions) in simultaneous use. An 208 IP session may in turn be associated with multiple IP flows. The 209 relation between subscribers and policies associated with it are 210 described in [WT134]. The policy relationships in this document show 211 that subscribers have services that are governed by policies. Thus, 212 the same subscriber policies govern all IP sessions/flows belonging 213 to the subscriber. 215 5.2. Advisability of Introducing PANA in DSL Environment 217 Among other challenges for DSL environment migrating from pure PPP 218 based networks, one is the need for the creation of an IP session 219 subscriber authentication model to secure network access and IP 220 address management provided by a DHCP infrastructure. Indeed, 221 contrary to PPP environment, an IP sessions model has no built-in 222 mechanisms for authentication purposes in a DHCP based environment. 223 If location-based authentication relying on access line 224 identification is actually possible (see in [TR101] the use of the 225 DHCP Relay Agent Information option, aka DHCP option 82, inserted by 226 the Access Node), additional mechanisms are required to provide 227 Network Access Providers (NAP) with an explicit per-subscriber access 228 authentication solution, in order to . 230 Providing a native support of EAP frames over IP, PANA is therefore a 231 natural candidate to provide the protocol support of an IP subscriber 232 authentication model. Moreover, PANA provides functionalities 233 fulfilling basic and advanced security requirements within an IP 234 session based environment (as described in [WT146]) , such as: 236 o IP address based session management mechanisms, using an explicit 237 session identifier; 239 o Authentication mechanism independent of the physical medium type; 241 o Enabling per-session enforcement policies (i.e. filters) depending 242 on the creation and deletion of the PANA session; 244 o Enabling session keep-alive and session monitoring functionalities 245 to optimize the use of resources and provide an accurate picture 246 of the state of a subscriber session (as described in [WT146]). 248 In this new context for DSL networks, PANA may be introduced to 249 authenticate the credentials of a user prior to the setup of an IP 250 session. The user selects the service provider and authenticates 251 itself. During IP session setup, policies for the use of connection 252 resources related to the IP session are established in the BRAS. 253 These policies govern the subscriber's use of network resources. IP 254 flows are accounted for and associated with the IP session and the 255 service session that triggered it. 257 Based on the content of the Liaison Statement sent by the DSL Forum 258 to the IETF, the specific subscriber authentication requirements were 259 discussed at the PANA WG meeting at IETF70 in Vancouver (Dec 5, 260 2007). The result of this analysis confirmed the applicability of 261 the PANA protocol for the DSL Forum's subscriber authentication 262 requirements. PANA WG Meeting analysis can be found in the 70th IETF 263 meeting proceedings 264 (http://www.ietf.org/proceedings/07dec/slides/pana-3/sld1.htm). 266 6. Applicability of PANA to IP Session based DSL Environment 268 6.1. Functional Architecture 270 6.1.1. Location of PAA and EP 272 In a PPP based environment, the BRAS is in charge of interfacing with 273 CPE for authenticating and authorizing them for the network access 274 service as well as performing policy control by acting as en 275 enforcement point. In an IP session based environment, such 276 functionalities may be provided at the same level by locating the PAA 277 and EP entities in the BRAS. One advantage provided by this 278 implementation is to preserve a improved and well-established DSL 279 network configuration. Moreover, PAA and EP being collocated, there 280 is no need to rely on an external interface between them to carry the 281 authorized client attributes i.e. filters, an API being sufficient in 282 that case. 284 The PANA design providing also the support for network configuration 285 in which PAA and EP are not collocated, as described in 286 [I-D.ietf-pana-framework], the PAA may be located in the BRAS while 287 the EP function is the DSLAM. In that specific case, the PAA-EP 288 interface implemented between the BRAS and the DSLAM may be based on 289 the current DHCP triggering or on a dedicated API. 291 In an IP session based environment, the PAA will have to verify the 292 credentials provided by a PaC located in the CPN and authorize 293 network access to the host/gateway associated with the client. 295 6.1.2. Location of the PaC 297 6.1.2.1. Bridged Mode 299 In the Bridged mode, the DSL Modem/RG acts as a simple link-layer 300 bridge. The DSL Modem/RG is here transparent at the IP layer. The 301 hosts (e.g. PC) connected to the DSL Modem/RG in the CPN and the 302 BRAS are then on the same IP link. Hosts may have a statically 303 configured IP address or obtain an IP address from a DHCP server 304 through the DSLAM (acting as a Layer-2 DHCP Relay agent as described 305 in [TR101]) and the BRAS (filtering DHCP requests towards the DHCP 306 server). 308 In this model, the PaC can be easily implemented in the hosts. Any 309 host connected to the DSL Modem/RG will be authenticated by the PAA 310 locating in the BRAS. It is therefore possible to perform a network 311 access control on a per-host basis, as required by the IP session 312 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 IP address from a DHCP server through the 328 DSLAM (acting as a Layer-2 DHCP-Relay agent as described in [TR101]) 329 and the BRAS (filtering DHCP requests towards the DHCP server). 330 Hosts connected to the DSL Modem/RG may use either (1) either private 331 IP addresses in an IPv4 environment with the DSL Modem/RG implemented 332 a Network Address Port Translation (NAPT) function or (2) routable IP 333 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 As described in [I-D.ietf-pana-framework], the PaC MUST obtain an IP 375 address prior to performing PANA-based authentication, called pre- 376 PANA address (PRPA). 378 In the context of PANA deployment in DSL environment based on the IP 379 Sessions model, the PRPA MAY be configured by the following methods: 381 1. The PaC MAY be statically configured with an IP address. This 382 address is therefore used as a PRPA. 384 2. The PaC MAY dynamically configure the PRPA using DHCPv4 [RFC2131] 385 or DHCPv6 [RFC3315]. 387 3. In IPv6, the PaC MAY configure non-link-local address(es) using 388 IPv6 stateless auto-configuration [RFC2461] if router 389 advertisements with prefixes are made available. 391 4. PaC MAY also use an IPv4 link-local address [RFC3927] and/or an 392 IPv6 link-local address [RFC2461]. 394 5. PaC MAY use unspecified IPv4 address (0.0.0.0). 396 After a successful authentication, the PaC MAY have to configure a 397 new IP address for communication with other nodes if the PRPA is an 398 unspecified IPv4 address, a local-use IP address (e.g., a link-local 399 or private address) or a temporarily allocated IP address. This IP 400 address is called a post-PANA address (POPA). An operator might 401 choose allocating a POPA only after successful PANA authorization 402 either to prevent waste of premium (e.g., globally routable) IP 403 resources until the PaC is authorized (especially in the IPv4 case), 404 or to enable PaC identity based address assignment. POPA can be 405 configured using DHCP [RFC2131] [RFC3315] or using IPv6 stateless 406 auto-configuration [RFC2461]. 408 6.3. Authorized Device ID 410 The MAC address of the PaC can be used as a session attribute of the 411 subscriber and used by EP for packet filtering once the PANA 412 authentication successfully completed. The MAC address can also be 413 used by the network to assign a subscriber-dependent IP address using 414 DHCP. Therefore, the association between the subscriber ID that was 415 used with the PANA authentication and the session attributes (MAC and 416 IP addressess) can be formed. 418 6.4. Cryptographic Protection 420 DSL networks are protected by physical means. Eavesdropping and 421 spoofing attacks are prevented by keeping the unintended users 422 physically away from the network media. Therefore, generally 423 cryptographic protection of data traffic is not common. 424 Nevertheless, if enhanced security is deemed necessary for any 425 reason, IPsec-based access control can be enabled on DSL networks as 426 well by using the method described in [I-D.ietf-pana-ipsec]. 428 6.5. Message Flows 430 This section provides example message flows using PANA in DSL 431 deployments. 433 Section 6.5.1 describes the basic components of generic message flow. 435 Section 6.5.2 describes the detailed message flows for a specific 436 scenario. 438 6.5.1. Generic Message Flows 440 This is the description of the basic components of generic message 441 flows. 443 DSL Modem/RG, DSLAM BRAS AAA server 444 or Host 445 (PaC) (EP) (PAA) 447 | | | | 448 |<--1. PRPA configuration----------->| | 449 | | | | 450 | | | | 451 |<--2. PAA discovery---------------->| | 452 | | | | 453 | | | | 454 |<--3. PANA authentication---------->|<--RADIUS/Diameter->| 455 | | | authentication | 456 | | | | 457 |<--4. POPA configuration----------->| | 458 | | | | 459 | |<-5. EP Filter-->| | 460 | | setup | | 461 | | | | 462 |<--6. IP session data traffic----------------> | 463 | | | | 464 | | | | 466 Figure 5. Generic PANA over DSL call flow 468 Depending on the deployment, either the DSL Modem acts as a RG and 469 therefore only that node is authenticated; or the DSL Modem acts as a 470 bridge and hosts connected to that bridge gets individually 471 authenticated. 473 Step 1: The DSL Modem/RG or host, acting as PaC, configures a pre- 474 PANA IP address (PRPA).This step is skipped if the PaC is using an 475 unspecified IPv4 address. 477 Step 2: PaC discovers the IP address of the PAA. PaC may use DHCP 478 [I-D.ietf-dhc-paa-option] or the discovery mechanism provided by 479 PANA [I-D.fajardo-pana-paa-discovery]. 481 Step 3: PaC and PAA performs authentication using EAP and AAA 482 protocols (RADIUS, Diameter, etc.) 484 Step 4: In case the PRPA was an unspecified IPv4 address, 485 temporary IP address or limited-use IP address, the PaC configures 486 a post-PANA IP address (POPA). This is the service IP address. 488 Step 5: PAA instructs the EP to allow authorized IP traffic of 489 PaC. This step may be implicitly part of step 4 (e.g. DHCPACK 490 with IP address configuration) or performed using a specific API. 492 Step 6: PaC can transmit and receive IP data packets. 494 Note that the step 4 is optional. Depending on the network 495 configuration and the IP address resource management, it may not be 496 needed for the PaC to configure a new IP address after the PANA 497 authentication. 499 6.5.2. Specific Example I 501 These are the message flows for a specific example where: 503 - DSL modem/RG is authenticated, 505 - PRPA is a link-local IPv4 address, 507 - PAA discovery is based on DHCP, 509 - Authentication method used is EAP-MD5, 511 - POPA is configured using DHCPv4, 513 - EP is triggered by DHCPACK whose 'yiaddr' field is filled. 515 DSL Modem/RG DSLAM BRAS AAA server 516 (PaC) (EP) (PAA) 518 | | | | 519 1. Link-local PRPA config | | 520 | | | | 521 | | | | 522 |--2. DHCP Inform *(req.PAA opt.)-->| | 523 | | | | 524 |<-3. DHCP Ack (PAA option)----------| | 525 | | | | 526 |--4. PANA Client initiation-------->| | 527 | | | | 528 |<-5. PANA Auth Req (EAP-MD5 chal)---| | 529 | | | | 530 |--6. PANA Auth Ans (EAP-MD5 resp)-->| | 531 | | | | 532 | | |-7. RADIUS Access ->| 533 | | | Request (EAP) | 534 | | | | 535 | | |<-8. RADIUS Access--| 536 | | | (EAP Success) | 537 |<-9. PANA Auth Req (EAP Success)----| | 538 | | | | 539 |--10. PANA Auth Ans (Ack)---------->| | 540 | | | | 541 |--11. DHCP Discover---------------->| | 542 | | | | 543 |<-12. DHCP Offer--------------------| | 544 | | | | 545 |--13. DHCP Request----------------->| | 546 | | | | 547 |<-14. DHCP Ack----*-----------------| | 548 | | | | 549 |<-15. IP session data traffic----------------> | 550 | | | | 552 Figure 6. Specific example message flow. 554 Step 1: The DSL Modem/RG configures an IPv4 link-local address 555 [RFC3927]. It is assumed that, if the DSL network does not allow 556 modems sending and receiving ARP requests/responses to each other, 557 then the network allows IP address collision among the modems and 558 deals with it by using auxiliary information such as MAC address, 559 VLAN, etc. 561 Steps 2-3: the DSL Modem/RG discovers the IPv4 address of the PAA 562 using the PANA Authentication Agent DHCPv4 Option 564 [I-D.ietf-dhc-paa-option]. The DSL Modem/RG uses its IPv4 link- 565 local address with DHCP and it does not request IP address 566 allocation (i.e., DHCP server will not fill 'yiaddr' in DHCP ACK 567 in response to DHCP Inform). Option 82 is inserted into the DHCP 568 Inform message by the DSLAM. 570 Step 4: The DSL Modem/RG initiates PANA with the newly-discovered 571 PAA. Alternatively, the PAA could initiate PANA in unsolicited 572 fashion. In that latter case, Step 4 may be skipped or run in 573 parallel with Step 5. 575 Steps 5-10: PANA and RADIUS carrying out EAP-MD5 authentication. 576 BRAS can utilize the Option 82 value discovered during Step 2. 578 Steps 11-14: Now that the DSL Modem/RG is authenticated, it 579 proceeds to configuring service IP address using DHCPv4. As soon 580 as the new IP address is confirmed by the DHCP ACK, the DSL 581 Modem/RG can stop using the IPv4 link-local address. In Step 14, 582 the DHCP ACK message carrying the IP address triggers the DSLAM to 583 update its filters with the authorized IP/MAC address of the DSL 584 Modem/RG. 586 Step 15: The DSL Modem/RG can transmit and receive IP data packets 587 using the service IP address. 589 Note that, during steps 1-14, the DSLAM (acting as EP) allows only 590 DHCP and PANA messages,and depending on deployment, address 591 resolution messages such as ARP and IPv6 Neighbor Discovery messges. 593 A variation of this call flow can be generated using PANA-based PAA 594 discovery [I-D.fajardo-pana-paa-discovery] instead of DHCP for the 595 Steps 2 and 3. If Option 82 value is needed by the BRAS, it can be 596 inserted into the PANA messages as they go through the DSLAM. 598 6.5.3. Specific Example II 600 This is a similar example to the previous one with the exception 601 that: 603 - PRPA is the unspecified IPv4 address, 605 - PAA discovery is based on PAA responding to broadcast PCI. 607 DSL Modem/RG DSLAM BRAS AAA server 608 (PaC) (EP) (PAA) 610 | | | | 611 | | | | 612 | | | | 613 |--1. PANA Client initiation-------->| | 614 | | | | 615 |<-2. PANA Auth Req (EAP-MD5 chal)---| | 616 | | | | 617 |--3. PANA Auth Ans (EAP-MD5 resp)-->| | 618 | | | | 619 | | |-4. RADIUS Access ->| 620 | | | Request (EAP) | 621 | | | | 622 | | |<-5. RADIUS Access--| 623 | | | (EAP Success) | 624 |<-6. PANA Auth Req (EAP Success)----| | 625 | | | | 626 |--7. PANA Auth Ans (Ack)----------->| | 627 | | | | 628 |--8. DHCP Discover----------------->| | 629 | | | | 630 |<-9. DHCP Offer---------------------| | 631 | | | | 632 |--10. DHCP Request----------------->| | 633 | | | | 634 |<-11. DHCP Ack----*-----------------| | 635 | | | | 636 |<-12. IP session data traffic----------------> | 637 | | | | 639 Figure 7. Specific example message flow. 641 Step 1: The DSL Modem/RG initiates PANA by sending a broadcasted 642 PCI. 644 The source IPv4 address of the PCI is set to 0.0.0.0. The 645 destination IPv4 address is set to 255.255.255.255. 647 Step 2: PAA responds with a PAR message which has its source IPv4 648 address set to the PAA's IP address, and the destination IPv4 649 address is set to 55.255.255.255. If the PAA is capable of 650 retrieving the PaC's MAC address from incoming PCI, then the PAR 651 is L2-unicasted using that MAC address. Otherwise, the PAR 652 message will be L2-broadcasted. 654 PaC discovers the PAA's IPv4 address when it receives the PAR 655 message. 657 Step 3: PaC sends the PAN message to the PAA's newly discovered 658 IPv4 address. 660 Steps 4-7: PANA and RADIUS carrying out EAP-MD5 authentication. 661 Note that it is possible to translate EAP-MD5/PANA to CHAP/RADIUS 662 and eliminate the need to support EAP/RADIUS. But the details of 663 such translation is outside the scope of this I-D. 665 Steps 8-11: Now that the DSL Modem/RG is authenticated, it 666 proceeds to configuring service IP address using DHCPv4. As soon 667 as the new IPv4 address is confirmed by the DHCP ACK, the DSL 668 Modem/RG can stop using the unspecified address. In Step 11, the 669 DHCP ACK message carrying the IPv4 address triggers the DSLAM to 670 update its filters with the authorized IP/MAC address of the DSL 671 Modem/RG. 673 Step 12: The DSL Modem/RG can transmit and receive IP data packets 674 using the service IP address. 676 In case the deployment requires the Option 82 as a by-product of 677 DHCP-based PAA discovery, then Steps 2-3 from previous call flow can 678 be added to this one as well. 680 A PAA implementation may not be capable of retrieving the PaC's MAC 681 address from L2 header of the incoming PANA messages, or be able to 682 send a L2-unicast even if it could retrieve the address. In such a 683 case, the PAA sends PANA messages as L2-broadcast. In order to 684 prevent other PaCs from processing the messages destined for a 685 specific PaC, each PaC is required to supply its own MAC address as a 686 payload AVP to PCI and expect it to be echoed back by the PAA in the 687 initial PAR (TBD: Define an AVP for that). PaCs shall drop PARs with 688 mismatching MAC payloads. If the PAA is capable of L2-unicasting 689 PANA messages by using the MAC address learned from the PCI payload, 690 it can do so. 692 Note that any message beyond Step 2 would include the PAA-assigned 693 and PaC-acknowledged PANA Session Id, hence use of MAC address 694 payload is not needed for those messages. 696 7. Security Considerations 698 The DSL infrastructure that connects the CPE to the DSLAM/BRAS is 699 assumed to run over a physically-secured non-shared media. For that 700 reason, neither the use of a key-generating EAP method nor a secure 701 L2/L3 channel bootstrapped by PANA is required. The current DSL 702 deployments are satisfied by using non-key-generating client-only 703 authentication methods (e.g., CHAP and its EAP equivalent EAP-MD5). 704 The same model can be maintained even with the PANA-based 705 deployments. If next generation deployments prefer key-generating 706 mutual authentication methods, they can be naturally used with PANA 707 too. 709 8. IANA Considerations 711 This document has no actions for IANA. 713 9. Acknowledgements 715 We would like to thank to Ted Lemon, Peter Arberg, Iljitsch van 716 Beijnum, Friedrich Armbruster, Aurelien Violet and Blandine Cauwet 717 for their valuable comments that contribute to improve this document. 719 10. References 721 10.1. Normative References 723 [I-D.ietf-dhc-paa-option] 724 Morand, L., "DHCP options for PANA Authentication Agents", 725 draft-ietf-dhc-paa-option-05 (work in progress), 726 December 2006. 728 [I-D.ietf-pana-pana] 729 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 730 Yegin, "Protocol for Carrying Authentication for Network 731 Access (PANA)", draft-ietf-pana-pana-18 (work in 732 progress), September 2007. 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 738 RFC 2131, March 1997. 740 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 741 and M. Carney, "Dynamic Host Configuration Protocol for 742 IPv6 (DHCPv6)", RFC 3315, July 2003. 744 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 745 Levkowetz, "Extensible Authentication Protocol (EAP)", 746 RFC 3748, June 2004. 748 10.2. Informative References 750 [I-D.fajardo-pana-paa-discovery] 751 Fajardo, V., "Simple PANA PAA Discovery Protocol", 752 draft-fajardo-pana-paa-discovery-00 (work in progress), 753 January 2008. 755 [I-D.ietf-pana-framework] 756 Jayaraman, P., Ohba, Y., Parthasarathy, M., and A. Yegin, 757 "Protocol for Carrying Authentication for Network Access 758 (PANA) Framework", draft-ietf-pana-framework-10 (work in 759 progress), September 2007. 761 [I-D.ietf-pana-ipsec] 762 Parthasarathy, M., "PANA Enabling IPsec based Access 763 Control", draft-ietf-pana-ipsec-07 (work in progress), 764 July 2005. 766 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 767 Discovery for IP Version 6 (IPv6)", RFC 2461, 768 December 1998. 770 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 771 Configuration of IPv4 Link-Local Addresses", RFC 3927, 772 May 2005. 774 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 775 "Protocol for Carrying Authentication for Network Access 776 (PANA) Requirements", RFC 4058, May 2005. 778 [TR101] DSL Forum TR-101, "Migration to Ethernet Based DSL 779 Aggregation", April 2006. 781 [TR25] DSL Forum TR-025, "Core Network Architecture for Access to 782 Legacy Data Network over ADSL", September 1999. 784 [TR59] DSL Forum TR-059, "DSL Evolution - Architecture 785 Requirements for the Support of QoS-Enabled IP Services", 786 September 2003. 788 [WT134] DSL Forum WT-134 Draft Version 1.0, "Policy Control 789 Framework for DSL", April 2006. 791 [WT146] DSL Forum WT-146 Draft Version 1.0, "IP Sessions", 792 February 2006. 794 Authors' Addresses 796 Lionel Morand 797 France Telecom R&D 798 France 800 Email: lionel.morand@orange-ftgroup.com 802 Alper E. Yegin 803 Samsung 804 Turkey 806 Email: a.yegin@partner.samsung.com 808 Yoshihiro Ohba 809 Toshiba America Research, Inc. 810 USA 812 Email: yohba@tari.toshiba.com 814 John Kaippallimalil 815 Huawei Technologies 816 USA 818 Email: jkaippal@huawei.com 820 Full Copyright Statement 822 Copyright (C) The IETF Trust (2008). 824 This document is subject to the rights, licenses and restrictions 825 contained in BCP 78, and except as set forth therein, the authors 826 retain all their rights. 828 This document and the information contained herein are provided on an 829 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 830 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 831 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 832 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 833 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Intellectual Property 838 The IETF takes no position regarding the validity or scope of any 839 Intellectual Property Rights or other rights that might be claimed to 840 pertain to the implementation or use of the technology described in 841 this document or the extent to which any license under such rights 842 might or might not be available; nor does it represent that it has 843 made any independent effort to identify any such rights. Information 844 on the procedures with respect to rights in RFC documents can be 845 found in BCP 78 and BCP 79. 847 Copies of IPR disclosures made to the IETF Secretariat and any 848 assurances of licenses to be made available, or the result of an 849 attempt made to obtain a general license or permission for the use of 850 such proprietary rights by implementers or users of this 851 specification can be obtained from the IETF on-line IPR repository at 852 http://www.ietf.org/ipr. 854 The IETF invites any interested party to bring to its attention any 855 copyrights, patents or patent applications, or other proprietary 856 rights that may cover technology that may be required to implement 857 this standard. Please address the information to the IETF at 858 ietf-ipr@ietf.org.