1. 3/20/2007IETF68 PANA WG1 PANA Issues and Resolutions Yoshihiro Ohba Alper Yegin

2. 3/20/2007IETF68 PANA WG2 Status Going through another AD review after IETF67 PANA is getting another simplification Only technical issues are presented here

3. 3/20/2007IETF68 PANA WG3 Rate Limiting Issue: –Provide stronger requirement on rate limiting of PCI processing –Need explicit warning about the interaction between possible rate limiting and use of Pings for dead-peer detection Resolution: –Section 4.3: “The PAA SHOULD limit the rate it processes incoming PANA- Client-Initiation messages in order not to subject itself to denial-of service attacks. Details of rate limiting are outside the scope of this specification.” –Section 4.5: “It should be noted that if a PAA or PaC which considers its connectivity lost after a relatively small number of unresponsive pings coupled with a peer that is aggressively rate-limiting the PANA-Ping messages, false- positives could result. Care should be taken when rate-limiting PANA-Ping messages to periodically respond, and a PAA or PaC should not rely on PANA-Ping messages to quickly determine loss of connectivity.” –Section 5.2: “Unless dropped due to rate limiting, the PaC and PAA MUST respond to all duplicate request messages received.”

4. 3/20/2007IETF68 PANA WG4 Reliable vs. In-order delivery Issue: Do we need a reliable transport for EAP? –EAP requires in-order delivery –EAP also works over reliable & in-order delivery, but reliability is not a MUST –PANA must support reliable delivery for some set of messages Design choices (Choice 1 is the current design) Choice 1: PANA supports reliable delivery only Requires one parameter in a message: sequence number Choice 2: PANA supports both reliable and unreliable delivery Requires three parameters in a message: transmission sequence number, received sequence number and request-id Proposed resolution: Keep the design as-is

5. 3/20/2007IETF68 PANA WG5 Message Type Reduction Issue: Can we reduce message types? Proposed resolution: –Merge PSR/PSA and PBR/PBA into PAR/PAN Define “start” and “complete” flags in PANA header This also results in a merge of handshake phase into authentication and authorization phase –Merge PPR/PPA, PUR/PUA, PRR/PRA and PER/PEA into PANA-Notification-Request/Answer Define “ping”, “update”, “re-auth” and “error” flags in PANA header

6. 3/20/2007IETF68 PANA WG6 Stateless handshake Issue: Do we want to support stateless handshake? –Stateless handshake means that the first request from the PAA does not include EAP message and the request is not retransmitted on a timer Discussion: –Retransmission creates a state Proposed Resolution: –If the PAA wants to stay stateless, in response to a PCI it should not include EAP in its PAR, and it should not re-transmit PAR on a timer

7. 3/20/2007IETF68 PANA WG7 Explicit vs. Implicit Update Issue: Do we need explicit update? –Any valid PANA message with an IP address change can serve as implicit “update” –Explicit update may be better for “future feature” of updating other attributes Proposed Resolution?

8. 3/20/2007IETF68 PANA WG8 PANA-Ping Issue: Can we separate Ping messages from others in terms of sequencing and retransmissions, so that they don't block progress? Proposed Resolution: Consider doing that if we end up redesigning the transport –We don’t change the transport, so we keep the current design

9. 3/20/2007IETF68 PANA WG9 Peer Identification in PCI Issue: How do a PaC is identified in PCI? Resolution: By looking at the IP address and port number Note: For other messages, PAA identifies the PaC by the Session-ID

10. 3/20/2007IETF68 PANA WG10 Error on authenticator failure in a corner case Issue: Do we need to send an error message when the EAP authentication fails at a pass- through authenticator without sending an EAP Failure message? Resolution: Do not send an error message and simply rely on the timeouts on the PaC

11. 3/20/2007IETF68 PANA WG11 NAT and UDP Port Number Issue: Request sent from PAA to well-known port does not work with NAT –Change UDP port usage to be based on which entity has initiated PANA session Proposed resolution: Replace Section 6.1 with: “Any PANA message is unicast between the PaC and the PAA. For any PANA message sent from the peer that has initiated the PANA session, the UDP source port is set to any number and the destination port is set to the assigned PANA port number (to be assigned by IANA). For any PANA message sent from the other peer, the source port is set to the assigned PANA port number (to be assigned by IANA) and the destination port is copied from the source port of the last received message. In case both the PaC and PAA initiates the session (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request messages cross each other), then the PaC is identified as the initiator.” PaC NAT PAA PSR (src port = PANA, dst port=x) PCI (src port = x, dst port=PANA)

12. 3/20/2007IETF68 PANA WG12 Thank you!