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

Derek Atkins <derek@ihtfp.com> Fri, 28 November 2008 20:03 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 4718D3A69E9; Fri, 28 Nov 2008 12:03:13 -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 CBDB73A683D; Fri, 28 Nov 2008 12:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611]
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 enDzsdegElLx; Fri, 28 Nov 2008 12:03:12 -0800 (PST)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id EC0903A67C1; Fri, 28 Nov 2008 12:03:11 -0800 (PST)
Received: from pgpdev.ihtfp.org (c-76-109-66-143.hsd1.fl.comcast.net [76.109.66.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 8C0FC8B4005; Fri, 28 Nov 2008 15:03:07 -0500 (EST)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id mASK3xjj026934; Fri, 28 Nov 2008 15:03:59 -0500
To: iesg@ietf.org, secdir@ietf.org
From: Derek Atkins <derek@ihtfp.com>
Date: Fri, 28 Nov 2008 15:03:57 -0500
Message-ID: <sjm1vwvwrbm.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Cc: 6man-chairs@tools.ietf.org, suresh.krishnan@ericsson.com
Subject: [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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

While this document itself does not have any security issues (it's
just creating a registry with IANA) it brings up some interesting
points.  First, what methods should IANA use to "authenticate and
authorize" entities to create or update changes to the registry?  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?

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir