Subject: Re: Security for the IETF wireless network

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2014 08:58:01 +1200

Well, since you had a reply-to to this unmoderated list :-)...

This is what I get (Windows 7):

Radius Server:           services.meeting.ietf.org
Root CA:                 Starfield Class 2 Certification Authority

The server "services.meeting.ietf.org" presented a valid certificate issued by "Starfield Class 2 Certification Authority", but
"Starfield Class 2 Certification Authority" is not configured as a valid trust anchor for this profile. Further, the server
"services.meeting.ietf.org" is not configured as a valid NPS server to connect to for this profile.

Regards
   Brian

On 25/07/2014 08:38, IETF Chair 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)
> 
>

---

From: "George, Wes" <[email-masked]>
Date: Fri, 25 Jul 2014 07:45:40 -0400

Important bit from the NOC's network instructions:

To use 802.1X:

Associate to SSID: ietf.1x OR ietf-a.1x
Use TTLS or PEAP/MSCHAPv2
Do Not Verify Server Cert and we won't verify yours :)
^^^^^^^^^^^^^^^^^^^^^^^^^

Thanks,

Wes

On 7/24/14, 4:58 PM, "Brian E Carpenter" <[email-masked]>
wrote:

>The server "services.meeting.ietf.org" presented a valid certificate
>issued by "Starfield Class 2 Certification Authority", but
>"Starfield Class 2 Certification Authority" is not configured as a valid
>trust anchor for this profile. Further, the server

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.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 25 Jul 2014 07:59:09 -0400

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" <[email-masked]> 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

---

From: Steve Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 08:09:03 -0400

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

---

From: joel jaeggli <[email-masked]>
Date: Fri, 25 Jul 2014 08:30:28 -0400

> an ethernet plug, but many now don't.

If you have the luxury of a wired port, deploying your own ap will
probably get you more deterministic service, and a secure air interface.
prefix delegatation is probably  something we need to do.

The amount of control we have over the hotels infrastruture varies, this
time it's a meru controller and we were able to change the ssid and get
it to bridge ipv6 which are both tiny miracles.

> that'd be a great improvement over what we have currently.

We end up providing network service to the rest of hotel during the
meeting so it also needs to work as expected for the rest of the guests.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 25 Jul 2014 05:36:41 -0700

At 4:38 PM -0400 7/24/14, IETF Chair wrote:

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

I'm not sure where to mention this; I used to use these 
preferentially, but the past two or so years have been unable to ever 
connect using either.  I can associate and authenticate, or so my 
machine tells me, but it never obtains an IP address or router 
information.  This is on an "early 2011" MacBook Pro running 10.6.8. 
I figured it was some quirk of my machine and switched to 'ietf'.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It Is Better To Have LOCKed and Lost than Never To Have LOCKed at All

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 25 Jul 2014 08:53:39 -0400

> it to bridge ipv6 which are both tiny miracles.

I have been carrying some type of access point in my luggage for the 
last decade. Currently it's an AirPort Express, but someone posted this 
earlier in the week and I was immediately intrigued:

http://www.ebay.com/itm/171085144197?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649

tim

---

From: Randy Bush <[email-masked]>
Date: Fri, 25 Jul 2014 09:04:57 -0400

> I figured it was some quirk of my machine and switched to 'ietf'.

please go, with your laptop, to noc

randy

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Jul 2014 15:10:48 +0200

Hi,

> "services.meeting.ietf.org" is not configured as a valid NPS server to connect to for this profile.

Sure. That's because you should never "just connect" to a IEEE 802.1X
network. You configure the security properties you expect *first* (i.e.
install/mark as trusted the CA, the expected server name, the EAP types
that are supposed to be supported on this network, an anonymous outer
identity if you like/need) - and *then* you actually connect, and see if
the server you arrived at is the one you expect.

This is a wholly different security model that website-certificate-TLS.

I've been in touch with the NOC earlier about this. The IETF network
website really needs to *publish* these expected security details, then
you need to *configure* them - and only then is the network secure, and
guaranteed to be the genuine IETF one.

There are also tools which generate installation programs for these
security properties so that unsuspecting users don't have to know or
realise what this "CA" thing is in the first place.

I run a website which does these things; and am perfectly fine with
handing out installers with digital signatures for the IETF network use.

If you're curious hop over to https://802.1x-config.org (and
particularly the "Take the tour" for explanations:
https://802.1x-config.org/tour1.php

Thanks for listening to this slightly ad-laden mail. :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Jul 2014 15:11:37 +0200

Hi,

> Do Not Verify Server Cert and we won't verify yours :)

