Re: [secdir] sec-dir review of draft-ietf-6man-reserved-iids-01

Jari Arkko <jari.arkko@piuha.net> Mon, 01 December 2008 21:54 UTC

Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DBE28C134; Mon, 1 Dec 2008 13:54:33 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535E128C11D; Mon, 1 Dec 2008 13:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
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 nM5OBpDUdAcR; Mon, 1 Dec 2008 13:54:32 -0800 (PST)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 78E7528C0E4; Mon, 1 Dec 2008 13:54:32 -0800 (PST)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 5866E19876B; Mon, 1 Dec 2008 23:54:28 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id EAE91198639; Mon, 1 Dec 2008 23:54:27 +0200 (EET)
Message-ID: <49345D00.7010006@piuha.net>
Date: Mon, 01 Dec 2008 23:54:08 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: Derek Atkins <derek@ihtfp.com>
References: <sjm1vwvwrbm.fsf@pgpdev.ihtfp.org>
In-Reply-To: <sjm1vwvwrbm.fsf@pgpdev.ihtfp.org>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: 6man-chairs@tools.ietf.org, iesg@ietf.org, suresh.krishnan@ericsson.com, secdir@ietf.org
Subject: Re: [secdir] sec-dir review of draft-ietf-6man-reserved-iids-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Thanks for your review, Derek. A couple of responses:

> First, what methods should IANA use to "authenticate and
> authorize" entities to create or update changes to the registry?

This is standard IANA practice, just like with any other registry. They 
operate based on RFC 5226 and registry-specific RFCs, and if there's 
ever a problem (such as no rule for a particular registry), they contact 
the IESG.

> But
> more importantly, what's to stop a rogue system from declaring itself
> to use one of the reserved addresses?  And what happens to the network
> as a whole if a system does this?
>   
Good question. I think Bob already answered this.

Jari

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir