Subject: PANA FAQ v0.4

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 5 Jun 2002 12:47:17 -0700

Folks,

Here is the new version of the PANA FAQ, 
revised based on the Thomas Narten's comments
(thanks Thomas) and on-going discussions...

Comments?

alper

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

PANA FAQ
=========

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 (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 infrastrcuture AAA, but in a protocol-neutral way that 
      doesn't require that the client understand the AAA protocols 
      in local use.

Q2: 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.

Q3: 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.

Q4: 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.

Q5: 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.

    PANA does deal with mobility in the "Road Warrier" sense, where a
    traditional client "dials in" to a NAS via PPP. But PPP is oriented
    towards point-to-point links, and the same functionality is needed in
    broadcast LAN environments (e.g., hotel or airport LANs, etc.)

Q6: 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.

Q7: 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. Though, transporting the required information
    to the enforcement points in the network is outside the scope of PANA.

Q8: 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.

Q9: 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.

Q10: Where is the PAA located in the access network?
A:   The PAA must be on an IP capable network element on the same
     IP link as the PaC. Hence it can be on the NAS or WLAN AP or first
     hop router.

Q11: Is PAA always co-located with the enforcement point?
A:   PANA does not require PAA to be co-located with the enforcement
     point. 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 enforcement point(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 on the enforcement points. This transport 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 (for 
     example) be used with link-layer protection, or network layer 
     protection (IPsec). 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:   This question is currently under discussion in the PANA WG.

V: 0.4

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 6 Jun 2002 11:33:13 -0700

> While I can guess what the EAP parenthesis mean I think other readers
> might not. Is the intent
> a transport protocol for an authentication payload (e.g., EAP)

Yes...will clarify..

> The second sentence could be stated more clearly e.g. with
> PPP was not intended to be used for authentication over
> multi-access links.
> (to skirt the issue that folks are using PPPoE)

Agreed.

> This reads a bit strange. Replacing the "PANA" with "PPP" makes more sense
> to me, and then saying
> "and PANA is itended to provide the same functionality in
> broadcast LAN environments ..."
> Is that the intent of the paragraph?

Yes, this makes better sense.

> The last sentence seem to assume that the enforcement point(s) could
> be separate from the PAA. Didn't we make the simplifying assumption
> on the mailing list to assume they are co-located?
> (Or was I halucinating?)

As far as PANA is concerned, they are co-located. This is the
simplifying assumption. PANA doesn't concern itself if some
architectures choose to separate them. We think (expect) that
the decision to separate or co-locate them does not affect PANA.

> This could be more clear.
> Does "IP capable" mean "can be managed using IP protocols" or does it
> mean "is the first hop router"?

The intention was: PAA must have an IP stack. PANA is a L3 protocol
therefore it requires IP processing capabilites on the PAA. That means
PAA cannot be on a device that doesn't have network layer identity (IP
address). For example: a hub.

>
> If a WLAN AP is between the PaC and 1st hop router, and one wishes to
> assign (local use) IP addresses to the client before authentication,
> I don't see how things will work.

I'm not sure if I understand the problem...

Since PAA can be on any node on the same IP link as the PaC, the
options are not just limited to the 1st hop router. Any host that is on
the same subnet as the PaC and 1st hop router can work, or even the AP
itself if it has an IP address (they usually do nowadays).

> This sounds like stating that the PANA needs to worry about all the
complexity
> relating to distributed operation and it will merely punt on
> the packet format specification for how to pass the ACLs to the
enforcement
> points.
> That is neither here nor there.
> Either say "PANA assumes that the PAA is co-located with the enforcement
point.
> Anything else it out of scope." or specify the whole thing.

The former is better :) I guess we were trying to prepare an answer for
"what if I want to separate PAA from the enforcement point(s), can I no
longer use PANA as it assumes they are co-located?" question...

>
> BTW: Note that no IETF protocol I know of require co-location.
> The TCP and IP specifications do not require that the TCP and IP be
> implemented in a co-located fashion. But they don't take it into account
> either.

OK, PANA should not concern itself about this either...

