Subject: PANA FAQ v0.5

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 26 Jun 2002 09:38:18 -0700

Folks,

Please see the latest version of PANA FAQ below.

Regards,

alper

-------------------8<---------------------------

PANA FAQ
version 0.5, 6/26/2002
======================

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 and the PAA?
A:  PaC : PANA Client
    PAA : PANA Authentication Agent
    The PaC and PAA are the client and server elements of the
    protocol.

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.

    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 enforcement points. Identification
    of clients which are authorized to access the network is done by the
    PANA protocol exchange. PANA assumes enforcement point is co-located
    with the PAA.

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 enforcement point?
A:   PANA assumes that the PAA is co-located with the enforcement point.
     Separating these entities requires an additional protocol, and this
     protocol is outside the scope of PANA.

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 enforcement points that the client is no longer
     connected). PANA will need to provide a hearbeat-type mechanism
     to provide this functionality. It's usage will be optional,
     depending on the specific L2.

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:   Yes. PaC can gain only limited access using its IP address prior
     to PANA authentication. In certain scenarios this IP address may
     be a temporary one and PaC may need to renew it after PANA exchange.
     In other cases PaC may maintain the same IP address, but the address is
     granted unlimited access after PANA exchange.