I recall some email threads with the NOC about this sentence. It's IMHO
not a message the IETF should promote.

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 09:29:33 -0400

Steve,

I completely agree with your comment and suggestions (including
at least knowing hotel network capabilities in advance of
arrival), but note that at least some of the reason while the
hotel networks perform so badly under IETF meeting load is that
many of them are seriously underprovisioned at multiple points.
If the meetings team were to perform simple tests (that we
helped design) based on the number of people in that team, they
would be likely to get good information about capability
limitations (e.g., ports and options) but would be unlikely to
get sufficient information about performance under serious load.
Clearly, we could figure out how to run a load test, but I
assume it would take a lot of cooperation from the hotel (or
several hundred of us occupying rooms).

best,
    john

--On Friday, 25 July, 2014 08:09 -0400 Steve Crocker
<[email-masked]> wrote:

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

---

From: Steve Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 09:34:27 -0400

Yes, stress testing the capacity of the hotel network is different from testing the functionality.  I suspect there are ways of doing this that don’t require occupying several hundred rooms.  But there’s no need to solve all problems at once.  If the IETF develops a regime for testing the functionality of the hotel networks and reporting the results in an organized fashion, I imagine there will be iterative improvements in the process over time, including clever ways of estimating the capacity.

Steve

---

From: joel jaeggli <[email-masked]>
Date: Fri, 25 Jul 2014 09:40:18 -0400

> several hundred of us occupying rooms).

so,

We've taken the hotel's captive portal / nat platform /internet service
out of the path for the residential network for the week. We do this
where possible, and in cases where we cannot this is typically noted.

While wifi coverage, lre/dsl and internal topology are out of our
control, the hotel network is being served by the the IETF network and
has no restrictions respecting authentication, ports available,
middleboxes and so forth. There is nothing especially interesting to
report there.

---

From: Steve Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 09:43:48 -0400

I’m not at this IETF meeting and I’m not referring to the current hotel network.  In the past, I’ve encountered all sorts of restrictions and limitations.  Also, there is often a big difference between the main hotel and the others.  In Maastricht, for example, I stayed at what was apparently a dorm hotel and I could not get access to nonstandard ports, e.g. for SSL protected access to my email.

Steve

---

From: George Michaelson <[email-masked]>
Date: Fri, 25 Jul 2014 09:57:32 -0400

I'd just like to say thanks to the NOC. I encountered no difficulties of
their making, and several things appeared to work better than before (tm)
which is always good.

I had the 1x as my pref from prior IETF and "it just worked".

OSX appears to have gone to a place where stop-start on wifi across
sleep/wake is a pain, but I cannot hold the noc responsible for that.
Contrariwise, I arrived 2 DAYS before the kick off of 'real' IETF and I had
IETF backed net almost immediately.

Well done. Thanks.

-G

On Fri, Jul 25, 2014 at 9:43 AM, Steve Crocker <[email-masked]> wrote:

> I’m not at this IETF meeting and I’m not referring to the current hotel
> network.  In the past, I’ve encountered all sorts of restrictions and
> limitations.  Also, there is often a big difference between the main hotel
> and the others.  In Maastricht, for example, I stayed at what was
> apparently a dorm hotel and I could not get access to nonstandard ports,
> e.g. for SSL protected access to my email.
>
> Steve
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 10:04:19 -0400

--On Friday, 25 July, 2014 09:40 -0400 joel jaeggli
<[email-masked]> wrote:

>...
> so,
> 
> We've taken the hotel's captive portal / nat platform
> /internet service out of the path for the residential network
> for the week. We do this where possible, and in cases where we
> cannot this is typically noted.
> 
> While wifi coverage, lre/dsl and internal topology are out of
> our control, the hotel network is being served by the the IETF
> network and has no restrictions respecting authentication,
> ports available, middleboxes and so forth. There is nothing
> especially interesting to report there.

Joel,

To be clear, I haven't complained about IETF hotel network
performance in years.  That has required some downward
adjustment of expectations but, when I get the sort of
performance I would expect in a well-served industrial facility
or university I'm just pleasantly surprised.  Things have gotten
considerably better since you folks started the practice of
replacing the hotel's external connections with IETF ones, but,
as you note, you have no control over hotel infrastructure and
that has occasionally been pretty bad.

Again, I'm not sure that is worth complaining about. 

On the other hand, it might be worth running some tests on the
capabilities in Steve's note, probably less to figure out where
to go (an equation that I suspect is too complex already) than
to give people early warning about things they may not be able
to do from their rooms and to know when it is extra-important
that terminal rooms and other meeting facilities don't depend on
hotel infrastructure (which I gather you almost always do
anyway).