> I suspect there is some complexity in having an L3 service provide
> keys for L2; it at least means that the L2 needs to be re-established
> in a secure mode once the keys are in place.
> Thus if PANA stated this as "will do for L3 per-packet auth and encr
> and it might turn out that if we are lucky that can be applied to
> L2 per-packet auth and encr" I would be more confortable that
> this isn't overselling the abilities.

OK. Will note that... Using generated keys for L2 is not as straight
forward as using for L3.

> Just say "Yes" :-)
> A reasonable approach in my head would be:
 >  - the client acquires IP addresses in normal fashion (DHCPv4, IPv6
>    stateless, DHCPv6)
>  - that mechanism indicates whether PANA is needed (in DHCP option, or RA
>    option)
>  - PANA indicates when authentication is done whether client needs to
>    re-acquire IP addresses (and perhaps which method to use)

My comments to this approach:
- 1st step has security issues, as I mentioned earlier. This is
opening security holes for anonymous malicious
attackers.
- 2nd step requires changes to other (existing and future) protocols.
I think this is undesirable.

But of course, to be fair, I should note that the other alternative of
using unspecified IP address has additional implementation cost.

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 11 Jun 2002 20:37:03 -0700

> *If* the model is that addresses are assigned before authentication
> and in some cases different addresses are assigned after the
authentication
> has completed, then it seems quite odd to have the PAA sit between the
> PaC and the router (where the router does address assignment using
stateless
> or by being a DHC relay), since the router would need to know whether
> the client has already authenticated.
>
> The above is a case where the PAA and 1st hop router need to be co-located
> (unless new protocols are invented between them).
> Do you have an outline/example case that can be made to work (without
> additional protocols) when the PAA and 1st hop router are not co-located?

I think these are good scenarios that suggest PAA be co-located with
1st hop router. The cost of not doing so is yet another protocol.

But there can be other scenarios as well. For example using DHCP, but
DHC server is not co-located with the 1st hop router. So now one might
choose to co-locate PAA with the DHC server, and not necessarily with
the 1st hop router.

Or, another scenario is where client's access to DHC servers and routers
from its operator's network is allowed only after PANA exchange. Client
is bridged to its operator's network after PANA.

>
> I'd prefer saying "co-located PAA and 1st hop router" thereby forcing
folks
> that want something more to provide positive arguments.
> There could be multiple cases folks could argue for:
>  - a PAA between PaC and 1st hop router
>  - a PAA shared between multiple 1st hop routers
>  - a PAA deeper in the network than the 1st hop router
>
> And "out-of-scope" is a reasonable answer IMHO, since it forces folks
> to provide positive arguments that there is a need for either
>  - an enforcement point between PaC and PAA
>  - multiple enforcement points updated by the same PAA
>  - an enforcement pointdeeper in the network than the PAA
>
> I don't see it necessarily changing the *protocols*.
> For instance, if the PaC tells DHCP to release its addresses, and then
> reinitilized the DHCP client to acquire addresses, it doesn't change DHCP
> but merely uses it in new ways by laying on top of DHCP.

How about the DHCP option and RA options needed? I agree these
don't qualify as "protocol changes." They are needed to signal
"the associated addresses are for temporary use only with PANA,
and need to be released and replaced after PANA."

> Yep - and it might constrain the solutions in undesirable manners.
> For instance, suppose it turns out that PIC is a reasonable solution
> (perhaps as a component). Well, you can't do the IKE phase 1 using
unspecified
> addresses (at least not using unmodified components).

I have a different view on this. I think not enabling PANA to work
with unspecified IP address because we *might* end up relying on
PIC is not a justified constraint. Probably some analysis needs to be
done. Note that being able to use unspecified IP address with PANA
does not preclude being able to use a temporary IP address as well.

>
> And if some folks later want to have PAAs that are not on the 1st link
> the constraint to allow unspecified addresses means additional complexity
> akin to DHCP's use of relay agents.

If there is a justifiable reason to place PAA more than one hop away
from the PaC, we should consider it now. Location of PAA and the
IP address allocation requirements are related.

And PANA's support for unspecified IP address does not prevent
IP address allocation before PANA. Both can be supported.

alper