Browse Prior Art Database

Improvements in Wireless Technology Disclosure Number: IPCOM000225257D
Publication Date: 2013-Feb-04

Publishing Venue

The Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 01 of 14


Zero-touch migration.


With the introduction of advanced switches, to distinguish the users connected on wired ports in campus, we have different authentication methods. for authenticating wired clients & to provide appropriate user-roles. Ex of authentication methods include MAC authentication, hotspot authentication, wired-dot1x authentication etc. For all of the authentications the administrator/user needs to put in some manual effort.

1. MAC-authentication: Administrator needs to enter all valid mac-addresses in radius server database, which is very huge effort

2. Hotspot authentication: It's frustrating for a valid corp user, as whenever he connects on network, he needs to do web-auth before he is given access to the network

3. Wired-dot1x auth: Administration/User needs to configure LAN adaptor settings to use dot1x on every corporate machine, which is again very cumbersome.

So if you take any of the above authentication method either user or administrator needs to put in some effort, making it less attractive for a customer deployment perspective.


Here with this disclosure, we would take off the pain of user and administrator from configuring anything extra.

On a switch we will create a aaa profile where radius server is mapped. And this aaa profile will be mapped to all ports. When a corporate machine is connected to a wired-port on the switch, the switch will assign guest role to the client initially, on client side NETWORK ACCESS CLIENT initiates dot1x exchange with the switch & completes authentication (using windows logon credentials). This is exactly similar to existing way of wired dot1x authentication. On successful authentication the wired-client is assigned authenticated role. Unless until the NETWORK ACCESS CLIENT-dot1x authentication is successful, the client will remain in guest role, where only DHCP,DNS is permitted & HTTP is re-directed for hotspot authentication.

NETWORK ACCESS CLIENT would do this so seamlessly, that neither administrator nor corp-user doesn't need to do anything extra, as we can push this option as a configuration in NETWORK ACCESS CLIENT profile.

Page 02 of 14

Where as a vistor comes inside campus & connects his laptop to any of wired- ports in coference room which in turn connected to corvina switch in the backend, will be assigned guest role. So when he tries to browse he would be re- directed to hotspot page as guest role has corresponding rules. So with this approach its seamless for corp-user, but maintaining similar level of security for guests.

NETWORK ACCESS CLIENT will first try to do dot1x authentication, and if it is success, then it won't initiate any ipsec tunnel, as it is trusted network. Whereas if NETWORK ACCESS CLIENT doesn't get any response for dot1x request, it will consider the network as un-trusted network & initiate ipsec in similar way as its working today. We may use existing logic of determining whether the network is trusted/un-trusted...