I think the world would be a better place (and not just for IETF
meetings) if hotels disclosed what they actually were providing
when they advertise "Internet service".  But, having seen about
zero attention paid to our efforts in that direction almost ten
years ago (trying to specify what the words should mean) go
exactly nowhere and having a major ISP respond to complaints
that a service advertised as "up to 5 Mbps" was delivering under
800 kpbs with "speeds not guaranteed", I'm pretty pessimistic
about near-term progress in that area.  

If the IETF could do something about it, I don't know what it
would be.  I suppose we could publish post-meeting performance
and capability information on the hotels we use (including
before and during the switch to our external connections), but
that might make some otherwise reasonable hotel choices decide
they don't really want us.   On the other hand, some of us
could, as individuals, approach some popular travel rating sites
and encourage them to create a much more sophisticated category/
report for Internet connectivity than "yes" or "no" and start
reporting what we find when we travel.

best,
   john

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Jul 2014 16:10:27 +0200

Hi,

> I had the 1x as my pref from prior IETF and "it just worked".

Did you ever verify the server cert?

Assuming you didn't (because NOC doesn't tell us what to expect), how do
you know you connected to the IETF network, and not some evil twin who
is able to spell "ietf-1x" correctly in his AP config dialog?

Greetings,

Stefan Winter

> Contrariwise, I arrived 2 DAYS before the kick off of 'real' IETF and I
> had IETF backed net almost immediately.
> 
> Well done. Thanks.
> 
> -G
> 
> 
> 
> 
> On Fri, Jul 25, 2014 at 9:43 AM, Steve Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I’m not at this IETF meeting and I’m not referring to the current
>     hotel network.  In the past, I’ve encountered all sorts of
>     restrictions and limitations.  Also, there is often a big difference
>     between the main hotel and the others.  In Maastricht, for example,
>     I stayed at what was apparently a dorm hotel and I could not get
>     access to nonstandard ports, e.g. for SSL protected access to my email.
> 
>     Steve
> 
>     On Jul 25, 2014, at 9:40 AM, joel jaeggli <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>

Tel: +352 424409 1
Fax: +352 422473

---

From: Bill Fenner <[email-masked]>
Date: Fri, 25 Jul 2014 10:12:34 -0400

> not a message the IETF should promote.

I believe there's a reasonable amount of support for opportunistic
encryption in the IETF.

The desired incremental delta between the "ietf" open SSID and the
"ietf.1x" encrypted SSID is the addition of encryption.  The additional
validation of "is this really the IETF" has been a non-goal.

It's appropriate for organizations with different goals to have different
policies.

  Bill

---

From: George Michaelson <[email-masked]>
Date: Fri, 25 Jul 2014 10:18:26 -0400

lets put the keyhash in a low rate bitstream and add it into GPS and Glonas
packets. If we write the code, then we can extract it at one bit per minute
or something, and every phone in the western hemisphere with Android or iOS
will have the pubkey.

anything else is just quiche.

or, we could ritually all incant the keyhash in plenary at the mike, for
the next meeting. That leaves newbies exposed to a +1 risk unti they come
to another IETF.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Jul 2014 16:21:51 +0200

Hi,

> It's appropriate for organizations with different goals to have
> different policies.

Sure. Adding the authentication is not difficult though if you already
went through the pain of a RADIUS server setup. Basically, a few lines
of HTML description of the network give you all the extra goodness.

IOW, the incremental delta between doing 1X poorly and doing 1X
correctly is small. So why not?

Those who only want encryption can continue to ignore the cert.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jul 2014 02:23:54 +1200

> validation of "is this really the IETF" has been a non-goal.

Fair enough. But that doesn't change the fact that my box doesn't
work that way by default and apparently I have to find out how
to override it. Being human, I reverted to the unencrypted network
instead.

    Brian

---

From: Bill Fenner <[email-masked]>
Date: Fri, 25 Jul 2014 10:30:17 -0400

> of HTML description of the network give you all the extra goodness.

Meaning, you'd be happy if we replace "Do not validate server cert" with
"If you'd like to validate the server cert, you can import the public key
<a href="...">here</a>, or the fingerprint is 53 63 6f 6f 62 79 20 44 6f 6f
62 79 20 44 6f 6f 21"?

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Fri, 25 Jul 2014 10:36:29 -0400

On Fri, Jul 25, 2014 at 10:23 AM, Brian E Carpenter <
[email-masked]> wrote:

