Richard Pruss wrote:
...
Yes but the PANA stuff requires an IP address...
OK. Part of the confusion, I think, is the draft presents a solution
without discussing the problem space in detail. i.e. There are already
multiple kinds of network access protocols, as we have been discussing
here. Yet the draft doesn't say why those other protocols do not apply
to this situation. Instead, it just proposes a solution.
It would have shortened this discussion if the draft had had 3-4
paragraphs about the network topology, and why PANA, 802.1x, etc. won't
work.
... It would be very bad to
use DHCP as a transport protocol for authentication.
That seems a moral statement but so would your morals agree to run
authentication over BOOTP?
It's a statement from experience and best practices. Maybe "bad" is a
morally loaded word. Perhaps "inefficient", or "awkward", or
"re-inventing the wheel" would be more acceptable.
...
Yes but EAPoL gives you port security and not per subscriber identity
and fails on very basic requirements like multiple identities on a
single port for Video vs Data. Of course there are also all the
operational problems of then getting your L3 boundary in sync with your
now L2 authentication point and of course the many cases where the L2
edge is not physically secure like multi-tenant buildings where you
could simply remove the config from the device and then you are on the
network.
If the L2 edge isn't secure, then the solution becomes much simpler.
Always give the subscriber an IP address, because they can probably
sniff the net and pick a local unused IP anyways. Then, at the L3
boundary, perform firewalling and filtering until the individual users
are authenticated.
This is done today in the wireless arena, in captive portals. It
gives subscriber identity. It ties subscriber identity to IP address,
and usually to MAC address, too. It provides for multiple identities on
a single port. It provides for dynamic download (and update) of
firewall filtering && QoS rules to the L3 device.
Current Enterprise and SP networks treat DHCP as explicit and do not
allow addresses that are not DHCP assigned into the ARP table or to be
forwarded. All switch and router vendors have a multitude of features
on this topic.
Many products implement features that go beyond the original goals of
the protocol.
I would have loved to use 802.1x from the client to the NAS as it would
be much easier all around but 802.1x does not traverse a bridge and it
does not support multiple identities on a single port without really
horrible security gaps.
Are there reasons why a captive portal wouldn't work?
Alan DeKok.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
