Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00

From: John Kristoff <[email-masked]>
Date: Wed, 3 Feb 2010 22:41:13 -0600

On Mon, 04 Jan 2010 21:31:07 -0800
Joel Jaeggli <[email-masked]> wrote:

> I notes with interest today the initial publication of:
> 
> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-00
> 
> for which I am certain review and feedback would be greatly
> appreciated.

I realize there is a -01 version of this draft.  Nonetheless, this
comment still applies.

One of the major stumbling blocks in managing control plane filtering
in my experience has been when a platform lacks sufficient diagnostic
capability such as control plane filter logging.  Perhaps some mention
of this in the Design Trade-offs section might include some text
highlighting this concern.  Rate limiting can be particularly
troublesome when "bad" traffic starves the "good".

John

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 4 Feb 2010 22:24:24 -0500

> in my experience has been when a platform lacks sufficient diagnostic

yes, if you can block/limit it, you MUST be able to log that fact, and
count that fact. Otherwise it because exceptionally difficult to get a
tcpdump on that sonet link to your neighbor...

> troublesome when "bad" traffic starves the "good".

it might be nice to have special macros for 'bgp neighbors' or  'local
interfaces' or 'connected networks'. to make configuration management
easier... of course those could be called 'implementation details' but
:)

now I'll go read the doc, and hopefully provide some comments.

-Chris

>
> John
>
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Rodney Dunn <[email-masked]>
Date: Fri, 05 Feb 2010 20:31:17 -0500

Thanks a lot for the feedback. We'll go back and see if/where/how we can 
work something around that in.

It is a valid point for sure.

On a side note...what if there were netflow on the control plane per 
class with drop codes in the export data? ;)

On 2/4/10 10:24 PM, Christopher Morrow wrote:
> On Wed, Feb 3, 2010 at 11:41 PM, John Kristoff<[email-masked]>  wrote:
>> Joel Jaeggli<[email-masked]>  wrote:
>>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 5 Feb 2010 20:42:15 -0500

On Fri, Feb 5, 2010 at 8:31 PM, Rodney Dunn <[email-masked]> wrote:
> On a side note...what if there were netflow on the control plane per class
> with drop codes in the export data? ;)
>

sure, seems like netflow would be more heavyweight than the just
logging... and I think I'd rather have logs (less sampling I'd hope?)

-chris

---

From: John Kristoff <[email-masked]>
Date: Fri, 5 Feb 2010 22:22:47 -0600

On Fri, 05 Feb 2010 20:31:17 -0500

> class with drop codes in the export data? ;)

That would be useful not only for the control plane of course.  However,
I concur with Chris.  Logging would be preferable in my experience when
you're in a diagnostic situation.

John

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 8 Feb 2010 09:33:26 -0700

I think a counter per rule is the minimum.
An snmp trap with the FIRST hit in X minutes with X being defined via configuration would be helpful in that we could notify the NOC of the issue, get them looking at it and could set levels.
If an not snmp trap, some way to get the counters exported (netflow, syslog, something) would be helpful.

Then if a counter is getting hit it would be nice to be able to "request" additional information something like netflow v5 fields is probably good enough.

Log vs count with options for different reporting methods.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christopher Morrow [[email-masked]]
Sent: Friday, February 05, 2010 6:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00

-chris

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