Subject: Re: PANA FAQ

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Jun 2002 06:28:17 -0400

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: Yoshihiro Ohba <[email-masked]>
Date: Wed, 5 Jun 2002 10:26:20 -0400

> usefulness of PANA in practice?

I don't think such a scope limitation will limit the usefulness of
PANA.  It would be important to allow PANA messaging to occur before
the client assigns a routable IP address through, e.g., DHCP or
Neighbor Discovery, but that usage can be supported without using
unspecified (i.e., all 0's) address as long as the client can use some
specified IP address (e.g., an IPv6 link-local address or a similar
type of IPv4 address) before it gets a routable IP address.

So I think that there is no strong reason to support PANA messaging
with unspecified IP address.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 5 Jun 2002 11:09:55 -0700

Yoshihiro,

> type of IPv4 address) before it gets a routable IP address.

Even configuring a link-local address would require host to
send IP packets on the link. An unauthenticated host would need
to send neighbor solicitations and neighbor advertisements
for duplicate address detection. Is this not a concern?

Note that using unspecified IP address doesn't require
sending and receiving IP packets prior to PANA exchange.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 5 Jun 2002 16:05:01 -0400

> for duplicate address detection. Is this not a concern?

Hmm, I don't understand why that becomes a concern.  We can discuss
based on an analogy to L2 authentication.

For example, when we consider 802.1X over 802.11, some management
frames (Beacon, Probe request/response, etc.) are allowed to be
exchanged between a station and an access point even before the
station is authenticated.  Bringing this ananogy to one step higher
layer, i.e., PANA over IP, it seems to be natural for an
unauthenticated host would exchange some IP layler management messages
(i.e., neighbor discovery messages) with access router(s).

> sending and receiving IP packets prior to PANA exchange.

I currently fail to see what the exact problem is when neighbor
discovery message exchange occurs prior to PANA exchange and how
unspecified IP address can solve that problem.

Yoshihiro Ohba

---

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

Yoshihiro,

> (i.e., neighbor discovery messages) with access router(s).

This analogy makes sense as long as these messaging happens
between the client and an agent in the network. 

Problems arises when you let this messaging happen between
clients, some of which might still be unauthenticated.

For DAD, an unauthenticated client must be able to send/receive
NS and NA. A malicious node can respond to every NS and
claim the IPv6 address, therefore deny the service for a legitimate
client which is trying to get a link-local address before PANA.

> unspecified IP address can solve that problem.

With unspecified IP address, client doesn't have to send or receive
any packets other than PANA prior to being authenticated. (no need for
DAD, NS, NA).

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 6 Jun 2002 14:35:20 -0400

Alper,

> client which is trying to get a link-local address before PANA.

As Erik pointed out, that attack for DAD is possible from both
unauthenticated and authenticated (in terms of client authentication)
client hosts.  In addition, even if we could apply per-packet
authentication mechansim to secure NS/NA messages (by using
SEcureND?), I think the DAD attack is still possible from the group of
hosts that share the same per-packet level security association used
for securing multicast NA messages (since NA messages used for DAD are
multicast, I assume here that a group SA would be needed.)  So, I
still fail to understand the problem the PANA-before-ND scenario is
actually trying to solve.  But this discussion is very interesting.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Jun 2002 20:45:24 -0700

Yoshi,

> actually trying to solve.  But this discussion is very interesting.

There are ways around this problem, but here is not the place to discuss
them. See draft-kempf-ipng-secure-nd-00.txt for one.

        jak