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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf