Subject: RE: PANA FAQ

From: "Bilgic, Murat" <[email-masked]>
Date: Wed, 5 Jun 2002 09:45:05 -0700

A publically routable IPv4 address is a fairly valuable resource. IMHO, in
an ideal network, it should not be given to whoever asks for it, i.e.,
before authentication. Therefore, "if the scope of PANA is limited to being
invoked ONLY AFTER the client has a usable IP adddress", then it will not
fit into my definition of an "ideal network". Solutions involving temporary
address pools seem plausible, and if I am not mistaken even practiced in
some networks, but they give me serious concern for other security problems.

Murat 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 3:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: PANA FAQ 

I'd like to hear more from others on the issue Basavaraj is raising
below.

If the scope of PANA  is limited to it being invoked ONLY AFTER the
client has a usable IP address (e.g., a link-local address in IPv6 or
a DHCP-learned address in IPv4), will this signficantly limit the
usefulness of PANA in practice?

I think this point is important because it suggests to me that some
folks are thinking that PANA should be the first interaction a client
has with the network, and that no IP address is assigned until PANA
does its work. If this is deemed important, I think we need to
understand this sooner rather than later.

Thoma

<[email-masked]> writes:

> >> I tend to agree. But the thinking has been that the host could possibly
ICMP
> >> with IP address 0 to carry EAP payload. So it is possible that we
> >> could do authentication without the host having been assigned
> >> an address. 
> >
> >I think this misses a basic point. If a server has to support multiple
> >concurrent operations with clients -- with each client using the all
> >0's address -- the server needs some other way to distinguish
> >connections than IP addresses/port numbers. This would likely be
> >something based on the link-layer addresses used. But now, we no
> >longer have vanilla IP. We have IP plus the link-layer address. Note
> >this is an issue for all higher-layer "connection-oriented" protocols
> >(EAP would be one, in the sense that a connection consists of a
> >sequence of related packets belonging to a single EAP transaction). So
> >it does create complexity and would seem to lose a number of the
> >advantages of the pure L3 solution (which I thought was supposed to be
> >L2-agnostic).

> If we believe there is added complexity that is not worth dealing
> within developing a solution for PANA with the all 0's address, then
> we could specify a requirement that "PANA MUST not use the all 0's IP
> address to communicate with the athentication agent in the network."
> This would ensure that the scope is well constrained.

> However this would seriously limit the scope of PANA in v4 networks at
> least. PANA can use the stateless address autoconfig mechanism in v6
> and use that address for the PANA messages. But in the case of v4,
> such a reqiurement would imply that we use mechanisms such as PPP (or
> DHCP) to obtain an IP address, and if that is the case, then the need
> for PANA is quite limited. 

> Maybe we should look at other alternatives such as having a temporary
> IP address (from a reserved pool) assigned to the host specifically
> for the task of PANA signaling, and if successful, can be substituted
> with another adress for the host to use (security implications need
> to be studied).

> >Thomas

> -Basavaraj

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Jun 2002 13:07:59 -0400

> some networks, but they give me serious concern for other security problems.

To be clear, based on discussions quite a while back, I don't assume
that giving a client an address means giving that client access "full
network access", e.g., an address that can be used to reach the
Internet.

There was talk of having (say) DHCP give an address, but that address
could have "limited routability", for example, only on the link or
within the local site. To gain more access, PANA would need to be
invoked, and a side-effect of the intereaction is that the PAA could
interaction with the AAA infrastructure (and other parts of the
internal infrastructure) in a way that results in the address that was
already granted gaining broader capabilities.

One issue I have with not allowing *any* IP access prior to the PANA
exchange is that this comes awfully close to saying you want PANA to
provide access control, which by the nature of it being L3, PANA
cannot provide. If that is really what one wants, it's hard to ignore
the argument that L2 authentication/access control is better able to do
this than L3. On many wireless technologies, for example, a client
could connect to the network spoof an authorized address, launch DOS
attacks, consume bandwidth resources on the first-hop link, etc.

Thomas

---

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Jun 2002 17:33:30 -0700

Thomas,

> attacks, consume bandwidth resources on the first-hop link, etc.

Well, this example does make it difficult to see how PANA could be a
replacement for L2 access control. If the point of a last hop AAA
protocol is to keep unauthorized hosts out of the network, then, by
requiring a host to first have an address, PANA would open the
possibility of attacks such as you've outlined. This is not to say that
PANA doesn't have other uses, however.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 5 Jun 2002 19:07:38 -0700

> > this than L3. 

But we are not arguing that PANA is better than L2 authentication and
PANA will replace L2 authentication. Q2 and Q3 in the FAQ address
these points.

> > On many wireless technologies, for example, a client

Clearly, in order to prevent address spoofing, per-packet protection
is required. This is regardless of whether we are talking about a L2
solution or a L3 solution. Q6 and Q19 of the FAQ are answer to this issue.

alper