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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf