Opened 3 years ago

Closed 3 years ago

Last modified 5 weeks ago

#892 closed request (fixed)

Re: [92all] IETF Wireless Network Changes

Reported by: dharkins@… Owned by: chelliot@…
Priority: tbd Milestone: ietf-092
Component: incoming Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

  Hi,

  Is there going to be a separate SSID that you request people who are
randomizing their MAC addresses to associate to? Or should we just
choose one of the ietf-* (or eduroam) networks as our needs dictate?
Are you doing anything special for those using locally-administered
MAC addresses (like shorter DHCP lease times) and if so are you keying
off the local bit or do you need some fixed 0th octet?

  Dan.

On 3/19/15 2:03 PM, "Chris Elliott" <chelliot@pobox.com<mailto:chelliot@pobox.com>> wrote:



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<mailto: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<mailto:chelliot@pobox.com>

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

Change history (8)

comment:1 Changed 3 years ago by chelliot@…

Owner: changed from llynch@… to chelliot@…
Status: newaccepted

comment:2 Changed 3 years ago by chelliot@…

Resolution: fixed
Status: acceptedclosed

Dan,

I probably should have addressed this as well, but this link clarifies that we have expanded the random MAC experiment to all IETF networks:

https://www.ietf.org/registration/MeetingWiki/wiki/ietf92#wifi_privacy_network_experiment_at_ietf92

We are both giving out shorter leases (which certain folks can argue whether it's needed or desired or not, but we, as administrators chose to do) and are using a separate IP pool on each network for those using MAC addresses with the local bit set.

Chris.

comment:3 Changed 3 years ago by stephen.farrell@…

Resolution: fixed
Status: closedreopened
Good stuff! 

You could publish a count of how many conflicting/dumb suggestions you get on each topical topic. Might be fun:-) 

Thanks for doing this,
S.


On Thu Mar 19 21:03:19 2015 GMT, Chris Elliott wrote:
> 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
>

comment:4 Changed 3 years ago by jim@…

Resolution: fixed
Status: reopenedclosed

Thanks Stephen! If we get enough, we'll add it to the NOC report ;-)

  • Jim

comment:5 Changed 3 years ago by bortzmeyer@…

Resolution: fixed
Status: closedreopened
On Thu, Mar 19, 2015 at 04:03:19PM -0500,
 Chris Elliott <chelliot@pobox.com> wrote 
 a message of 585 lines which said:

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

In the Continental room, I cannot even see the SSID "ietf". I tried
wit two machines (a Fairphone smartphone, running Android, and a
laptop Dell PC with Ubuntu). Both see "ietf-hotel", "ietf-legacy" and
"ietf-2.4only". I can connect to all them (including the encrypted
"ietf-2.4only") but I don't see "ietf" in the list.

comment:6 Changed 3 years ago by chelliot@…

Stephane,

It sounds like your laptop has a 2.4Ghz-only wireless card. If so, this is
expected--those are the SSIDs you will be able to use.

If your wireless card is capable of 5Ghz then please ensure that you have
that band enabled on your card. If you continue to have problems please
feel free to come by the help desk when it's open, or the NOC (Fountain
room) if you need help before it opens.

Chris.

On Sun, Mar 22, 2015 at 12:10 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr>
wrote:

> On Thu, Mar 19, 2015 at 04:03:19PM -0500,
>  Chris Elliott <chelliot@pobox.com> wrote
>  a message of 585 lines which said:
>
> > 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).
>
> In the Continental room, I cannot even see the SSID "ietf". I tried
> wit two machines (a Fairphone smartphone, running Android, and a
> laptop Dell PC with Ubuntu). Both see "ietf-hotel", "ietf-legacy" and
> "ietf-2.4only". I can connect to all them (including the encrypted
> "ietf-2.4only") but I don't see "ietf" in the list.
>



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

comment:7 Changed 3 years ago by chelliot@…

Resolution: fixed
Status: reopenedclosed

comment:8 Changed 5 weeks ago by Rick Alfvin

Milestone: ietf-92ietf-092

Milestone renamed

Note: See TracTickets for help on using tickets.