1 / 6

PANA Framework Status

PANA Framework Status. IETF 66. Progress. IETF last call+ completed draft-ietf-pana-framework-06 Pekka Savola, Bernard Aboba, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black, IEEE 802.11 Working Group Lots of clarifications (text improvement) The I-D aims “informational RFC”

wilda
Download Presentation

PANA Framework Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PANA Framework Status IETF 66

  2. Progress • IETF last call+ completed • draft-ietf-pana-framework-06 • Pekka Savola, Bernard Aboba, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black, IEEE 802.11 Working Group • Lots of clarifications (text improvement) • The I-D aims “informational RFC” • “Bound” vs. “associated” • The PANA session can be associated with the communication channel it was carried over. • IKEv1 vs. IKEv2 • Must implement IKEv1, IKEv2 optional • Document simplification and clean up recommended

  3. Considerations • Do we really need to acknowledge PAA and EP separation and reflect it on the protocol design? • This separation is widely (if not always) used. • Explicit support has very minor impact on the PANA protocol design (explicit identification of EPs) • Do we need to specify PAA-to-EP protocol? Can't we mark it as out of scope and not specify anything? • The PAA-to-EP protocol gap was identified during the early days of the WG. • That protocol is orthogonal to PANA protocol • Some people have concerns about using SNMP for configuration. • Various protocols were assessed earlier (RADIUS, COPS, Diameter, LDAP) and SNMP was chosen. • Deployments are not forced to use SNMP

  4. Considerations • Can't we only consider cases where the lower-layer is already secured? • Only supporting lower-layer-secured (e.g., wired) networks is unnecessarily limiting • This limitation does not yield any considerable PANA protocol simplification • Keep the hooks in place (Protection-Capability AVP, PaC-EP-Master-Key derivation) • Can we drop PANA-IPsec? • The details will be removed from the framework document • The PANA-IPsec document is necessary for interoperability (keep it) • No impact on the PANA protocol specification. • Can we drop the enabling L2 security from the specs? People can still do that, but we'd avoid its discussion in the specs (which has raised many concerns, e.g., IEEE 802.11) • IEEE 802.11 section will be removed from the framework document, and spun off to another dedicated document

  5. Considerations • Can we refocus and simplify the PANA framework document? • Move the “5. IP address configuration” to an Appendix in base specification • Remove (while retaining useful details elsewhere in the document) • “6. Data Traffic Protection” • “7. PAA-EP Protocol” • “8. Network Selection” • “9. EAP Method Selection” • Spin off to independent documents • “10. Example Cases” • One for WiFi, one for DSL networks

  6. IEEE Feedback • https://datatracker.ietf.org/documents/LIAISON/file336.txt • PANA with bootstrapping IPsec is OK • PANA with virtual open AP mode is OK • Uncontrolled port does NOT allow PANA. IEEE 802.11 change is requried (e.g., definition of a new Authentication and Key Management mechanism) • In IEEE 802.11 systems, data frames are sent only in State 3, not in any state • There is no way to indicate the presence of the “PSK mode bootstrapped from PANA” capability in the RSN Information Element.

More Related