PANA WG Yacine El Mghazli Internet Draft Alcatel Category: Informational Document: draft-yacine-pana-paa-ep-reqs-00.txt Expires: December 2003 June 2003 PANA PAA-EP Protocol Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [STD]. 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 This document specifies the requirements that the PAA-EP protocol must satisfy in order to meet the needs of PANA when the PAA is separated from EP(s). El Mghazli Expires - December 2003 [Page 1] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 Conventions used in this document 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 [RFC2119]. Table of Contents 1. Glossary.......................................................3 2. Introduction...................................................3 2.1 Scope......................................................4 3. PANA framework Assumptions/Issues..............................4 3.1 Multiple PAAs..............................................4 3.2 Inter-PAAs communication...................................6 4. PAA-EP Protocol Requirements...................................7 4.1 Push model.................................................7 4.2 Pull model.................................................7 4.3 1:n PAA-EP relation........................................8 4.4 Inactive peer detection....................................8 4.5 Stateful approach..........................................8 4.6 Recovery...................................................8 4.7 General Security Requirements..............................8 4.8 Accounting/Feedback from the EPs...........................9 4.9 Re-use of an existing protocol.............................9 Security Considerations...........................................9 References........................................................9 Acknowledgments........................Error! Bookmark not defined. Author's Addresses...............................................10 Full Copyright Statement.........................................11 El Mghazli Expires - December 2003 [Page 2] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 1. Glossary PANA Protocol for Carying Authentication for Network Access. PaC (PANA Client): The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization. DI (Device Identifier): The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, this identifier might contain any of IP address, link- layer address, switch port number, etc. of a connected device. PAA (PANA Authentication Agent): The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. EP (Enforcement Point): 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. 2. Introduction 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 enforcement points. Identification of clients which are authorized to access the network is done by the PANA protocol exchange. 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 El Mghazli Expires - December 2003 [Page 3] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 control lists to allow authenticated and authorized clients' traffic through the EPs. PANA Working Group 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. 2.1 Scope The following section 3 discusses the PANA framework assumptions that are being made within the PANA working group. It deals with crucial issues around the authentication process, when the PAA is separated from EP(s). From this standpoint, section 4 details the requirements that the PAA-EP protocol must satisfy in order to meet the needs of such a framework. 3. PANA framework Assumptions/Issues 3.1 Multiple PAAs Multiple PAAs may be used for redundancy, load sharing, distributed authentication, or other purposes: a) Redundancy is the case where one or more PAAs are prepared to take over if an active PAA fails. b) Load sharing is the case where two or more PAAs are concurrently active and any PaC that can be authenticated by one of the PAAs can also be authenticated by any of the other PAAs. For both redundancy and load sharing, the PAAs involved are equivalently capable. The only difference between these two cases a) and b) is in terms of how many active PAAs there are. c) Distributed authentication is the case where two or more PAAs are concurrently active but certain PANA requests using PANA can only be serviced by certain PAAs. The logical separation can be based on: . Topology: One given PAA is in charge of authenticating a pool of PaCs belonging to the same topological area. . The ISP: One given PAA is in charge of authenticating the PaCs clients to a given ISP. Then it forwards the PANA requests based on the NAI or other identifier. El Mghazli Expires - December 2003 [Page 4] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 . Etc. Clearly stating the motivation for having multiples PAAs authenticating PaCs and provisoning EPs in an access network has direct consequences on both PaC-PAA and EP-PAA relations. 3.1.1 PAA-PaC relation assumption According to [PANA] (section "Discovery and Initial Handshake Phase"), "There can be multiple PAAs on the link. The result does not depend on which PAA PaC chooses. By default PaC chooses the PAA that sent the first response." Then, it is straighforward that the assumption that is being made here is that two or more PAAs are concurrently active and any PaC that can be authenticated by one of the PAAs can also be authenticated by any of the other PAAs. We are clearly in the case where the PaCs load is shared between the multiple PAAs (b). Do note that discovery issues are raised with allowing muliples PAAs to authenticate the various PaCs. [PANA] solves the problem simply stating that the chosen PAA corresponds to the first response. It is consistent with case b). 3.1.2 PAA-EP relation issue In a similar manner, it is crucial for identifying the various PAA-EP protocol requirements to clearly identify the context for having multiples PAAs with respect to the EPs provisoning. One PAA have to communicate with several EPs once a PaC is authenticated is a requirement for the PAA-EP protocol (see section 4.3). In the case where there is a single PAA, the assumption being made is that the PAA will provision all the EPs. However, it remains an issue in case we have multiple PAAs. When multiple PAAs authenticate the PaC, a given PAA can either: a) Redundancy: provisions all the EPs of the underlying access network and each EP has a single active PAA. A back-up PAA is ready to take over if the first one fails. b) Load sharing: provisions all the EPs of the underlying access network and each EP can be controlled by another active PAA. El Mghazli Expires - December 2003 [Page 5] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 c) Distributed control: provisions a pool of EPs within a given area. The pool can be identified based on topological criteria for instance. The choice between these options is motivated by PANA-specific considerations. Typically, these can be: . Scalability: How many EPs are managed by the PAA(s) ? . Symetry: Does all the EPs need to be configured with the same rules ? . Etc. 3.2 Inter-PAAs communication When multiple PAAs are employed, their internal organization is considered an implementation issue that is beyond the scope of PANA. PAAs are wholly responsible for coordinating amongst themselves to provide consistency and synchronization. However, PANA does not define the implementation or protocols used between PAAs, nor does it define how to distribute functionality among PAAs. Nevertheless, PANA will support mechanisms for PAA redundancy or fail over, and it is expected that vendors will provide redundancy or fail over solutions within the PANA framework. El Mghazli Expires - December 2003 [Page 6] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 4. PAA-EP Protocol Requirements 4.1 Push model PAA must be able to "push" the provisioning information down to EPs, without any of the EPs "pulling" it. Since PANA exchange takes place between PaC and PAA, EPs are unlikely to be aware of it. EP provisioning takes place once the PaC is authenticated and authorized, hence the event triggering the EP configuration takes place at the PAA. Then it's straighforward to initiate the exchange at the PAA. 4.2 Pull model The PUSH model (PAA-initiated configuration) should be used for the communication between PAA and EP. On the other hand, the PULL model (EP-initiated configuration) might be supported also for the following purposes: 1. Initial EP registration/Recovery: When a EP is newly connected to the network, it needs to register itself to the PAA. In a similar manner, when an EP crashes and comes up again, it needs to re-connect its PAA. In general, when a failure is detected, the EP must try to reconnect to the remote PAA or attempt to connect to PAA. 2. (Optional) traffic-driven config (a.k.a. event-notification): As stated in [PANA], PaC may also choose to start sending packets before getting authenticated. In that case, the network should detect this and send an unsolicited PANA_start message to PaC. EP is the node that can detect such activity. If EP and PAA are co- located, then an internal mechanism (e.g. API) between the EP module and the PAA module on the same host can prompt PAA to start PANA. In case they are separate, there needs an explicit message to prompt PAA. Upon detecting the need to authenticate a client, EP can send a trigger message to the PAA on behalf of the PaC. This can be one of the messages provided by the PAA-EP protocol, or, in the absence of such a facility, PAC_discovery can be used as well. This message MUST carry the device identifier of the PaC. So that, El Mghazli Expires - December 2003 [Page 7] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 PAA can send the unsolicited PANA_start message directly to the PaC. 4.3 One-to-many PAA-EP relation One PAA have to communicate with several Eps once a PaC is authenticated. The PAA-EP protocol must be able to handle this 1:n communication. 4.4 Inactive peer detection The protocol used between PAA and EP should be able to detect inactive peer within an appropriate time period. This can be achieved by having both the EP and remote PAA constantly verify their connection to each other via keep-alive messages: a heartbeat in fact. 4.5 Stateful approach The protocol must allow to maintain some states in the PAA in order for an EP that went down and came back up, or an EP that is being introduced in the network to (re-)synchronize with the PAA. In general terms, the PAA-EP protocol needs to support the stateful model between the PAA and the EP(s) and some other mechanism for the EP to learn the policies currently in effect on that access network. 4.6 Recovery TBD. If there is awareness of a connection state in the application level and we have a keepalive and/or use a reliable transport protocol (similar to routing protocols), all detection and synchronizing of state will come naturally. 4.7 General Security Requirements The PAA-EP protocol must provide for message authentication, confidentiality, and integrity. The PAA-EP protocol must define mechanisms to mitigate replay attacks on the control messages. El Mghazli Expires - December 2003 [Page 8] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 4.8 Accounting/Feedback from the EPs The PAA must have an efficient way to to get the accounting information of PaC from EP since the PAA may be a client of the AAA backend infrastructure. 4.9 Re-use of an existing protocol This work hopefully will not involve any new protocol design, it may involve definition of new AVPs for existing protocols. The PANA working group should try to re-use one of the many protocols around to do this. The following protocols were mentioned for consideration: . SNMP [SNMP] . COPS-PR [COPS-PR] . DIAMETER [DIAMETER] . RADIUS [RADIUS] . ForCES [ForCES] Security Considerations See section 4.7 References [STD] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology" (draft-ietf- pana-requirements-07.txt). [RADIUS] C. Rigney et. al, "Remote Authentication Dial In User Service", RFC2865, June 2000. [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Policy Provisioning,", RFC 3084, March 2001 El Mghazli Expires - December 2003 [Page 9] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 [PANA] D. Forsberg, Y. Ohba, B. Pati, H. Tschofenig, A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)"(draft-ietf-pana-pana-00.txt). [DIAMETER] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, "Diameter Base Protocol" (draft-ietf-aaa-diameter-15.txt). Author's Addresses Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex Phone: +33 (0)1 69 63 41 87 Email: yacine.el_mghazli@alcatel.fr El Mghazli Expires - December 2003 [Page 10] Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003 Full Copyright Statement "Copyright (C) The Internet Society (2003). 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. El Mghazli Expires - December 2003 [Page 11]