Subject: Re: [OPSEC] OPSEC control plane protection draft

From: "Smith, Donald" <[email-masked]>
Date: Mon, 16 Aug 2010 15:16:20 -0600

For undesirables in JTK's paper here he specifically did a deny ip any any at the end of the cpp policy for that.

http://aharp.ittns.northwestern.edu/papers/copp.html

The default term for juniper is log and discard.

There isn't a deny ip any any in the draft.

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Rob Bird
> Sent: Friday, March 26, 2010 11:28 AM
> To: David Dugal
> Cc: [email-masked];
> [email-masked]
> Subject: Re: [OPSEC] OPSEC control plane protection draft
>
> This is most excellent. I was just advising a customer this
> morning on this very issue (again).
>
> I look forward to working on this.
> Rob
>
> -
> Rob Bird, Chief Technology Officer
> Red Lambda, Inc.
> "Network security at global scale"
> www.redlambda.com
>
>       On Mar 26, 2010 1:03 PM, "David Dugal"
> <[email-masked]> wrote:
>
>       -----BEGIN PGP SIGNED MESSAGE-----
>       Hash: SHA1
>
>       Hi Richard.
>
>       Thank you very much for the scrutiny, analysis and feedback.  As
>       mentioned during my brief presentation, our hope is that this
>       recommendation by example will provide awareness of a
> possible attack
>       surface occasionally overlooked, especially by smaller or newer
>       installations.
>
>       I appreciate the feedback and will enhance the draft to
> make reference
>       to cryptographic security, as well as attempt to make
> the document IP
>       version agnostic.
>
>       Thank you for your support, both in carefully reading
> the document, and
>       for your willingness to have our draft taken under the
> OPSEC WG wing.
>
>       - ---
>       David G. Dugal                           Support:
> +1-408-745-9500
>       Security Incident Response Team          Direct:
> +1-978-589-0719
>       Juniper Networks                         Mobile:
> +1-603-377-1162
>       Westford, MA, USA                        PGP Key: 0xAB6E02A5
>
>
>       On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight
> Time), Richard
>       Graveman <[email-masked]> proclaimed ...
>
>
>       > David,
>       >
>       > I read the draft carefully after the meeting and
> realize that my
>       > comments missed the...
>
>       > .
>       >
>       -----BEGIN PGP SIGNATURE-----
>       Version: GnuPG v1.4.10 (MingW32)
>
>       iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr
>       2zMAoPb5y3phm260P1zSoDu0LSbUjNcN
>       =kitD
>       -----END PGP SIGNATURE-----
>
>
>       _______________________________________________
>       OPSEC mailing list
>       [email-masked]
>       https://www.ietf.o...
>
>

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.

---

From: Rodney Dunn <[email-masked]>
Date: Mon, 16 Aug 2010 21:34:39 -0400

Donald,

First thanks for the comment. It's a good one. We actually originally 
had it with a default drop for the all IP and default classes. However, 
after a good bit of discussion we (both Cisco and Juniper) felt that we 
should soften it up just a bit. We agreed to add the explicit match for 
the ALLIP class so it could be monitored and then tightened down further.

We realized there were various opinions on how that should be done.

ie:

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

Thanks,
Rodney

On 8/16/10 5:16 PM, Smith, Donald wrote:
> (coffee != sleep)&  (!coffee == sleep)
>>        Graveman<[email-masked]>  proclaimed ...
>>
>>
>>        >  David,
>>        >
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 16 Aug 2010 21:58:43 -0400

On Mon, Aug 16, 2010 at 9:34 PM, Rodney Dunn <[email-masked]> wrote:
> Donald,
>
> First thanks for the comment. It's a good one. We actually originally had it
> with a default drop for the all IP and default classes. However, after a
> good bit of discussion we (both Cisco and Juniper) felt that we should
> soften it up just a bit. We agreed to add the explicit match for the ALLIP
> class so it could be monitored and then tightened down further.
>

can we get a 'first verify complete COPP coverage, then deny all
remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph?

It sounds like someone with a legal degree got to your final
recommendation :) that, operationally, leaves the network with a whole
to plug, and I can guarantee that someone with a scanning virus is
gonna fill it for you :(

-chris

>>>       >  David,
>>>       >
>>>       >  I read the draft carefully after the meeting and
>>> realize that my
>>>       >  comments missed the...
>>>
>>>       >  .
>>>       >

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 17 Aug 2010 09:30:15 -0600

While difficult to get right leaving a hole to allow "unknown stuff" to go to the control plane is counter-intuitive if we are talking about protecting the control plane.

When I write about mitigations for router vulnerabilities within our network one of the things I often include in the mitigations is the fact that the services and control plane of the routers is locked down. Almost locked down with a hole that may or may not allow something that could trigger the vulnerability is not as good:)

