1 / 12

PANA Issues and Resolutions

PANA Issues and Resolutions. Yoshihiro Ohba Alper Yegin. Status. Going through another AD review after IETF67 PANA is getting another simplification Only technical issues are presented here. Rate Limiting. Issue: Provide stronger requirement on rate limiting of PCI processing

widmanj
Download Presentation

PANA Issues and Resolutions

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 Issues and Resolutions Yoshihiro Ohba Alper Yegin IETF68 PANA WG

  2. Status • Going through another AD review after IETF67 • PANA is getting another simplification • Only technical issues are presented here IETF68 PANA WG

  3. 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.” IETF68 PANA WG

  4. 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 IETF68 PANA WG

  5. 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 IETF68 PANA WG

  6. 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 notinclude EAP in its PAR, and it should not re-transmit PAR on a timer IETF68 PANA WG

  7. 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? IETF68 PANA WG

  8. PANA-Ping • Issue: Can we separate Ping messages from others in terms of sequencing andretransmissions, 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 IETF68 PANA WG

  9. 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 IETF68 PANA WG

  10. 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 timeoutson the PaC IETF68 PANA WG

  11. 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.” PCI (src port = x, dst port=PANA) PaC NAT PAA IETF68 PANA WG PSR (src port = PANA, dst port=x)

  12. Thank you! IETF68 PANA WG

More Related