Transcript PPT Version

PANA Issues and Resolutions
Yoshihiro Ohba
Alper Yegin
11/6/2006
IETF67 PANA WG
1
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
2
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
3
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
– 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
11/6/2006
IETF67 PANA WG
PAA
PCI
PSR
PSA
PAR
:
4
Device identifier
• Issue: Can we limit the device ID to IP address (so
that we don’t get into L2 addresses and locallysignificant 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
5
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
6
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 reconfiguration notification from network or equivalent
• Proposed resolution
– Remove PPAC AVP
– Remove Appendix A
11/6/2006
IETF67 PANA WG
7
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
8
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
9
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
10
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
11
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
12
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
11/6/2006
IETF67 PANA WG
13
AVP/Message Allocation Policy
• Issue:
– Clarification is needed on allocation policy for a new mandatorysupported 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 mandatorysupported 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
14
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-MessageHeader AVP to be contained in PER
– Type: Octetstring
– Length: 12
– Contents: The header of erroneous message
11/6/2006
IETF67 PANA WG
15
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
16
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
17
Thank you!
11/6/2006
IETF67 PANA WG
18
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
19