Transcript PPT Version

PANA Specification
Last Call Issues
Yoshihiro Ohba, Alper Yegin,
Basavaraj Patil,
D. Forsberg, Hannes Tschofenig
Nov. 9, 2004
IETF61 PANA WG
Overview
• Received many comments
– Generated 39 new issues
– Thank you for reviewing and giving detailed
comments
• Two categories in this presentation
– Category A Issues (24 issues, just listed today):
• Editorial issues
• Technical issues that requires minor clarification
– Category B Issues (15 issues, discussed today):
• Technical issues that requires protocol changes or major
clarification
Nov. 9, 2004
IETF61 PANA WG
List of Category A Issues (1/2)
•
•
•
•
•
•
•
Issues 118, 119 (cookie issues: naming change and how to get DI)
Issue 120 (removal of sentence on EAP message creation)
Issue 121 (clarification on PANA_MAC_KEY and TSK)
Issue 122 (clarification on replay attack protection)
Issue 123 (clarification on “very first request message”)
Issue 124, 133 (clarification on “stateless”)
Issue 125 (clarification on why piggybacking EAP-Resp in PAN is
not always good)
• Issue 126 (clarification of PANA-Reauth exchange error)
• Issue 128 (DI and IP address of PaC in PANA SA attributes)
• Issue 129 (Clarification of optimized PANA execution)
Nov. 9, 2004
IETF61 PANA WG
List of Category A Issues (2/2)
• Issue 130 (replacing the term “client” with “device”)
• Issue 131, 132 (Clarification in terminology section)
• Issue 135 (PTR/PTA exchange is not needed after PBR/PBA failure
with PANA_AUTHORIZATION_REJECTED)
• Issue 138 (Clarification of “one IP hop” requirement)
• Issue 139 (clarification of L2 trigger)
• Issue 140 (EAP-Success/Failure also carried in PFER)
• Issue 141 (editorial comments from Gerardo)
• Issue 142 (section 6.1 needed?)
• Issue 143 (Clarification of CTP and PANA)
• Issue 146 (editorial comments from Julien)
• Issue 147 (which PAA ID with AAA-Key int computation)
Nov. 9, 2004
IETF61 PANA WG
Category B Issues
Nov. 9, 2004
IETF61 PANA WG
Issue 112: ‘M’ bit Clarification
• Issue:
– The M (Mandatory) bit is underspecified. When it is set, what
happens when it is set/unset and an AVP is not recognized?
• Proposed Resolution:
– If an AVP with the 'M' bit set is unrecognized (unknown
type/value), the message MUST be discarded
– If an AVP with the 'M' bit cleared is unrecognized, the message
MAY simply ignore the AVP
– Default value for AVPs defined in this document:
• The 'M' bit MUST be set.
• The 'V' bit MUST NOT be set
Nov. 9, 2004
IETF61 PANA WG
Issue 113: Clarification of Authorization
Phase
• Issue:
– The wording “authorization phase” is confusing because
authorization is performed at the end of authentication phase
• Proposed resolution:
– Change the name to “Authorized phase”
– Revise text for explaining the authorized phase
Nov. 9, 2004
IETF61 PANA WG
Issue 114: Liveness Test
• Issue:
– Can a PANA exchange other than PANA-Ping exchange be used
for liveness test?
• Discussion
– Yes
• Resolution:
– Add the following text in section11.8
• “Not only a PANA ping exchange but also other valid recent
request/answer exchange can imply the other side is alive.”
Nov. 9, 2004
IETF61 PANA WG
Issue 115: Clarification of PANA session
definition
• Issue:
– Why the session cannot be shared across multiple network
interfaces?
• Discussion:
– This is because only one DI of the PaC is allowed to be bound to
a PANA session at a time for simplicity
– Should be rephrased without using the term “interface”
• Proposed resolution:
– Rephrase the session definition using the term “device identifier”
instead of “interface”
Nov. 9, 2004
IETF61 PANA WG
Issue 116,134: Device-Id, Protection-Cap.
and PPAC AVPs handling in PBR
• Issue:
– Rules as to when to or not to include Device-Id AVP in PBR should be
more specific
• Discussion:
– Device-Id AVP in PBR needs to be always included when ProtectionCapability AVP is carried in PBR
– Do we use DI binding only when we use L2/L3 ciphering enable after
PANA? (The answer is NO)
• DI binding without enabling L2/L3 ciphering can be performed without
Device-ID AVP (i.e., taking DI from MAC/IP header)
• But carrying Device-Id in PANA message can make implementation easier
• Proposed resolution:
– Device-Id AVP is carried in PBR if Prot.-Cap. AVP is carried
– Dev.-ID AVP MAY be carried in PBR if Prot.-Cap. AVP is not carried
– If PBA does not contain Device-Id AVP when expected, the PAA initiates
PER/PEA exchange to terminate the session
– Other change: When PBR does not carry PANA-SUCCESS result code,
Prot.-Cap. AVP and PPAC AVP is not carried in PBR
Nov. 9, 2004
IETF61 PANA WG
Issue 117: DI with IPsec Clarification
• Issue:
– Which is the DI of PaC, IPsec-TOA or IPsec-TIA?
• Discussion: ongoing
• Resolution?
Nov. 9, 2004
IETF61 PANA WG
Issue 127: Retransmission Acknowledgment
• Issue:
PAR(p)[EAP-Request]
– What would happen if PANA-AuthAnswer(p) is lost?
– Could PANA-Auth-Request(q+1) be used
to confirm PANA-Auth-Reques(p)?
PAN(p)
lost
PAR(q+1)[EAP-Response]
• Discussion:
– Since PAR(q+1) would not have been sent if PAN(p) were not
received by PaC, the PAA can accept PAR(q+1)
– We are relying on 1- PAR carries EAP, 2- PaC is an EAP peer,
3- EAP peer cannot generate traffic on its own. These may
change in a future. More robust mechanism would be needed
• Proposed Resolution:
– No optimization. Let the protocol run as it is should work.
Nov. 9, 2004
IETF61 PANA WG
Issue 136: Network Selection in PANA and
Network Selection in EAP
• Issue:
– Relationship between the two network selection mechanisms at
the different layers should be explained
• Discussion:
– Selection in EAP (mainly for AAA proxy selection) occurs always
after selection in PANA (ISP selection) in scope of the chosen
ISP. No conflict between the two selections
– ISP selection should work with roaming case
– The two selection can conflict when EAP-based selection is used
for ISP selection
• Implementations should avoid such conflict
• Proposed Resolution?
Nov. 9, 2004
IETF61 PANA WG
Issue 137: Lifetimes of session, AAA-Key
and PANA_MAC_KEY
• Issue:
– What is the relationship between PANA session lifetime, AAAKey lifetime and PANA_MAC_KEY lifetimes
• Discussion:
– They are the same
• Proposed resolution:
– Add clarification text to indicate (session lifetime)=(AAA-Key
lifetime) = (PANA_MAC_KEY lifetime)
Nov. 9, 2004
IETF61 PANA WG
Issue 144:Mobility - PAA update in the AAA
infrastructure
• Issue:
– In the mobility handling, a mechanism is needed for the old
and/or new PAA to inform the AAA server of the movement of the
PaC
• Discussion:
– There are several possible methods that can be used for that
purpose, as long as state synchronization among the old PAA,
new PAA and AAA server is maintained
– But this is not PANA issue
• Consensus?
– No additional text in PANA specification
Nov. 9, 2004
IETF61 PANA WG
Issue 145: Failed AVP
• Issue:
– Failed-AVP AVP is not always needed for PANA-Error-Request
• There are some errors that is not related to AVP, such as
PANA_MESSAGE_UNSUPPORTED
– OTOH, more than one Failed-AVP AVPs can be carried in PER,
one per errornous AVP
• Proposed resolution:
– Allow zero or more Failed-AVP AVPs for PER
– Proposed text posted to the ML
Nov. 9, 2004
IETF61 PANA WG
Issue 148:ABNF spec into the
document
• Issue:
– PANA is trying to reuse Diameter ABNF for message definition,
but PANA ABNF is not the same as Diameter ABNF
• PANA message header is different from Diameter message header
• Proposed resolution:
– Adding PANA ABNF grammar
Nov. 9, 2004
IETF61 PANA WG
Issue 149: General purpose notification
• Issue:
– PANA currently does not have general purpose notification
mechanism
– What about defining notification exchange in PANA?
• Discussion:
– Would be useful for having notification mechanism
• Authorization related information
– PAA-to-PaC notification only? Or both PAA-to-PaC and PaC-toPAA notification?
• Consensus?
Nov. 9, 2004
IETF61 PANA WG
Issue 150: PAA mandating separate
authentication
• Issue:
– Can the PAA refuse to authenticate if the PaC sets S-Flag to 0 in
PANA-Start-Answer message in discovery and handshake
phase?
– If yes, there should be a way to indicate this decision by the PAA
to the PaC
• Discussion:
– Is this refusing functionality useful/or practical?
– Anyway, adding such functionality would be easier
• Resolution?
Nov. 9, 2004
IETF61 PANA WG
Thank You!
Nov. 9, 2004
IETF61 PANA WG