idnits 2.17.1 draft-ietf-pana-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 119 has weird spacing: '... reside on th...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: PANA MUST not assume a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST provide protection against replay attacks on both PaCs and PAAs. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RDISC' is mentioned on line 205, but not defined == Missing Reference: 'ADDRCONF' is mentioned on line 350, but not defined == Missing Reference: 'D1' is mentioned on line 572, but not defined == Missing Reference: 'D2' is mentioned on line 576, but not defined == Unused Reference: '8021X' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'PPP' is defined on line 429, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '8021X' ** Obsolete normative reference: RFC 2002 (ref. 'MIPV4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-15 ** Obsolete normative reference: RFC 3012 (ref. 'MNAAA') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2461 (ref. 'NDISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPV4' -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP' ** Obsolete normative reference: RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Reinaldo Penno, Editor 3 INTERNET-DRAFT Alper E. Yegin 4 Date: October 2002 Yoshihiro Ohba 5 Expires: April 2003 George Tsirtsis 6 Cliff Wang 8 Protocol for Carrying Authentication for 9 Network Access (PANA) 10 Requirements and Terminology 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 It is expected that future IP devices will have a variety of access 37 technologies to gain network connectivity. Currently there are 38 access-specific mechanisms for providing client information to the 39 network for authentication and authorization purposes. In addition 40 to being limited to specific access media (e.g., 802.1x for IEEE 802 41 links), some of these protocols are limited to specific network 42 topologies (e.g., PPP for point-to-point links). The goal of the 43 PANA is to provide a layer two agnostic and IPv4/IPv6 compatible 44 client-server protocol that allows a host to be authenticated for 45 network access. The protocol will run between a client's device 46 and an agent device in the network where the agent might be a client 47 of the AAA infrastructure. This document defines the common 48 terminology and identifies the requirements for PANA. 50 Table of Contents 52 Status of this Memo...............................................1 53 Abstract..........................................................1 54 Table of Contents.................................................2 55 1. Introduction...................................................2 56 2. Key Words......................................................3 57 3. Terminology....................................................4 58 4. Requirements...................................................4 59 4.1. Authentication...............................................4 60 4.1.1. Authentication of Client...................................4 61 4.1.2. Authorization, Accounting and Access Control...............5 62 4.1.3. Authentication Backend.....................................5 63 4.1.4. Identifiers................................................5 64 4.2. Network......................................................6 65 4.2.1. Multi-access...............................................6 66 4.2.2. Disconnect Indication......................................6 67 4.2.3. Location of PAA............................................7 68 4.2.4. Secure Channel.............................................7 69 4.3. Interaction with Other Protocols.............................7 70 4.4. Performance..................................................8 71 4.5. Reliability and Congestion Control...........................8 72 4.6. Miscellaneous................................................8 73 4.6.1. IP Version Independence....................................8 74 4.6.2. Denial of Service Attacks..................................8 75 4.6.3. Location Privacy...........................................8 76 4.7 Change Log....................................................9 77 Acknowledgements..................................................9 78 References........................................................9 79 Authors' Addresses...............................................10 80 Appendix (PANA Model)............................................11 81 Full Copyright Statement.........................................13 83 1. Introduction 85 Network access technologies for wired and wireless media are 86 evolving rapidly. With the rapid growth in the number and type of 87 devices and terminals that support IP stacks and can access the 88 Internet, users can potentially use a single device having the 89 capability of attaching via different multiple access media and 90 technologies to interface to the network. 92 If a client can have more than one type of interface, using 93 access-specific authentication mechanisms leads to running a 94 collection of protocols on the client for the same purpose. 96 For example, the authentication mechanisms in PPP are being used 97 for many wired access scenarios as well as some wireless access, 98 which requires using PPP encapsulation for the data packets. Using 99 PPP just for client authentication is viewed as a sub-optimal 100 solution as it causes extra round-trips, overhead of encapsulation 101 and processing, 102 and forces the network topology into a point-to-point 103 model. A point in case is PPPoE which is used over multi-access 104 networks primarily for the purpose of exploiting the authentication 105 scheme provided by PPP. Also, IEEE 802 relies on 802.1X which 106 provides EAP authentication that is limited to IEEE 802 link layers. 108 It is clearly advantageous to use a general protocol to authenticate 109 the client for network access on any type of technology. There is 110 currently no general protocol to be used by a client for gaining 111 network access, and the PANA Working Group will attempt to 112 fill that hole. 114 The protocol design will be limited to defining a client-server 115 messaging protocol (i.e., a carrier) that will allow authentication 116 payload to be carried between the host/client (PaC) and an 117 agent/server (PAA) in the access network for authentication and 118 authorization purposes regardless of the AAA infrastructure that 119 may (or may not) reside on the network. As a network-layer 120 protocol, it will be independent of the underlying access 121 technologies. It will also be applicable to any network topology. 123 The Working Group will not invent new security protocols and 124 mechanisms but instead will use the existing mechanisms. In 125 particular, the Working Group will not define authentication 126 protocols, key distribution or key agreement protocols, or key 127 derivation. The desired protocol can be viewed as the front-end 128 of the AAA protocol or any other protocol/mechanisms the network 129 is running at the background to authenticate its clients. It will 130 act as a carrier for an already defined security protocol or 131 mechanism. 133 As an example, Mobile IP Working Group has already defined such a 134 carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request 135 message is used as the carrier for authentication extensions (MN-FA 136 [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the 137 foreign agents. In that sense, designing the equivalent of Mobile 138 IPv4 registration request messages for general network access is the 139 goal of this work, but not defining the equivalent of MN-FA or MN- 140 AAA extensions. 142 This document defines the common terminology and identifies the 143 requirements of a protocol for PANA. These terminology and 144 requirements will be used to define and limit the scope of the work 145 to be done in this group. 147 2. Key Words 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [KEYWORDS]. 153 3. Terminology 155 Device Identifier (DI) 157 The identifier used by the network as a handle to control and 158 police the network access of a client. Depending on the access 159 technology, identifier might contain any of IP address, link- 160 layer address, switch port number, etc. of a device. PANA 161 authentication agent keeps a table for binding device 162 identifiers to the PANA clients. At most one PANA client 163 should be associated with a DI on a PANA authentication agent. 165 PANA Client (PaC) 167 The entity wishing to obtain network access from a PANA 168 authentication agent within a network. A PANA client is 169 associated with a network device and a set of credentials to 170 prove its identity within the scope of PANA. 172 PANA Authentication Agent (PAA) 174 The entity whose responsibility is to authenticate the 175 credentials provided by a PANA client and grant network 176 access service to the device associated with the client 177 and identified by a DI. 179 4. Requirements 181 4.1. Authentication 183 4.1.1. Authentication of Client 185 PANA MUST authenticate a PaC for network access. A PaC can be 186 identified by the credentials (identifier, authenticator) supplied 187 by one of the users of the device or the device itself. PANA MUST 188 only grant network access service to the device identified by the 189 DI, rather than granting separate access to multiple simultaneous 190 users of the device. Once the network access is granted to the 191 device, the methods used by the device on arbitrating which one of 192 its users can access the network is outside the scope of PANA. 194 PANA MUST NOT define new security protocols or mechanisms. Instead 195 it must be defined as a "carrier" for such protocols. PANA MUST 196 identify which specific security protocol(s) or mechanism(s) it can 197 carry (the "payload"). The current thinking is that a sufficient 198 solution would be for PANA to carry EAP. If PANA WG decides that 199 extensions to EAP are needed, it will define requirements for an 200 EAP WG instead of defining these extensions. 202 Authentication and encryption of data traffic except between 203 the Pac and PAA is outside the scope of PANA. Providing a complete 204 secure network access solution by also securing router discovery 205 [RDISC], neighbor discovery [NDISC], and address resolution 206 protocols [ARP] is outside the scope as well. 208 Both the PaC and the PAA MUST be able to authenticate each other for 209 network access. Providing capability of only PAA authenticating the 210 PaC is not sufficient. 212 PANA MUST be capable of carrying out both periodic and on-demand re- 213 authentication. Both the PaC and the PAA MUST be able to initiate 214 both the initial authentication and the re-authentication process. 216 When the DI is carried explicitly as part of the PANA payload, the 217 authentication computation MUST also include this field to provide 218 integrity protection for the DI. When the DI is carried implicitly 219 as the source of the PANA message, the protocol has to make sure 220 that the DI's integrity is protected by some other means (e.g., 221 physical verification of incoming port number of the PANA message in 222 the case of switch port number as a DI and PAA co-located with the 223 link-layer access device). Protecting PaCs against DI theft is 224 outside the scope of PANA. 226 4.1.2. Authorization, Accounting and Access Control 228 In addition to carrying authentication information, PANA MUST also 229 provides only a binary authorization to indicate whether the PaC 230 is allowed to access full IP services on the network. Providing 231 finer granularity authorization, such as negotiating QoS parameters, 232 authorizing individual services (http vs. ssh), individual users 233 sharing the same device, etc. is outside the scope of PANA. 235 Providing access control functionality in the network is outside the 236 scope of PANA. Client access authentication should be followed by 237 access control to make sure only authenticated and authorized 238 clients can send and receive IP packets via access network. Access 239 control can involve setting access control lists on the enforcement 240 points. Identification of clients which are authorized to access 241 the network is done by the PANA protocol exchange. 243 Carrying accounting data is outside the scope of PANA. 245 4.1.3. Authentication Backend 247 PANA protocol MUST NOT make any assumptions on the backend 248 authentication protocol or mechanisms. PAA may interact with 249 backend AAA infrastructures such as RADIUS or Diameter, but it is 250 not a requirement. When the access network doesn't rely on a 251 IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can 252 still use a proprietary backend system, or rely on the information 253 locally stored on the authentication agents. 255 The interaction between the PAA and the backend authentication 256 entities is outside the scope of PANA. 258 4.1.4. Identifiers 260 PANA SHOULD allow various types of identifiers to be used for the 261 PaC (e.g., NAI, IP address, FQDN, etc.) 263 PANA SHOULD allow various types of identifiers to be used as the DI 264 (IP address, link-layer address, port number of a switch, etc.) 266 PAA MUST be able to create a binding between the PaC and the 267 associated DI upon successful PANA exchange. The DI MUST be carried 268 either explicitly as part of the PANA payload, or implicitly as the 269 source of the PANA message, or both. This binding is used for access 270 control and accounting in the network as described in section 4.1.2. 272 4.1.5. IP Address Assignment 274 PANA does not perform any address assignment functions but MUST 275 only be invoked after the client has a usable IP address 276 (e.g., a link-local address in IPv6 or a DHCP-learned address 277 in IPv4) 279 4.2. Network 281 4.2.1. Multi-access 283 Protocol MUST support PaCs with multiple interfaces, and networks 284 with multiple routers on multi-access links. 286 4.2.2. Disconnect Indication 288 PANA MUST NOT assume connection-oriented links. Links may or may not 289 provide disconnect indication. Such notification is desirable in 290 order for the PAA to cleanup resources when a client moves away 291 from the network (e.g., inform the enforcement points that the 292 client is no longer connected). PANA SHOULD have a mechanism to 293 provide disconnect indication. 295 This mechanism must allow PAAs to detect the departure of a PaC from 296 the network. This mechanism SHOULD also allow a PaC to detect the 297 discontinuation of the network access service. Access 298 discontinuation can happen due to various reasons such as network 299 systems going down, or a change in access policy. 301 Several mechanisms can be used to provide disconnect indication, 302 e.g., frequent re-authentication; but the use of a heartbeat 303 function is not recommended. 305 4.2.3. Location of PAA 307 The PAA must be on an IP capable network element on the same 308 IP link as the PaC. Hence it can be on the NAS or WLAN AP or first 309 hop router (most likely scenario). The use of PANA when the PAA is 310 not on the same link as the PaC is outside the scope of PANA. 312 Since a PaC may not be pre-configured with the IP address of PAA, 313 but may have to dynamically discover instead. Therefore PANA 314 protocol must define a dynamic discovery method. Given that 315 the PAA is on the same link as the PaC, there are number 316 of discovery techniques that could be used (e.g., multicast or 317 anycast) by the PaC to find out the address of the PAA. 319 PANA does not assumes the PAA is co-located with the enforcement 320 point. Network access enforcement can be provided by one or more 321 nodes on the same IP subnet as the client (e.g., multiple routers), 322 or on another subnet in the access domain (e.g., gateway to the 323 Internet, depending on the network architecture). When the PAA and 324 the enforcement point(s) are separated, there needs to be another 325 transport for client provisioning. This transport is needed to 326 create access control lists to allow authenticated and authorized 327 clients on the enforcement points. This WG will identify a 328 (preferably existing) protocol solution that allows the PAA 329 to deliver the authorization information to one or more EPs 330 when the PAA is separated from EPs. 332 4.2.4. Secure Channel 334 PANA MUST not assume a secure channel between the PaC and the PAA. 335 PANA MUST be able to provide authentication especially in networks 336 which are not protected against eavesdropping and spoofing. PANA 337 MUST provide protection against replay attacks on both PaCs and 338 PAAs. 340 Alternatively a combination of PANA with its chosen payload (EAP) 341 can be used to meet the requirements stated above. 343 4.3. Interaction with Other Protocols 345 Mobility management is outside the scope of PANA. Though, PANA MUST 346 be able to co-exist and not interfere with various mobility 347 management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 348 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other 349 standard protocols like IPv6 stateless address auto-configuration 350 [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP 351 [DHCP]. It MUST NOT make any assumptions on the protocols or 352 mechanisms used for IP address configuration of the PaC. 354 4.4. Performance 356 PANA design SHOULD give consideration to efficient handling of 357 authentication process. This is important for gaining network access 358 with minimum latency. As an example, a method like minimizing the 359 protocol signaling by creating local security associations can be 360 used for this purpose. 362 4.5. Reliability and Congestion Control 364 PANA MUST provide reliability and congestion control. It can do so 365 by using techniques like re-transmissions, cyclic redundancy check, 366 delayed initialization and exponential back-off. 368 In order to satisfy the these requirements, the PANA MAY specify 369 that high layer protocols, such as EAP, provide these 370 services 372 4.6. Miscellaneous 374 4.6.1. IP Version Independence 376 PANA MUST work for both IPv4 and IPv6. 378 4.6.2. Denial of Service Attacks 380 PANA MUST be robust against a class of DoS attacks such as blind 381 masquerade attacks through IP spoofing that swamp the PAA in 382 spending much resources and prevent legitimate clients� attempts of 383 network access. 385 4.6.3. Location Privacy 387 Location privacy is outside the scope of PANA. 389 4.7. Change Log 391 Version 04 393 * Minor Editorial corrections 395 * Inserted the PANA model appendix 397 Version 03 399 * In section 4.2.2 the requirement for a heartbeat mechanism to 400 provide disconnect indication was removed. Rewording of the 401 section was done 403 * In section 4.2.3 and 4.1.2 rewording was done to account for 404 the separation of PAA and EP and the protocol between them. 406 * In section 4.2.4 new text was added to account for the possibility 407 to rely on the high layer protocol (EAP) to meet the requirements 408 stated 410 * In section 4.5 new text was added to allow reliability and 411 congestion control to be provided by the payload protocol, e.g., 412 EAP. 414 Acknowledgements 416 We would like to thank Basavaraj Patil, Subir Das, and the PANA 417 Working Group members for their valuable contributions to the 418 discussions and preparation of this document. 420 References 422 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 423 Requirement Levels", RFC 2119, March 1997. 425 [8021X] "IEEE Standards for Local and Metropolitan Area Networks: 426 Port Based Network Access Control", IEEE Draft 802.1X/D11, March 427 2001. 429 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 430 51, RFC 1661, July 1994. 432 [MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002, 433 October 1996. 435 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 436 draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress. 438 [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 439 Extensions", RFC3012, November 2000. 441 [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 442 for IP Version 6 (IPv6)",RFC 2461, December 1998. 444 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 445 RFC 826, November 1982. 447 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 448 Mobile IPv4", November 2001. Work in progress. 450 [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile 451 IPv6", July 2001. Work in progress. 453 [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration 454 Protocol for IPv6", December 2001. Work in progress. 456 [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 457 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 459 Authors' Addresses 461 Alper E. Yegin 462 DoCoMo USA Labs 463 181 Metro Drive, Suite 300 464 San Jose, CA, 95110 465 USA 466 Phone: +1 408 451 4743 467 Email: alper@docomolabs-usa.com 469 Yoshihiro Ohba 470 Toshiba America Research, Inc. 471 P.O. Box 136 472 Convent Station, NJ, 07961-0136 473 USA 474 Phone: +1 973 829 5174 475 Email: yohba@tari.toshiba.com 477 Reinaldo Penno 478 Nortel Networks 479 600 Technology Park 480 Billerica, MA, 01821 481 USA 482 Phone: +1 978 288 8011 483 Email: rpenno@nortelnetworks.com 485 George Tsirtsis 486 Flarion Technologies 487 Bedminster One 488 135 Route 202/206 South 489 Bedminster, NJ, 07921 490 USA 491 Phone : +44 20 88260073 492 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 493 Cliff Wang 494 Smart Pipes 495 565 Metro Place South 496 Dublin, OH, 43017 497 USA 498 Phone: +1 614 923 6241 499 Email: cwang@smartpipes.com 501 Appendix 503 A. PANA Model 505 Following sub-sections capture the PANA usage model in different 506 network architectures with reference to its placement of logical 507 elements such as, PANA Client (PaC) and PANA Authentication Agent 508 (PAA) w.r.t Enforcement Point (EP) and Access Router (AR). Four 509 different scenarios are described in following sub-sections. Note 510 that PAA may or may not use AAA infrastructure to verify the 511 credentials of PaC and grants or deny the device (belongs to that 512 particular PaC) to access the network resources. 514 A.1. PAA Co-located with EP but separated from AR 516 In this scenario (Figure 1), PAA is co-located with the enforcement 517 point on which access control is performed. PaCs communicate with 518 the PAA for network access on behalf of a device (D1, D2,... etc.). 519 PANA in this case provides a means to transport the authentication 520 parameters from the PaC to PAA securely. PAA understands how to 521 verify the credentials. After verification, PAA sends back the 522 success or failure to PaC. However, PANA does not play any explicit 523 role in performing access control except that it provides a hook to 524 access control mechanisms. 526 PaC -----EP/PAA-+ 527 [D1] | 528 +- ----- AR ----- (AAA) 529 | 530 PaC -----EP/PAA-+ 531 [D2] 533 Figure 1: An example of PANA Model 534 [PAA co-located with EP but separated from AR] 536 A.2. PAA Co-located with AR but separated from EP 538 Figure 2 describes this model. In this scenario, PAA is not co- 539 located with EPs but resides in the edge subnet. Although we have 540 shown only one AR here there could be multiple ARs with PAAs co- 541 located. PaC exchanges the same messages with PAA as discussed 542 earlier. The difference here is when initial authentication for the 543 PaC is successful, access control parameters are to be distributed to 544 respective enforcement points residing in the edge subnet so that the 545 corresponding device on which PaC is authenticated must get the 546 access to the network. Similar to earlier case, PANA does not play 547 any explicit role in performing access control except that it 548 provides a hook to access control mechanisms. However, a separate 549 protocol is needed between PAA and EP to carry access control 550 parameters. 552 PaC -------- EP --+ 553 [D1] | 554 +--- router/PAA --- (AAA) 555 | 556 PaC -------- EP --+ 557 [D2] 559 Figure 2: An example of PANA Model 560 [PAA co-located with AR but separated from EP] 562 A.3. PAA colocated with EP and router 564 In this scenario (Figure 3), PAA is co-located with the EP and AR on 565 which access control and routing are performed. PaC exchanges the 566 same messages with PAA and PAA performs similar functionalities as 567 above. PANA in this case also does not play any explicit role in 568 performing access control except that it provides a hook to access 569 control mechanisms. 571 PaC ---------- EP/PAA/router+ 572 [D1] | 573 + -------(AAA) 574 | 575 PaC ---------- EP/PAA/router+ 576 [D2] 578 Figure 3: An example of PANA Model 579 [PAA co-located with EP and AR] 581 A.4. PAA Separated from EP and AR 583 Figure 4 represents this model. In this scenario, PAA is neither co- 584 located with EPs nor ARs but resides on the edge subnet. Although we 585 have shown only one PAA here there could be multiple PAAs in the edge 586 subnet. PaC does similar exchanges with PAA as discussed earlier. 587 Similar to model 5.2, after successful authentication, access control 588 parameters will be distributed to respective enforcement points via a 589 separate protocol and PANA does not play any explicit role to this. 591 PaC ----- EP -----+- router -----+ 592 | | 593 PaC ----- EP --- -+ | 594 | | 595 PaC ----- EP -----+- router ---- + ----(AAA) 596 | 597 +- PAA 599 Figure 4: An example of PANA Model 600 [PAA separated from EP and AR] 602 Full Copyright Statement 604 "Copyright (C) The Internet Society (2002). All Rights Reserved. 605 This document and translations of it may be copied and furnished to 606 others, and derivative works that comment on or otherwise explain it 607 or assist in its implementation may be prepared, copied, published 608 and distributed, in whole or in part, without restriction of any 609 kind, provided that the above copyright notice and this paragraph 610 are included on all such copies and derivative works. However, this 611 document itself may not be modified in any way, such as by removing 612 the copyright notice or references to the Internet Society or other 613 Internet organizations, except as needed for the purpose of 614 developing Internet standards in which case the procedures for 615 copyrights defined in the Internet Standards process must be 616 followed, or as required to translate it into languages other than 617 English. 619 The limited permissions granted above are perpetual and will not be 620 revoked by the Internet Society or its successors or assigns. 622 This document and the information contained herein is provided on an 623 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 624 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 625 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 626 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 627 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.