If we’re going to discuss hotel networks, encryption of the channel is nice to have but there are more serious problems. o Many hotel networks restrict the ports that can be reached. This results in an absolute failure for some of us. o Many hotel networks do not support the full range of options for DNSSEC. o Many hotel networks have very poor bandwidth and become overloaded when the IETF comes to town. The meetings team does an excellent job of planning and running the meetings. They do extensive investigation of each proposed meeting site and they do a stellar job setting up and running the networks at each meeting. I wish they would also test the hotel networks in advance and report to all of us the limitations we’re likely to encounter. And, of course, it would be pretty easy for a volunteer group of IETFers to organize a reporting effort too. Steve On Jul 25, 2014, at 7:59 AM, George, Wes <wesley.george@xxxxxxxxxxx> wrote: > Jari, while I support this idea, if I had to prioritize, I'd rather us > focus on consistently offering *any* secured WiFi option in the hotel > rooms. > > Here at the Fairmont, for example: ietf-hotel is the only SSID available, > and it's not secure. Yes, one could use wired, assuming one's widget has > an ethernet plug, but many now don't. > > I realize that this request is often limited by the host hotel's > infrastructure, which may or may not support .1x, but even if the best we > can do is to offer WPA2 with "IETF", or "encryptionFTW" as the password, > that'd be a great improvement over what we have currently. > > Thanks, > > Wes > > > On 7/24/14, 4:38 PM, "IETF Chair" <chair@xxxxxxxx> wrote: > >> While many of us have been working on improved transport and other >> security mechanisms, I’d like to observe that the default wireless >> network we are using here in Toronto is unencrypted over the air. I am >> not sure how good practice that is. And it is probably not a good example >> either. >> >> Could we consider making 802.1X the default, for instance, starting in >> Honolulu meeting? At least in the sense of the ietf SSID providing >> security and perhaps ietf-nosec providing the current behaviour? >> >> It would also be helpful if you try it now. The two SSIDs, ietf.1x and >> ietf-a.1x are available now, we recommend you use them and we would >> appreciate your reporting any problems. The user ID and password are both >> 'ietf' (sans quotes). >> >> Jari Arkko >> IETF Chair >> (with input from some NOC people) >> > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.