Hi Joel, Reading the entire thread, I think we should seriously consider your detailed suggestions to improve the PANA framework draft for broader acceptance in the community. Thank you, Yoshihiro Ohba On Tue, May 30, 2006 at 09:42:25AM -0400, Joel M. Halpern wrote: > I think the confusion and complexity that I perceive comes from the > fact that the framework problem treats all the tasks (user > authentication, network selection, and securing the network > connection as being of the same significance or same relationship to > the solution. > > I think that most of the discussion of IPSec and pre-post PANA > addresses does not belong here at all. > > Let me suggest an approach that might simplify and shorten the document: > [Unfortuantely, I can't promise that it will fix everyone's problems.] > > 2. Describe the primary goal of PANA, and approach thereto. This > would state that the goal is to authenticate the user using an IP > level protocol. This would probably state that the primary approach > is to proivde a transport for EAP that meets the requirements for an > EAP transport [cite RFC.] > > 3. Describe very briefly the interaction between the EP and the > PAA. State that the protocol between them is out of scope. Note > that the EP must allow PANA messages to the PAA before authentication > is completed. (Yes, that's obvious, but it is actually worth stating.) > > 4. Describe that PANA protocol needs to provide for negotiation of > information before authentication. List briefly some of the things > to be negotiated (services available, algorithms available.) Also > indicate that the PANA protocol can provide additional > post-authentication information to the client (in the PANA response) > and to the EP. > > Securing the data channel between the PCC and the EP should be out of > scope. If you want to say anything about that, you might note that > this may be done in a link specific fashion, in may be done with an > unauthenticated IP exchange before PANA, or PANA may be used to carry > additional credentials / keys to be used to establish an > authenticated secure association. The reason I would not include > this is that the question of why I need an authenticated exchange > will complicate the document. The other reason for not describing it > is that it does not change the framework at all, and should be > documented as a usage of PANA capabilities, in its protocol RFC. > > I would then probably dramatically reduce section 10. Trying to > describe all those cases does not actually help the reader get the > mental model. And I think they are too deployment specific. > > The real key here is to focus on the primary goal. The resulting > document ought to be clearer, and focused on the problem that needs > to be solved. It can indicate that PANA can be used to help other > things, but that those things are not the purpose / point of PANA. > > At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote: > >Hi Joel, > > > >Thank you for spending your time reading the framework document and > >sending your feedback. Please see my response below. > > > >On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote: > >> In reading the PANA Framework document, what I read seemed to me to > >> be more of a "system" or "solution" document than a clean IETF > >> protocol framework. > > > >I think your reading is correct. The document describes how different > >types of access network deployments are enabled by PANA. > > > >> > >> I saw efforts to address three different problems: > >> 1) Securing an otherwise unsecured link, when the access node is not > >> known to the client in advance. > >> 2) Selecting an authorization (charging, possibly packet handling) > >service > > > >Just to make sure, do you mean by 2) network selection that is > >described in Section 8 of pana-framework draft? > > > >> 3) Authenticating the user > >> > >> EAP over IP (or UDP, or link) is about authenticating the user. If a > >> media independent technique better than just using a browser is > >> needed, then solve that problem. > > > >This is surely one problem PANA is trying to solve, and has been > >clarified from the beginning of the work and more in this dicussion, I > >believe. > > > >> Personally, I would find the work > >> far more persuasive if it did not also try to solve the problem of > >> creating an IPSec association to the access device, nor of the > >> authorization selection problem. > > > >Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering) > >from EAP-based network access authentication is another problem. When > >a lower-layer does not provide EAP service, it is clear that PANA is a > >standard way to solve the problem. Perhaps the main confusion is > >coming from the fact, as a side effect of solving this bootstrapping > >problem, that it is possible to use PANA to bootstrap lower-layer > >ciphering *even if the lower-layer supports EAP*. While I understand > >the confusion but let me explain several reasons for why I think this > >is still viable for lower-layers that support EAP. > > > >- Use of PANA for bootstrapping IKEv2. I explained several reasons > >for why doing this while IKEv2 can carry EAP, in my response to Vidya: > >http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html. > > > >- Use of PANA for bootstrapping IEEE 802.11i PSK mode. This makes APs > >and non-AP STAs that support 802.11i but do not support 802.11r can > >transit from one AP to another without necessarily perform EAP for > >every AP transition as long as the APs are acting as EPs of the same > >PAA. One may argue that this usage becomes useless when all APs and > >non-AP STAs are migrated to 802.11r, but it is still possible to use > >PANA for inter-ESS transition which is not covered by 802.11r. > > > >> > >> And spell out in clear English what use case needs that problem > >> solved. I can read between the lines and start to guess. But the > >> document is quite unclear. The appendix about DSL is not helpful in > >> that regard. > > > >One of the reasons for this may be that the problem statement and > >requirements are described in a separate RFC (i.e., RFC 4058) not in > >the pana-framework draft. Of course another reason may be that I, the > >editor of the draft, am not a native English speaker. > > > >BTW, there is no appendix in pana-dramework draft. So you may refer > >to Section 10.1 about DSL. Is this correct? > > > >I hope this sheds some light on the discussion. > > > >Yoshihiro Ohba > > > >> > >> Yours, > >> Joel M. Halpern > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@xxxxxxxx > >> https://www1.ietf.org/mailman/listinfo/ietf > >> > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf