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

Steve Crocker <steve@shinkuro.com> Fri, 25 July 2014 13:34 UTC

Return-Path: <steve@shinkuro.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 2D2EA1A02E0; Fri, 25 Jul 2014 06:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.773
X-Spam-Level:
X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
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 fCDUXvuPeCkA; Fri, 25 Jul 2014 06:34:27 -0700 (PDT)
Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 556DE1A02D2; Fri, 25 Jul 2014 06:34:27 -0700 (PDT)
Received: from dummy.name; Fri, 25 Jul 2014 13:34:27 +0000
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Hotel networks (Was Re: Security for the IETF wireless network)
From: Steve Crocker <steve@shinkuro.com>
In-Reply-To: <3708BC187C6387C727398CBB@JCK-EEE10>
Date: Fri, 25 Jul 2014 09:34:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC4F2987-3EC1-4FBE-8BE6-F166BD587EC3@shinkuro.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>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/A2xZjrwkW7dZnOqIKhIBAs7Tabs
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 13:34:28 -0000

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

On Jul 25, 2014, at 9:29 AM, John C Klensin <john-ietf@jck.com> 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).
> 
> best,
>    john
> 
> 
> --On Friday, 25 July, 2014 08:09 -0400 Steve Crocker
> <steve@shinkuro.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.
> 
> 
> 
>