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