This is one of the reasons we had that whole logging of exceptions/dropped traffic discussion a while back.
Not just a counter actual logging (sampled ok, syslog or snmp ... ok ... but some logging of traffic similar to a netflow record would be helpful).

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Christopher Morrow
> Sent: Monday, August 16, 2010 7:59 PM
> To: [email-masked]
> Cc: Smith, Donald;
> [email-masked]; [email-masked]
> >> For undesirables in JTK's paper here he specifically did a
> deny ip any any
> >> at the end of the cpp policy for that.
> >>
> >> This communication is the property of Qwest and may
> contain confidential
> >> or

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 17 Aug 2010 13:43:12 -0400

> Not just a counter actual logging (sampled ok, syslog or snmp ... ok ... but some logging of traffic similar to a netflow record would be helpful).

+1 to the entire message here... you just don't want to leave open
holes, ever, in critical infrastructure.

-chris

---

From: Jared Mauch <[email-masked]>
Date: Tue, 17 Aug 2010 14:21:46 -0400

> holes, ever, in critical infrastructure.

+2

- Jared

---

From: Rodney Dunn <[email-masked]>
Date: Tue, 17 Aug 2010 16:05:43 -0400

We agree that the end goal should be to lock the device down to the most 
granular degree possible. We made an effort to highlight that at various 
places in the document. I like your suggestion to add an additional 
paragraph specifically highlighting the importance of getting to a point 
where the default traffic would be a drop. Could you review the 
paragraph below between *-*'s and make suggestions to wording if it's 
not explicit or clear enough?

Thanks,
Rodney

Some references already in the document are...

ie: Section 3.2 Filter Design

..By adjusting the granularity and order of the filters more
    granular forensics can be performed...

In addition to the filters, rate-limiters for certain classes of
    traffic are also installed in the forwarding plane as defined in
    Section 3.1.  These rate limiters help futher control the traffic
    that will reach the control plane for each filtered class as well as
    all traffic not matching an explicit class.  The actual rates
    selected for various classes is network deployment specific and
    analysis of required rates for stability should be done periodically.

and the note for the catch all:

Syntactically, these filters explicitly define "allowed" traffic
    (including IP addresses, protocols, and ports), define acceptable
    actions for these acceptable traffic profiles (e.g., rate-limit or
    simply permit the traffic), and then drop to the bit bucket all
    traffic destined to the router control plane that is not within the
    specifications of the policy definition.

and in Section 3.3 we wanted to articulate the importance of locking it 
down as granular as possible:

...The goal of the method for protecting the router control plane is to
    minimize the possibility for disruptions by reducing the vulnerable
    surface.  The latter is inversely proportional to the granularity of
    the filter design.  The finer the granularity of the filter design
    (e.g., isolating a more targeted subset of traffic from the rest of
    the policed traffic, or isolating valid source addresses into a
    different class or classes) the smaller the probability of
    disruption.
...

What about if we add this in the Design
Trade-Off section to address the concern so we will be more precise.

*In addition to the traffic matching explicit classes care should be 
taken on the policy decision that governs the handling of traffic that 
would fall through the policy. Typically that traffic is referred to as 
traffic falling in the default class. It may also be traffic that 
matches a generic protocol specific class where previous classes that 
have more granular matching did not match all packets for that specific 
protocol. The ideal policy would have explicit classes to match only the 
traffic specifically required at the control plane and drop all other 
traffic. This approach requires rigorous traffic pattern identification 
such that a default drop policy does not break existing functionality of 
the device. The approach defined in this document allows the default 
traffic and rate limits it rather than just dropping it. This approach 
was highlighted as a way to give time to the implementer to evaluate the 
traffic in a production scenario prior to dropping all traffic not 
explicitly matched and permitted. However, it is highly recommended that 
after monitoring the traffic matching the default class explicit classes 
should be defined such that the default class could be configured to 
drop traffic falling through the policy.*

Rodney

On 8/16/10 9:58 PM, Christopher Morrow wrote:
> On Mon, Aug 16, 2010 at 9:34 PM, Rodney Dunn<[email-masked]>  wrote:
>> Donald,
>>

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 17 Aug 2010 14:25:07 -0600

