IETF Logo Mail Archive

[secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router

"Scott G. Kelly" <scott@hyperthought.com> Sun, 25 July 2010 12:24 UTC

Return-Path: <scott@hyperthought.com>
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 A5EC03A6912 for <secdir@core3.amsl.com>; Sun, 25 Jul 2010 05:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 WvsmTlww5k0B for <secdir@core3.amsl.com>; Sun, 25 Jul 2010 05:24:13 -0700 (PDT)
Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by core3.amsl.com (Postfix) with ESMTP id AB1493A6847 for <secdir@ietf.org>; Sun, 25 Jul 2010 05:24:13 -0700 (PDT)
Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A7B0A1B4212; Sun, 25 Jul 2010 08:24:33 -0400 (EDT)
Received: from dynamic9.wm-web.iad.mlsrvr.com (dynamic9.wm-web.iad.mlsrvr.com [192.168.2.216]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A03D21B40AA; Sun, 25 Jul 2010 08:24:33 -0400 (EDT)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic9.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 917D3320088; Sun, 25 Jul 2010 08:24:33 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sun, 25 Jul 2010 05:24:33 -0700 (PDT)
Date: Sun, 25 Jul 2010 05:24:33 -0700
From: "Scott G. Kelly" <scott@hyperthought.com>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1280060673.59399192@192.168.2.231>
X-Mailer: webmail8
Subject: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router
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: Sun, 25 Jul 2010 12:24:14 -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.

As the title implies, this document discusses basic requirements for IPv6 customer edge routers. The comments given here are limited to security only.

The security considerations section begins with a paragraph stating that basic stateless egress and ingress filters should be supported (lowercase "should"), and goes on to say that the CE router should offer mechanisms to filter traffic entering the customer network, but that how these are implemented is out of scope (lowercase "should"). Then, it has the following statements:

   Security requirements:

   S-1:  The IPv6 CE router SHOULD support
         [I-D.ietf-v6ops-cpe-simple-security].

   S-2:  The IPv6 CE router MUST support ingress filtering in accordance
         with [RFC2827] (BCP 38)

When I first read this, I thought the statements in the first paragraph were somewhat weak and imprecise, as they don't use RFC2119 language. When I read draft-ietf-v6ops-cpe-simple-security-12.txt, I thought that document gives a relatively thorough treatment of security considerations, but I'm not sure what it means to say "The IPv6 CE router SHOULD support" it. 

What does this mean? Since the referenced ID only makes recommendations (and explicitly states the RFC2119 language is not binding) what does it mean to "support" it? Must a device implement all recommendations? Must it implement only certain ones? 

I think it makes sense to reference the simple security document rather than re-writing significant sections of it here, but I also think that this statement of security requirements should be considerably more precise.

--Scott

v2.23.0 | Report a Bug | By Email