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

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 26 May 2006 16:34:22 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 27 May 2006 11:00:46 -0400

Vidya,

Administratively scoped multicast is not the only way for PAA
discovery.  DHCP based PAA discovery is also available:

draft-ietf-dhc-paa-option-02.txt

Regards,
Yoshihiro Ohba

---

From: Pekka Savola <[email-masked]>
Date: Sat, 27 May 2006 20:44:41 +0300 (EEST)

> draft-ietf-dhc-paa-option-02.txt

I suspect adminsitratively scoped multicast discovery wouldn't be 
acceptable for much the similar reasons as Service Location Protocol 
(SLP) wouldn't be -- it requires multicast deployment.

We made an analysis of end-point discovery mechanisms for v6 tunnels a 
while ago.  It might be worth a read:

http://draft-palet-v6ops-tun-auto-disc.potaroo.net

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings