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

["Scott G. Kelly" <[e-mail]>]

Hi Chris,

I think your suggestions are reasonable.

--Scott


On Thursday, August 5, 2010 8:00am, "Chris Donley" <[e-mail]> 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:[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
> 
> 
> 
>