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

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