PANA Update and Open Issues (draft-ietf-pana-pana-02.txt)

1
PANA Update and Open Issues(draft-ietf-pana-pana-
02.txt)

• Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil,
  Hannes Tschofenig,
• Alper Yegin

2
PANA Issueshttp//www.danforsberg.info8080/pana-
issues/

• 15 issues for draf-ietf-pana-pana-01were resolved
  and closed Resolution text incorporated in
  pana-02
• There are 9 open issues for pana-02

3
PANA-01 Issues (Closed)
4
Message Format Related Issues

• The same message type is allocated to each pair
  of Request and Answer message (Issue 22)
• use R-flag to distinguish Request from Answer
• PANA uses its own type space for message and AVP
  types (Issue 23)
• No type space sharing with Diameter
• A new message PANA-Error is defined (Issue 17)
• Section 4.1.8 defines the error handling rule
• Section 9.3.13 defines the message format
• AVP alignment rule is added (Issue 24)
• The same 32-bit alignment rule as Diameter
• Termination-Cause AVP values are defined (Issue
  18)
• Result-Code AVP values are defined (Issue 19)

5
Other Issues

• Defined detailed retransmission behavior and
  default parameters (Issue 20, explained later)
• Service Profile Names (Issue 25, explained later)
• Clarified that Session-Lifetime is non-negotiable
  and can be carried in PANA-Bind-Request message
  sent from PAA (Issue 8)
• Clarified that PAA SHOULD initiate EAP
  re-authentication before the session lifetime
  expires (Issue 31)
• Security Consideration section is updated (Issue
  32)
• Re-wording periodical refresh to liveness
  test, etc.
• Clarification of Section 4.9 Device-ID Choice
  (Issue 33)
• PaC and PAA checks peers Device ID each other
• Minor editorial changes (Issues 21, 26, 30)

6
Issue 20 Retransmission Timers and Counters

• Issue Define default timer and retransmission
  counts
• Resolution
• Adopt the RFC3315 DHCPv6 model
• Define algorithm and parameters for
  retransmission
• Use of exponential backoff
• Classify messages retransmitted by PANA Each
  class uses the same default parameter values
• PANA-PAA-Discover
• Other messages
• Define default values for each class

7
Issue 25 Service Profile Names

• Issue Carrying network information during
  discovery and initial handshake phase would be
  helpful for a user to choose NAP and ISP
• Resolution
• Defined two new AVPs NAP-Information AVP and
  ISP-Information AVP
• Defined a new flag (S-flag)
• Define the usage of the AVPs and S-flag

8
Issue 25 (contd)NAP,ISP-Information AVP

• NAP-Information lt AVP Header 1034 gt
• 01 Provider-Identifier
• Provider-Name
• AVP
• ISP-Information lt AVP Header 1035 gt
• 01 Provider-Identifier
• Provider-Name
• AVP
• Provider-Identifier (Unsigned32) IANA-Assigned
  Enterprise Identifier
• Provider-Name (UTF8String)

9
Issue 25 (contd)NAP,ISP-Information AVP Usage

• PAA can advertise -Information AVPs in
  PANA-Start-Request message
• S-flag in PANA-Start-Request/Answer exchange is
  used for negotiating NAP/ISP separate
  authentication
• F(inal)-flag is not needed any more
• During the negotiation, PaC can choose an ISP by
  including an ISP-Information AVP in the
  PANA-Start-Answer message
• PAA can specify which authentication (NAP or ISP)
  is occuring
• by including a corresponding -Information AVP in
  the first PANA-Auth-Request message in each
  authentication

10
Issue 25 (contd)Example Sequence
PANA-PAA-Discover
PANA-Start-Request ISP1, ISP2, NAP // S-flag set
Discovery Initial Handshake
PANA-Start-Answer ISP1, NAP // S-flag set
PANA-Auth-RequestNAP, EAPReq.
PANA-Auth-AnswerEAPResp.
NAP Authentication

