1 / 20

PANA Specification Last Call Issues

Detailed overview of 39 new issues discussed in IETF61 PANA WG, addressing categories A and B issues for protocol clarification and change. Includes resolution proposals for better protocol implementation.

belindac
Download Presentation

PANA Specification Last Call Issues

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 SpecificationLast Call Issues Yoshihiro Ohba, Alper Yegin, Basavaraj Patil, D. Forsberg, Hannes Tschofenig IETF61 PANA WG

  2. Overview • Received many comments • Generated 39 new issues • Thank you for reviewing and giving detailed comments • Two categories in this presentation • Category A Issues (24 issues, just listed today): • Editorial issues • Technical issues that requires minor clarification • Category B Issues (15 issues, discussed today): • Technical issues that requires protocol changes or major clarification IETF61 PANA WG

  3. List of Category A Issues (1/2) • Issues 118, 119 (cookie issues: naming change and how to get DI) • Issue 120 (removal of sentence on EAP message creation) • Issue 121 (clarification on PANA_MAC_KEY and TSK) • Issue 122 (clarification on replay attack protection) • Issue 123 (clarification on “very first request message”) • Issue 124, 133 (clarification on “stateless”) • Issue 125 (clarification on why piggybacking EAP-Resp in PAN is not always good) • Issue 126 (clarification of PANA-Reauth exchange error) • Issue 128 (DI and IP address of PaC in PANA SA attributes) • Issue 129 (Clarification of optimized PANA execution) IETF61 PANA WG

  4. List of Category A Issues (2/2) • Issue 130 (replacing the term “client” with “device”) • Issue 131, 132 (Clarification in terminology section) • Issue 135 (PTR/PTA exchange is not needed after PBR/PBA failure with PANA_AUTHORIZATION_REJECTED) • Issue 138 (Clarification of “one IP hop” requirement) • Issue 139 (clarification of L2 trigger) • Issue 140 (EAP-Success/Failure also carried in PFER) • Issue 141 (editorial comments from Gerardo) • Issue 142 (section 6.1 needed?) • Issue 143 (Clarification of CTP and PANA) • Issue 146 (editorial comments from Julien) • Issue 147 (which PAA ID with AAA-Key int computation) IETF61 PANA WG

  5. Category B Issues IETF61 PANA WG

  6. Issue 112: ‘M’ bit Clarification • Issue: • The M (Mandatory) bit is underspecified. When it is set, what happens when it is set/unset and an AVP is notrecognized? • Proposed Resolution: • If an AVP with the 'M' bit set is unrecognized (unknown type/value), the message MUST be discarded • If an AVP with the 'M' bit cleared is unrecognized, the message MAY simply ignore the AVP • Default value for AVPs defined in this document: • The 'M' bit MUST be set. • The 'V' bit MUST NOT be set IETF61 PANA WG

  7. Issue 113: Clarification of Authorization Phase • Issue: • The wording “authorization phase” is confusing because authorization is performed at the end of authentication phase • Proposed resolution: • Change the name to “Authorized phase” • Revise text for explaining the authorized phase IETF61 PANA WG

  8. Issue 114: Liveness Test • Issue: • Can a PANA exchange other than PANA-Ping exchange be used for liveness test? • Discussion • Yes • Resolution: • Add the following text in section11.8 • “Not only a PANA ping exchange but also other valid recent request/answer exchange can imply the other side is alive.” IETF61 PANA WG

  9. Issue 115: Clarification of PANA session definition • Issue: • Why the session cannot be shared across multiple network interfaces? • Discussion: • This is because only one DI of the PaC is allowed to be bound to a PANA session at a time for simplicity • Should be rephrased without using the term “interface” • Proposed resolution: • Rephrase the session definition using the term “device identifier” instead of “interface” IETF61 PANA WG

  10. Issue 116,134: Device-Id, Protection-Cap. and PPAC AVPs handling in PBR • Issue: • Rules as to when to or not to include Device-Id AVP in PBR should be more specific • Discussion: • Device-Id AVP in PBR needs to be always included when Protection-Capability AVP is carried in PBR • Do we use DI binding only when we use L2/L3 ciphering enable after PANA? (The answer is NO) • DI binding without enabling L2/L3 ciphering can be performed without Device-ID AVP (i.e., taking DI from MAC/IP header) • But carrying Device-Id in PANA message can make implementation easier • Proposed resolution: • Device-Id AVP is carried in PBR if Prot.-Cap. AVP is carried • Dev.-ID AVP MAY be carried in PBR if Prot.-Cap. AVP is not carried • If PBA does not contain Device-Id AVP when expected, the PAA initiates PER/PEA exchange to terminate the session • Other change: When PBR does not carry PANA-SUCCESS result code, Prot.-Cap. AVP and PPAC AVP is not carried in PBR IETF61 PANA WG

  11. Issue 117: DI with IPsec Clarification • Issue: • Which is the DI of PaC, IPsec-TOA or IPsec-TIA? • Discussion: ongoing • Resolution? IETF61 PANA WG

  12. Issue 127: Retransmission Acknowledgment • Issue: • What would happen if PANA-Auth-Answer(p) is lost? • Could PANA-Auth-Request(q+1) be used to confirm PANA-Auth-Reques(p)? PAR(p)[EAP-Request] PAN(p) lost PAR(q+1)[EAP-Response] • Discussion: • Since PAR(q+1) would not have been sent if PAN(p) were not received by PaC, the PAA can accept PAR(q+1) • We are relying on 1- PAR carries EAP, 2- PaC is an EAP peer, 3- EAP peer cannot generate traffic on its own. These may change in a future. More robust mechanism would be needed • Proposed Resolution: • No optimization. Let the protocol run as it is should work. IETF61 PANA WG

  13. Issue 136: Network Selection in PANA and Network Selection in EAP • Issue: • Relationship between the two network selection mechanisms at the different layers should be explained • Discussion: • Selection in EAP (mainly for AAA proxy selection) occurs always after selection in PANA (ISP selection) in scope of the chosen ISP. No conflict between the two selections • ISP selection should work with roaming case • The two selection can conflict when EAP-based selection is used for ISP selection • Implementations should avoid such conflict • Proposed Resolution? IETF61 PANA WG

  14. Issue 137: Lifetimes of session, AAA-Key and PANA_MAC_KEY • Issue: • What is the relationship between PANA session lifetime, AAA-Key lifetime and PANA_MAC_KEY lifetimes • Discussion: • They are the same • Proposed resolution: • Add clarification text to indicate (session lifetime)=(AAA-Key lifetime) = (PANA_MAC_KEY lifetime) IETF61 PANA WG

  15. Issue 144:Mobility - PAA update in the AAA infrastructure • Issue: • In the mobility handling, a mechanism is needed for the old and/or new PAA to inform the AAA server of the movement of the PaC • Discussion: • There are several possible methods that can be used for that purpose, as long as state synchronization among the old PAA, new PAA and AAA server is maintained • But this is not PANA issue • Consensus? • No additional text in PANA specification IETF61 PANA WG

  16. Issue 145: Failed AVP • Issue: • Failed-AVP AVP is not always needed for PANA-Error-Request • There are some errors that is not related to AVP, such as PANA_MESSAGE_UNSUPPORTED • OTOH, more than one Failed-AVP AVPs can be carried in PER, one per errornous AVP • Proposed resolution: • Allow zero or more Failed-AVP AVPs for PER • Proposed text posted to the ML IETF61 PANA WG

  17. Issue 148:ABNF spec into the document • Issue: • PANA is trying to reuse Diameter ABNF for message definition, but PANA ABNF is not the same as Diameter ABNF • PANA message header is different from Diameter message header • Proposed resolution: • Adding PANA ABNF grammar IETF61 PANA WG

  18. Issue 149: General purpose notification • Issue: • PANA currently does not have general purpose notification mechanism • What about defining notification exchange in PANA? • Discussion: • Would be useful for having notification mechanism • Authorization related information • PAA-to-PaC notification only? Or both PAA-to-PaC and PaC-to-PAA notification? • Consensus? IETF61 PANA WG

  19. Issue 150: PAA mandating separate authentication • Issue: • Can the PAA refuse to authenticate if the PaC sets S-Flag to 0 in PANA-Start-Answer message in discovery and handshake phase? • If yes, there should be a way to indicate this decision by the PAA to the PaC • Discussion: • Is this refusing functionality useful/or practical? • Anyway, adding such functionality would be easier • Resolution? IETF61 PANA WG

  20. Thank You! IETF61 PANA WG

More Related