Alper Yegin wrote:
The above two issues are related. If PANA would eliminate trying to
operate on L2 access controls, and rely solely on an IP Address and
associated filter, then it would truly be a Network Layer authentication
and Network Layer access protocol. I believe this would go a very long
way to eliminate confusion over where PANA can add value. I cannot
understate this enough.
This is fundamental difference in how we view PANA. I don't consider
PANA as "Network Layer access protocol" while I only consider PANA as
a network layer protocol for carrying authentication information for
network access.
This is a terminology issue, I believe.
As we said in RFC 4058:
After a device is authenticated by using PANA, it MUST be authorized
for "network access." That is, the core requirement of PANA is to
verify the authorization of a PaC so that PaC's device may send and
receive any IP packets.
So, PANA authenticates for (and used for authorization of) "network access."
"Network" access to me means access to send "Network" packets, which is
synonymous to "IP packets" in the statement above. Expanded a bit, I
believe the intent here is to say that:
PANA authenticates a PaC so that it can be authorized by a PAA to
install filters on an (colocated or separate) EP that permits IP packets
to flow to or from a PaC on a given network. I see nothing in that
statement that requires L2 or L1 specifics. Since the EP probably
already has to filter at the network layer simply to permit/deny the
PANA packets themselves onto the network, it is perfectly reasonable to
assume that enforcement may be done at L3. Doing so, reduces the
complexity of your problem dramatically, and I believe puts PANA in a
place that most people will be able to readily understand.
Execution of access control is orthogonal to PANA authentication. A network
can choose to change IP filters to allow traffic from authenticated client,
change L2 filters to do equivalent, or even do some L1 filtering.
Which is where you get into the layer violations that people get
concerned about, and why your protocol ends up looking more complex than
it need be. Stick to "Network Access" and you are fine. Move down into
"Data Link Access" and you start putting the cart before the horse, and
open yourself up to an array of complexities by looking downward into
the stack.
At the end, what's really allowed/disallowed is the IP network access.
If you allow this type of logic, I could say that in the end what is
really allowed/disallowed is email access. If you are carrying PANA
packets on the network, by definition you already have at least some
level of data-link and Network (IP) connectivity. I honestly believe
that trying to manipulate L2 and L1 via PANA is becoming a burden that
may, in the end, sink the entire ship.
- Mark
I hope this clarifies.
Alper
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
