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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Yes, that individual I-D is productized as a proprietary protocol by one
> company (Cisco). 

As I understand it, EAP over UDP is one of the items proposed for 
standardization in the NEA WG.  That leads me to wonder whether the IETF 
will be chartering multiple WGs to standardize EAP encapsulation over IP. 

Although my understanding of both PANA and NEA is no doubt 
incomplete/wrong/confusled, having multiple EAP encapsulation standards 
seems duplicative to me.

> As for 3GPP2, I can get into really gory details of what has been happening
> there, but it's not technical at all (if you are familiar with 3GPP2 and the
> relevant players in this discussion, you can guess).

The issue is that integration of PANA with link layer technologies 
requires the support of the organizations that own those link layers.  
Without that link layer integration (for whatever reason) the scenarios 
can't be realized, at least in a mainstream way. 

It seems to me that one of the motivations for PANA is to *avoid* link layer 
dependencies in situations where link layer technology is inadequate/can't 
be deployed, and a forklift upgrade isn't in the budget.  In those 
circumstances, integration with link layers or IPsec VPN technology is 
not under consideration -- because that would require a forklift upgrade.

For example, the wireless hotspot case where something more sophisticated 
than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN 
deployment isn't a realistic alternative.  Or the shared wired media case 
where "network port authentication" doesn't really work, and wholesale 
switch port replacements aren't affordable.  In both of those cases, EAP 
over IP might provide a light weight, easily deployed solution.

Yet, rather than focusing on the specific scenarios in which PANA might 
be compelling, the PANA framework document tries to cover a wide 
range of potential uses, trying to position PANA for use in scenarios 
where the case is less obvious. 

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]