Re: [OPSEC] OPSEC control plane protection draft

[Rodney Dunn <[e-mail]>]

Thanks Donald.

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

Thanks for the review.

Rodney



On 8/19/10 5:18 PM, Smith, Donald wrote:
> Rodney, this looks good to me. You have addressed all of my concerns.
> Thank you.
>
> (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.