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

"Scott G. Kelly" <scott@hyperthought.com> Fri, 06 August 2010 18:50 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 378B33A6912 for <secdir@core3.amsl.com>; Fri, 6 Aug 2010 11:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level:
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 QbFTU-k7tgpH for <secdir@core3.amsl.com>; Fri, 6 Aug 2010 11:50:11 -0700 (PDT)
Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by core3.amsl.com (Postfix) with ESMTP id 5CB9A3A6898 for <secdir@ietf.org>; Fri, 6 Aug 2010 11:50:11 -0700 (PDT)
Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id DAFBE1B40CA; Fri, 6 Aug 2010 14:50:42 -0400 (EDT)
Received: from dynamic3.wm-web.iad.mlsrvr.com (dynamic3.wm-web.iad.mlsrvr.com [192.168.2.152]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id C67171B40D9; Fri, 6 Aug 2010 14:50:42 -0400 (EDT)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic3.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id B1FC5332006E; Fri, 6 Aug 2010 14:50:42 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 6 Aug 2010 11:50:42 -0700 (PDT)
Date: Fri, 6 Aug 2010 11:50:42 -0700 (PDT)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "Chris Donley" <C.Donley@cablelabs.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
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg>
References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg>
Message-ID: <1281120642.72688236@192.168.2.229>
X-Mailer: webmail8
Cc: "draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org" <draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org>, Ole Troan <ot@cisco.com>, "cpe-router@external.cisco.com" <cpe-router@external.cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@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: Fri, 06 Aug 2010 18:50:13 -0000

Hi Chris,

I think your suggestions are reasonable.

--Scott


On Thursday, August 5, 2010 8:00am, "Chris Donley" <C.Donley@cablelabs.com>; said:

> Scott,
> 
> If we were to make the following changes to the security section, would they
> address your concerns?
> 
> It is considered a best practice to filter obviously malicious
>    traffic (e.g. spoofed packets, "martian" addresses, etc.).  Thus, the
>    IPv6 CE router should ought to support basic stateless egress and ingress
>    filters.  The CE router should is also expected to offer mechanisms to filter
>    traffic entering the customer network; however, the method by which
>    vendors implement configurable packet filtering is beyond the scope
>    of this document.
> 
>    Security requirements:
> 
>    S-1:  The IPv6 CE router SHOULD support
>          [I-D.ietf-v6ops-cpe-simple-security]. In particular, the IPv6 CE router
> SHOULD support functionality sufficient for implementing the set of
> recommendations in [I-D.ietf-v6ops-cpe-simple-security] Section 4.  This
> document takes no position on whether such functionality is enabled by
> default or mechanisms by which users would configure it.
> 
>    S-2:  The IPv6 CE router MUST support ingress filtering in accordance
>          with [RFC2827] (BCP 38)
> 
> 
> Also, since we're so late in the process, my preference would be to specify device
> security as part of our Phase 2 draft (scheduled to start work on 8/13).  Would
> you have any issue with that?
> 
> Chris
> 
> -----Original Message-----
> From: Scott G. Kelly [mailto:scott@hyperthought.com]
> Sent: Tuesday, August 03, 2010 3:32 PM
> To: Ole Troan
> Cc: secdir@ietf.org; iesg@ietf.org;
> draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org;
> cpe-router@external.cisco.com
> Subject: Re: secdir review of draft-ietf-v6ops-ipv6-cpe-router
> 
> 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
> 
> 
> 
>