[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