Here’s a quick summary of the network layout:
|ietf||The “default” ietf network||yes||5Ghz only||v4 and v6|
|ietf-legacy||A network for legacy and unencrypted use||no||2.4 and 5Ghz||v4 and v6|
|ietf-2.4ONLY||An encrypted network for 2.4Ghz users||yes||2.4Ghz only||v4 and v6|
|ietf-v6ONLY||For users wanting a pure IPv6||yes||5Ghz only||v6 only|
|ietf-nat64||For users that want to only use a IPv6 stack, yet be able to reach some IPv4 resources||yes||5Ghz only||v6 with access to some v4 resources through NAT64 and DNS64|
|eduroam||For educational users, authenticated against their home institution||yes||2.4 and 5Ghz||v4 and v6|
|ietf-hotel||A network over the hotel infrastructure with no filtering and utilizing the IETF uplinks||no||2.4 and (some locations) 5Ghz||v4 and v6|
All networks marked as encrypted offer layer 2 security. This is done using WPA enterprise with 802.1X (PEAP or TTLS) authentication and AES encryption. We are all using the same credentials (user “ietf”, password “ietf”), yet each user will get unique session encryption keys. Our Radius authentication servers use a certificate that you can verify by going below: Certificate_Information.
The “ietf” SSID (the closest thing we have to a “default” wireless network) only will be seen on the 5Ghz spectrum. This network is also encrypted.
The “ietf-legacy” SSID is “open” (no authentication or encryption) and available on both 2.4 and 5Ghz channels. This network is primarily designed for users of older (“legacy”) devices, but can be used by anyone for any reason. Obviously, there will be no layer 2 security.
The “ietf-2.4ONLY” SSID allows you to select the 2.4Ghz band yet get an encrypted connection. This will be useful for those with devices that support only 2.4Ghz and those that have some issue with the 5Ghz network configuration.
The “ietf-v6ONLY” and “ietf-nat64” SSIDs are encrypted and are restricted to just the 5Ghz frequencies. While we’d like all attendees to use these SSIDs, we also improve the performance of the 2.4Ghz channels by reducing the number of SSID announcements. In addition, the majority of users of these networks have been doing so from 5Ghz-capable devices.
The “eduroam” SSID is encrypted and allows users to authenticate to their Eduroam participating institution. Those of you that will be using it will already be aware of it.
And, finally, the “ietf-hotel” SSID uses the hotel network infrastructure, yet the uplink is our IETF network. This will give an improved experience for IETF users in their rooms and public spaces around the hotel not covered by the IETF wireless network. Note that, as we don’t control this network, we will need to work with the hotel to resolve any issues found.
As a little background, we (the IETF) have discussed the layout of wireless networks here at the IETF several times over the last few years, most recently in a thread Jari Arkko started on the ietf-announce list, with followups on the ietf list, July 24th of last summer . In addition, we (the IETF/IAB and I* things) have published several items in this space, including BCP 188  and the IAB Statement on Internet Confidentiality . After careful analysis and testing, the NOC team is now able to deploy changes in keeping with the above to the IETF 92 network.
 “Security for the IETF wireless network“ https://www.ietf.org/mail-archive/web/ietf-announce/current/msg13073.html https://www.ietf.org/mail-archive/web/ietf/current/msg88796.html
 “Pervasive Monitoring Is an Attack“ BCP 188, RFC 7258 https://tools.ietf.org/html/bcp188
 “IAB Statement on Internet Confidentiality“ https://www.iab.org/documents/correspondence-reports-documents/2014-2/iab-statement-on-internet-confidentiality/
“The IAB now believes it is important for protocol designers, developers, and operators to make encryption the norm for Internet traffic. Encryption should be authenticated where possible, but even protocols providing confidentiality without authentication are useful in the face of pervasive surveillance as described in RFC 7258.”
We encourage you to authenticate our Radius server certificate. Here's the certificate in three different formats, including the SHA1 checksum and pgp signed versions.
Note that these files are stored on Snozzages (ask Warren…) because this Wiki will only allow me to upload pictures.
Please feel free to come by the help desk in the terminal room if you have questions or comments, or email me (see below), or, if you want to see me in particular, I'm likely to be found in the NOC in room 423 on 4th floor of the Pacifico Convention Center, Yokohama.
— Chris Elliott 2015/11/01 13:30