1. Why not EAP over PANA? Qualcomm, Inc. Vidya Narayanan, Dondeti, Lakshminath, Jun Wang, Pete Barany Notice: QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non- discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by QUALCOMM Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

2. Introduction and Outline PANA is complex at many levels  Too many documents  Too many protocols Unnecessarily too deep in the stack  Need IP address to operate Complex Architecture More susceptible to DoS attacks Configuration Complexity Fundamental issues raised at the IETF Not a coincidence that it is not used anywhere yet!

3. PANA Document List WG Documents  draft-ietf-pana-cxtp draft-ietf-pana-cxtp  draft-ietf-pana-mobopts draft-ietf-pana-mobopts  draft-ietf-pana-preauth draft-ietf-pana-preauth  draft-ietf-pana-snmp draft-ietf-pana-snmp  draft-ietf-pana-statemachine draft-ietf-pana-statemachine  draft-ieft-pana-aaa-interworking draft-ieft-pana-aaa-interworking  draft-ietf-pana-framework draft-ietf-pana-framework  draft-ietf-pana-ipsec draft-ietf-pana-ipsec  draft-ietf-pana-pana draft-ietf-pana-pana  RFC 4058 RFC 4058 RFC 4058  RFC 4016 RFC 4016 RFC 4016  draft-ietf-pana-usage-scenarios draft-ietf-pana-usage-scenarios Related documents  draft-anjum-pana-location-requirements-00.txt draft-anjum-pana-location-requirements-00.txt  draft-bournelle-pana-mobopts-analysis-00.txt draft-bournelle-pana-mobopts-analysis-00.txt  draft-forsberg-pana-skc-00.txt draft-forsberg-pana-skc-00.txt  draft-marin-pana-ieee80211doti-00.txt draft-marin-pana-ieee80211doti-00.txt Evidently, a long list of documents to even parse, let alone implement!

4. Fundamental Issues with PANA IETF Security AD Evaluation of PANA:  “The PANA WG seems to have a fundamental misunderstanding about 802.11i. I believe that the people involved in the PANA WG have been told about their misunderstanding by the editor of 802.11i (Jesse Walker from Intel), and it seems that this input was ignored this input. As a result the PANA specification that will not work at all in wireless LANs that deploy 802.11i.”

5. Fundamental Issues with PANA IETF Security AD Evaluation of PANA:  “An Access Point that implements 802.11i will silently discard all PANA traffic, and as a result, the PANA usage scenarios 802.11i (either TKIP or CCMP, which are called WPA and WPA2 by the WiFi Alliance) cannot work as described.”

6. PANA Architecture PaCPAAAS EP PANA AAA/LDAP/API SNMP/ API IKE/ 4-way HS

7. Protocols Involved in PANA EAP over PANA  EAP (RFC3748)  IPsec  PANA-SNMP  CxTP  PANA-AAA EAP Method Secure Association Protocol  802.11i 4-way exchange  802.16e 3-way exchange  IKE  Key management still separate and diverse for different access technologies

8. Protocols Involved – EAPoHRPD EAP over HRPD  EAP (RFC3748) EAP Method GEE

9. Protocol Layering HRPD EAP Layer Peer Layer Method1Method2 GEE Layer UDP EAP Layer Peer Layer Method1Method2 IPLower LayerPANA EAPoPANA Peer Stack EAPoHRPD Peer Stack

10. DoS Impacts Worst case impact on system (EAP over PANA)  L2 AND L3 equipment!  More layers to launch DoS attacks  DHCP-based attacks possible Worst case impact on system (EAPoHRPD)  L2 equipment only!

11. Comparison (1 of 2) EAP over HRPD EAP over PANA Number of OTA messages required  7 7 7 7  7 (not counting AT obtaining IP address) NOTE: If not optimized via piggybacking,  13 EAP methods supported AllAll Integrity protection of EAP messages Yes (dependent upon EAP method) Yes Encryption of attributes in EAP messages Yes (dependent upon EAP method) Reliable, in-order delivery Yes (via EAP retransmission and RLP retransmission/sequence numbers) Yes (via PANA retransmission/sequence numbers, EAP retransmission, and RLP retransmission/sequence numbers) Fragmentation Yes (via RLP or specific EAP method) IP address required No Yes (e.g, link-local)

12. Comparison (2 of 2) EAP over HRPD EAP over PANA Reliable indication that EAP exchange has completed successfully or failed Yes (dependent upon the EAP method) Yes Separate access authentication (NAP) and service authentication (ISP) supported YesYes Identity privacy supported Yes (dependent upon the EAP method) Bandwidth efficient Yes Requires UDP/IP header (maybe use ROHC to help) LightweightYes Not really 3GPP2 standards work required Yes (about the same as for EAPoPANA … see next slide) Yes (about the same as for EAPoHRPDRLP … see next slide) IETF momentum/industry adoption Yes (meaning EAP over a specific link-layer, not EAP over HRPD per se) Questionable … also, 3GPP2 dependent upon IETF to publish PANA RFCs in timely manner

13. PANA Timeline 2001 Start of PANA work 20022003200420052006?? Original Deadline Fundamental Issues Raised; Still in last call Start of EAPoHRPD work 20052006 Start Of GEE GEE to IESG EAPoHRPD/GEE Timeline EAPoHRPD Completion

14. Timeline EAPoHRPD  4Q of 2005 GEE  Submission to IESG by 5/1/06 PANA  Last call in progress  Fundamental issues raised by security AD No clear resolution seems possible  Work in progress for 5 years now; could prolong much longer

15. Conclusion Stating the obvious, no reason to use PANA  EAPoHRPD is simpler  EAPoHRPD with GEE does everything we need