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

[Chris Donley <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, August 03, 2010 3:32 PM
To: Ole Troan
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: secdir review of draft-ietf-v6ops-ipv6-cpe-router

Hi Ole,

On Monday, August 2, 2010 5:58am, "Ole Troan" <[e-mail]> 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