[78all] Admission Control to the IETF 78 and IETF 79 Networks

IETF Chair <chair@ietf.org> Wed, 30 June 2010 21:55 UTC

Return-Path: <chair@ietf.org>
X-Original-To: 78all@core3.amsl.com
Delivered-To: 78all@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7590C3A693E; Wed, 30 Jun 2010 14:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.999
X-Spam-Level:
X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAM1ZS53Ga+9; Wed, 30 Jun 2010 14:55:18 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 9442D3A659C; Wed, 30 Jun 2010 14:55:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 26670E08C8; Wed, 30 Jun 2010 14:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBcSC7Mo0DYo; Wed, 30 Jun 2010 14:55:27 -0700 (PDT)
Received: from [192.168.2.108] (pool-96-241-163-123.washdc.fios.verizon.net [96.241.163.123]) by c1a.amsl.com (Postfix) with ESMTPSA id 79DF5E0885; Wed, 30 Jun 2010 14:55:26 -0700 (PDT)
Message-ID: <4C2BBD51.2060605@ietf.org>
Date: Wed, 30 Jun 2010 17:55:29 -0400
From: IETF Chair <chair@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: IETF Announce <ietf-announce@ietf.org>
References: <CFB08C07-DE90-47BE-ADFF-FC72162BBFA1@daedelus.com>
In-Reply-To: <CFB08C07-DE90-47BE-ADFF-FC72162BBFA1@daedelus.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 78all@ietf.org, IETF <ietf@ietf.org>, IESG <iesg@ietf.org>
Subject: [78all] Admission Control to the IETF 78 and IETF 79 Networks
X-BeenThere: 78all@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <78all.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/78all>, <mailto:78all-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/78all>
List-Post: <mailto:78all@ietf.org>
List-Help: <mailto:78all-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/78all>, <mailto:78all-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2010 21:55:20 -0000

I am writing to let you know about a change in the IETF meeting network.
At IETF 79 in Beijing, the IETF network will be connected to the open
Internet with absolutely no filtering.  However, we have agreed with our
hosts that only IETF meeting participants will have access to the
network.  Following sound engineering practices, we will deploy
admission control mechanisms as part of the IETF 78 meeting network in
Maastricht to ensure that they are working properly before they are
mission critical.

I am writing to let you know what to expect in both Maastricht and Beijing.


ADMISSION CONTROL CREDENTIALS

To gain access to the IETF network, you will need to provide a
credential. Your primary credential will be your registration ID.  You
can find your registration ID on the registration web page, in the
response email confirmation you received from the Secretariat, on your
payment receipt, and on the back of your IETF meeting badge.  Your
Registration ID will be your user name, and it will be used with a
password that will be provided at a later date.  This same password will
be used by all attendees.

We recognize that IETF 78 registration IDs are very easy to guess.  We
expect to use less easily guessed registration IDs for IETF 79.

If for any reason you are uncomfortable using your Registration ID,
there will be a supply of completely anonymous Registration ID/Password
pairs on slips of paper available at the help desk and registration
desk.  You will be asked to show an IETF meeting badge to ensure that
slips are only provided to registered meeting attendees.

Each set of credentials will allow up to three separate MAC addresses on
the network, allowing attendees to use the same credential for their
laptop, phone, or other devices.  The limit is to prevent the leak of a
single credential from undermining the entire system.


GAINING ACCESS TO THE NETWORK

The primary mechanism to gain access to the wireless network will be
either the "ietf.1x" or "ietf-a.1x" SSID.  These will be configured with
WPA1 and WPA2 Enterprise.  You simply provide your credentials to your
supplicant software for authentication to the network.  I personally
encourage you to use WPA2 over WPA1 if your software and hardware
support both.

If your software does not support WPA Enterprise, you can use the
captive portal.  To use this portal, associate with either the
"ietf-portal" or "ietf-a-portal" SSID.  Upon initial connection,
Internet connectivity will be blocked.  Simply open a browser and go to
any web site, just like many hotel networks, and you will be redirected
to a portal page where you can enter your credentials.  Once the
credentials are validated, your MAC address will have unrestricted
access to the network for some period of time.  The portal page will
also have links to the internal wiki page with helpful information as
well as a way to create trouble tickets prior to authentication.

If your small devices does not support WPA Enterprise and does not have
a browser, then you will be able to visit the help desk and register the
device MAC address for access to the network.  If you need to register
your device, please know the MAC address of your device before you show
up at the help desk.


FALLBACK PLAN

Implementing this plan at IETF 78 in Maastricht is important, but
obviously not without risk.  The IEEE 802.1X-based access mechanisms
have been well tested at previous meetings, and this mechanism is not
likely to be a source of trouble.  The captive portal, however, is a
greater unknown.  Please use the WPA SSIDs if at all possible to reduce
the load on the portal machines.  If the portals do experience problems,
the NOC team will implement a backup plan.  The backup plan will only be
used as a last resort as the backup plan will not be an option at IETF
79 in Beijing.


Safe Travel and Best Wishes,
  Russ Housley
  IETF Chair