ietf
[Top] [All Lists]

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

2006-05-26 16:35:20
Hi Jari,


Hi Vidya,

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.
 

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?


Let me separate out two issues here. In order to discover that you are
in a network that requires this type of operation, you need to know via
some kind of advertisements (SSID, for instance) that you are not in the
home network. For instance, VPN connections today are mostly user
initiated. 

Another issue that you mention here is the discovery of the address of
the control device - this is typically done via DNS today. 

Thinking further about the PAA discovery mechanisms outlined in the PANA
protocol, it seems to bring some deployment concerns. Administratively
scoped multicast is one of the advocated methods of performing PAA
discovery. Administrative scoping of multicast is a huge administrative
burden and is not a good deployment option. Protocols like DVMRP allow
TTL scoping which are somewhat better. But, the thought of opening up
port control to allow multicast packets into the network prior to
authentication is not appealing to me. 

Another option that PANA provides for PAA discovery is traffic-driven
discovery. This is somewhat similar to what EAP relies on - i.e., the
network figures out that it needs to send an EAP Request Identity (in
the absence of an EAPoL-Start like message). 

In short, discovery hardly seems to be a reason to use PANA to me - I'm
trying to at least taste the kool-aid, even if I can't drink it all, but
somehow, am yet finding a convincing reason why I should :) 

Vidya


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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>