> > On Fri, Jul 25, 2014 at 9:11 AM, Stefan Winter <[email-masked]
> >
> > wrote:
> >
> >> Hi,
> >>
> >>> To use 802.1X:
> >>>
> Sorry, I assumed that this was just an annoying dialog and there was a
checkbox for "do it anyway".  We will have to find a way to manage the
usability on Windows, whether that means "buy a cert from someone who is in
Microsoft's default trust list too" or "provide instructions for Windows
users" or what.

  Bill

---

From: "John Levine" <[email-masked]>
Date: 25 Jul 2014 15:05:06 -0000

>the next meeting. That leaves newbies exposed to a +1 risk unti they come

Just put it in the Note Well.

R's,
John

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Jul 2014 17:32:20 +0200

Hi,

> usability on Windows, whether that means "buy a cert from someone who
> is in Microsoft's default trust list too" or "provide instructions for
> Windows users" or what.
>

A common misunderstanding. There *is no* default trust list for IEEE
802.1X purposes. Even on Microsoft, you have to tick the checkbox on the
one CA you trust for this connection. Due to that, whether you paid for
a commercial CA's cert or just created a self-signed one doesn't matter;
self-signed simply adds the extra step of importing the CA in the first
place. Both need the user to TheRightThing(tm).

The instruction can be "use this .exe that we provide, it will push the
right knobs for you." That's why I mentioned my website which gives you
such installers.

Stefan

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Jul 2014 17:39:25 +0200

Hi,

> Meaning, you'd be happy if we replace "Do not validate server
> cert" with "If you'd like to validate the server cert, you can import
> the public key <a href="...">here</a>, or the fingerprint is
> 53 63 6f 6f 62 79 20 44 6f 6f 62 79 20 44 6f 6f 21"?

Basically, yes. Client device UI typically offers two ways for cert
validation; ideally, you'd put both on the website.

a) if you just click/tap to connect (let's call it "ignorance mode ;-)
", all PKIX validation is ignored, UIs typically only present you with
the CN of the *server cert* and the fingerprint of the *server cert*. So
the IETF web site should publish name and fingerprint of the server cert
(on its HTTPS variant of course, to establish trust in this information
in the first place)

b) if you are a good user, you'd establish the PKIX CA root on your
client device. For that, the IETF web site should provide the *root CA*
certificate for download (plus its fingerprint for extra paranoia
checks), along with the expected *server CN*.

Since you provision the CA cert anyways, it doesn't matter if it's a
commercial CA or your own purpose-built one. If you want to roll your
own, eduroam folks have a huge load of instructions and considerations
which cert properties should be in that certificate. See here:
https://wiki.terena.org/display/H2eduroam/EAP+Server+Certificate+considerations

Of course you can add PDF instructions for Windows users how to import a
CA etc., and many networks do that. Or you make use of such automatic
installer tools which do the job on the user's device automatically. I
think I mentioned one already ;-) , and that I'm happy to give the
Enterprise edition of it away for free to the IETF network:
https://802.1x-config.org .
Greetings,

Stefan Winter

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 25 Jul 2014 12:28:29 -0400 (EDT)

> 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 

There are some commercial efforts appearing in this space, also.
http://www.hotelwifitest.com/ is a crowdsourced effort that addresses 
speed tests, but not port filtering tests.

I would love to see Netalyzer[1] reports from each of the IETF hotels, 
including overflow hotels, but that might require more effort or room 
nights than the site survey and advance teams normally allow for. 
Crowdsourcing might be the way to go.

-- Sam

[1] http://netalyzr.icsi.berkeley.edu/

---

From: Randall Gellens <[email-masked]>
Date: Fri, 25 Jul 2014 12:02:49 -0700

At 9:43 AM -0400 7/25/14, Steve Crocker wrote:

>  I'm not at this IETF meeting and I'm not referring to the current 
> hotel network.  In the past, I've encountered all sorts of 
> restrictions and limitations.  Also, there is often a big 
> difference between the main hotel and the others.  In Maastricht, 
> for example, I stayed at what was apparently a dorm hotel and I 
> could not get access to nonstandard ports, e.g. for SSL protected 
> access to my email.

I wish the IETF NOC could take over the networks of every hotel in 
every city we visit, but I don't expect them to be able to.

-------------- Randomly selected tag: ---------------
If your only hammer is C++, everything starts to look like a thumb.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 25 Jul 2014 12:24:51 -0700

>  is able to spell "ietf-1x" correctly in his AP config dialog?

Would connecting to this evil twin network be worse than connecting 
to the plain ietf network, perhaps also operated by an evil twin?

