All,

The NOC team, after much discussion, has deployed some changes (we hope
improvements…) to the IETF 92 network. More details below, but in short:
the main “ietf” wireless network is now encrypted; when prompted for
credentials, enter ietf for both the username and password.

These changes are designed to:


   -

   improve wireless performance,
   -

   further encourage the use of the 5Ghz wireless spectrum,
   -

   encourage the use of layer 2 encryption, and yet,
   -

   provide access for older devices and those that don’t desire layer 2
   encryption.


We will be carefully monitoring the networks and, if issues are found, we
will take appropriate action. We encourage you to send feedback and
suggestions (noc@ietf.org). As this is the IETF, we expect to receive many
conflicting suggestions. The NOC team is ultimately responsible for
bringing a network that works for all IETF attendees, and we will be
evaluating suggestions for possible inclusion at future meetings.

Here’s a quick summary of the new network layout:


SSID

Description

Encrypted

Frequencies

IP versions

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 will offer layer 2 security. This is done
using WPA enterprise with 802.1X (PEAP or TTLS) authentication and AES or
TKIP encryption. As usual, 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 to this page:
https://www.ietf.org/registration/MeetingWiki/wiki/92net.

The “ietf” SSID (the closest thing we have to a “default” wireless network)
now only will be seen on the 5Ghz spectrum. This network is also now
encrypted.

The new “ietf-legacy” SSID will be 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 will allow 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 only changes to the “ietf-v6ONLY” and “ietf-nat64” SSIDs are the
addition of encryption and the restriction 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.

“eduroam” hasn’t changed. 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 ours. 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 [1]. In addition,
we (the IETF/IAB and I* things) have published several items in this space,
including BCP 188 [2] and the IAB Statement on Internet Confidentiality
[3]. After careful analysis and testing, the NOC team is now able to deploy
changes in keeping with the above to the IETF 92 network.



[1] “Security for the IETF wireless network“

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13073.html

https://www.ietf.org/mail-archive/web/ietf/current/msg88796.html


[2] “Pervasive Monitoring Is an Attack“

BCP 188, RFC 7258

https://tools.ietf.org/html/bcp188


[3] “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.”


-- 
Chris Elliott
chelliot@pobox.com

"What the f*ck is a sesame? It's a street...it's a way to open sh*t!"
--Mitch Hedberg