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

Yaron Sheffer <yaronf@checkpoint.com> Sat, 06 June 2009 11:30 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id AAA893A659B; Sat, 6 Jun 2009 04:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q6AeJNb4gCCS; Sat, 6 Jun 2009 04:30:44 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com []) by core3.amsl.com (Postfix) with ESMTP id 7EBE23A6A8D; Sat, 6 Jun 2009 04:30:43 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2E81629C004; Sat, 6 Jun 2009 14:30:50 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com []) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B404429C001; Sat, 6 Jun 2009 14:30:49 +0300 (IDT)
X-CheckPoint: {4A2A51BA-0-14201DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost []) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n56BUi3d013688; Sat, 6 Jun 2009 14:30:45 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([]) by il-ex01.ad.checkpoint.com ([]) with mapi; Sat, 6 Jun 2009 14:30:45 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-iana-special-ipv4-registry@tools.ietf.org" <draft-iana-special-ipv4-registry@tools.ietf.org>
Date: Sat, 06 Jun 2009 14:30:41 +0300
Thread-Topic: SecDir review of draft-iana-special-ipv4-registry-01
Thread-Index: AcnmE208cUQsiY1ASkmgEeKSVSWSUwAg/Q8Q
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898EBAA@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_018D_01C9E6B3.5E9A6140"
MIME-Version: 1.0
Subject: [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 11:30:49 -0000

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.




-        The document is missing a reference to [rfc3330bis] (which should
be Normative). Does "[date]" refer to this document's publication date?

-        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 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.