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

Reply via email to