
Making network authentication simple in a Bring Your Own Device environment - fanf2
https://gist.github.com/8dfb9c981a5b4a308cd33aa76c111104
======
AceJohnny2
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.

~~~
solotronics
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...](https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-
vxlan-data-plane-encapsulation.html)

~~~
vbernat
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.

------
zaroth
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.

~~~
NationOfJoe
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?

~~~
jon-wood
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.

------
mschuster91
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.

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

------
whalesalad
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.

------
paulenash
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.

------
rkagerer
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?

~~~
plopilop
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.

~~~
rkagerer
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).

~~~
plopilop
Ok, I see, my bad.

Well then, no idea.

------
bleke
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

~~~
gandem
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.

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

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

~~~
urda
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.

