Minutes of: Protocol for carrying Authentication for Network Access (pana) At: IETF68 March 22, 2007 (Prague, Czech Repbulic) Chairs: Basavaraj Patil Alper Yegin Credit for these minutes: 1. Ajoy Singh (ASINGH1 at motorola dot com) ------------------------------------------------------- Working group status update (Alper Yegin): Chair: ADs completed second review of draft-ietf-pana-pana-14.txt. Document is waiting for revision. AD is not in room we will have to discuss with AD offline. Chair: PANA framework document is in next IETF last call. Chair: No progress on other documents. Chair: PANA IPSEC document completed second review, revision pending before IESG submission. Chair: PANA SNMP draft in WG last call. Chair: We plan to issue last call. We want to have enough people for offline review. Chair: state machine draft : revision needed before issuing WG last call. Chair: Based on latest document we will have last call. Author (Victor) Last revision was for 03. We need more discussion with WG. Chair: We have missed all revision. Chair: Stick with milestone. Chair: Is there any question about status of WG and document in hand? Everything is clear Yoshi presented "PANA Issues and Resolution" Status: Going through another review after IETF 67. PANA is coming with another review. PANA is getting another simplification. Issue 1 : Rate limiting: More stronger requirements needed on rate limiting of PCI processing. Need stronger relationship between rate limiting and pinging for data peer detection. We have 3 texts in different sections: section 4.3: describes PAA should rate limit PCI processing Section 4.5: Explicit warning with rate limit and pinging. PAA or PaC should not determine pana ping for loss of connectivity. section 5.2: Clarify duplicate detection is always performed if packets are not dropped due to rate rate limiting. Second issue: Reliable vs. In order delivery Do we need reliable transport for EAP? (1) EAP requires in order delivery (2) PANA supports reliability for some set of messages (3) EAP works over reliable delivery Choice 1: PANA message requires sequence number to support reliable delivery. Requires one parameter in message: sequence number. Choice 2: Use SCTP design: tx sequence number, rx sequence number, request id, Proposed solution: Keep this as it is (choice 1) comments (?): no comments Issue 2: Message Type Reduction simplification and message reduction 9 message types, how to reduce Type 1 merging: Merging messaging used for PSR/ PSA and PBR/PBA into PAR/PAN define start and complete flags to distinguish special cases. requires merging of handshake phase into authentication and authorization Merge: merge PPR/PPA, PUR/PUA, PRR/PRA and PER/PEA into PANA-Norifcation-Request and answer Similiar to IKE 2 design. Modification of payload for information exchange. Define couple of flags to define various situations: "ping", "update", "re-auth" and "error" flags in PANA header. Victor: Does this mean semantic of PSR/PSA will be changed or will this be used same way? Yoshi: USed same way Stateless handshake: Yoshi: Do we want to support stateless handshake? Pana can belong over multiple IP host. To support multiple handshake , ... After PAA handshae, PAC received parameters. No state is created and state is not transmiteed during time. Can we support stateless transport mandatory? Retransmission is supported. Resolution: If PAA wants to stay stateless, in response to a PCI, it should not include EAP in its PAR and it should not re-transmit PAR on a timeout Yoshi: Any discussion or comments. No comments. Explicit vs.. Implicit update: Do we need explicit update? 1st options: allow implicit update. PAA updates after it recognizes IP address has changed. Use update flag, better for updating other attributes Proposed resolution? Comments: Lionel: In case of IP address change, should we document ................. Yoshi: We can describe in the base spec so that any lower layer can make use of this without additional media.... There is implicit assumption that in PANA some configuration IP address could change PAA should be able to notify this ether explicitly or implicitly. IP address change should be defined in document. Either implicit or explicitly Raj: I think my recommendation will be to use an explicit mechanism. This is better mechanism. State machine impact will be much better. Alper: Agree with Raj, explicit is better. AD in the spirit of simplicifying the protocol introduced flags. Question to WG : Should there be any objection to explicitly update? Does anyone prefer implicit? WG thinks explicit is better. We need to confirm with AD to ensure they have different opinion or not. PANA-Ping Ping message may have additional identifier. May not see actual benefit of additional identifier. Unless we change the designing of PANA transport, current specification is sufficient. Peer Identification in PCI: How PAA can identify PAC? Resolution: Using IP address of PAC and UDP port number. Note: PAA identifies PAC by session-ID. Comments: none Error on authentication on corner case. Issue: Do we need to send authentication error when EAP authentication fails at pass through authentication without sending an EAP failure message? Resolution: do not send an error message NAT and UDP traversal issue: UDP port number usage issue. current specification uses well known port for the request sent to PAA. This does not work. We need to change UDP port usage. To make it easier, we just describe the rule which entity is initiating PANA session. If PANA message is sent from entity that initiates PANA session. Destination port is set to well known port. Source port is any. This will work. Someone tested the rule. PAC and PAA starts to initiate the session at the same time. Simply consider the PAC as the initiator in this case. Rule for PAC initiated PANA session. Lionel: The IP address in the PAA what will be the content of binding at the end of authentication process. Resolution: PAC IP address will be part of binding. Lionel: Which IP address is used in binding? NAT IP address or PAC IP address. Yoshi: NAT IP address is seen by PAA. Binding context should contain nor only IP address but some other identifier such as port number which is outside the scope of specification. Lionel: scope of NAT should be captured in draft. Somewhere in the draft we should describe what happens at PAA. Yohsi: GSL (?) draft comments: NAT is specific to GSL (?). It is more generic. Something more is needed in specification if it not in the base protocol. Yoshi: good comments. Alper: We will run WG consensus by the AD. Next steps: revise and issue second IETF last call of base protocol need revision in IPSEC document. revise and issue state machine Issue WG last call on PAA-EP doc. meeting adjourned.