Subject: [OPSEC] Document advancement notice: draft-ietf-opsec-protect-control-plane.

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Sep 2010 13:56:18 -0400

Hello all,

Just a quick status update -- WG LC is closed for draft-ietf-opsec- 
protect-control-plane and it has been forwarded to the IESG.

It has just progressed to 'AD Evaluation' and you can follow its  
progress here: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20212&rfc_flag=0

Please join me in congratulating David, Carlos and Rodney for  
authoring this, and thanks to everyone for comments, feedback, review,  
etc.

Below is the Document Shepherd report (please note that I began  
preparing the report when starting WGLC, and forgot to bump the date  
before progressing it):

-------------------------------------------------------------------------------------
Document shepherd writeup for:

draft-ietf-opsec-protect-control-plane-03
http://tools.ietf.org/id/draft-ietf-opsec-protect-control-plane-03.txt

Prepared by:
Warren Kumari
9/06/2010

1.a
The Document Shepherd is Warren Kumari, Opsec WG co-chair. The  
Document Shepherd has reviewed Draft 03 of
draft-ietf-opsec-protect-control-plane and concluded that the document  
is prepared for IESG  review and publication as an
informational document.

1.b
This document has received substantial review within the working group  
and a large
amount of feedback was provided and incorporated. There was also  
review from non-WG
members. The Document Shepherd has no concerns about the depth or  
breadth of review.

1.c
The Document Shepherd does not believe that this document requires  
review from a particular
or broader perspective. The Document Shepard believes that the members  
of the WG that
reviewed the document have the required expertise, and that the  
methods described in the
document are well known and understood by the members of the WG.

1.d
The Document Shepard does not have any specific concerns or issues  
with this document
that the Responsible Area Director and/or the IESG should be aware of.
No IPR disclosures related to this document  have been filed.

1.e
Working Group consensus appears strong. The Working Group consists of  
a core
group who actively reviewed, commented on and provided input to the
document, and a large number of observers who remain silent.
The document was discussed during the IETF-77, IETF-78 meetings, and  
there was a
spirited debate with someone who hadn't read the draft, and later  
retracted his comments.
No dissenting feedback was received during WG last call.

1.f
No appeals or discontent are noted in the working group regarding the  
current draft at this time.

1.g
No nits found.

1.h.
There are only Informative references.

1.i
An IANA  Consideration section exists and is consistent with the body
of the document. The document has no IANA actions (and asks the RFC  
Editor
to remove said section).

1.j
The document contains no formal language. It does contain  
configuration samples that
have been checked.

1.k

Document Announcement Write-up

Summary:

This memo provides a method for protecting a router's control plane
from undesired or malicious traffic.  In this approach, all legitimate  
router
control plane traffic is identified and then a filter is deployed in  
the router's
forwarding plane. This filter prevents traffic not specifically  
identified as
legitimate from reaching the router's control plane or rate limiting it
to an acceptable level.

Working Group Summary
The document was accepted as a working group item on the mailing list
on 4/30/2010. Working Group last call was performed for two weeks,  
ending
on 9/15/2010, with no objections.

Document Quality
This document covers well understood and widely deployed methods
for protecting the control plane of network devices from attack. It  
contains example
configuration snippets for two vendors implementations.
It is part of a set of work undertaken by the WG to provide guidelines  
to operators
on how to secure their infrastructure from attack.

--------------------------------------------
W

---

From: Rodney Dunn <[email-masked]>
Date: Tue, 21 Sep 2010 15:45:40 -0400

Added in the list for others to see/comment if need be.

Rodney

