Re: [Int-area] Re: [dhcwg] Discussion of subscriber authentication

[Ralph Droms <rdroms at cisco.com>]

Good point; I agree...

- Ralph


On 4/22/07 5:27 PM, "Soininen Jonne (NSN FI/Espoo)" <jonne.soininen at nsn.com>
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" <rdroms at cisco.com> 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" <aland at nitros9.org> 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
>>> Int-area at lists.ietf.org
>>> https://www1.ietf.org/mailman/listinfo/int-area
>> 
>> _______________________________________________
>> Int-area mailing list
>> Int-area at lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
Int-area at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area