Minutes of:
Protocol for carrying Authentication for Network Access (pana)
At: IETF72 (Dublin)
MONDAY, July 28, 2008 from 0900-1130
Chairs: Basavaraj Patil <[EMAIL PROTECTED]>
Alper Yegin <[EMAIL PROTECTED])
Credit for these minutes:
1. Christian Bauer (Christian.Bauer at dlr.de)
2. Mohana Jeyatharan (Mohana.Jeyatharan at sg.panasonic.com)
==============================================================
WG Status, Agenda
- Pana base protocol published after 1 year's of WG last call and revisions.
- Pana framework published as information RFC.
- Several WG documents expired and will not be revised and few will be
chosen in the re-chartering of this WG.
I-D: Application of pana framework to DSL networks
Presenter: Lionel Morand
* Intention is to how to implement pana protocol over DSL networks
Moving from PPP to IP networks and thus some IP address is required
especially for multihop networks.
* Changes from from version 1 to version 2
using unspecified IP address in DSL networks.
* Proposal is to use unspecified IPv4 address before authentication.(IPv4)
Jari: I remember there was criticism related to the usage of
unspecified IP address (from Thomas Narten)
Alper: Yes, but at that time there was no strong justification for
unspecified address. There are problems, as many things don't work
(multi-hop, SAs)
Jari: Just as a reminder: slides do not completely represent the
discussion as it was.
Lionel: Idea was to authenticate user before aquiring an IP address ->
so we have a requirement.
Specification was not clear enough on the usage of unspecified
address. Now there should be enough justification.
Jari: This updates the base PANA protocol?
Alper: I-D describes how it can be implemented, without changing base-spec.
Jari: Nothing here should be in conflict with protocol spec.
Alper: There are no keywords, is is not normative.
Jari: If you change the code, you also change the PANA protocol.
Alper: Disagree. We have some liberty here.
Jari: We need furhter discussion. We should have the same
understanding when reading/having read the protocol.
Richard - Question 1: How does AAA server get port?
Alper: That's the option 82 question.
Jari: I guess DSLAM inserts some information.
Lionel: We only use DHCP to retrieve PAA address. Any information will
be received by option 82.
Alper: This problem and how to deal with it is described in the draft.
Jari: PANA client does not know port number.
Alper: For deployments that need port, we add another DHCP req-rsp
signalling just for discovering PAA. Then DSLAM inserts option 82.
Richard - Questions 2: How do you trigger dhcp discovery?
Lionel:
Basvaraj: Host is required to configure an address anyway. And the
authentication is required before that.
[so trigger is implicit]
Chairs Conclusions:
DHCP and MIPv4 already uses unspecified IP address. It is fine for
MIPv64and DHCPv4 and we beleive it will be fine for Pana.
Jari: What are the next steps?
Chairs/Lionel: That will be discussed later.
+++++++++++++++++++++++++++++++++++++
Rechartering of WG and relevant I-Ds
Presenter: Chairs
Primary objectives has been achieved.
- Proposal to take Pana working group in maintenance mode. Review
current drafts and consider the essential ones. Going into maintenance
mode and if there is a concrete cause and then the documents will be
reviewd based on the context of the working group.
Critical ones are:
*state machine document. part of the base protocol.useful for
implementation.
*Pana enabling IPsec based access control. should be considered as a
standards track.
*draft-ietf-aaa-interworking document will be dropped
*context transfer protocol for pana. the relevance is very low. This
should be consdiered in mipshop.
*pana MIB. This document is relevant and this is needed for
completeness. Victor can take over this document.
*master key between pana client and enforcement point. relevance is
high. already expired.
*network selection support should be dropped.
*pre-aunthentication support PANA. This is very useful and this will
be part of the revised charter and milestones.
Open questions from participants:
The pana applicability to DSL networks.
DSL is not too interested in PANA in DSL forum. Basavaraj says no harm
in looking at this. In a years time will try to close this working group.
Lionel is inetersted in taking up the pana enbaling IPsec base access
control.
Jari's take in the final conclusion
Alper: Use of unspecified IP address is also used in DHCPv4 and MIPv4,
because they do not care within their context.
We have a justification within PANA to deviate from standard IP
design. We loose features of IP, but we think thats fine for PANA.
Richard: Is there a clear interest from DSL forum?
Basvaraj: There is nothing formal. They have not said "we dont want to
use PANA".
Jari: I have no extra information. But I think they are interested.
Alper: Their statement is: "there are two different solutions, but we
have not yet decided on one."
Basvaraj: There is interest from people to work on it. Let's see what
impact it makes.
Lionel: We should complete the work for "IPsec based Access
Control". IMO we need it.
Jari: "Pre-authentication support" I-D expired, but relevance
high. There is a problem here. Lets complete the four documents, and
let it up to DSL forum if they use it.
Basvaraj: We will send you a revised charter.
Jari: I could also do AD sponsoring of documents if necessary. But
lets not commit to it now.
State machine, MIB, theoratical appliation of pana to DSL
optimization such as pre-authentication. No point working on expired
documents.
AD sponsoring the optimization documents.
Next steps, revise the charter.
Jari: Documents needs to be completed and then working group will be
suspended.
--
Chairs: Next Steps
Basvaraj: We go into maintenance mode.
Jari: Ok. Its more sleep mode though. I am inclined to terminate WG
ASAP. When PANA is applied somewhere, we need new WGs.
_______________________________________________
Pana mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pana
