Re: [OPSEC] OPSEC control plane protection draft

"Smith, Donald" <Donald.Smith@qwest.com> Thu, 19 August 2010 21:17 UTC

Return-Path: <Donald.Smith@qwest.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107933A680D for <opsec@core3.amsl.com>; Thu, 19 Aug 2010 14:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTwu1Ujeec+K for <opsec@core3.amsl.com>; Thu, 19 Aug 2010 14:17:38 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 18CB23A6A4C for <opsec@ietf.org>; Thu, 19 Aug 2010 14:17:38 -0700 (PDT)
Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o7JLIBxP001636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Aug 2010 16:18:11 -0500 (CDT)
Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id o7JLI5wu029571; Thu, 19 Aug 2010 16:18:06 -0500 (CDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Thu, 19 Aug 2010 15:18:05 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: "'rodunn@cisco.com'" <rodunn@cisco.com>
Date: Thu, 19 Aug 2010 15:18:04 -0600
Thread-Topic: [OPSEC] OPSEC control plane protection draft
Thread-Index: Acs/3rAP8kZzfUCyQ5y6FqxaDYO81QABUFBQ
Message-ID: <B01905DA0C7CDC478F42870679DF0F10091D90C043@qtdenexmbm24.AD.QINTRA.COM>
References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <ba2fbc6f1003261027u5c62b7b4od135d00144a83a02@mail.gmail.com> <B01905DA0C7CDC478F42870679DF0F10091D90BD15@qtdenexmbm24.AD.QINTRA.COM> <4C69E72F.6090608@cisco.com> <AANLkTikJHA8O4EbL43nHGYfEdt2k0-V0Tv2uy390soeD@mail.gmail.com> <4C6AEB97.2010501@cisco.com> <B01905DA0C7CDC478F42870679DF0F10091D90BDD9@qtdenexmbm24.AD.QINTRA.COM> <4C6AF600.8030504@cisco.com> <4C6D9725.4080505@cisco.com>
In-Reply-To: <4C6D9725.4080505@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] OPSEC control plane protection draft
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Aug 2010 21:17:40 -0000

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

(coffee != sleep) & (!coffee == sleep)
Donald.Smith@qwest.com gcia

> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn@cisco.com]
> Sent: Thursday, August 19, 2010 2:42 PM
> To: rodunn@cisco.com
> Cc: Smith, Donald; 'opsec@ietf.org'
> 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<rodunn@cisco.com> 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)
> >>>>>> Donald.Smith@qwest.com gcia
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]
> >>>>>>> On Behalf Of Rob Bird
> >>>>>>> Sent: Friday, March 26, 2010 11:28 AM
> >>>>>>> To: David Dugal
> >>>>>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org;
> >>>>>>> opsec@ietf.org
> >>>>>>> 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"
> >>>>>>> <ddugal@juniper.net> 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<rfgraveman@gmail.com> 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
> >>>>>>> OPSEC@ietf.org
> >>>>>>> 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
> >>>>>> OPSEC@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/opsec
> >>>>>
> >>>>> _______________________________________________
> >>>>> OPSEC mailing list
> >>>>> OPSEC@ietf.org
> >>>>> 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
> > OPSEC@ietf.org
> > 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.