PANA Specification Last Call Issues

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