PANA Issues and Resolutions Yoshihiro Ohba Alper Yegin 11/6/2006 IETF67 PANA WG

Status Going through AD review after IETF Last Call Waiting for external review on language tag usage in Notification AVP PANA is getting more simplified Only technical issues are presented here 11/6/2006 IETF67 PANA WG

Session-Id Issue: Globally unique session identifier is not needed 4-octet session identifier locally unique within PAA is sufficient Proposed resolution: Define 4-octet Session-Id field in PANA message header and remove Session-Id AVP A new Session-Id is assigned by PAA and carried in PSR/PSA exchange The assigned Session-Id is carried in subsequent messages throughout the session Remove PANA_UNKNOWN_SESSION_ID result code (message with unknown Session-ID should be silently discarded without generating a PER) 11/6/2006 IETF67 PANA WG

Stateless handshake : Issue Proposed resolution: Do we need an optional “stateless” mode (marked with “L-bit”?) Whether stateless or stateful mode, there is at least minimum state that needs to be maintained (cookie, initial sequence number). Adding PSR retransmission to this state is not a big issue. Proposed resolution: Remove the distinction between the stateless and stateful mode Remove Cookie AVP Use Session-Id for testing reachability of PaC test PaC needs to receive PSR to generate PSA with a valid Session-Id Remove L-flag PSR retransmission MAY be turned off if PAA wants to be stateless PaC retransmits PCI until it receives PANA-Auth-Request PSA retransmission is not needed PaC PAA PCI PSR PSA PAR : 11/6/2006 IETF67 PANA WG

Device identifier Issue: Can we limit the device ID to IP address (so that we don’t get into L2 addresses and locally-significant addresses)? Proposed resolution: Remove the DI determination from the spec. Leave it to other specs (architectures) using PANA Remove device identifier definition from Section 2 Remove Device-Id AVP Remove “Device-Id Choice” Section 11/6/2006 IETF67 PANA WG

Bootstrapping lower-layer Issue: Bootstrapping functionality should be removed from base specification Proposed resolution Remove Protection-Capability AVP Remove “PaC-EP-Master-Key” section 11/6/2006 IETF67 PANA WG

Post-PANA address configuration Issue: Post-PANA Address Configuration (PPAC) should be removed from PANA specification Discussion: IP address configuration is an orthogonal and out-of scope issue for PANA Each address configuration protocol has own re-configuration notification from network or equivalent Proposed resolution Remove PPAC AVP Remove Appendix A 11/6/2006 IETF67 PANA WG

Network selection Issue: Network selection can be better defined in a separate I-D to simplify the base specification Use of RADIUS operator identifier has been proposed in place of SMI vendor id, but still needs discussion Proposed resolution: Remove network selection functionality Remove Provider-Identifier, Remove Provider-Name, NAP-Information and ISP-Information AVPs Remove “Network Selection” Section 11/6/2006 IETF67 PANA WG

Nonce AVP Issue: Protocol can be simplified by always carrying Nonce AVP in the first PAR/PAN exchange (and not in PSR/PSA at all) This also allows fresh nonces to be used for re-keying PANA_AUTH_KEY in re-authentication phase Proposed resolution: Remove Nonce AVP from PSR and PSA Specify that Nonce AVP is carried only in the first PAR/PAN exchange in both authentication and authorization phase and re-authentication phase 11/6/2006 IETF67 PANA WG

Filtering exceptions Issue: Needs text for describing that EP needs to pass certain IP packets (e.g., DHCP) that are needed for PANA even for unauthorized client Proposed resolution: Add the following sentence in EP definition: "EPs should prevent data traffic from and to any unauthorized client unless it's either PANA or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor discovery, DHCP, etc.)." 11/6/2006 IETF67 PANA WG

EAP message duplication handling Issue: EAP message duplication is handled by EAP layer, so PANA does not need to handle it Proposed resolution: Remove the last paragraph (quoted below) of Section 5.2 “PANA MUST NOT generate EAP message duplication. EAP payload of a retransmitted PANA message MUST NOT be passed to the EAP layer.” 11/6/2006 IETF67 PANA WG

IP source/destination address Issue: The following sentence in Section 6.1 is too obvious “The source and destination addresses SHOULD be set to the addresses on the interfaces from which the message will be sent and received, respectively.” Proposed solution: Remove the sentence 11/6/2006 IETF67 PANA WG

UDP port numbers Current rule: For response: (Src,Dst) := (Dst,Src) of request For others: Src := Sender-generated port number Dst := Dst of previously sent msg or well-known (IANA-assigned) port number Issue: Why not always use well-known port number for destination port? Discussion: Use of an ephemeral port number contained in a request as destination port of a response is common (e.g., Mobile IPv4) But it would make filtering PANA messages at firewall difficult Proposal: Always use well-known port number in either src or dst port For response: Same as current rule Dst := well-known port number 11/6/2006 IETF67 PANA WG

AVP/Message Allocation Policy Issue: Clarification is needed on allocation policy for a new mandatory-supported AVP or a new message IANA namespace would be needed for Version field as well Discussion: A new mandatory-supported AVP or a new message used for a mandatory-supported feature would require a new version of PANA specification Proposed resolution: Add “Standards Action” for AVP Code and Message Type allocation policy Add text in Section 10 to cover the discussion Add IANA namespace for Version field, with Standards Action required 11/6/2006 IETF67 PANA WG

PANA-Error-Request Issue: PER needs to contain information on which message caused an error, in addition to which AVP caused an error Proposed resolution: Define Failed-Message-Header AVP to be contained in PER Type: Octetstring Length: 12 Contents: The header of erroneous message 11/6/2006 IETF67 PANA WG

Additional condition to terminate request retransmission Issue: Request retransmission should be stopped when a protected PER for the request is received Proposed resolution: Revise Section 9 to have the additional condition for terminating request retransmission 11/6/2006 IETF67 PANA WG

Other changes Reassign Result-Code AVP values Authentication Result Codes: 0 (success),1 (auth failure), 2 (authz failure) Protocol Error Result Codes: 1001, 1002, … Increase the number of experimental Message Types from 2 to 16 Change AVP Code allocation policy for not allowing the exception of not requiring IETF Consensus for allocating just one or two AVP Even a single AVP allocation requires IETF Consensus Don’t use Vendor-Id=0 for IETF assigned AVPs. Use absence of Vendor-Id for that purpose 11/6/2006 IETF67 PANA WG

Thank you! 11/6/2006 IETF67 PANA WG

Filtering exceptions Issue: Needs text for describing that EP needs to pass certain IP packets (e.g., DHCP) that are needed for PANA even for unauthorized client Proposed resolution: Add the following sentence in EP definition: (another version) "EPs should prevent data traffic from and to any unauthorized client. This specification concerns itself only with the case that any address allocation., ND, etc. traffic does not need to pass thorough the EP." 11/6/2006 IETF67 PANA WG