Good point; I agree... - Ralph
On 4/22/07 5:27 PM, "Soininen Jonne (NSN FI/Espoo)" <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