On 9/20/10 2:22 PM, Rodney Dunn wrote:
> Specific responses inline...my overall take is that trying to break out
> a "management traffic" will create more confusion than it's worth as
> there are many levels of granularity and layering that can be applied.
>
> Rodney
>
>
>>
>> We did talk about this with Rodney some time ago and converged on what
>> you see in the doc, that the protection is about that: packets "for me"
>> from the router perspective.
>>
>
> "control plane" was viewed as common terminology for traffic that goes
> to the RP on devices. Management traffic is considered a subset of that
> and therefore was explicitly called out.
>
> "...The
> router control plane supports routing and management functions. It
> is generally described as router architecture hardware and software
> components for handling packets destined to the device itself as well
> as building and sending packets originated locally on the device."
>
> More inline at rd>
>
>
>> Rodney?
>>
>> Thanks,
>>
>> -- Carlos.
>>
>> -----Original Message-----
>> From: Smith, Donald [mailto:[email-masked]]
>> Sent: Thursday, September 16, 2010 5:11 PM
>> To: 'Warren Kumari'; 'Danny McPherson'
>> Cc: [email-masked]'; Carlos Pignataro (cpignata); 'Christopher
>> Morrow'
>> Subject: RE: [OPSEC] Document advancement
>> notice:draft-ietf-opsec-protect-control-plane.
>>
>> I missed this during my last review and we are past last call:(
>>
>>
>>> From the introduction:
>> "Modern router architecture design maintains a strict separation of
>> forwarding and routing control plane hardware and software. The
>> router control plane supports routing and management functions. It
>> is generally described as router architecture hardware and software
>> components for handling packets destined to the device itself as well
>> as building and sending packets originated locally on the device.
>> Forwarding plane is typically described as router architecture
>> hardware and software components responsible for taking a packet
>> coming in one interface, performing a lookup to identify the packet's
>> IP next hop and determine the outgoing interface towards the
>> destination, and forwarding the packet through the correct outgoing
>> interface."
>>
>> We seem to have put the management plane protection on the control
>> plane.
>> Normally those are considered to be different planes with the mgmt plane
>> protected by acls not copps.
>
> rd> The idea is that any traffic headed to the device that would
> potentially go to the RP be protected in a "layered" approach. I think
> as a WG we need to revisit the infrastructure ACL draft to compliment
> the COPP one. Specifically to the comment one might need to protect the
> control plane from management plane traffic overload of a specific class
> although we didn't go that granular in the example illustration.
>
>>
>> As I started thinking about this I think the cisco copps example that is
>> controlling the snmp and ssh access would allow access to those two
>> protocols from IP addresses not in the management network because the
>> allotherip is going to allow it correct?
>>
>
> rd> Yes. That is why we put the verbage encouraging the user to covert
> the rate limited permit all in the default class to a drop once the
> baselining and operation verfication are done.
>
>
>> Normally I would just configure an acl to block anything other then the
>> management ips but I am not sure that will work after the copps has
>> allowed it.
>>
>
> rd> They should still work as those features work in serial just like
> infrastructure ACL's applied directly on the interfaces.
>
>
>> So should we remove the management element from the cpp policy and
>> recommend an standard "allow your management ips to these services and
>> deny the rest acl"?
>
> rd> I don't think so. The encouraged action is to have a layered
> approach between COPP, infrastructure/interface ACL's, protocol level
> filtering (ie: vty ACL's, etc.). We tried to illustrated the rate
> limiting concept on a class such that the user could extrapolate that to
> other classes if they so desired for their implementation.
>
>
>>
>> I dropped the ops-trust alias for now as we are past last call and I MAY
>> be mistaken:)
>>
>>
>> (coffee != sleep)& (!coffee == sleep)
>> [email-masked] gcia
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> On Behalf Of Warren Kumari
>>> Sent: Wednesday, September 15, 2010 11:56 AM
>>> To: [email-masked] mailing list
>>> Subject: [OPSEC] Document advancement notice:
>>> draft-ietf-opsec-protect-control-plane.
>>>
>>> Hello all,
>>>
>>> progress here:
>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
>>> w_id&dTag=20212&rfc_flag=0
>>>
>>> _______________________________________________
>>> OPSEC mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/opsec
>>>
>>
>> This communication is the property of Qwest and may contain confidential
>> or
>> privileged information. Unauthorized use of this communication is
>> strictly
>> prohibited and may be unlawful. If you have received this communication
>> in error, please immediately notify the sender by reply e-mail and
>> destroy
>> all copies of the communication and any attachments.
>>