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

Russ Housley <housley@vigilsec.com> Thu, 01 July 2010 19:43 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 BF8D43A6A1B for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 12:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.426
X-Spam-Level:
X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 b9SAjAx6aFcy for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 12:43:12 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id E669D3A6A3B for <ietf@ietf.org>; Thu, 1 Jul 2010 12:43:10 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D6DC4F24043; Thu, 1 Jul 2010 15:44:06 -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 QiUXvQkTP8U5; Thu, 1 Jul 2010 15:43:14 -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 1BE12F24042; Thu, 1 Jul 2010 15:44:06 -0400 (EDT)
Message-ID: <4C2CEFDE.5070109@vigilsec.com>
Date: Thu, 01 Jul 2010 15:43:26 -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: "Richard L. Barnes" <rbarnes@bbn.com>
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> <4C2CE406.7090600@vigilsec.com> <AA10E4A4-BEEF-4564-B454-D93A963AA12F@bbn.com>
In-Reply-To: <AA10E4A4-BEEF-4564-B454-D93A963AA12F@bbn.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
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 19:43:18 -0000

Richard:

Yes, the slips obtained from the IETF registration desk and the network
help desk are anonymous.  You show your badge, and then you can pick one
or more slips from the container.  The people at the desk will not know
which registration ID you got.

We will use this same approach for IETF 78 and IETF 79.  However, I
reserve the right to make process improvements based on the lessons
learned at IETF 78.

Russ

On 7/1/2010 2:59 PM, Richard L. Barnes wrote:
> Russ,
> 
> Couple of quick questions:
> -- Are the anonymous IDs truly anonymous (show existence of badge [not
> necessarily name on badge] and get one) or are they tied to a user
> identity? -- Will users be allowed to request multiple anonymous IDs? --
> Will these policies be identical for both IETF 78 and IETF 79?
> 
> Thanks,
> --Richard
> 
> 
> On Jul 1, 2010, at 2:52 PM, Russ Housley wrote:
> 
>> 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
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
>