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

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 3 Aug 2010 14:32:26 -0700 (PDT)

Hi Ole,

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 6 Aug 2010 11:50:42 -0700 (PDT)

Hi Chris,

I think your suggestions are reasonable.

--Scott

On Thursday, August 5, 2010 8:00am, "Chris Donley" <[email-masked]> 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:
> 
>          [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.
> 
> 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:[email-masked]]
> Sent: Tuesday, August 03, 2010 3:32 PM
> To: Ole Troan
> Cc: [email-masked]; [email-masked];
> [email-masked];
> [email-masked]
> Subject: Re: secdir review of draft-ietf-v6ops-ipv6-cpe-router
> 
> Hi Ole,
> 
> 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...>
> 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
> 
> 
> 
>

---

From: Chris Donley <[email-masked]>
Date: Thu, 5 Aug 2010 09:00:00 -0600

Scott,

If we were to make the following changes to the security section, would they address your concerns?

   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.

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

Hi Ole,

<trimmed...>

<more trimmed...>

--Scott

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Aug 2010 13:26:03 +0200

Scott et al,

I'm not entirely sure what the process here is.
do you want to see a new revision of the draft incorporating Scott's comments as well as the feedback we have received from the DHC WG review before we proceed to the IESG review?

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Aug 2010 08:32:28 -0700

Note from the document shepherd...

The process is that the IESG expects an updated draft in response to comments. However, they usually consider the draft for a while and then TELL you that they want it. It is on the telechat for approval Thursday, and per https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ has no "discuss" ballots and "enough positions to pass", which appears to be two "no objection" ballots.

Tell me: what is required to address Scott's comments? Is this a big change or a small one? If it is a small enough change, I would suggest that you address it, address Stewart's comment ("expand acronym MLD on first usage"), and pick up three idnits points that have crept in since the draft was last posted:

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: draft-ietf-6man-ipv6-subnet-model has been published
     as RFC 5942

  == Outdated reference: A later version (-05) exists of
     draft-ietf-6man-node-req-bis-04

  == Outdated reference: A later version (-12) exists of
     draft-ietf-v6ops-cpe-simple-security-11

And then post it and send a URL to the diffs to the IESG so they can see what you did. That would allow them to send it on tomorrow. If doing that in the next few hours isn't reasonable, then wait for the IESG remarks, which I would expect will sound a lot like what I just said but with a different date.

Ron, your thoughts?

>>> default. It might be worthwhile to update it according to your thoughts above.

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Aug 2010 09:30:03 -0700

Ack. Pick up the other two changes, which are minute, post it, and give the IESG the diffs URL. Thanks.

On Aug 11, 2010, at 9:02 AM, Ole Troan wrote:

> Fred,
> thanks for the clarification, the changes are in my opinion small.
> 
> the security considerations are limited to tightening up language and make it clear what we "expect" from the CPE simple security draft:
> 
>       <section title="Security Considerations">
>         <t>It is considered a best practice to filter obviously malicious
> -        IPv6 CE router should support basic stateless egress and ingress
> -        filters.  The CE router should also offer mechanisms to filter
> +        IPv6 CE router ought to support basic stateless egress and ingress
> +        filters.  The CE router is also expected to offer mechanisms to filter
>         vendors implement configurable packet filtering is beyond the scope of
>         this document.</t>
> 
>         <t>Security requirements:<list style='format S-%d:'>
> -            <t>The IPv6 CE router SHOULD support
> -            <xref target="I-D.ietf-v6ops-cpe-simple-security"></xref>.</t>
> +            <t>The IPv6 CE router SHOULD support <xref
> +            target="I-D.ietf-v6ops-cpe-simple-security"></xref>. In
> +            particular, the IPv6 CE router SHOULD support
> +            functionality sufficient for implementing the set of
> +            recommendations in <xref
> +            target="I-D.ietf-v6ops-cpe-simple-security"></xref>
> +            section 4. Ths document takes no position on whether such
> +            functionality is enabled by default or mechanisms by which
> +            users would configure it.</t>
> 
> in addition we have on the advice from the DHC WG removed the last part of this requirement:
>          <t>If the IPv6 CE router requests both an IA_NA and an IA_PD
>          in DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply
> -         messages, even if the message does not contain any addresses
> -         (IA_NA options with status code equal to NoAddrsAvail).</t>
> +         messages, even if the message does not contain any
> +         addresses.</t>
> 
> cheers,
> Ole
> 
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Aug 2010 18:02:50 +0200

Fred,

 

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Aug 2010 18:57:35 +0200

Fred,

> Ack. Pick up the other two changes, which are minute, post it, and give the IESG the diffs URL. Thanks.

thanks again. posted.
the diffs are at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-cpe-router-07.txt

(also the previously discussed L-16/W-6 changes are included.)

cheers,
Ole