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

"Scott G. Kelly" <scott@hyperthought.com> Tue, 03 August 2010 21:32 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 EAE213A6B0A for <secdir@core3.amsl.com>; Tue, 3 Aug 2010 14:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.855
X-Spam-Level:
X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 5Y1dCAhCHKih for <secdir@core3.amsl.com>; Tue, 3 Aug 2010 14:31:59 -0700 (PDT)
Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by core3.amsl.com (Postfix) with ESMTP id B77203A6768 for <secdir@ietf.org>; Tue, 3 Aug 2010 14:31:57 -0700 (PDT)
Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8C80A1B425D; Tue, 3 Aug 2010 17:32:26 -0400 (EDT)
Received: from dynamic2.wm-web.iad.mlsrvr.com (dynamic2.wm-web.iad.mlsrvr.com [192.168.2.151]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 79D3F1B407A; Tue, 3 Aug 2010 17:32:26 -0400 (EDT)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic2.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 5DE0F28E8066; Tue, 3 Aug 2010 17:32:26 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 3 Aug 2010 14:32:26 -0700 (PDT)
Date: Tue, 3 Aug 2010 14:32:26 -0700 (PDT)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "Ole Troan" <ot@cisco.com>
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: <1280871146.382928184@192.168.2.231>
X-Mailer: webmail8
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: Tue, 03 Aug 2010 21:32:02 -0000

Hi Ole,

On Monday, August 2, 2010 5:58am, "Ole Troan" <ot@cisco.com>; said:

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

Okay, I guess it makes more sense when viewed as introductory text for the numbered requirements.

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

Since the referenced draft is informational and does not mandate any behavior (it only makes non-binding recommendations), I'm still confused about what it means to "support" it - it seems very difficult to pin down. Do you mean that these devices MUST provide knobs for all capabilities defined there, or just some of them (and if so, which ones)? 

Since both of these documents are informational, perhaps it doesn't matter, but it seems like we'd be doing the user community a better service if we took a definite position on baseline security requirements for these devices.

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

The simple security document does reference management applications (section 3.5), but only states that they should not be accessible on the WAN interface by default. It might be worthwhile to update it according to your thoughts above. 

--Scott