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

[Fred Baker <[e-mail]>]

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?

On Aug 11, 2010, at 4:26 AM, Ole Troan wrote:

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

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