Hi Jari,
Hi Vidya,
Re 1: I do believe an IP layer solution in this space is
potentially
useful. Not as something that replaces existing link layer
solutions
and takes over the market, but there are situations where
it would be
useful, for instance over link layers that have no such
support, as a
solution for networks where you just want to add a node in
the middle
of the access network without updating all access points
(kind of like
a replacement for weblogin but without the need for user
intervention), etc.
I am trying to figure out the use case for an IP layer
solution in this
space as an access authentication protocol and I am not
convinced that
we need something like PANA. If you are in fact, adding a
node in the
middle of the access network that is going to perform access
control,
is it just performing authentication or also attempting to
derive keys
and secure the data traffic? With a solution like PANA, a link layer
secure association protocol or IPsec needs to be run to secure data
traffic. If the former, the authenticator (or at least the
EP) needs to
be located at the edge. This needs support at the link layer anyway,
and all such link layers already support EAP.
If the latter, the most natural solution to use is IKEv2 with EAP,
since even with PANA, you still need to run IKE/IKEv2 and
IPsec - so, I
don't see what benefit PANA provides here.
My comment above relates to the overall interest in an IP
layer solution without considering what protocol is used.
I also wrote in my e-mail something about the different
alternative solutions. It is true that IKEv2 with EAP is
potentially a good fit for this task. IKEv2 is my favorite
EAP encapsulation protocol :-) However, its not clear that it
currently has all the parts (though I could have missed some
extension somewhere).
For instance, some mechanism appears to be needed to discover
that you are in a network that requires this type of
operation, and to find the address of the control device that
you need to talk to. I haven't done the research on how easy
it would be to add this (probably quite easy) or if there are
other things that we would need. Thoughts?
Let me separate out two issues here. In order to discover that you are
in a network that requires this type of operation, you need to know via
some kind of advertisements (SSID, for instance) that you are not in the
home network. For instance, VPN connections today are mostly user
initiated.
Another issue that you mention here is the discovery of the address of
the control device - this is typically done via DNS today.
Thinking further about the PAA discovery mechanisms outlined in the PANA
protocol, it seems to bring some deployment concerns. Administratively
scoped multicast is one of the advocated methods of performing PAA
discovery. Administrative scoping of multicast is a huge administrative
burden and is not a good deployment option. Protocols like DVMRP allow
TTL scoping which are somewhat better. But, the thought of opening up
port control to allow multicast packets into the network prior to
authentication is not appealing to me.
Another option that PANA provides for PAA discovery is traffic-driven
discovery. This is somewhat similar to what EAP relies on - i.e., the
network figures out that it needs to send an EAP Request Identity (in
the absence of an EAPoL-Start like message).
In short, discovery hardly seems to be a reason to use PANA to me - I'm
trying to at least taste the kool-aid, even if I can't drink it all, but
somehow, am yet finding a convincing reason why I should :)
Vidya
Anyway, I agree with Dave Crocker that the bar should be
higher for using "there's another solution" argument in last
call discussion of chartered work than in, say, a BOF
discussion. Perhaps we should focus more on whether the
function itself is something that we agree on, and what we
can do to fix/scope/help PANA.
--Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf