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

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)
 Donald.Smith@qwest.com<mailto:Donald.Smith@qwest.com>
________________________________
From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Christopher Morrow [morrowc.lists@gmail.com]
Sent: Friday, February 05, 2010 6:42 PM
To: rodunn@cisco.com
Cc: opsec@ietf.org
Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00

On Fri, Feb 5, 2010 at 8:31 PM, Rodney Dunn <rodunn@cisco.com> wrote:
> 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? ;)
>

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

>
> On 2/4/10 10:24 PM, Christopher Morrow wrote:
>>
>> On Wed, Feb 3, 2010 at 11:41 PM, John Kristoff<jtk@cymru.com>  wrote:
>>>
>>> On Mon, 04 Jan 2010 21:31:07 -0800
>>> Joel Jaeggli<joelja@bogus.com>  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
>>
>> 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...
>>
>>> 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".
>>
>> 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
>>> OPSEC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsec
>>>
>> _______________________________________________
>> 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.