Re: [secdir] SecDir review of draft-iana-special-ipv4-registry-01

Geoff Huston <gih@apnic.net> Sat, 06 June 2009 23:00 UTC

Return-Path: <gih@apnic.net>
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 687703A6969; Sat, 6 Jun 2009 16:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 10PshwIG4csB; Sat, 6 Jun 2009 16:00:02 -0700 (PDT)
Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id CD8DD3A6817; Sat, 6 Jun 2009 16:00:01 -0700 (PDT)
Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D4BF0110041; Sun, 7 Jun 2009 09:00:03 +1000 (EST)
Message-Id: <4C488261-A489-4B1F-899D-161EEA05DE49@apnic.net>
From: Geoff Huston <gih@apnic.net>
To: Yaron Sheffer <yaronf@checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898EBAA@il-ex01.ad.checkpoint.com>
Content-Type: text/plain; charset="WINDOWS-1252"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sun, 07 Jun 2009 09:00:01 +1000
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898EBAA@il-ex01.ad.checkpoint.com>
X-Mailer: Apple Mail (2.935.3)
X-Mailman-Approved-At: Sun, 07 Jun 2009 13:57:05 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-iana-special-ipv4-registry@tools.ietf.org" <draft-iana-special-ipv4-registry@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-iana-special-ipv4-registry-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/mail-archive/web/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>
X-List-Received-Date: Sat, 06 Jun 2009 23:00:03 -0000

Hi Yaron,

Thanks indeed for this review of the draft..

On 06/06/2009, at 9:30 PM, Yaron Sheffer wrote:

> 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.
>
> This document consists of a directive to IANA on creating and  
> managing an IPv4 Special Purpose Address registry. It took me some  
> time to realize this document is about all of two hundred fifty six  
> IP addresses. It sure seems to be a lot of effort for very few  
> addresses.

We have managed to drive ourselves into areas of confusion over  
addresses in the past over too great a level of informality in aspects  
of address administration and this is one more element of adding some  
guidance for IANA and the IETF in terms of the process of making  
address assignments through IANA for the purposes described in Section  
2 of this document. Without this direction IANA has no clear process  
that it must follow to make such assignments, and the results, if  
judged by what we've done in the past, are somewhat haphazard at best.


>
> General
>
> -        The document is missing a reference to [rfc3330bis] (which  
> should be Normative).


Yes, agreed, although I'm not sure of the Normative / Informative  
delineation in this case - but I'm sure that the rfc editor could  
provide the appropriate advice here.

> Does "[date]" refer to this document’s publication date?


yes

> -        The document is copied from RFC 4773, in places a bit too  
> verbatim. In particular it mentions "scoped, local, or private  
> contexts", which rarely apply to IPv4. Today even link-local IPv4  
> addresses are usually treated as error indications, unfortunately.

I would not agree with such a blanket assertion for IPv4. 192.88.99.1  
appears to be intended to operate as a scoped context address, for  
example.


>
> Security
>
> I would have been much happier with a Security Considerations  
> section that said there are no such considerations. The current text  
> includes:
>
> "This registry is intended to provide an authoritative source of  
> information regarding the currency and intended purpose of IPv4  
> Special Purpose address blocks that are designated from the IANA- 
> administered IPv4 Special Purpose address pool.  This is a small  
> step towards the creation of a comprehensive registry framework that  
> can be used as a trust point for commencing a chain of address  
> validation."
>
> I am not aware of specified mechanisms to securely allocate,  
> deallocate and query the ownership and status of IP addresses.  
> Perhaps it’s just my ignorance, but if any such mechanisms exist,  
> they should be referenced from the document. In the absence of such  
> security mechanisms, the above paragraph doesn’t make sense to me,  
> in particular when the scope current is just 256 addresses.

This is a cut and paste from RFC4773. There is a rich history of  
ambiguity over the details of many address allocations, and this  
document is part of an intention to clarify procedure and registry  
outcomes, and yes, such a registry is a potential anchor point for a  
more formal mechanism that could validate attestations relating to  
addresses and their use. However the technology is still the subject  
of study in the IETF in the SIDR WG in particular, and reference to  
any stable outcomes of that WG appear to be somewhat premature, nor  
would stalling the process of this document to await such outcomes  
serve any useful purpose as far as I am aware.

Thanks,

     Geoff