Re: [OPSEC] OPSEC control plane protection draft

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).

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

> -----Original Message-----
> From: christopher.morrow@gmail.com
> [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow
> Sent: Monday, August 16, 2010 7:59 PM
> To: rodunn@cisco.com
> Cc: Smith, Donald;
> draft-dugal-opsec-protect-control-plane@tools.ietf.org; opsec@ietf.org
> Subject: Re: [OPSEC] OPSEC control plane protection draft
>
> 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.