Sam,
I think your note is asking in fact a number of questions:
1. Is the concept of EAP-authentication over IP for network
access useful, as opposed to link layer mechanisms?
2. Is the PANA realization of this idea good, and
are the documents satisfactory?
3. Is there a specific real-world case where PANA is being
applied or will be applied?
4. What other alternatives exist for the same function
and how do they compare to PANA?
Re 1: I do believe an IP layer solution in this space
is potentially useful. Not as something that replaces
existing link layer solutions and takes over the market,
but there are situations where it would be useful,
for instance over link layers that have no such support,
as a solution for networks where you just want to add
a node in the middle of the access network without updating
all access points (kind of like a replacement for weblogin
but without the need for user intervention), etc.
Re: 2: Here there are some issues, clearly. Defining
a mechanism that works well in the IP layer does take
some considerable care for discovery, local IP address,
binding of the EAP to what is being done, etc. reasons.
Even if you didn't have these complications, the task
of getting all details right takes a long time, just
witness how long 802.11i took. The task becomes
even harder if you try cover situations that involve distributed
implementation, allowances for different pluggable
components, different environments, etc. This may be
the root cause why we are in this discussion. Without "the
target" WGs want to shoot for maximum flexibility, but if they
overdo it they may get too many issues to worry about. And
a lot of baggage to carry around in the protocol. And
it for sure makes it hard to read the specs.
Having said the above, I'm not sure there are any
fundamental, unfixable problems in the protocol.
The base protocol itself looks solid.
Re: 3: This has been a long standing issue for the WG's
results. I don't have much to add what was already said by
others; in general, many of the specific technologies
like 3GPP cellular or 802.11 employ their own link-layer
solutions and the vendors tend to go with these. But
I also know that PANA had been under serious
consideration at least for 3GPP2 networks.
Re: 4: There are indeed choices. The default assumption
is going to be link layer protection, but as I said
above, there seems to be some scenarios for other
solutions as well. The question is what those solutions
are and how they compare. One alternative is IKEv2
with its EAP support. It comes close to a full solution,
but appears to lack at least discovery functionality
since nomadic clients can't be expected to know the
addresses of gateways in the networks they visit.
But there may be some extension that I'm unaware
of. (Historically, it is interesting to note that the first
IKEv2 drafts started to appear around the time that
PANA got chartered, though it seems that EAP support
was added to IKEv2 only later.)
Another alternative is described in draft-thomson-nacp-02.txt;
this is a bare bones, very simple EAP-over-UDP solution.
I like it, but if it were adopted as an IETF proposed
standard it would probably need to support discovery,
key confirmation and possibly some other things.
PPPoE is an alternative. Propably folks who are doing
this are going to continue using it.
Some other partial solutions exist too. For instance,
PANA has the capability to support authenticating
both to a local network and to a home network;
draft-barany-eap-gee is a solution for that (but
met with some number of questions in the last
EAP meeting).
Is there a winner among the alternatives?
Perhaps too early to tell. I have some unease
with all of the options, in fact.
So what's the conclusion? My conclusion is that
there is need for a non-link layer solution, too.
I feel the pain from PANA searching real world
deployment, but I'm not sure we should set the
PS bar so high that if you do not have commercial
deployment you cannot publish your documents.
We should, however, require that the specifications
pass last call review, and work remains there.
I'm not sure I have easy answers on how to get
there. One advice that I would like to give is
to take another look at the ambition level and
scale it down. (Management 101: if you can't
fix it, rip it out.) A solution that does not mix
IP and link layer solutions would be preferrable,
IMHO, and then we would get out of the 802.11
interaction problems. Perhaps lose the EP
separation. Core PANA as a way to run EAP
and confirm possession of the resulting key
would be very useful, IMHO. Tunneling IPsec for
data packets could be optional.
--Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf