Re: Admission Control to the IETF 78 and IETF 79 Networks

Russ Housley <housley@vigilsec.com> Thu, 01 July 2010 18:52 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F863A6A02 for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 11:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.402
X-Spam-Level:
X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, 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 j4I0hlimcSBL for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 11:52:41 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 4A6C43A6825 for <ietf@ietf.org>; Thu, 1 Jul 2010 11:52:41 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7E3AA9A4771 for <ietf@ietf.org>; Thu, 1 Jul 2010 14:53:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id vlub4G35J-pL for <ietf@ietf.org>; Thu, 1 Jul 2010 14:52:45 -0400 (EDT)
Received: from [192.168.2.108] (pool-96-241-163-123.washdc.fios.verizon.net [96.241.163.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 69CB69A473C for <ietf@ietf.org>; Thu, 1 Jul 2010 14:53:18 -0400 (EDT)
Message-ID: <4C2CE406.7090600@vigilsec.com>
Date: Thu, 01 Jul 2010 14:52:54 -0400
From: Russ Housley <housley@vigilsec.com>
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@ietf.org
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
References: <CFB08C07-DE90-47BE-ADFF-FC72162BBFA1@daedelus.com> <4C2BBD51.2060605@ietf.org> <6.2.5.6.2.20100701070804.0c26b8a0@resistor.net> <6D6E25E2-057B-4591-9288-1283036D0374@cisco.com> <20100701154421.GB43159@shinkuro.com>
In-Reply-To: <20100701154421.GB43159@shinkuro.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 01 Jul 2010 18:52:42 -0000

Andrew:

>> While it is new in IETF meetings, it is far from unusual in WiFi
>> networks to find some form of authentication. This happens at coffee
>> shops, college campuses, corporate campuses, and people's
>> apartments. 
> 
> I'd hate to think that the IETF is modelling its networks on dodgy
> semi-opaque NAT boxes with bad DNS habits and poor performance.  
> 
> That aside, I have some questions.  What are the plans for logging of
> the authentication requests, failures, and successes, and who could
> legally have access to those logs?  In particular, are the governments
> of the countries where the (respective) events are to be held able to
> require that the logs be turned over?  How long will the logs be kept,
> and by whom?  (Obviously, these are not new issues, but given the
> increased ability under this approach to associate a particular human
> with one or more MAC addresses, it would seem that the status of such
> logging might be more important.)

No matter where a meeting is held, we are subject to the laws of that
location.  Nothing new there.

The use of anonymous registration IDs is available to anyone that wants
to go that route.  Anyone concerned about the logs should use one.

The NOC Team sees no value in the logs after the meeting is over.  The
logs will be discarded by the NOC Team at the end of the meeting.  Of
course, during the meting they might be very hepful in debugging and such.

Russ