[ietf78-tech] Admission Control: Just to be completely clear

Mon Jun 28 08:04:01 PDT 2010

Just to throw a late monkey wrench on the pile....

Has anyone used the captive portal that is now built into the Juniper EX series?

I have a 48 port at home but its not setup for remote use :-( , so I cant test it until i get home which is too late. From what I have read on it, it seems like we could use them redundantly in path and let them do the portal hijacking. it backends to radius so thats easy. And we know v6 support is handled.

Then we get portal and solid switching all on one.

Again assumes that this would be acceptable to the Beijing engineers.

Rob

On Jun 28, 2010, at 8:47 AM, John Kemp wrote:

> 
> Did want to remind people of one other option.  The performance question
> on the
> filtering VLAN is still the big one in my mind.  3rd option beyond MAC
> acl's on
> Cisco Switch, and MAC rules in Ebtables is IP+MAC in Iptables IPSET.
> 
> If you toss out the IPV6 requirement for the filtering VLAN, then this
> would work
> well.  It gives you IPV4+MAC as the access control.  This requires
> longer DHCP
> leases, but that shouldn't be a problem.  What it gives you is a hash on
> the IP for
> the lookup, and then adds the MAC check after the hash lookup.  So it is
> fast.
> We've had this running with 4000 users, so it is known-to-work, and we
> have the
> code for it.
> 
> The performance worry on both the 3560's and the Ebtables for me is that
> I believe
> both of those will devolve to linear search on the total number of users
> on the filtering
> lan (* some statistical average).  This is per-packet, linear search on
> some 1000 rules.
> And when we did this with IP-Tables MAC matching, it was sluggish when
> you hit
> that number.
> 
> So my own preference would be IPSET's (IP+MAC) as the control mechanism.
> But this means you also buy off on: no IPV6 on the control VLAN, and the
> DHCP
> for that VLAN has to be 12 hours at least.
> 
> John Kemp (kemp at network-services.uoregon.edu)
> 
> 
> On 6/27/2010 11:16 PM, Rob Nagy wrote:
>> It seems like combining Chelliot's idea with Joell and Johns comments that writing to acls on two redundant core switches, which we could ensure end up at Beijing would be the most stable and most secure. Allowing us easy redundancy in the data path and flexibility in the portal.
>> Then whatever we do for tokens is fairly easy to implement on the portal and we avoid end device limitations. 
>> 
>> It should even be fairly trivial to write a tool for the help desk to generate user/passwords and push it to the portal for people who lose or forget theirs even. 
>> 
>> In mind the big question then goes to Jim, can we push core switch gear on the Beijing meeting for the auth?
>> 
>> Alice
>> 
>> Sent from my iPhone
>> 
>> On Jun 27, 2010, at 10:17 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>> 
>> 
>>> If it's not on the same l2 domain all you have is ip address to write the acl with, but yeah...
>>> 
>>> Joel's iPad
>>> 
>>> On Jun 27, 2010, at 9:08 PM, Chris Elliott <chelliot at pobox.com> wrote:
>>> 
>>> 
>>>> A thought just occurred to me. We don't need to restrict access to the network. We need to restrict access to the Internet connection. This means we have a single (redundant) point to implement access control--the routers or their switch ports.
>>>> 
>>>> Chris.
>>>> 
>>>> 
>>>> --
>>>> Chris Elliott
>>>> 
>>>> 
>>>> On Jun 28, 2010, at 12:02 AM, John Kemp <kemp at network-services.uoregon.edu> wrote:
>>>> 
>>>> 
>>>>> On 6/27/2010 8:18 PM, Jim Martin wrote:
>>>>> 
>>>>>> Gentlepeople,
>>>>>> From some of the comments that have flown around here in the last day or so, I'm concerned that we aren't all in sync on what we're trying to do with the admission control project. Here's an attempt to clarify it from my point of view. If anyone disagrees with this, please speak up!
>>>>>> 
>>>>>> Goal
>>>>>> ------
>>>>>> The IETF Meeting in Beijing this fall will have a network that is designed to connect to the Internet in a completely unfiltered way. Due to this lack of filtering, we've been asked to ensure that only IETF attendees can gain access to that network. At this point, the requested authentication tokens are a simple shared username/password that are distributed to the attendees as they arrive, however we'd like to ensure that per-user authentication is possible should the requirements become more strict. 
>>>>>> 
>>>>>> To this end, we'd like to prototype this admission control system for Maastricht, both to validate the system under load and to provide a "heads up" to the attendees that this will be the way things are in Beijing.  This also allows us to disable the admission control if there's a problem, an option not available in Beijing. 
>>>>>> 
>>>>>> Caveats
>>>>>> -----------
>>>>>> -  We're late. We need to socialize what we'll be doing to the IETF community via Ray (IETF Administrative Director) and Russ (IETF Chair), so we need to get them information soon.
>>>>>> 
>>>>>> - We have people with very limited laptops/devices, so we cannot assume they can to 802.1x
>>>>>> 
>>>>>> - We have some very privacy focused individuals which will undoubtedly be concerned with anything we do. We simply need to avoid stirring up the hornets more than we need to.
>>>>>> 
>>>>>> - The equipment being used in Maastricht is not guaranteed to be the same equipment being used in Beijing. Keeping things as device agnostic as possible is a good thing. 
>>>>>> 
>>>>>> - Failure /IS/ an option in Maastricht, but would be very bad in Beijing
>>>>>> 
>>>>>> 
>>>>>> Timeline
>>>>>> ------------
>>>>>> We really need a fleshed out plan ASAP. There an administrative call for the Maastricht IETF early (US) Tuesday morning where we should be able to put details forward.
>>>>>> 
>>>>>> - Jim
>>>>>> 
>>>>>> 
>>>>> Glad you reraised the issue.
>>>>> 
>>>>> If you have a significant number of people who can successfully utilize
>>>>> authentication on WPA1 and WPA2 networks,
>>>>> then I think the access control issue becomes almost moot.  Which
>>>>> suggests to me that you want to make sure that it isn't the
>>>>> usual PSK setup, but rather, some sort of authentication on the wireless.
>>>>> 
>>>>> Other point was, as was noted by Chris? earlier, a Cisco switch should
>>>>> be as good a bridge as a Linux bridge.  So from a performance
>>>>> standpoint, the Cisco switch might be the better hardware to use for the
>>>>> implementation of any MAC address filtering.  Only issue
>>>>> I could see here would be if the number of users that can't do WPA1 or
>>>>> WPA2 is LARGE, then there is the potential for pain, given
>>>>> that Cisco sometimes codes in arbitrary limits.
>>>>> 
>>>>> So that's kind of where I am thinking.  I would say: 1) force
>>>>> authentication on WPA1 and WPA2, and we can do something to
>>>>> create a captive portal, but try to use the Cisco switch as the access
>>>>> control device.
>>>>> 
>>>>> I have other evil thoughts, but the main one is, seems like pushing WPA1
>>>>> and WPA2 authentication is the real focus here.
>>>>> 
>>>>> John Kemp (kemp at network-services.uoregon.edu)
>>>>> 
>>>>> _______________________________________________
>>>>> ietf78-tech mailing list
>>>>> ietf78-tech at daedelus.com
>>>>> http://www.daedelus.com/mailman/listinfo/ietf78-tech
>>>>> 
>>>> _______________________________________________
>>>> ietf78-tech mailing list
>>>> ietf78-tech at daedelus.com
>>>> http://www.daedelus.com/mailman/listinfo/ietf78-tech
>>>> 
>>>> 
>>> _______________________________________________
>>> ietf78-tech mailing list
>>> ietf78-tech at daedelus.com
>>> http://www.daedelus.com/mailman/listinfo/ietf78-tech
>>> 
>> _______________________________________________
>> ietf78-tech mailing list
>> ietf78-tech at daedelus.com
>> http://www.daedelus.com/mailman/listinfo/ietf78-tech
>> 
> 

Robert Nagy
- - - - - - - - - -
Senior Dive Master | Deep Dive Networking Inc
p: 408.480.5133 | aim/icq: 95091173 | e:rob at deepdivenetworking.com
www.deepdivenetworking.com