-------------- Randomly selected tag: ---------------
In my country, we believe (and rightly so) that mindless superstition
and meaningless ritual are what separate us from the animals.
                                            --'Latka Gravis' on _Taxi_

---

From: "Niels Dettenbach (Syndicat IT&Internet)" <[email-masked]>
Date: Fri, 25 Jul 2014 21:30:04 +0200

>every city we visit, but I don't expect them to be able to.

sorry for my noise, but this may shorten the discussion:

Why not simply buy some kind of prepaid SIM card in the target country for i.e. 5-10 EUR/USD incl. some kind of "starter volume"? I hardly assume that most of you have some kind of mobile 3.xG mobile terminal which is able to serve your personal area network (PAN) by wifi, bluetooth or cable for these days? Additionally there are meshes or hotspot initiatives who are open to guests for free in many larger towns.

Since i was in a canadian branch of Mar*** hotel who "transparently relayed" all SMTP and HTTP over their main location while blocking any TLS and SSL / SSH / VPN tunneling i know what i have to assume about such kind of "free hotel networks".

At least for typical  pro IP users who knows to "use" available  IP bandwidth this should be acceptable and a oeconomic alternative.

just my two cents,

Niels.
-- 
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com

---

From: Stefan Winter <[email-masked]>
Date: Sat, 26 Jul 2014 12:33:38 +0200

Hi,

> Would connecting to this evil twin network be worse than connecting to
> the plain ietf network, perhaps also operated by an evil twin?

Those two choices are equally bad indeed.

The point is that we can do much better, with a few simple steps. And
the IETF network has already gone 90% of the way by enabling 1X with
RADIUS server etc. At that point, *not* going the few last steps doesn't
make much sense.

You don't stop running a marathon one mile before the end, just because
"25 miles is pretty good, I don't need the rest". Or do you?

Thinking about it, maybe the 1X network evil twin is worse than a plain
open network even: when connecting to an open network, people (probably
and rightfully) don't assume any confidence in the network they connect
to. The 1X "enterprise security" label alone can easily make people
think that it is more secure against all kinds of attacks and be more
relaxed in their surfing/usage habits - while it's not, unless you take
all the right steps.

Greetings,

Stefan Winter

---

From: Randall Gellens <[email-masked]>
Date: Thu, 31 Jul 2014 21:45:50 -0700

>  reporting what we find when we travel.

I happened to see this today

"How to Check a Hotel's WiFi Speed Before Checking In"
http://www.frequentflier.com/blog/how-to-check-a-hotels-wifi-speed-before-checking-in/

Which reports that the site http://www.hotelwifitest.com makes speed 
tests and speed test results available:

"The results of user's speed tests are also combined with other 
users' input to create hotel WiFi profiles viewable on the Hotel Wifi 
Test webpage."

Seems like a step in the right direction.  Of course, speed during a 
few samples isn't the complete picture, but it's better than nothing. 
Perhaps IETFers can help the site measure other factors?

-------------- Randomly selected tag: ---------------
And still I persist in wondering if folly must always
be man's nemesis.                    --Edgar Pangborn

---

From: Randall Gellens <[email-masked]>
Date: Thu, 31 Jul 2014 21:49:35 -0700

At 9:45 PM -0700 7/31/14, Randall Gellens wrote:

>  Which reports that the site http://www.hotelwifitest.com makes 
> speed tests and speed test results available:
>
> users' input to create hotel WiFi profiles viewable on the Hotel 
> Wifi Test webpage."
>
>  Seems like a step in the right direction.  Of course, speed during 
> a few samples isn't the complete picture, but it's better than 
> nothing. Perhaps IETFers can help the site measure other factors?

By the way, the site reports that the Fairmont Royal York has an 
expected speed of 9.3 Mbps, a maximum of 18.5 Mbps, with a confidence 
of 17.5%.

-------------- Randomly selected tag: ---------------
Demagogue: One who preaches doctrines he knows to be untrue to men he
knows to be idiots.                                    --H.L. Mencken

---

From: Melinda Shore <[email-masked]>
Date: Thu, 31 Jul 2014 21:36:15 -0800

On 7/31/14 8:45 PM, Randall Gellens wrote:
> Seems like a step in the right direction.  Of course, speed during a few
> samples isn't the complete picture, but it's better than nothing.

I'm good with requiring hotels to have proper hot water kettles in
guest rooms.  That was excellent.

I'm a little surprised to hear that people are using that sort of
bandwidth at meetings.  I do think it would be useful to know what
sort of content filtering, etc (if any) hotels are doing on their
guest networks.

Melinda