Re: Hotel networks (Was Re: Security for the IETF wireless network)

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


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 <steve(_at_)shinkuro(_dot_)com
<mailto:steve(_at_)shinkuro(_dot_)com>> 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 <joelja(_at_)bogus(_dot_)com
    <mailto:joelja(_at_)bogus(_dot_)com>> wrote:

    On 7/25/14, 9:29 AM, John C Klensin wrote:

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


    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.

    best,
       john


    --On Friday, 25 July, 2014 08:09 -0400 Steve Crocker
    <steve(_at_)shinkuro(_dot_)com <mailto:steve(_at_)shinkuro(_dot_)com>> 
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.

    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.



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

0x8A39DC66.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature