Hello, In addition to the requirements list, it would be good to know if the needed thing is specific for DSL or should it be more generic.
Cheers, Jonne. On 4/19/07 4:32 PM, "ext Ralph Droms" <[EMAIL PROTECTED]> wrote: > In between a description of "the network topology", and "why PANA, 802.1x, > etc. won't work.", we need a list of requirements. > > - Ralph > > On 4/19/07 4:02 AM, "Alan DeKok" <[EMAIL PROTECTED]> wrote: > >> 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 > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
