Making network authentication simple in a Bring Your Own Device environment | Hacker News Reader

Making network authentication simple in a Bring Your Own Device environment

gist.github.com

107 pointsfanf225 comments

Their solution is based on per-subscriber VLANs. VLANs have a 12-bit ID, so 4096 maximum. In practice there are usually fewer available, some ranges being reserved by network infrastructure.

And indeed: NB: Per the spec, the maximum number of VLANs on a network is 4094. In our case, it is not an issue, as our subscriber count should not exceed 3500 in the foreseeable future. If we were to exceed it, we would need to look at other solutions.

That's one hell of a caveat. It works well for them because French universities (this is deployed at SupElec, one of them) are usually small, but wouldn't pass muster in most US situations.

maybe I have been looking at datacenters too much lately but I think you could probably achieve the same thing and better scale + performance with something like VXLAN EVPN down to the switch instead of vlan per user. the end user would have interesting stuff like MAC mobility too so it would be suitable for the staff and servers as well as student network

edit: yeah that would be awesome, you could move a VM from a server to your laptop with minimal interruption

https://www.juniper.net/documentation/en_US/junos/topics/con...

Student staff usually learn first network tricks on their first year and stay for 3 years. Complex solutions cannot be used because they don't have the experience and even if they get it quick enough, this would put a huge barrier to yearly new comers.

How many engineers have spent how many hours trying to hack solutions for exactly this problem for their corporate/academic network over, and over, and...?

And when they hit 4096 user accounts?

It's actually depressing how hard they had to work to enable a basic BYOD network-layer authentication use case. Particularly since network-level device authentication is basically "securing your network 101" which any network in the world practicing good security hygiene should be implementing.

I know very little about network-layer security, is there a best practice here? Do people try so hard because they do not like it or is there one per vendor type of thing, nothing open and "standard"

Is this problem not actually solved and your just pointing out how depressing that something seemingly so essential is not solved?

curious as well. I first understood it as "how could they struggle with something so basic"

Typically wired 802.1x is used in an enterprise setting, where devices are under control of the IT staff. In that case provisioning devices with a certificate can be done easily and it all works pretty smoothly. Likewise enterprise settings want to put all users on the same (or a small number of) VLAN(s). Any devices outside of IT’s control, such as employee phones and tablets, will be restricted to a guest network with no access to anything beyond the internet connection.

In this case neither is true - they have no control over devices being connected so can’t rely on SSL certs, and they explicitly want to isolate each user on their own VLAN. Given those constraints this is a much harder problem to solve.

Oh yeah, the horrors of 802.1x.

There is one thing though that the blog post is missing: devices claiming to support 802.1x but where that path was never tested. This is something I discover often enough in Chinese Android devices - the UI works fine but then the connection simply fails without any error message to the user.

I wonder what's shown in adb logcat in this case.

radius logs might help. But no proper error messages on Samsung devices either.

This step by step explanation is truly fascinating to me. Really love the way this was written! Engineering solutions to these problems is probably one of my favorite things to do. I built the VPN and internal DNS/service resolution stuff for FarmLogs and went through some similar experiences.

This is pretty much the same as Ruckus wireless provide out the box, expect that they use a combo of unique PSK and MAC address for each device

Great article, wonderful to read how you came to your final configuration. Having wired support is a bonus.

What about some kind of "out of band" solution? i.e. I plug in my smart bulb, then log into a website from my phone to "claim" and authorize that new device. Kind of like a Bluetooth pairing UX for networking.

Are there any infrastructure / software products out there which offer an experience like that out of the box?

As stated in the article, the previous version of the network required MAC addresses for authentication, and you can easily code something that will allow you to add a MAC to your account from a Web page.

But they wanted to do something new, where you don't have to ask students for something quite obscure for non-techs such as MAC address.

Of course the biggest caveat here is the number of VLANs (4096) that limit the scalability, but which was satisfactory in their case.

I think you misunderstood. In what I'm envisioning users would not need to type in a MAC address. The infrastructure would detect the new device (via MAC and/or other fingerprintable characteristics) and tie it to the user based on time (here are devices plugged in recently), location (filter by devices in jacks or access points we think are assigned to / proximate to you), and their input (yeah that guy is mine!). You could have them disconnect/connect the device a small, specific # of times to confirm, if there's too much ambiguity (lots of similar new devices just plugged in).

Ok, I see, my bad.

Well then, no idea.

Very ineffective solution for this type authentication, currently any manageable switch has option to enable packet switching only between selected ports (and is same with wirelesses, you can set that clients don't communicate directly), just use firewall plus few scripts and solution ready.

For universities there are thing as eduroam, which works like following: 1. there are 802.x authentication with certificates and users + password; 2. for legacy clients just landing page with firewall tricks

You do not solve the problem of traceability with packet switching.

Regarding eduroam your comment is incorrect. Most 802.1x auth in universities with eduroam use peap+mschapv2 which is a serious security issue (md4 nt hash). It is way too cumbersome to configure eap-tls and certificates. There are ways to get around it with passpoint/hotspot 2.0 provisionning but this is far from being supported on devices.

Our solution seems way cleaner than what you suggest. There is very few maintenance with our current setup and any student can connect securely to any AP are port in the campus. Our experience with custom scripts is not very satisfying.

I doubt it will work Re:ux constraints - but I wonder if going ipv6 only w/ipsec would another option.

Summarizing a lot of experience in this one: don't BYOD. Especially if you want to advance in your career.

Can you elaborate why not?

Given the context in this post is a campus environment for students, that seems a little unworkable!

As stated in the article:

> Here at ViaRezo, our job is to offer a high-speed, affordable and reliable Internet connection to the students of CentraleSupélec at Paris-Saclay.

Telling student's they can't BYOD is not acceptable solution to the problem.

They are students managing a huge network, that's an amazing learning experience. Of course they have to BYOD.

Reply on news.ycombinator.com