PANA Issues and Resolutions

1
PANA Issues and Resolutions

• Yoshihiro Ohba
• Alper Yegin

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

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)

4
Stateless handshake

• Issue
• 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

5
Device identifier

• Issue Can we limit the device ID to IP address
  (so that we dont 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

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

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

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

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

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

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

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
• For others
• Src Sender-generated port number
• Dst well-known port number

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

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

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

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
• Dont use Vendor-Id0 for IETF assigned AVPs.
  Use absence of Vendor-Id for that purpose

18
Thank you!
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."