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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. Thank you!
11/6/2006
IETF67 PANA WG

19. 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