PANA-Bind-Request/Answer
Execution order can be reversed
PANA-Auth-RequestISP1, EAPReq.
PANA-Auth-AnswerEAPResp.

ISP Authentication
PANA-Bind-Request/Answer
11
PANA-02 Issues (Open)
12
Open Issue List (ordered by importance)http//www
.danforsberg.info8080/pana-issues/
13
Issue 34 Behavior with NAP and ISP

• Issue How Session-Lifetime relates to NAP and
  ISP authentications?
• Proposed Resolution
• A single Session-Lifetime is bound to a PANA
  session
• When NAP and ISP have different authorization
  lifetimes, the smaller one relates to the
  Session-Lifetime
• When EAP re-authentication occurs, both NAP and
  ISP authentications will be performed

14
Issue 37 Unknown Realm Error Propagation

• Issue
• Should unknown realm AAA message routing error
  be propagated to PaC?
• Discussion
• EAP state machine does not support propagation of
  AAA errors
• When such an error occurs, the authentication
  state machine enters a sink failure state
  without generating any error or an EAP-Failure
  message
• Direct interface from AAA to PAA would be needed
• Resolution?

15
Issue 29 EAP Failure and PANA-Bind-Request

• Issue
• Should PANA-Termination-Request be used for
  carrying EAP-Failure instead of
  PANA-Bind-Request?
• Discussion
• When NAP/ISP separate authentication is
  performed, a single EAP failure does not mean
  PANA authentication failure
• Resolution
• PANA-Term.-Request is not appropriate to carry
  EAP-Failure for the above reason
• Use PANA-Bind-Request,Answer message to carry
  EAP-Success/Failure (as the current draft does)
• Bind may be renamed to Result if the word
  Bind does not make sense to carry EAP-Failure

16
Issue 36 (Re)authentication Race Condition

• Issue
• It is possible for both PaC and PAA to
  simultaneously initiate EAP (re)authentication.
  How can PANA handle the case?

PaC
PAA
PANA-Start-Request (or PANA-Auth-Request)
PANA-PAA-Discover

• Proposed Resolution
• PAA can always be the winner, by ignoring the
  received PANA-PAA-Discover message after it sends
  a PANA-Start-Request (or PANA-Auth-Request)

17
Issue 35 EP Information

• Issue
• PANA-IPsec draft assumes that PaC learns the IP
  address of the EP during the PANA exchange. But
  PANA specification does not support it
• Proposed Resolution
• Having an AVP to carry the Device-Id of EP(s)
• Device-Id AVP can have a field to indicate
  whether the device belongs to PAA or a separate
  EP
• The AVP is carried in PANA-Bind-Request

18
Issue 16 Multihoming Support

• Issue
• When PaC has multiple interfaces on the same IP
  link, should it be supported with a single PANA
  session or separate PANA sessions?
• Discussion
• A single PANA session for multiple interfaces is
  basically an optimization issue
• Proposed resolution
• We should do a more thorough analysis if we
  support the scenario with a single PANA session
• Until the analysis is made, separate PANA session
  is sufficient

19
Issue 12 Supporting Network Access
Authentication for Ad-hoc Networks

• Issue
• Should PANA support ad-hoc network scenario where
  there may be one or more untrusted nodes between
  PaC and PAA?
• Resolution?

Ad-hoc network
ISP
PaC
PAA
Untrusted nodes
20
Issue 2 Downgrading Protection

• Issue
• EAP allows negotiation of an EAP method between
  authenticator and peer. This mechanism is
  vulnerable to downgrading attacks.
• Discussion
• Providing downgrading protection in PANA is not
  good since an EAP server may not be co-located
  with PAA
• EAP method negotiation is not performed by PANA,
  so this is an EAP issue
• Resolution
• Text incorporated in Security Considerations
  section
• Recommendation of using EAP-GSSAPI to negotiate
  an EAP method