Nov. 9, 2004IETF61 PANA WG PANA Specification Last Call Issues Yoshihiro Ohba, Alper Yegin, Basavaraj Patil, D. Forsberg, Hannes Tschofenig

Nov. 9, 2004IETF61 PANA WG 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

Nov. 9, 2004IETF61 PANA WG 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)

Nov. 9, 2004IETF61 PANA WG 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)

Nov. 9, 2004IETF61 PANA WG Category B Issues

Nov. 9, 2004IETF61 PANA WG 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 not recognized? 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

Nov. 9, 2004IETF61 PANA WG 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

Nov. 9, 2004IETF61 PANA WG 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.”

Nov. 9, 2004IETF61 PANA WG 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”

Nov. 9, 2004IETF61 PANA WG 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

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

Nov. 9, 2004IETF61 PANA WG 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)? PAN(p) PAR(p)[EAP-Request] PAR(q+1)[EAP-Response] lost 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.

Nov. 9, 2004IETF61 PANA WG 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?

Nov. 9, 2004IETF61 PANA WG 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)

Nov. 9, 2004IETF61 PANA WG 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

Nov. 9, 2004IETF61 PANA WG 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

Nov. 9, 2004IETF61 PANA WG 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

Nov. 9, 2004IETF61 PANA WG 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?

Nov. 9, 2004IETF61 PANA WG 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?

Nov. 9, 2004IETF61 PANA WG Thank You!