IETF Logo Mail Archive

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

Christopher Morrow <morrowc.lists@gmail.com> Sat, 06 February 2010 01:41 UTC

Return-Path: <christopher.morrow@gmail.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 957293A6FCC for <opsec@core3.amsl.com>; Fri, 5 Feb 2010 17:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 p2uf35aA0z0F for <opsec@core3.amsl.com>; Fri, 5 Feb 2010 17:41:25 -0800 (PST)
Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id 98EC43A6FCB for <opsec@ietf.org>; Fri, 5 Feb 2010 17:41:25 -0800 (PST)
Received: by iwn10 with SMTP id 10so4816294iwn.22 for <opsec@ietf.org>; Fri, 05 Feb 2010 17:42:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=PDCuvJkb7hrAk7PG4nH4z+mxkpPIP5FDiE1B7J0oWPQ=; b=oD2IfMldZrmh4QC2xwxUvsL7aI0IEC86MQkZ8Bem143ojd3Fn0U8xZlvWBQYzIMwyu nHqShSdBOdcAYCurjoEb723y9ECSsYhN/aNG3OSARUlVQubX0mahaEwts0RRzq6M4PRx P3KoYOSu59cDSFxDBa3AJ47JUd4ODrbpDg3Qo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NV2lziqWQqizsRd0vb57kDMEAsrFPAiJT8lOpssHExPPGXFsrsLtyf9aWvkdPZIm92 WqvSREysuVhWxB47qP3RRDzXD9pGj/GW0sVJj7NEsLvTuEhneNhQUe6DfpVywWByr12I F5ocmJ0tWe4f+b2FaFe4oe8fIua06WdPzEwe4=
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.231.160.149 with SMTP id n21mr614103ibx.93.1265420535217; Fri, 05 Feb 2010 17:42:15 -0800 (PST)
In-Reply-To: <4B6CC665.7070909@cisco.com>
References: <4B42CE9B.8070505@bogus.com> <20100203224113.2a79333f@t61p> <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> <4B6CC665.7070909@cisco.com>
Date: Fri, 05 Feb 2010 20:42:15 -0500
X-Google-Sender-Auth: 3432336ebb7946a2
Message-ID: <75cb24521002051742n75442ebas365882f7d7bd9bbc@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: rodunn@cisco.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: opsec@ietf.org
Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00
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: Sat, 06 Feb 2010 01:41:26 -0000

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
>

v2.23.0 | Report a Bug | By Email