Jason et al., https://www.eduroam.org/wp-content/uploads/2016/05/eduroam_Compliance_Statement_v1_0.pdf
The compliance statement doesn’t require a specific frequency. So, if you want to turn 2.4 GHz off, nothing prevents you to do so for eduroam. eduroam doesn’t try to regulate local decisions too much, but enough to provide standardization and a consistent user experience (if 2.4 GHz is not supported the SSID won’t show up at all for 2.4 GHz users!…but the dot on the map might still confuse them a bit). On the other hand, you have to pass all EAP methods. So Curtis discussion on the evil twin and preventing this to happen can be done for IDPs but not for SPs (an SP must pass all EAP conversations). If you fear man in middle for password based EAP methods, using the CAT tool can help in that respect since it forces the installation of the RADIUS infrastructure certificate. Nothing beats EAP-TLS of course since the password is not involved except during the initial EAP-TLS on-boarding (can you MiTM the initial on-boarding? ;-) The same applies to the conflicting eduroam SSID. If you read the compliance statement you can create an “eduroam-” SSID. It is really not advised, as Jason mentioned, to run a different name since it breaks the “instant connectivity” and creates much confusion for users (and Help Desk calls!). We always promote agreements between the two neighboring institutions (exchange VLANs, Wi-Fi controllers collaboration when same brand is involved, IP Mobility, ...). PassPoint/HotSpot2.0 should address some of these concerns of neighboring SSIDs since preferences can be given to different networks. Best, Philippe Philippe Hanset www.eduroam.us www.anyroam.net > On Jun 19, 2016, at 8:53 PM, Jason Cook <[email protected]> wrote: > > Yeah we have had this problem at a few different levels... sorry for the long > response > > Initially we had AARNET (the Australian national operator) sharing our floor, > so we managed to experience the issue first hand. At that stage we got > approval to change our SSID to resolve the issue. "eduroam-UofA" was chosen > and our normal ssid is "UofA". To be honest this is not an ideal solution, > and at the time (and probably still) is not actually allowed. It brakes the > idea of eduroam simply working, the plan is you configure your device once > and you can then go to any participating institution around the world, turn > your device on and away you go. Having a different SSID means more support > requests for you and the home institution when it doesn't just work. At the > time (2007) the usage wasn't as high so it wasn't a huge issue..... though > supplicants tended be troublesome to configure. A few years later AARnet > offices moved and we wanted to be standard so we are back to "eduroam" SSID. > > It's not all over though, we have multiple institutions (3) around us > offering eduroam including buildings 15m away, and a new medical precinct is > being built that will potentially end up with 5 different institutions in an > area. Finally something on the back burner is the our city wireless offering > eduroam.... So the future will get interesting. But onto the current > situation. To be honest at this point we haven't had too many issues recently > with users hopping between SSID's in their offices. Likely the fact we don't > recommend eduroam as the users primary SSID would be the primary reason. We > did have a few calls on the close buildings years back, however coverage was > done differently and it wasn't un-common in non-dense installs to sometimes > see higher signal from neighbouring buildings in some rooms. But with denser > deployments and more consistent signal provision you rarely see neighbouring > buildings with higher signal.... In addition for eduroam visitors as a > workaround they can use our "UofA" SSID, don't remember this ever being > required but it does work. eduroam participation "requires" that SSID but as > far as I'm aware doesn’t stop you from also offering it on others, or even > wired dot1x for that matter. > > Likely we'll never go to eduroam as the only SSID for the many neighbours > reason as well as it's good to have your branding in the air. You can also > have issues like Curtis is mentioning where you want to change something for > security or other reasons but may be restricted by eduroam policy. I don't > think eduroam would approve of disabling 2.4ghz completely for example..... > Our national document is being reviewed but currently states WPA-TKIP is > required......HAHAHA. Don't think so. > > Finally we and other insinuations have wireless installs in our hospitals, > recently the hospitals have provided blanket wireless coverage and > interference became a major issue. The hospitals agreed to offer eduroam > SSID, and we are all pulling out our gear. (so more similar to Ryan's > experience). We started by disabling eduroam when they went live and now it's > a working it's hardware removing time. In this case each of the 3 main Uni's > here have a fibre into the hospital data centre and our users are routed > directly to us giving us more control of their intranet access should we > wish. > > A few discussions occurred about the varying technical solutions to all of > above including the medical precinct and city wifi etc back in 2014. Things > like SDN, Proxy Mobile IPv6 and routing for all users done centrally were > thrown around but it all seemed a bit too early and we put it aside for now, > I'm sure it's going to be back on the table in the near future. > > -- > Jason Cook > Technology Services > The University of Adelaide, AUSTRALIA 5005 > Ph : +61 8 8313 4800 > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:[email protected]] On Behalf Of Curtis K. Larsen > Sent: Saturday, 18 June 2016 12:49 AM > To: [email protected] > Subject: Re: [WIRELESS-LAN] eduroam ssid > > We're beginning to run into this problem as well. Luckily, eduroam is not > our primary SSID so at least the critical business functions continue to work > fine on a separate SSID. My guess is that we'll end up turning eduroam off > at those remote locations if problems get reported. > > In talking with the eduroam admin from the other institution they mentioned > that when this occurs in Europe the solution has been to change the name of > the SSID. Is this really allowed? If so, I'm sold! Then we can start using > our primary SSID with eduroam credentials! This is what I always thought > eduroam should have been. To me the value was always in the universal > credential > *NOT* the SSID name. That was always a drawback for me especially as > supplicants become easier to configure. > > The other problem that we're going to run into soon is that we will be > phasing out PEAP on our main SSID to mitigate against the evil twin > vulnerability, but what do we do with eduroam? I mean I guess you could say > it is the remote institution's problem, or the user's problem if they connect > to an evil twin on your campus because they're not validating the server. > But if the evil twin is on your campus it seems you have at least some > responsibility in the matter. But as it stands, eduroam will leave a bit of > a gaping security hole for us. > > -- > Curtis K. Larsen > Senior Network Engineer > University of Utah IT/CIS > > > > On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote: >> Yes. We have a satellite school at UNC Asheville. Up until recently, UNC >> Asheville was not >> running eduroam, and UNC Chapel Hill was the only occupant of a couple of >> buildings on campus. >> UNC Asheville adopted eduroam and wanted to move into adjoining spaces. So >> we were going to have >> the situation where UNC Chapel Hill folks might attach to the wrong >> institution’s eduroam and >> vice versa. We ended up bridging the two networks together through a single >> link, and based on >> realm, UNC Asheville will terminate UNC Chapel Hill folks directly to our >> network (through trunked >> vlans). It is nice, because now anywhere on UNC Asheville campus, UNC >> Chapel Hill folks have UNC >> Chapel Hill IP space. Because it made sense, we actually turned off our >> access points and allowed >> UNC Asheville to provide wireless in our areas (so we wouldn’t have >> competing wireless). >> >> >> Ryan Turner >> Manager of Network Operations >> ITS Communication Technologies >> The University of North Carolina at Chapel Hill >> >> [email protected]<mailto:[email protected]> >> +1 919 445 0113 Office >> +1 919 274 7926 Mobile >> >> >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >> [mailto:[email protected]] On Behalf Of Becker, Jason >> Sent: Thursday, June 16, 2016 11:45 PM >> To: [email protected] >> Subject: [WIRELESS-LAN] eduroam ssid >> >> Has anyone ran into this situation… >> >> We are an eduroam participating school and have multiple buildings that are >> either across the road >> or sometimes sidewalk that another University owns. The other school is >> wanting to join eduroam >> so my issue is when we are both broadcasting the same ssid in possibly the >> same airspace. I have >> a felling this is going to cause many problems as clients could bounce back >> and forth between >> systems. >> >> If you had to deal with this I like to hear your thoughts on it. >> >> -- >> Thanks, >> Jason Becker >> Network Systems Engineer >> Washington University in St. Louis >> [email protected]<mailto:[email protected]> >> 314-935-5006 >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group >> discussion list can be found at >> http://www.educause.edu/groups/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7ccb70500b292d4427293208d39661db4b%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=qGNRUEHsNMv7sMBIsc4xSekkNTdOESCI%2fPCz87RzRZY%3d>. >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can >> be found at http://www.educause.edu/groups/. >> >> > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