> From: Rodney Dunn [mailto:[email-masked]]
> Sent: Tuesday, August 17, 2010 2:06 PM
> To: Christopher Morrow
> Cc: Smith, Donald; [email-masked]; [email-masked]
> would fall through the policy.
Do we need to say that by convention there is no default deny at the end of a cpp policy?

>Typically that traffic is
> referred to as
into the default ...
> drop traffic falling through the policy.*

Can we add a COMMENTED OUT deny ip any any in the default policy with a
"do not enable until throughly tested in production ..." type statement.

> >>> For undesirables in JTK's paper here he specifically did
> a deny ip any any

---

From: Rodney Dunn <[email-masked]>
Date: Tue, 17 Aug 2010 16:50:08 -0400

> Do we need to say that by convention there is no default deny at the end of a cpp policy?

Another good catch...how about this:

....Typically that traffic is referred to as traffic falling in the 
default class. It may also be traffic that matches a generic protocol 
specific class where previous classes that have more granular matching 
did not match all packets for that specific protocol. The ideal policy 
would have explicit classes to match only the traffic specifically 
required at the control plane and drop all other traffic. *As most 
vendor implementations permit all traffic hitting the default class an 
explicit drop action would need to be configured in the policy such that 
the traffic hitting that default class would be dropped versus being 
delivered up to the control plane.* This approach requires rigorous 
traffic pattern identification such that a default drop policy does not 
break existing functionality of the device.....

> "do not enable until throughly tested in production ..." type statement.

I would prefer we cover it in the text section because that would make 
it harder to link the Legitimate Traffic (Section 3.1) definition to the 
actual configuration in the document.

Rodney

---

From: Rodney Dunn <[email-masked]>
Date: Thu, 19 Aug 2010 16:42:13 -0400

The current proposal on the table is the additional paragraph in Section 
3.3 "Design Trade-offs" section to add the following paragraph between 
*-*'s. The purpose of this paragraph is to highlight that the end goal 
would be to have a COPP policy that is as explicit as possible on what 
to permit and dropping all other traffic. Does the list agree that this 
paragraph accurately reflects that desire?

Section 3.3 "Design Trade-offs"

...
The goal of the method for protecting the router control plane is to

*In addition to the traffic matching explicit classes care should be 
taken on the policy decision that governs the handling of traffic that 
would fall through the policy. Typically that traffic is referred to as 
traffic that gets matched in a default class. It may also be traffic 
that matches a protocol specific class where previous classes that have 
more granular matching did not match all packets for that specific 
protocol. The ideal policy would have explicit classes to match only the 
traffic specifically required at the control plane and drop all other 
traffic that does not mach a predefined class. As most vendor 
implementations permit all traffic hitting the default class an explicit 
drop action would need to be configured in the policy such that the 
traffic hitting that default class would be dropped versus permitted and 
then delivered to the control plane. This approach requires rigorous 
traffic pattern identification such that a default drop policy does not 
break existing functionality of the device. The approach defined in this 
document allows the default traffic and rate limits it rather than just 
dropping it. This approach was highlighted as a way to give time for the 
implementer to evaluate the traffic in a production scenario prior to 
dropping all traffic not explicitly matched and permitted. However, it 
is highly recommended that after monitoring the traffic matching the 
default class that explicit classes be defined to catch the legitimate 
traffic. After all legitimate traffic is being explicitly matched the 
default class should be configured to drop any remaining traffic. *

Additionally, the baselining and monitoring of traffic flows to the
router's control plane are critical in determining both the rates and
granularity of the policies being applied.  This is important to
validate the existing policies and rules or update them as the
network evolves and its traffic dynamics change.  Some possible ways
to achieve this include individual policy counters that can be
exported or retrieved for example via SNMP, and logging of filtering
actions.

....

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 19 Aug 2010 15:18:04 -0600

Rodney, this looks good to me. You have addressed all of my concerns.
Thank you.

> Sent: Thursday, August 19, 2010 2:42 PM
> To: [email-masked]
> Cc: Smith, Donald; [email-masked]'
> >> Do we need to say that by convention there is no default
> deny at the
> >> end of a cpp policy?
> >>
> >>
> >

---

From: Rodney Dunn <[email-masked]>
Date: Thu, 19 Aug 2010 18:01:10 -0400

Thanks Donald.

I'll update the xml source tomorrow with that and we'll wait for any 
additional comments.

Thanks for the review.

Rodney