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

John C Klensin <john-ietf@jck.com> Fri, 25 July 2014 14:05 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6ED1B295E; Fri, 25 Jul 2014 07:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja-XCpEJGZiW; Fri, 25 Jul 2014 07:05:11 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEB51A0299; Fri, 25 Jul 2014 07:04:25 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1XAg2H-000G3l-Lo; Fri, 25 Jul 2014 09:59:49 -0400
Date: Fri, 25 Jul 2014 10:04:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: joel jaeggli <joelja@bogus.com>, Steve Crocker <steve@shinkuro.com>, "George, Wes" <wesley.george@twcable.com>
Subject: Re: Hotel networks (Was Re: Security for the IETF wireless network)
Message-ID: <F4A7C1707FF74B85D3F921CC@JCK-EEE10>
In-Reply-To: <53D25E42.1010903@bogus.com>
References: <0FE63216-9BE8-450F-80FB-D1DB6166DFEF@ietf.org> <CFF7BBD1.28A2F%wesley.george@twcable.com> <8B1DA3E3-F195-4CBC-B565-85CAFC31CB1B@shinkuro.com> <3708BC187C6387C727398CBB@JCK-EEE10> <53D25E42.1010903@bogus.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/xIkCPKQOsjR5Xlt2kJoreVOHIlQ
Cc: IETF Chair <chair@ietf.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 14:05:16 -0000


--On Friday, 25 July, 2014 09:40 -0400 joel jaeggli
<joelja@bogus.com> 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