[secdir] secdir review of draft-iana-ipv4-examples-01

Barry Leiba <barryleiba.mailing.lists@gmail.com> Tue, 08 September 2009 15:59 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 3684428C18A; Tue, 8 Sep 2009 08:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id kUGuWlivBiFT; Tue, 8 Sep 2009 08:59:50 -0700 (PDT)
Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com []) by core3.amsl.com (Postfix) with ESMTP id 1C2EC28C179; Tue, 8 Sep 2009 08:59:50 -0700 (PDT)
Received: by yxe37 with SMTP id 37so1182868yxe.5 for <multiple recipients>; Tue, 08 Sep 2009 09:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type; bh=W8m/t32zCvi62JCFgYaK5jRB3sTn5ZMBlYlWjnLnOIo=; b=Pmt4g2AtS5NsmRuwcgEIpnKbEr2UnjYL2N4ILVDfjy8XCwq8c5mth1GzCvIf2GVWa5 3PQhOhvnwI0uOg7pkx5PM5QoGjgg8NJoIZWGtLkWAiWmLrmEmPUbXg7yxcpui7FL3G6e mP5GH4DEDuxxflnz6qNy3qIdUnqwQrDsHDNa8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=v17FzBC7dl+oQjE+eqJv7jvwamdxmxu66vsuAbp4sCdAak3aByOBMCuOSc80LjdqDc I+8gSoapLQASaQ0DkPcKXbVUryvlVKyFzqUgvSXnxIXYkAUIx/udUM0jfscRcN0tT0fJ ERxrpZIb0x51KZQKcYOL9dK3RxqKEicA8G9Gc=
MIME-Version: 1.0
Received: by with SMTP id e14mr24957856ybg.149.1252425617647; Tue, 08 Sep 2009 09:00:17 -0700 (PDT)
Date: Tue, 08 Sep 2009 12:00:17 -0400
Message-ID: <6c9fcc2a0909080900h7db8d58n21564c56e16bc543@mail.gmail.com>
From: Barry Leiba <barryleiba.mailing.lists@gmail.com>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: draft-iana-ipv4-examples@tools.ietf.org
Subject: [secdir] secdir review of draft-iana-ipv4-examples-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: barryleiba@computer.org
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: Tue, 08 Sep 2009 15:59:51 -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 is just a short, informational document that reserved two new
address ranges for example use.  I have no significant issues with it.

I do have two minor questions:

1. The document does have normative language, telling operators what
they SHOULD and SHOULD NOT do with this addresses, and it instructs
IANA not to allocate addresses from these blocks.  Should it be BCP,
rather than Informational?  It doesn't matter terribly, so I'm just
asking the question.

2. The Security Considerations section says the document has no
security implications, but I'm not sure that's correct.  By calling
out certain addresses as examples, we might be inviting malefactors to
try to snag traffic meant for these addresses in an attempt to trick
those who use the example addresses as though they were real.  If the
advice in the Operational Implications section isn't followed, that
would result in an opportunity for fraud, for example.  I look at this
as an explanation of the importance of following the Operational
Implications advice.

Again, I consider this a minor point, and the document should
certainly go forward.