1. Open issues with PANA Protocol
IETF59
Yoshihiro Ohba/Basavaraj Patil

2. Issue 52: Details of double authentication
Issues:
It is not clear whether NAP/ISP separate authentication is actually supported or not
Some AVPs are not needed in the first PBR
Device-Id, Session-Lifetime, Protection-Capability
It might be better to provide functionality to abort session when the 1st EAP round fails
Cryptographic binding between the 1st and 2nd EAP rounds is needed
Proposed resolution
Clarified text will be added
It might be better to define a new PANA message for delimiter between 1st and 2nd EAP rounds
Re-use of S-bit in authentication phase (S-bit is currently used in discovery and initial handshake phase only)
The 2nd EAP round must be protected with a MAC AVP unless lower-layer is secured
This means that the 1st EAP round must generate a key

3. Issue 53: Additional discovery information
It might be useful if additional information to identify a PAA is carried in the discovery and initial handshake phase
Multi-interface PAA with serving multiple IP subnets can advertise the same PAA identity
PaC can perform re-authentication based on PRAR/PRAA exchange when it moves to another subnet as long as it communicates with the “same” PAA
Resolution:
Define PANA Session-Id to have the same format as Diameter Session-Id
Diameter Session-Id AVP contains globally unique NAS identifier

4. Issue 54:Mandatory cookie
Inclusion of the cookie at the start of the PANA exchange be mandatory
Justification: Protocol becomes simpler
Discussion: Carrying EAP AVP and the cookie together in PANA-Start-Request cannot be “stateless”
Resolution?

5. Issue 55:Client cookie is useful
Would it be useful for the client to provide its own cookie as well
Justification: This would cost very little, but protect the client against blind PAA spoofing attempts
Discussion:
The type of DoS attacks between the PaCs and PAAs are not symmetrical.
PaC does not need to communicate with multiple PAAs in parallel
Is there any DoS prevention such a cookie can provide?
Resolution?

6. Issue 56: AAA routing based on NAI vs. ISP choice clarification
Section 4.2 claims that AAA routing is based on the ISP choice. The first hop decision can be based on this, but further on in the network it must be based on the NAI
Discussion: Only the destination-host/realm can be inferred from the ISP choice. The rest of the AAA routing will be based on them (not the ISP choice)
Resolution: Section 4.2 will be revised to clarify this

7. Issue 57: PSR retransmission strategy
Currently PANA-Start-Request is not retransmitted and initial handshake will stall when unsolicited PSR is lost
Discussion: How about making both PSR and PSA to be retransmitted?
Retransmission of PSR conflict with stateless discovery (i.e., with insertion of cookie)
Proposed Resolution:
Stateless discovery: PSA is retransmitted
Stateful discovery: PSR is retransmitted
Stateless
Discovery
Stateful
Discovery
PDI
PSR[Cookie]
PSR
PDI(retransmitted)
PSR(retransmitted)
PSR[Cookie]
PSA
PSA
PSR(retransmitted)
PSA(retransmitted)
PSA

8. Issue 58: Fast-reauthentication and authorization
PANA optionally supports mobility optimization but there are a number of security issues at the system level when the mobility optimization is done based on context transfer between PAAs.
See draft-ietf-eap-keying-01.txt, Sections 1.4 and in particular for some examples
Proposed Resolution: we should minimally update the text to take people's attention to these issues.

9. Issue 62: PAA discovery triggered by data traffic
Optional use of PDI message sent from EP to PAA is a part of PAA-EP protocol
PAA-EP protocol should be described in a separate document
Do we still need to use PDI message when SNMP is used for PAA-EP protocol?
Proposed Resolution: Deprecate the use of PDI message sent from EP to PAA

10. Issue 63: MAC AVP a SHOULD or a MUST
MAC AVP should always appear in PANA-Auth-Request/Answer exchanges when a PANA SA exists
Currently, MAC AVP is “SHOULD”
“For any EAP-based re-authentication, if there is an established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected by adding a MAC AVP to each message.”
Proposed Resolution: Replace “SHOULD” with “MUST”

11. Issue 64: Two separate codes for Session ID AVP
Session-Id AVP has two AVP type codes (263 and 1026) depending on whether the AVP payload has the same format as Diameter Session-Id
A single type code should be used
A single format should be used to avoid ambiguity
Proposed Resolution:
Use type code 1026
Use the same format as Diameter Session-Id

12. Issue 65: Clarification on simultaneous per-packet protection
Issues:
Protection-Capability AVP is defined as a collection of flags for different data protection capability indications, but actually only one protection capability is allowed
An “UNKNOWN” protection capability is defined but is it needed?
Proposed Resolution: Change the Protection-Capability AVP definition to:
"The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data indicates the data protection capability supported by EP. Below is a list of specified data protection capabilities:
L2_PROTECTION
IPSEC_PROTECTION"

13. Issue 28 – PaC/PAA State Machine
Should the state machine be included in the PANA Protocol I-D?
Yes. But not necessarily in the format that has been presented earlier.
Proposal is to create an ascii state table (with state, condition/event, action, next state) similar to Sec. 8.1, 8.2 etc. of the diameter RFC (RFC3588)
Table derived from the graphical state machine diagram has been created and posted for comments
Next step:
Incorporate the state machine in the next revision of the I-D as an appendix

14. Issue 35 – EP Information Issue:
Setup of an IPsec SA, post authentication relies on the PaC knowing the address of the EP
Proposed solution:
Sec specifies the EP-Device-ID AVP which is included in the success response sent to the PaC in the PANA exchange
Status: Closed

15. Issue 36 - Reauthentication race condition
It is possible that both PAA and PaC initiate the discovery and initial handshake procedure at the same time, i.e., the PAA sends a PANA-Start-Request message while the PaC sends a PANA-PAA-Discover message.
Proposed solution:
The PAA SHOULD silently discard the PANA-PAA-Discover message received from the PaC after it has sent a PANA-Start-Request message while creating a state for the PaC.
Status: Closed

16. Other Issues Issue 59 (TTL):
TTL checks will be incorporated in the text
Issue 60 (MSK vs AAA-Key):
I-D will use AAA-Key instead of MSK.
Issue 61 (PANA SA):
PANA SA definition is revised (it can only exist when there is a AAA-key)