PANA FAQ version 0.7, 1/9/2003 ====================== Q1: What is PANA? A: PANA is - a layer two agnostic network layer messaging protocol for authenticating IP hosts for network access - a transport protocol for authentication payload (e.g., EAP) between a client (IP based) and a server (agent) in the access network. It's a single protocol that all clients can use, regardless of the AAA infrastructure that may (or may not) reside on the network. Conceptually, PANA allows clients to interact with the infrastructure AAA, but in a protocol-neutral way that doesn't require that the client understand the AAA protocols in local use. Q2: What is the PaC, PAA, and EP? A: PaC : PANA Client PAA : PANA Authentication Agent EP : Enforcement Point The PaC and PAA are the client and server elements of the authentication protocol. EP(s) are in charge of preventing unauthorized use of the network. Q3: Does PANA aim to replace link layer authentication? A: No. PANA will complement and/or coexist with link layer authentication mechanisms to enable network layer authentication. For example, not all L2 authentication methods can provide support for various authentication methods, dynamic service provider selection, and roaming clients. When these features are required but not already provided by the link layer authentication, PANA can be used in a complementary way. PANA may be a substitute for link-layer authentication in environments where L2 authentication is unavailable (or cannot be used). There are drawbacks and limitations to this approach, but some people have indicated that this is still a useful application in some environments. Q4: Do we still need PANA if the link-layer supports authentication? A: It is a common practice to use higher-layer authentication on top of link-layer authentication. For example in 3GPP and 3GPP2, PPP is used for authentication after link-layer authentication succeeds. Or, http-redirect method is used as a higher-layer user authentication in some other network access architectures. Hence even if link-layer authentication exists, PANA is needed in certain scenarios. In some cases, L2 authentication is also used to (implicitely) authorize IP service (e.g., PPP). In such environments, PANA may not be useful or necessary. Q5: Is PANA specifically targeted for mobile/wireless networks? A: No. PANA is applicable for any type of network that requires the host that is attaching to it for access to authenticate itself before being granted access. Note that PANA is specifically targeted at multi-access links, as opposed to point-to-point links. This is one reason why PPP is not deemed adequate. PPP was not intended to be used for authentication over multi-access links. Q6: Does PANA deal with mobility? A: No. However mobile IP based networks may use PANA for network access authentication. Mobile IPv4 developed its own protocols for performing PANA-like functions (e.g., MN-FA interaction). Mobile IPv6 does not have a foreign agent (FA) and has not (yet) developed Mobile IP-specific mechanisms for gaining access to a foreign network. It is expected that PANA would provide such functionality without the need for a Mobile IP-specific protocol. PPP does deal with mobility in the "Road Warrier" sense, where a traditional client "dials in" to a NAS via this protocol. But PPP is oriented towards point-to-point links. PANA is intended to provide similar authentication functionality in broadcast LAN environments (e.g., hotel or airport LANs, etc.) Q7: Does PANA introduce new security vulnerabilities as a result of being an L3 solution? A: There are potential DOS vulnerabilities, theft-of-service vulnerabilities. An access authentication protocol like PANA should be accompanied by a per-packet authentication method. PANA provides a way for such protection to be achieved. See Q19. Q8: Does PANA do access control? A: No. PANA enables access control indirectly. 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 EP(s). Identification of clients which are authorized to access the network is done by the PANA protocol exchange. Q9: Does PANA require a AAA protocol/infrastructure in the access network? A: PANA may interact with backend AAA infrastructures such as RADIUS or Diameter. But it is not a requirement. When the access network doesn't rely on a 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. Q10: Where is the PAA located in the access network? A: It is assumed that the PAA is attached to the same link as the PaC (i.e., no intermediary IP routers). It is generally co-located with the first hop router. Q11: Is PAA co-located with the EP? A: PANA does not assume that the PAA is co-located with the EP(s). The WG will identify a protocol solution for enabling PAA-EP communication. Q12: How does the PaC know the address of the PAA? A: Since the PAA is on the same link as the PaC, there are number of discovery techniques that could be used (e.g., multicast or anycast). Q13: Does PANA assign the client/host an IP address? A: No. PANA does not perform any address assignment functions. Q14: What type of authorization does PANA provide? A: It provides only a binary authorization to indicate whether the PaC is allowed to access full IP services on the network. It doesn't deal with finer granularity authorization, such as negotiating QoS parameters, authorizing individual services (http vs. ssh), individual users sharing the same device, etc. Q15: Is PANA applicable to IPv6 only? A: No. PANA is IP version agnostic in addition to being L2 agnostic. Q16: What is the role of EAP in PANA? A: The current thinking is that a sufficient solution would be for PANA to carry EAP. If PANA WG decides that extensions to EAP are needed, it will define requirements for an EAP WG instead of defining these extensions. Q17: Is PANA a client-server or peer-peer protocol? A: PANA is a client-server protocol. Q18: Does the PAA know (or need to know) when the PaC has disconnected from the network? A: Some networks do not provide an L2 mechanism to indicate when connectivity between the client and PAA has been lost. Such notification is desirable in order for the PAA to cleanup resources when a client moves away from the network (e.g., inform the EPs that the client is no longer connected). Q19: Does PANA provide per-packet authentication and encryption? A: PANA itself does not do this. However, PANA will provide a way for such per-packet authentication/encryption to be achieved. There are EAP methods that can generate session keys. Therefore PANA is an enabler for per-packet protection. The keys generated could be used with network layer protection (IPsec). Another possibility is to use them with link-layer protection, though this would require L2-L3 interaction. Generation and distribution of these keys is outside the scope of PANA. Q20: Does the PaC have to configure an IP address before using PANA? A: Not necessarily. PANA design should allow clients to use this protocol before or after IP address configuration. PaC should be granted only limited access even if it configures an IP address prior to PANA. Link-local IPv4 and IPv6 addresses are likely candidates for pre-PANA IP address configuration.