1 / 20

PANA Update and Open Issues (draft-ietf-pana-pana-02.txt)

PANA Update and Open Issues (draft-ietf-pana-pana-02.txt). Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin. PANA Issues http://www.danforsberg.info:8080/pana-issues/.

rhona
Download Presentation

PANA Update and Open Issues (draft-ietf-pana-pana-02.txt)

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 Update and Open Issues(draft-ietf-pana-pana-02.txt) Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin IETF 58 PANA WG

  2. PANA Issueshttp://www.danforsberg.info:8080/pana-issues/ • 15 issues for draf-ietf-pana-pana-01were resolved and closed Resolution text incorporated in pana-02 • There are 9 open issues for pana-02 IETF58 PANA WG

  3. PANA-01 Issues (Closed) IETF58 PANA WG

  4. Message Format Related Issues • The same message type is allocated to each pair of Request and Answer message (Issue 22) • use R-flag to distinguish Request from Answer • PANA uses its own type space for message and AVP types (Issue 23) • No type space sharing with Diameter • A new message “PANA-Error” is defined (Issue 17) • Section 4.1.8 defines the error handling rule • Section 9.3.13 defines the message format • AVP alignment rule is added (Issue 24) • The same 32-bit alignment rule as Diameter • Termination-Cause AVP values are defined (Issue 18) • Result-Code AVP values are defined (Issue 19) IETF58 PANA WG

  5. Other Issues • Defined detailed retransmission behavior and default parameters (Issue 20, explained later) • Service Profile Names (Issue 25, explained later) • Clarified that Session-Lifetime is non-negotiable and can be carried in PANA-Bind-Request message sent from PAA (Issue 8) • Clarified that PAA SHOULD initiate EAP re-authentication before the session lifetime expires (Issue 31) • Security Consideration section is updated (Issue 32) • Re-wording “periodical refresh” to “liveness test”, etc. • Clarification of Section 4.9 “Device-ID Choice” (Issue 33) • PaC and PAA checks peer’s Device ID each other • Minor editorial changes (Issues 21, 26, 30) IETF58 PANA WG

  6. Issue 20: Retransmission Timers and Counters • Issue: Define default timer and retransmission counts • Resolution: • Adopt the RFC3315 [DHCPv6] model • Define algorithm and parameters for retransmission • Use of exponential backoff • Classify messages retransmitted by PANA Each class uses the same default parameter values • PANA-PAA-Discover • Other messages • Define default values for each class IETF58 PANA WG

  7. Issue 25: Service Profile Names • Issue: Carrying network information during discovery and initial handshake phase would be helpful for a user to choose NAP and ISP • Resolution: • Defined two new AVPs: NAP-Information AVP and ISP-Information AVP • Defined a new flag (S-flag) • Define the usage of the AVPs and S-flag IETF58 PANA WG

  8. Issue 25 (cont’d){NAP,ISP}-Information AVP NAP-Information ::= < AVP Header: 1034 > 0*1 { Provider-Identifier } { Provider-Name } * [ AVP ] ISP-Information ::= < AVP Header: 1035 > 0*1 { Provider-Identifier } { Provider-Name } * [ AVP ] Provider-Identifier (Unsigned32): IANA-Assigned Enterprise Identifier Provider-Name (UTF8String) IETF58 PANA WG

  9. Issue 25 (cont’d){NAP,ISP}-Information AVP Usage • PAA can advertise *-Information AVPs in PANA-Start-Request message • S-flag in PANA-Start-Request/Answer exchange is used for negotiating NAP/ISP separate authentication • F(inal)-flag is not needed any more • During the negotiation, PaC can choose an ISP by including an ISP-Information AVP in the PANA-Start-Answer message • PAA can specify which authentication (NAP or ISP) is occuring • by including a corresponding *-Information AVP in the first PANA-Auth-Request message in each authentication IETF58 PANA WG

  10. Issue 25 (cont’d)Example Sequence PANA-PAA-Discover PANA-Start-Request [ISP1, ISP2, NAP] // S-flag set Discovery& Initial Handshake PANA-Start-Answer [ISP1, NAP] // S-flag set PANA-Auth-Request[NAP, EAP{Req.}] PANA-Auth-Answer[EAP{Resp.}] NAP Authentication … PANA-Bind-Request/Answer Execution order can be reversed PANA-Auth-Request[ISP1, EAP{Req.}] PANA-Auth-Answer[EAP{Resp.}] ISP Authentication … PANA-Bind-Request/Answer IETF58 PANA WG

  11. PANA-02 Issues (Open) IETF58 PANA WG

  12. Open Issue List (ordered by importance)http://www.danforsberg.info:8080/pana-issues/ IETF58 PANA WG

  13. Issue 34: Behavior with NAP and ISP • Issue: How Session-Lifetime relates to NAP and ISP authentications? • Proposed Resolution: • A single Session-Lifetime is bound to a PANA session • When NAP and ISP have different authorization lifetimes, the smaller one relates to the Session-Lifetime • When EAP re-authentication occurs, both NAP and ISP authentications will be performed IETF58 PANA WG

  14. Issue 37: Unknown Realm Error Propagation • Issue: • Should “unknown realm” AAA message routing error be propagated to PaC? • Discussion: • EAP state machine does not support propagation of AAA errors • When such an error occurs, the authentication state machine enters a sink “failure” state without generating any error or an EAP-Failure message • Direct interface from AAA to PAA would be needed • Resolution? IETF58 PANA WG

  15. Issue 29: EAP Failure and PANA-Bind-Request • Issue: • Should PANA-Termination-Request be used for carrying EAP-Failure instead of PANA-Bind-Request? • Discussion: • When NAP/ISP separate authentication is performed, a single EAP failure does not mean PANA authentication failure • Resolution • PANA-Term.-Request is not appropriate to carry EAP-Failure for the above reason • Use PANA-Bind-{Request,Answer} message to carry EAP-Success/Failure (as the current draft does) • “Bind” may be renamed to “Result” if the word “Bind” does not make sense to carry EAP-Failure IETF58 PANA WG

  16. Issue 36: (Re)authentication Race Condition • Issue: • It is possible for both PaC and PAA to simultaneously initiate EAP (re)authentication. How can PANA handle the case? PaC PAA PANA-Start-Request (or PANA-Auth-Request) PANA-PAA-Discover • Proposed Resolution: • PAA can always be the winner, by ignoring the received PANA-PAA-Discover message after it sends a PANA-Start-Request (or PANA-Auth-Request) IETF58 PANA WG

  17. Issue 35: EP Information • Issue: • PANA-IPsec draft assumes that PaC learns the IP address of the EP during the PANA exchange. But PANA specification does not support it • Proposed Resolution: • Having an AVP to carry the Device-Id of EP(s) • Device-Id AVP can have a fieldto indicate whether the device belongs to PAA or a separate EP • The AVP is carried in PANA-Bind-Request IETF58 PANA WG

  18. Issue 16: Multihoming Support • Issue: • When PaC has multiple interfaces on the same IP link, should it be supported with a single PANA session or separate PANA sessions? • Discussion • A single PANA session for multiple interfaces is basically an optimization issue • Proposed resolution: • We should do a more thorough analysis if we support the scenario with a single PANA session • Until the analysis is made, separate PANA session is sufficient IETF58 PANA WG

  19. Issue 12: Supporting Network Access Authentication for Ad-hoc Networks • Issue: • Should PANA support ad-hoc network scenario where there may be one or more untrusted nodes between PaC and PAA? • Resolution? Ad-hoc network ISP PaC PAA Untrusted nodes IETF58 PANA WG

  20. Issue 2: Downgrading Protection • Issue: • EAP allows negotiation of an EAP method between authenticator and peer. This mechanism is vulnerable to downgrading attacks. • Discussion: • Providing downgrading protection in PANA is not good since an EAP server may not be co-located with PAA • EAP method negotiation is not performed by PANA, so this is an EAP issue • Resolution: • Text incorporated in Security Considerations section • Recommendation of using EAP-GSSAPI to negotiate an EAP method IETF58 PANA WG

More Related