Re: [OPSEC] OPSEC control plane protection draft

[Christopher Morrow <[e-mail]>]

On Thu, Aug 19, 2010 at 5:18 PM, Smith, Donald <[e-mail]> wrote:
> Rodney, this looks good to me. You have addressed all of my concerns.
> Thank you.

me as well, and thanks!

>
> (coffee != sleep) & (!coffee == sleep)
> [e-mail] gcia
>
>> -----Original Message-----
>> From: Rodney Dunn [mailto:[e-mail]]
>> Sent: Thursday, August 19, 2010 2:42 PM
>> To: [e-mail]
>> Cc: Smith, Donald; '[e-mail]'
>> Subject: Re: [OPSEC] OPSEC control plane protection draft
>>
>> 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
>> 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.
>>
>> *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.
>>
>> ....
>>
>>
>>
>>
>> On 8/17/10 4:50 PM, Rodney Dunn wrote:
>> >
>> >>> 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.
>> >> 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.....
>> >
>> >
>> >
>> >>> 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.*
>> >>
>> >> 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.
>> >>
>> >
>> > 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
>> >
>> >
>> >>>
>> >>>
>> >>> Rodney
>> >>>
>> >>>
>> >>>
>> >>> On 8/16/10 9:58 PM, Christopher Morrow wrote:
>> >>>> On Mon, Aug 16, 2010 at 9:34 PM, Rodney
>> >>> Dunn<[e-mail]> 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.
>> >>>>>
>> >>>>> We realized there were various opinions on how that
>> should be done.
>> >>>>
>> >>>> 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
>> >>>>
>> >>>>> ie:
>> >>>>>
>> >>>>>
>> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
>> >>>>>
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Rodney
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On 8/16/10 5:16 PM, Smith, Donald wrote:
>> >>>>>>
>> >>>>>> 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)
>> >>>>>> [e-mail] gcia
>> >>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: [e-mail] [mailto:[e-mail]]
>> >>>>>>> On Behalf Of Rob Bird
>> >>>>>>> Sent: Friday, March 26, 2010 11:28 AM
>> >>>>>>> To: David Dugal
>> >>>>>>> Cc: [e-mail];
>> >>>>>>> [e-mail]
>> >>>>>>> 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"
>> >>>>>>> <[e-mail]> 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:
>> >>>>>>> [phone]
>> >>>>>>> Security Incident Response Team Direct:
>> >>>>>>> [phone]
>> >>>>>>> Juniper Networks Mobile:
>> >>>>>>> [phone]
>> >>>>>>> Westford, MA, USA PGP Key:
>> >>> 0xAB6E02A5
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight
>> >>>>>>> Time), Richard
>> >>>>>>> Graveman<[e-mail]> 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
>> >>>>>>> [e-mail]
>> >>>>>>> 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.
>> >>>>>> _______________________________________________
>> >>>>>> OPSEC mailing list
>> >>>>>> [e-mail]
>> >>>>>> https://www.ietf.org/mailman/listinfo/opsec
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OPSEC mailing list
>> >>>>> [e-mail]
>> >>>>> 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.
>> > _______________________________________________
>> > OPSEC mailing list
>> > [e-mail]
>> > 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.
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>