Subject: RE: The Emperor Has No Clothes: Is PANA actually useful?

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 26 May 2006 11:38:35 -0700

Jari,
 
> 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.
> 

I am trying to figure out the use case for an IP layer solution in this
space as an access authentication protocol and I am not convinced that
we need something like PANA. If you are in fact, adding a node in the
middle of the access network that is going to perform access control, is
it just performing authentication or also attempting to derive keys and
secure the data traffic? With a solution like PANA, a link layer secure
association protocol or IPsec needs to be run to secure data traffic. If
the former, the authenticator (or at least the EP) needs to be located
at the edge. This needs support at the link layer anyway, and all such
link layers already support EAP. 

If the latter, the most natural solution to use is IKEv2 with EAP, since
even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't
see what benefit PANA provides here. 

Perhaps I am missing something here? 

Regards,
Vidya

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Sat, 27 May 2006 00:30:19 +0300

Hi Vidya,

>see what benefit PANA provides here. 
My comment above relates to the overall interest in an IP layer solution
without considering what protocol is used.

I also wrote in my e-mail something about the different alternative
solutions. It is true that IKEv2 with EAP is potentially a good
fit for this task. IKEv2 is my favorite EAP encapsulation
protocol :-) However, its not clear that it currently has all
the parts (though I could have missed some extension somewhere).
For instance, some mechanism appears to be needed to discover
that you are in a network that requires this type of operation,
and to find the address of the control device that you need
to talk to. I haven't done the research on how easy it would
be to add this (probably quite easy) or if there are other
things that we would need. Thoughts?

Anyway, I agree with Dave Crocker that the bar should be
higher for using "there's another solution" argument in last
call discussion of chartered work than in, say, a BOF
discussion. Perhaps we should focus more on whether
the function itself is something that we agree on, and
what we can do to fix/scope/help PANA.

--Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 May 2006 15:32:59 -0700

> to talk to. 

More fundamentally, when there are multiple gateways (for any
redundancy/failover/etc reason), pure IKEv2 solution requires multiple EAP
runs to get authorized for accessing "one" network. This does not work well
with the AAA backend deployments (which defaults to one authentication per
network access).

And it did not make any sense to augment IKEv2 (let alone not being able to
use IKEv1) to meet the PANA requirements, and then force everyone to use it
even though they are not interested in IPsec SAs. 

This was discussed in the PANA WG long time ago. But for people who are not
following the work and trying a last minute "how about this now?" this might
appear like an original idea.

Alper

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 May 2006 16:39:23 -0700

I tried this in my secdir review, for instance suggesting that 
perhaps PANA-IPsec should be limited to IKEv2 and 4301 and people had 
different opinions ranging from 'not sure about forcing IKEv2 on 
PANA' to 'there wouldn't be any differentiator to PANA' (they are not 
quotes; I am paraphrasing), and so really didn't find a consensus to 
make any recommendations.

In the end though, I think perhaps publishing PANA documents after 
the necessary clean-up as experimental and informational RFCs is the 
right way to go about it.  There is a long of line of WGs where this 
has happened and some of those documents have eventually come back 
into standards track.

best regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Sat, 27 May 2006 09:07:23 +0300

Lakshminath Dondeti wrote:

> I tried this in my secdir review, for instance suggesting that perhaps
> PANA-IPsec should be limited to IKEv2 and 4301 and people had
> different opinions ranging from 'not sure about forcing IKEv2 on PANA'
> to 'there wouldn't be any differentiator to PANA' (they are not

That discussion has still been going on (but I forget if it
was in secdir list, with the ADs, or on the PANA list). FWIW,
I fully agree that limiting to IKEv2 would be the right choice.

--Jari