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

Ole Troan <ot@cisco.com> Mon, 02 August 2010 12:58 UTC

Return-Path: <ot@cisco.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 711C63A68B7; Mon, 2 Aug 2010 05:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 w-48KMPIp6M8; Mon, 2 Aug 2010 05:58:10 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 42FA53A67F5; Mon, 2 Aug 2010 05:58:10 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALddVkxAZnwM/2dsb2JhbACgDnGmIpp8gxCCKQSIfw
X-IronPort-AV: E=Sophos;i="4.55,302,1278288000"; d="scan'208";a="142274304"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2010 12:58:36 +0000
Received: from dhcp-osl-vl300-64-103-53-101.cisco.com (dhcp-osl-vl300-64-103-53-101.cisco.com [64.103.53.101]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o72CwZL0003670; Mon, 2 Aug 2010 12:58:35 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <ot@cisco.com>
X-Priority: 3 (Normal)
In-Reply-To: <1280060673.59399192@192.168.2.231>
Date: Mon, 02 Aug 2010 14:58:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF8B120C-DF37-452D-8AA5-0C96A6295B2F@cisco.com>
References: <1280060673.59399192@192.168.2.231>
To: "Scott G. Kelly" <scott@hyperthought.com>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Wed, 04 Aug 2010 04:08:54 -0700
Cc: draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Mon, 02 Aug 2010 12:58:11 -0000

Scott,

thank you very much for a thorough review!
some further comments inline.

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

we tried to limit RFC2119 language to only the numbered requirements. the initial paragraph is only to set the stage for the more detailed requirements below. basically just saying that the CPE should support a packet filtering capability. but from a security point of view I'm not sure if we can state this in very much more concrete terms?

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

the intention was to state the the CPE router should have the capability of doing the functions described in the simple security draft. but we did not want to make any recommendation what the default should be. I believe recommending that simple security is enabled by default in a CPE routers would violate the Internet architecture principles. would it help if we changed the text to:

S-1: The IPv6 CE router SHOULD support the [I-D.ietf-v6ops-cpe-simple-security]. This functionality MUST be user configurable and this
        specification makes no recommendation what the default setting should be.


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

while on the topic of security. we should perhaps have said something more about device security. as in requirements for access to the device itself. today many of these routers allow telnet and http access, more often than not with default password. where they also make a distinction between 'inside' and 'outside', which some recent attacks have taken advantage of.

does the security directorate have any other (and more detailed) recommendations they would have liked to see in this document?

cheers,
Ole