PANA Working Group Alper E. Yegin, Editor INTERNET-DRAFT Yoshihiro Ohba Date: April 2003 Reinaldo Penno Expires: October 2003 George Tsirtsis Cliff Wang Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of the PANA is to provide a link-layer agnostic and IPv4/IPv6 compatible client-server protocol that allows a host to be authenticated for network access. The protocol will run between a client's device and an agent device in the network where the agent might be a client of the AAA infrastructure. This document defines the common terminology and identifies the requirements for PANA. Yegin (Editor), et. al. Expires Oct 2003 [Page 1] Internet Draft PANA Requirements and Terminology Apr 2003 Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Table of Contents.................................................2 1. Introduction...................................................3 2. Key Words......................................................4 3. Terminology....................................................4 4. Requirements...................................................5 4.1. Authentication...............................................5 4.1.1. Authentication of Client...................................5 4.1.2. Authorization, Accounting and Access Control...............6 4.1.3. Authentication Backend.....................................6 4.1.4. Identifiers................................................7 4.2. IP Address Assignment........................................7 4.3. EAP Lower Layer Requirements.................................7 4.4. PAA-EP Protocol..............................................8 4.5. Network......................................................8 4.5.1. Multi-access...............................................8 4.5.2. Disconnect Indication......................................8 4.5.3. Location of PAA............................................9 4.5.4. Secure Channel.............................................9 4.6. Interaction with Other Protocols............................10 4.7. Performance.................................................10 4.8. Ordered-delivery, Congestion Control........................10 4.9. Miscellaneous...............................................10 4.9.1. IP Version Independence...................................10 4.9.2. Denial of Service Attacks.................................10 4.9.3. Location Privacy..........................................10 5. Change Log....................................................11 Acknowledgements.................................................11 References.......................................................11 Authors' Addresses...............................................13 Appendix.........................................................14 Full Copyright Statement.........................................16 Yegin (Editor), et.al. Expires Oct 2003 [Page 2] Internet Draft PANA Requirements and Terminology Apr 2003 1. Introduction Providing secure network access service requires access control based on the authentication and authorization of the clients and the access networks. Initial and subsequent client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication methods between the client and the access network. IETF PANA Working Group has been chartered with the goal of designing a network-layer access authentication protocol. Link-layer authentication mechanisms are used as enablers of secure network access. A higher-layer authentication is deemed necessary when link-layer authentication mechanisms are either not available for lack of technology or deployment difficulties, or not able to meet the overall requirements, or when multi-layer (e.g., link-layer and network-layer) authentication is needed. Currently there is no standard network-layer solution for authenticating clients for network access. In the absence of such a solution, some inadequate standards-based solutions are deployed or non-standard ad-hoc solutions are invented. [USAGE] Internet-Draft describes the problem statement in detail. The protocol design will be limited to defining a client-server messaging protocol (i.e., a carrier) that will allow authentication payload to be carried between the host/client and an agent/server in the access network for authentication and authorization purposes regardless of the AAA infrastructure that may (or may not) reside on the network. As a network-layer protocol, it will be independent of the underlying access technologies. It will also be applicable to any network topology. The Working Group will not invent new security protocols and mechanisms but instead it will use the existing mechanisms. In particular, the Working Group will not define authentication protocols, key distribution or key agreement protocols, or key derivation. The desired protocol can be viewed as the front-end of the AAA protocol or any other protocol/mechanisms the network is running at the background to authenticate its clients. It will act as a carrier for an already defined security protocol or mechanism. As an example, Mobile IP Working Group has already defined such a carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request message is used as the carrier for authentication extensions (MN-FA [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the foreign agents. In that sense, designing the equivalent of Mobile IPv4 registration request messages for general network access is the goal of this work, but not defining the equivalent of MN-FA or MN- AAA extensions. This document defines the common terminology and identifies the requirements of a protocol for PANA. These terminology and Yegin (Editor), et.al. Expires Oct 2003 [Page 3] Internet Draft PANA Requirements and Terminology Apr 2003 requirements will be used to define and limit the scope of the work to be done in this group. 2. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 3. Terminology Device Identifier (DI) The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, identifier might contain any of IP address, link- layer address, switch port number, etc. of a connected device. PANA authentication agent keeps a table for binding device identifiers to the PANA clients. At most one PANA client should be associated with a DI on a PANA authentication agent. PANA Client (PaC) The entity wishing to obtain network access from a PANA authentication agent within a network. A PANA client is associated with a network device and a set of credentials to prove its identity for network access authorization. PANA Authentication Agent (PAA) The entity whose responsibility is to authenticate the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. Enforcement Point (EP) A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP. Yegin (Editor), et.al. Expires Oct 2003 [Page 4] Internet Draft PANA Requirements and Terminology Apr 2003 4. Requirements 4.1. Authentication 4.1.1. Authentication of Client PANA MUST authenticate a PaC for network access. A PaC can be identified by the credentials (e.g., identifier, authenticator) supplied by one of the users of the device or the device itself. PANA MUST only grant network access service to the device identified by the DI, rather than granting separate access to multiple simultaneous users of the device. Once the network access is granted to the device, the methods used by the device on arbitrating which one of its users can access the network is outside the scope of PANA. PANA MUST NOT define new security protocols or mechanisms. Instead, it MUST be defined as a "carrier" for such protocols. PANA MUST identify which specific security protocol(s) or mechanism(s) it can carry (the "payload"). The current thinking is that a sufficient solution would be for PANA to carry EAP [EAP]. If PANA WG decides that extensions to EAP are needed, it will define requirements for the EAP WG instead of designing such extensions. Providing authentication, integrity and replay protection for data traffic after a successful PANA exchange is outside the scope of this protocol. In networks where physical layer security is not present, link-layer or network-layer (e.g., IPsec) ciphering can be used to provide such security. These mechanisms require presence of cryptographic keying material at PaC and EP, which can be generated by various EAP methods. Although PANA does not deal with key derivation or distribution, it indirectly enables this by the virtue of carrying EAP. The keying material produced by EAP methods cannot be directly used with IPsec. In that case these initial keys can be used with an IPsec key management protocol like IKE to generate the required security associations. Key distribution from PAA to EP SHOULD be handled by a separate protocol that takes care of provisioning in the network (see section 4.3). Providing a complete secure network access solution by also securing router discovery [RDISC], neighbor discovery [NDISC], and address resolution protocols [ARP] is outside the scope as well. Securing IPv6 router discovery and neighbor discovery protocols are within the scope of IETF SEND Working Group. Some access networks might require or allow their clients to get authenticated and authorized by the NAP (network access provider) and ISP before the clients gain network access. NAP is the owner of the access network who provides physical and link-layer connectivity to the clients. PANA MUST be capable of enabling two independent authentication operations (i.e., execution of two separate EAP methods) for the same client. Determining the authorization Yegin (Editor), et.al. Expires Oct 2003 [Page 5] Internet Draft PANA Requirements and Terminology Apr 2003 parameters as a result of two separate authentications is an operational issue and therefore it is outside the scope of PANA. Both the PaC and the PAA MUST be able to authenticate each other for network access. Providing capability of only PAA authenticating the PaC is not sufficient. PANA MUST be capable of carrying out both periodic and on-demand re- authentication. Both the PaC and the PAA MUST be able to initiate both the initial authentication and the re-authentication process. Certain type of service theft is possible when the DI is not protected during or after the PANA exchange [SECTHREAT]. PANA MUST have the capability to exchange DI securely between the PAC and PAA where the network is vulnerable to man-in-the-middle attacks. While PANA MUST provide such a capability, its utility relies on the use of an authentication method that can generate keys for cryptographic computations on PaC and PAA. 4.1.2. Authorization, Accounting and Access Control In addition to carrying authentication information, PANA MUST also provide only a binary authorization to indicate whether the PaC is allowed to access full IP services on the network (i.e., able to send and receive any IP packets). Providing finer granularity authorization, such as negotiating QoS parameters, authorizing individual services (e.g., http vs. ssh), individual users sharing the same device, etc. are outside the scope of PANA. Providing access control functionality in the network is outside the scope of PANA. Client access authentication SHOULD be followed by access control to make sure only authenticated and authorized clients can send and receive IP packets via access network. Access control can involve setting access control lists on the EPs. Identification of clients that are authorized to access the network is done by the PANA protocol exchange. Carrying accounting data is outside the scope of PANA. 4.1.3. Authentication Backend PANA protocol MUST NOT make any assumptions on the backend authentication protocol or mechanisms. PAA MAY interact with backend AAA infrastructures such as RADIUS or Diameter, but it is not a requirement. When the access network does not rely on an IETF- defined AAA protocol (e.g., RADIUS, Diameter), then it can still use a proprietary backend system, or rely on the information locally stored on the authentication agents. Yegin (Editor), et.al. Expires Oct 2003 [Page 6] Internet Draft PANA Requirements and Terminology Apr 2003 The interaction between the PAA and the backend authentication entities is outside the scope of PANA. 4.1.4. Identifiers PANA SHOULD allow various types of identifiers to be used for the PaC (e.g., NAI, IP address, FQDN, etc.). This requirement generally relies on the client identifiers supported by various EAP methods. PANA SHOULD allow various types of identifiers to be used as the DI (e.g., IP address, link-layer address, port number of a switch, etc.) PAA MUST be able to create a binding between the PaC and the associated DI upon successful PANA exchange. The DI MUST be carried either explicitly as part of the PANA payload, or implicitly as the source of the PANA message, or both. Multi-access networks also require use of a cryptographic protection along with DI filtering to prevent unauthorized access [SECTHREAT]. The keying material required by the cryptographic methods needs to be stored as an attribute of DI. The binding between DI and PaC is used for access control and accounting in the network as described in section 4.1.2. 4.2. IP Address Assignment Providing address assignment functionality is outside the scope of PANA. PANA protocol design MAY require the PaC to configure an IP address before using this protocol. Allocating an IP address to unauthenticated PaCs may create security vulnerabilities, such as IP address depletion attacks on the access network [SECTHREAT]. This threat may not be an issue for IPv6 because of the large address space, but it can affect IPv4 networks. This threat can be mitigated by allowing the protocol to run without an IP address on the PaC (i.e., using unspecified source address). Such a design choice might limit the re-use of existing security mechanisms, and impose additional implementation complexity. This trade off should be taken into consideration in designing PANA. 4.3. EAP Lower Layer Requirements EAP protocol itself imposes various requirements on its transport protocols. These requirements are based on the nature of the EAP protocol, and needs to be satisfied for correct operation. Please see [EAP] for the generic transport requirements that MUST be satisfied by PANA as well. Yegin (Editor), et.al. Expires Oct 2003 [Page 7] Internet Draft PANA Requirements and Terminology Apr 2003 4.4. PAA-EP Protocol PANA does not assume that the PAA is always co-located with the EP(s). Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). When the PAA and the EP(s) are separated, there needs to be another transport for client provisioning. This transport is needed to create access control lists to allow authenticated and authorized clients’ traffic through the EPs. This WG will preferably identify an existing protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. Possible candidates include but not limited to COPS, SNMP, DIAMETER. This task is similar to what MIDCOM Working Group is trying to achieve, therefore some of that WG’s output might be useful here. It is assumed that the communication between PAA and EP(s) is secure. The objective of using this protocol is to provide filtering rules to EP(s) for allowing network access of a recently authenticated and authorized PaC. The chosen protocol MUST be capable of carrying DI and cryptographic keys for a given PaC from PAA to EP. Depending on the PANA protocol design, support for either of the pull model (i.e., EP initiating the PAA-EP protocol exchange per PaC) or the push model (i.e., PAA initiating the PAA-EP protocol exchange per PaC), or both MAY be required. For example, if the design is such that the EP allows the PANA traffic to bypass even for unauthenticated PaCs, it should also allow and expect the PAA to send the filtering information at the end of successful PANA without EP ever sending a request. 4.5. Network 4.5.1. Multi-access Protocol MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. In other words, PANA MUST not assume PaC has only one network interface, or the access network has only one first hop router, or the PaC is using a point- to-point link. 4.5.2. Disconnect Indication PANA MUST NOT assume that the link is connection-oriented. Links MAY or MAY NOT provide disconnect indication. Such notification is desirable in order for the PAA to cleanup resources when a client moves away from the network (e.g., inform the enforcement points that the client is no longer connected). PANA SHOULD have a mechanism to provide disconnect indication. When such indications are not protected by means of physical or link-layer mechanisms, Yegin (Editor), et.al. Expires Oct 2003 [Page 8] Internet Draft PANA Requirements and Terminology Apr 2003 PANA MUST ensure this protection to prevent attackers from leveraging this extension for DoS attacks. This mechanism MUST allow the PAA to be notified about the departure of a PaC from the network. This mechanism MUST also allow a PaC to be notified about the discontinuation of the network access service. Access discontinuation can happen due to various reasons such as network systems going down, or a change in access policy. In case the clients cannot send explicit disconnect messages to the PAA, PAA can still detect their departure by relying on periodic authentication requests. 4.5.3. Location of PAA The PAA and PaC MUST be exactly one IP hop away from each other. That means, there must be no IP routers between two. Note that, this does not mean they are on the same physical link. Bridging techniques can place two nodes just exactly one IP hop away from each other although they might be connected to separate physical links. Furthermore, two nodes on the same IP subnet does not necessarily satisfy this requirement, as they can be more than one hop away from each other [MULTILINK]. PAA can be on the NAS (network access server) or WLAN access point or first hop router. The use of PANA when the PAA is multiple IP hops away from the PaC is outside the scope of PANA. A PaC MAY not be pre-configured with the IP address of PAA. Therefore PANA protocol MUST define a dynamic discovery method. Given that the PAA is one hop away from the PaC, there are a number of discovery techniques that could be used (e.g., multicast or anycast) by the PaC to find out the address of the PAA. 4.5.4. Secure Channel PANA MUST not assume presence of 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 enable protection against replay attacks on both PaCs and PAAs. This requirement partially relies on the EAP protocol and the EAP methods carried over PANA. Use of EAP methods that provide mutual authentication and key derivation/distribution is essential for satisfying this requirement. EAP does not make a secure channel assumption, and supports various authentication methods that can be used in such environments. Additionally, PANA MUST ensure its design does not contain vulnerabilities that can be exploited when it is used over insecure channels. PANA MAY provide a secure channel by deploying a two-phase authentication. First phase can be used for Yegin (Editor), et.al. Expires Oct 2003 [Page 9] Internet Draft PANA Requirements and Terminology Apr 2003 creation of the secure channel, and the second phase is for client and network authentication. 4.6. Interaction with Other Protocols Mobility management is outside the scope of PANA. Though, PANA MUST be able to co-exist and not interfere with various mobility management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other standard protocols like IPv6 stateless address auto-configuration [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP [DHCP]. It MUST NOT make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC. 4.7. Performance PANA design SHOULD give consideration to efficient handling of authentication process. This is important for gaining network access with minimum latency. As an example, a method like minimizing the protocol signaling by creating local security associations can be used for this purpose. 4.8. Ordered-delivery, Congestion Control PANA MUST provide ordered-delivery for messages that carry EAP PDUs as described in [EAP]. PANA MUST provide congestion control for all messages. It can do so by using techniques like delayed initialization and exponential back off. 4.9. Miscellaneous 4.9.1. IP Version Independence PANA MUST work with both IPv4 and IPv6. 4.9.2. Denial of Service Attacks PANA MUST be robust against a class of DoS attacks such as blind masquerade attacks through IP spoofing that swamp the PAA in spending much resources and/or prevent legitimate clients' attempts of network access. 4.9.3. Location Privacy Location privacy is outside the scope of PANA. Yegin (Editor), et.al. Expires Oct 2003 [Page 10] Internet Draft PANA Requirements and Terminology Apr 2003 5. Change Log Version 05 * Definition of EP added. * Text is clarified to indicate some of the requirements are satisfied by EAP and EAP methods. * IP address pre-configuration requirement changed. * EAP lower layer requirements section added. * Location of PAA further clarified (link vs. subnet vs. IP hops). * PAA-EP protocol section added. Version 04 * Minor Editorial corrections. * Inserted the PANA model appendix. Version 03 * In section 4.2.2 the requirement for a heartbeat mechanism to provide disconnect indication was removed. Rewording of the section was done. * In section 4.2.3 and 4.1.2 rewording was done to account for the separation of PAA and EP and the protocol between them. * In section 4.2.4 new text was added to account for the possibility to rely on the high layer protocol (EAP) to meet the requirements stated. * In section 4.5 new text was added to allow reliability and congestion control to be provided by the payload protocol, e.g., EAP. Acknowledgements We would like to thank Subir Das, Lionel Morand, Mohan Parthasarathy, Basavaraj Patil and the PANA Working Group members for their valuable contributions to the discussions and preparation of this document. References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [USAGE] Y. Ohba, S. Das, B. Patil, H. Soliman, A. Yegin, "Problem Statement and Usage Scenarios for PANA", draft-ietf-pana-usage- scenarios-05.txt, April 2003. Work in progress. [8021X] "IEEE Standards for Local and Metropolitan Area Networks: Port Based Network Access Control", IEEE Draft 802.1X/D11, March Yegin (Editor), et.al. Expires Oct 2003 [Page 11] Internet Draft PANA Requirements and Terminology Apr 2003 2001. [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and Security Requirements", draft-ietf-pana-threats-03.txt, April 2003. Work in progress. [EAP] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-01.txt, January 2003. Work in progress. [MULTILINK] D. Thaler, C. Huitema, "Multi-link Subnet Support in IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, December 2002. Work in progress. [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4", RFC 3344, August 2002. [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-21.txt, February 2003. Work in progress. [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC3012, November 2000. [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)",RFC 2461, December 1998. [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982. [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in Mobile IPv4", November 2001. Work in progress. [FMIPV6] R. Koodli (editor), et. al., "Fast Handovers for Mobile IPv6", March 2003. Work in progress. [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration Protocol for IPv6", November 2002. Work in progress. [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. Yegin (Editor), et.al. Expires Oct 2003 [Page 12] Internet Draft PANA Requirements and Terminology Apr 2003 Authors' Addresses Alper E. Yegin DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA, 95110 USA Phone: +1 408 451 4743 Email: alper@docomolabs-usa.com Yoshihiro Ohba Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ, 07961-0136 USA Phone: +1 973 829 5174 Email: yohba@tari.toshiba.com Reinaldo Penno Nortel Networks 600 Technology Park Billerica, MA, 01821 USA Phone: +1 978 288 8011 Email: rpenno@nortelnetworks.com George Tsirtsis Flarion Technologies Bedminster One 135 Route 202/206 South Bedminster, NJ, 07921 USA Phone : +44 20 88260073 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com Cliff Wang Smart Pipes 565 Metro Place South Dublin, OH, 43017 USA Phone: +1 614 923 6241 Email: cwang@smartpipes.com Yegin (Editor), et.al. Expires Oct 2003 [Page 13] Internet Draft PANA Requirements and Terminology Apr 2003 Appendix A. PANA Model Following sub-sections capture the PANA usage model in different network architectures with reference to its placement of logical elements such as PANA Client (PaC) and PANA Authentication Agent (PAA) w.r.t Enforcement Point (EP) and Access Router (AR). Four different scenarios are described in following sub-sections. Note that PAA may or may not use AAA infrastructure to verify the credentials of PaC to authorize network access. A.1. PAA Co-located with EP but separated from AR In this scenario (Figure 1), PAA is co-located with the enforcement point on which access control is performed. PaCs communicate with the PAA for network access on behalf of a device (D1, D2, etc.). PANA in this case provides a means to transport the authentication parameters from the PaC to PAA. PAA understands how to verify the credentials. After verification, PAA sends back the success or failure response to PaC. However, PANA does not play any explicit role in performing access control except that it provides a hook to access control mechanisms. This might be the case where PAA is co- located with the access point (an IP-capable L2 access device). PaC -----EP/PAA-+ [D1] | +- ----- AR ----- (AAA) | PaC -----EP/PAA-+ [D2] Figure 1: PAA co-located with EP but separated from AR. A.2. PAA Co-located with AR but separated from EP Figure 2 describes this model. In this scenario, PAA is not co- located with EPs but it is placed on the AR. Although we have shown only one AR here there could be multiple ARs one of which is co- located with the PAA. PaC exchanges the same messages with PAA as discussed earlier. The difference here is when the initial authentication for the PaC succeeds, access control parameters are to be distributed to respective enforcement points so that the corresponding device on which PaC is authenticated must be able to access to the network. Similar to the earlier case, PANA does not play any explicit role in performing access control except that it provides a hook to access control mechanisms. However, a separate Yegin (Editor), et.al. Expires Oct 2003 [Page 14] Internet Draft PANA Requirements and Terminology Apr 2003 protocol is needed between PAA and EP to carry access control parameters. PaC -------- EP --+ [D1] | +--- AR/PAA --- (AAA) | PaC -------- EP --+ [D2] Figure 2: PAA co-located with AR but separated from EP. A.3. PAA Co-located with EP and AR In this scenario (Figure 3), PAA is co-located with the EP and AR on which access control and routing are performed. PaC exchanges the same messages with PAA and PAA performs similar functionalities as above. PANA in this case also does not play any explicit role in performing access control except that it provides a hook to access control mechanisms. PaC ---------- EP/PAA/AR--+ [D1] | + -------(AAA) | PaC ---------- EP/PAA/AR--+ [D2] Figure 3: PAA co-located with EP and AR. A.4. PAA Separated from EP and AR Figure 4 represents this model. In this scenario, PAA is neither co- located with EPs nor with Ars. It still resides on the same IP link as ARs. PaC does similar exchanges with PAA as discussed earlier. Similar to model in A.2, after successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this. Yegin (Editor), et.al. Expires Oct 2003 [Page 15] Internet Draft PANA Requirements and Terminology Apr 2003 PaC ----- EP -----+- AR -----+ | | PaC ----- EP --- -+ | | | PaC ----- EP -----+- AR ---- + ----(AAA) | +- PAA Figure 4: PAA separated from EP and AR. Full Copyright Statement "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Yegin (Editor), et.al. Expires Oct 2003 [Page 16]