[unisog] Tracking usage of dynamic IP

[Alexander Clouter]

Hi,

Peter John Hill <pjhill at u.washington.edu> [20071113 07:09:03 -0800]:
> 
> On Nov 13, 2007, at 2:29 AM, Alexander Clouter wrote:
> >
> > Time to use that magical buzzword 802.1x.  To be serious though it really 
> > does work and we are using it here.  We are doing the full Authentication 
> > (MAC fallback based and user based), Authorisation (which VLAN to dump 
> > them in) and the accounting data too.  In your situation you are only 
> > interested in the accounting side of things.  I have not tried out an 
> > accounting only approach but I cannot see why it would not work.
> >
> > It seems pretty difficult to get equipment that is not 802.1x enabled and 
> > so I would recommend you use it.  To be honest no MAC<->IP mapping will 
> > work unless you have solid anti-spoofing[1] inplace you cannot rely on 
> > the data. er gets a new fresh authentication.
> 
> I like the idea, because it provides a more reliable userid to port  
> and mac association and uses radius for accounting data, which is  
> pretty mature.
> 
> The one thing I wonder about is that since we are talking about a  
> university setting, how do you deal with things like xboxes, apple  
> tvs, tivos. I think your config specified that each mac addr had to  
> authenticate in order for them pass non-EAPOL frames. Would this  
> encourage users to install home routers instead of home switches in  
> their dorms and offices so that they could have one machine that does  
> the 802.1x and gets the network up for the rest?
> 
Well the settings I initially gleaned from:

http://www.oneunified.net/blog/2007/04/30/

I was unaware of the fallback MAC authentication approach until I read it, 
it had been recently added to IOS from my understanding.

The client workstations after the link is brought up have about ten seconds 
to respond otherwise the switch goes about waiting for the MAC address to 
appear (usually in a DHCP packet).  This is then used to form a RADIUS 
authentication packet, the MAC address is used for the username and password.  
Our RADIUS server (FreeRADIUS) is primed to notice this as a 'legacy' system 
and deal with it appropriately.  If the MAC address is registered in our LDAP 
tree then it is dumped in a VLAN[1].

If the MAC address is not recognised the RADIUS server decides the client does 
not have an 802.1x supplicant and dumps them in a 'get-a-supplicant' VLAN.  

In the case when someone has a supplicant installed (even after lets say the 
MAC based authentication has taken place) an EAP-Start packet is fired off 
which resets the whole 802.1x state machine on the switch and then user (we 
use EAP-TTLS via SecureW2 however PEAP or even TLS could be used) 
authentication helps decide which VLAN they are placed in[2].

Before the *authorisation* kicks in the MAC address is checked if it is 
registered and if not dumps them in a registration VLAN.  If the machine is 
registered then they get dumped straight into the 'users-unmanaged' (our 
users but on laptops/workstations that our university is not responsible for) 
VLAN.  The exception to this are eduroam[3] users; if the realm is not one 
that we handle and the authentication succeeds then the work station is 
dumped straight into the 'eduroam' VLAN as we are not permitted to collect 
details regarding eduroam roaming users[4].

> How about projectors? Most printers probably support 802.1x. Are these  
> things dealt with as exceptions where somehow the switch config for  
> that device needs to allow that device to not use 802.1x?
> 
*Pre-registered* as being permitted to use MAC authentication.

> It's an interesting deployment scenario, that's why I am asking. These  
> are questions that I have wondered about whenever thinking about 802.1x.
> 
I can see why you are curious.  There was *nothing* out there for me to work 
on.  All the conslutants had no advice other than "make sure you have a good 
testbed" :-/  It was complete trial and error on my part.  I probably have 
missed other details[5] so do ask and it is probably tucked away in my brain 
somewhere :)

So in conclusion, this is completely new territory.  All those commercial NAC 
solutions actually do *not* support 802.1x and simply over throw the switch 
configuration forcing them kludgly into a 'quarantine' VLAN.  We wanted 
something far more graceful where we change an LDAP object (to 'quarantine' 
for example) and then re-initialise the 802.1x state machine for the port on 
the switch or AP.

Fortunately my employer (a university) was happy for me to write one from 
scratch in Perl</smugness> :)

Cheers

Alex

[1] this is pretty much identical to a VMPS approach but without the need for 
	OpenVMPS and gives you the perfect 802.1x migration strategy for some 
	time in the future
[2] well this home brewed (GPL and still in development) NAC solution of ours 
	actually lets workstations exist in a number of VLAN's and users can 
	only exist in a single VLAN.  Where ever there is this overlap that 
	is the VLAN the machine is placed into
[3] http://www.eduroam.org/
[4] if an abuse issue arises we blacklist the MAC address
[5] such as that a Cisco 440x sucks as you cannot disassociate someone via 
	SNMP and that Mac OS X machines (and Linux) will not renew their DHCP 
	lease if you force a re-authentication of the port they are connected 
	to (so you have to shutdown the port for ten seconds and then 
	re-enable it)

-- 
 ____________________________________
/ A journey of a thousand miles must \
| begin with a single step.          |
|                                    |
\ -- Lao Tsu                         /
 ------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.sans.org/pipermail/unisog/attachments/20071113/5b4a7a0e/attachment.bin