Re: [OPSEC] Comments on draft-dugal-opsec-protect-control-plane-02
Ron Bonica <rbonica@juniper.net> Fri, 09 April 2010 16:13 UTC
Return-Path: <rbonica@juniper.net>
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 1CE4C3A6993 for <opsec@core3.amsl.com>; Fri, 9 Apr 2010 09:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.74
X-Spam-Level:
X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 tJmA6GKeZRhs for <opsec@core3.amsl.com>; Fri, 9 Apr 2010 09:13:24 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 6F89C3A69F9 for <opsec@ietf.org>; Fri, 9 Apr 2010 09:12:50 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS79R/hDJbockMjc54JJ+wvl+u4P1AP9X@postini.com; Fri, 09 Apr 2010 09:12:48 PDT
Received: from [172.28.134.28] (172.28.134.28) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 9 Apr 2010 09:10:27 -0700
Message-ID: <4BBF516F.5060508@juniper.net>
Date: Fri, 09 Apr 2010 12:10:23 -0400
From: Ron Bonica <rbonica@juniper.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
References: <C629017C-E5CF-4FD8-8B60-99901293423F@tcb.net>
In-Reply-To: <C629017C-E5CF-4FD8-8B60-99901293423F@tcb.net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Comments on draft-dugal-opsec-protect-control-plane-02
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: Fri, 09 Apr 2010 16:13:26 -0000
Hi Folks, <Speaking as individual contributor> Danny McPherson wrote: > I support this document becoming an OPSEC WG item. A few > mostly trivial comments below. I do believe the document > would benefit from an overwrite for readability, but it > seems to be in pretty good shape (and that's the purpose of > making it a WG item). +1 > > One substantive item is that I believe it needs to be a lot > more detailed on IPv6 examples, in particular as they relate > to ICMP. This is where lots of operators really need extra > guidance today. I would like to suggest a sequel document specifically for operators who are deploying dual stack. There are enough sharp edges in dual stack deployment that it deserves some thought. > > Also, it should be clear about how transit traffic with TTL > expiry isn't necessarily addressed to the device, but might get > punted to the control plane. There is some text that touches > on this, but this issue is not clear from the text. +1 > > Finally, after giving RFC 1812 another read (phew), my comments > at the microphone about references to that document aren't > really useful. I had thought it had more detailed information > on what it terms "in-band" access, however, the guidance there > isn't particular useful in this context. > > -danny > > > --- > S 1. > > s/as as/as/ > > s/traffic unwanted traffic/unwanted traffic/ > > --- > S 2. > > I think the document would benefit from IPv6 examples as well, and > should reference that use case here and provide it further along in > parallel to IPv6 examples. > > --- > S 3. > > s/sample router introduced/sample router is introduced/ > > --- > S 3.1. > > While I realize it's for example only, it might well be useful to > add some sort of authentication packets to that example, so that > folks can login if they have non-local auth models. > > Also, does anyone have recent rates of ICMP traffic destined to the > control plane of high-end routers? 2 Mbps of ICMP seems pretty > high to me.. > > --- > S 3.2 > > It might be useful for the document, or the appendices to recommend > allowing all traffic initially and auditing what hits the control > plane before applying explicit filters or rate limits. Additionally, > use of flow-based behavioral analysis or even CLI functions to > identify what client/server functions a given control plane handles > would be very useful during initial policy development phases (and > certainly for forensics afterwards). Perhaps this belongs at the > end of S 3.3, in the last graf where you touch on some of this. > > --- > S 3.3 > > I'm not sure what "sub-traffic" is.. > > It might be worth expanding this a bit to say that an astute operator > would likely define varying rate limits for ICMP such than internal > traffic (i.e., from internal address blocks) obtains uninhibited > access to the control plane, while traffic from external blocks is > rate limited. I think you meant to allude to this, but don't really > make it clear in the current text. > > > --- > S 4. > > I believe it'd be worthwhile to mention that while in the inter-domain > context express ingress anti-spoofing policies may be difficult, > operators should apply ingress infrastructure ACLs to limit access to > infrastructure from external source address spoofing of internal address > space. I.e., allow no packet into the perimeter of the network that > has a source address of internal prefixes. Of course, iACLs and GTSM > might well be a new section to this document, or a document entirely > themselves. > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > . >
- [OPSEC] Comments on draft-dugal-opsec-protect-con… Danny McPherson
- Re: [OPSEC] Comments on draft-dugal-opsec-protect… Warren Kumari
- Re: [OPSEC] Comments on draft-dugal-opsec-protect… Joel Jaeggli
- Re: [OPSEC] Comments on draft-dugal-opsec-protect… Ron Bonica
- Re: [OPSEC] Comments on draft-dugal-opsec-protect… Smith, Donald