From root@core3.amsl.com Fri Aug 6 14:45:24 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D70DA3A6767; Fri, 6 Aug 2010 14:45:11 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100806214511.D70DA3A6767@core3.amsl.com> Date: Fri, 6 Aug 2010 14:45:02 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 21:45:25 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Protecting The Router Control Plane Author(s) : D. Dugal, et al. Filename : draft-ietf-opsec-protect-control-plane-02.txt Pages : 22 Date : 2010-08-06 This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane or rate limited to an acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-control-plane-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-protect-control-plane-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-06143450.I-D@ietf.org> --NextPart-- From rodunn@cisco.com Fri Aug 6 15:00:21 2010 Return-Path: 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 362A83A67D4 for ; Fri, 6 Aug 2010 15:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 F6WYU+Ilbs23 for ; Fri, 6 Aug 2010 15:00:20 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 2BF103A6767 for ; Fri, 6 Aug 2010 15:00:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o76M0pjE020386 for ; Fri, 6 Aug 2010 18:00:51 -0400 (EDT) Received: from rtp-rodunn-8711.cisco.com (rtp-rodunn-8711.cisco.com [10.116.190.130]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o76M0oLa028040 for ; Fri, 6 Aug 2010 18:00:51 -0400 (EDT) Message-ID: <4C5C8612.4070702@cisco.com> Date: Fri, 06 Aug 2010 18:00:50 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-02.txt posted today X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 22:00:21 -0000 OPSEC members, We have posted the -02 revision today to draft-ietf-opsec-protect-control-plane. http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-control-plane-02.txt In it we have addressed all feedback thus far including the much requested V6 additions which represented the last outstanding item we had not previously incorporated. We would appreciate any and all review comments. Thanks, Rodney/David/Carlos -------- Original Message -------- Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-02.txt Date: Fri, 6 Aug 2010 14:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: opsec@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Protecting The Router Control Plane Author(s) : D. Dugal, et al. Filename : draft-ietf-opsec-protect-control-plane-02.txt Pages : 22 Date : 2010-08-06 This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane or rate limited to an acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-control-plane-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From joelja@bogus.com Sun Aug 8 09:58:35 2010 Return-Path: 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 3E4563A6827 for ; Sun, 8 Aug 2010 09:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 9g2wDRTsGAN4 for ; Sun, 8 Aug 2010 09:58:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 734553A6858 for ; Sun, 8 Aug 2010 09:58:33 -0700 (PDT) Received: from joelja-mac.local (adsl-99-173-15-227.dsl.pltn13.sbcglobal.net [99.173.15.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o78Gx1pu007238 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 8 Aug 2010 16:59:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4C5EE24F.5050105@bogus.com> Date: Sun, 08 Aug 2010 09:58:55 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 08 Aug 2010 16:59:02 +0000 (UTC) Subject: [OPSEC] IETF 78 Meeting minutes Final Draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 16:58:35 -0000 note-taker: Joe Abley jabber-monitor: Joe Abley meeting starts at Mon 26 Jul 2010 17:41:35 CEST Joel recounts note well. Joel presents Agenda. No changes were requested. Joel presents document status. Andrew Yourtchenko presents on draft-ietf-opsec-protect-control-plane. This is the second time this document has been presented. An overview of the motivations and document approach was provided. The status of the document is that -02 is expected to be published in mid-August, and that the authors anticipate being ready for last call at that time. Joel notes: That document is progressing well, August WGLC does notseem unreasonable. Other vendor-specific examples would be welcome in addition to the current two. General problem space is not limited to routers, but is also applicable to other converged devices. No additional comments from the room. Yinxing Wei presents Analysis of Security Association For Current Routing Protocol work being done under the karp working group charter. Chris Morrow: wonders why there is a need for more key management protocols. Chris thinks that manual configuration is fine; he just wants a reliable way of updating a key smoothly, and of changing many keys because of a single event (e.g. employee leaves the company). The KMF approach seems overly complicated. Joel notes (operational) desire not to boil the ocean. Chris agrees that's a more succinct way of making his point. Joel suggests that in the ops area we are unconvinced (need to be convinced rather than mind made up) that rolling out a key management protocol would solve a useful problem. Chris did like the survey of what different routing protocols provide. He is just decidedly unsure about the usefulness of a key management protocol. Joel presents Outreach Activities. On NANOG there has been discussion of a set of well-known BGP community string attributes. Consensus on the NANOG list seems to be that any document which aims to document lists of standard values is unlikely to gain relevance. However, it seems like there is some value in cataloguing the kinds of controls people provide using community string attributes. Fred Baker is interested in how we might set up an IANA registry. Joe described briefly the possible approaches, but noted that a registry would be more useful for a list of prescribed of attribute values, not for a catalogue of capabilities. Warran Kumari wonders whether this is a job for an IETF document, or whether something more ephemeral like a wiki might not be better. Joel wonders whether a common vocabulary might be really what we want, not something specifically tied to particular values. No obvious volunteers were evident in re-steering the existing document, but there is interest and Joel knows people outside this meeting who are interested in working on documents in this general area. Joel passed on a suggestion from Bob Natale that opsec might have an interest in sharing information with the TM Forum (formerly the OSI Network Management Forum). Joel noted that almost all of our documents are on track for last call before the next meeting, and hence a re-charter will be discussed on the mailing list between then. Also noted that scheduling meetings is difficult and that we should not meet arbitrarily, if there is no work to be done in the working group. Sean turner - Ops area directors have expressed the opinion that the work in opsec finds a better home in opsec than it would in opsawg, and so there is enthusiasm there for this working group to remain alive. Sean turner (security ad) - mentioned that Tim has reviewed the revisions to -crypto-issues following his earlier DISCUSS, and he has some new comments that he will pass on. Meeting closed at Mon 26 Jul 2010 18:23:08 CEST. From joelja@bogus.com Sun Aug 8 14:35:13 2010 Return-Path: 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 987D13A680B; Sun, 8 Aug 2010 14:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.424 X-Spam-Level: X-Spam-Status: No, score=-101.424 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_40=-0.185, SARE_SUB_OBFU_Q1=0.227, 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 wSfSnPYj-Kbb; Sun, 8 Aug 2010 14:35:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 9DAFC3A680A; Sun, 8 Aug 2010 14:35:11 -0700 (PDT) Received: from dhcp-183.nokia.net (dhcp-183.nokia.net [192.103.16.183] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o78LZh68022183 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 8 Aug 2010 21:35:43 GMT (envelope-from joelja@bogus.com) Message-ID: <4C5F232E.6050401@bogus.com> Date: Sun, 08 Aug 2010 14:35:42 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 08 Aug 2010 21:35:44 +0000 (UTC) Cc: opsec@ietf.org Subject: [OPSEC] Review of draft-ietf-karp-threats-reqs-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 21:35:13 -0000 Reviews of this document were requested during the IETF 78 karp working group meeting. since I raised my hand, I've undertaken to provide a review of this document. I think this is a pretty good document, It could do with a bit of re-organization which I'll deal with in the criticism. One piece of feedback I think I heard loud and clear in the opsec working group discussion of karp activities was that operators are no sold on the idea of a Key Manangement Protocol as a requirement. KM as activity is currently handled as part of configuration and while being able to rekey or change protocols without interuption or synchronized coordination is particularly desirable, there's not groundswell of support around for example making an ldap query everytime you fire-up a bgp session. criticism: page 5 last paragraph... Effectively the the unicast layer 3 or above routing protocol being discussed here is BGP. The fact of the matter OSPF RIP ISIS are part of the reason we don't have a general purpose solution. page 6 paragraph 2 While I'm not sure that I characterize rfc 2385 protection as part of bgp, it's certainly part of running bgp today. likewise in the is-is case tlv 10 is an existing protection mechanism. page 6 scope of roadmap work should likley just make an informative reference to the appropiate document (framework) page 7 1.4 goal 2 goal 2 is a section unto itself, as a principle it should be one or two sentences at most. it's possible that the balance of the contents of goal 2 bleongs in a subsection of 1.3 since it provides guidance on scope. goal 3 deployability is one word even if your dictionary disagrees I'm not sure that 3 and 4 are actually sufficiently differentiated. goal 3 is for the benefit of the robots and goal 4 is for the humans, but the human practices in (4) currently are the product of number (3) goal 4 again part of this goal belongs in the scope, not in the goal itelf. page 10 1.5 non-goals it's "validity" I think not security that we're not addressing, and that is the SIDR goal, that security is the product of protecting the validity of routing data. page 11 threats in scope... reflecting for a moment on the neature of outsiders, I think the concept of terminated employees is necessarily specific. The property that terminated employees share with some other potential outsiders is that (at one time) the came by the information used to launch the attack legitimately, they share this property with for example former peers, shared route reflectors at some exchange points, routeviews/ris, customers (possibly the largest set) upstream isps etc. I would focus on the property on not on the individual case. the goal in all cases is the rekey quickly enough to prevent legitimate credientials from being resused for illegitimate purposes. problem today, appart from the fact that rekeying is painful is that we re-use the same credentials over and over again becasue of the nature of (multihop) bgp and the prevalance of l3 or l2 vpn, what constitutes onpath is itself somewhat nebulous, an attacker sitting inside your l2vpn provider might well alter the LSP to better facilitate onpath injection or to seperate the endpoints without superficially altering any other link characteristics. I'm reasonably certain that devices which has legitimate credentials but no longer should are not rendered out of scope as byzantine sources. page 13 DoS attacks on transport sub-systems does no end in a complete sentence. Brute Foce Attacks Against Password/Keys generating per session keys is another widely used method for reducing the value of brute force attacks that's somewhat more specfic than simply frequently rekeying. 3 requirements for phase 1 regarding 13 - I'm reasonable certain that there are operators that would not consider the lack of inclusion of a key-management protocol a blocker. I could imagine work on a protocol where the developers might declare victory and go home before including hooks for a KMP. I'd probaly therefore use SHOULD in this context. 15 - if what is being asked for is a minimal increase in the number of messages passed, that should simply be stated in lieue of the convergence time requirement.. 19 - yes include in 3.6 21.1-4 are actually subsidiary to 20 like wise items in 23 are really under 22 no item 26 From Donald.Smith@qwest.com Mon Aug 16 14:15:55 2010 Return-Path: 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 8CBA03A6ABD for ; Mon, 16 Aug 2010 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 q28-5KWh797W for ; Mon, 16 Aug 2010 14:15:54 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 319413A67B5 for ; Mon, 16 Aug 2010 14:15:54 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o7GLGSWI026765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Aug 2010 16:16:28 -0500 (CDT) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id o7GLGMI4013707; Mon, 16 Aug 2010 15:16:22 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 16 Aug 2010 15:16:22 -0600 From: "Smith, Donald" To: "'Rob Bird'" , "'David Dugal'" Date: Mon, 16 Aug 2010 15:16:20 -0600 Thread-Topic: [OPSEC] OPSEC control plane protection draft Thread-Index: AcrNCatzvqxAjw0ZR9mcYMGNSF8+OBwaF0kw Message-ID: References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'draft-dugal-opsec-protect-control-plane@tools.ietf.org'" , "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:15:55 -0000 For undesirables in JTK's paper here he specifically did a deny ip any any = at the end of the cpp policy for that. http://aharp.ittns.northwestern.edu/papers/copp.html The default term for juniper is log and discard. There isn't a deny ip any any in the draft. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Rob Bird > Sent: Friday, March 26, 2010 11:28 AM > To: David Dugal > Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; > opsec@ietf.org > Subject: Re: [OPSEC] OPSEC control plane protection draft > > This is most excellent. I was just advising a customer this > morning on this very issue (again). > > I look forward to working on this. > Rob > > - > Rob Bird, Chief Technology Officer > Red Lambda, Inc. > "Network security at global scale" > www.redlambda.com > > On Mar 26, 2010 1:03 PM, "David Dugal" > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Richard. > > Thank you very much for the scrutiny, analysis and feedback. As > mentioned during my brief presentation, our hope is that this > recommendation by example will provide awareness of a > possible attack > surface occasionally overlooked, especially by smaller or newer > installations. > > I appreciate the feedback and will enhance the draft to > make reference > to cryptographic security, as well as attempt to make > the document IP > version agnostic. > > Thank you for your support, both in carefully reading > the document, and > for your willingness to have our draft taken under the > OPSEC WG wing. > > - --- > David G. Dugal Support: > +1-408-745-9500 > Security Incident Response Team Direct: > +1-978-589-0719 > Juniper Networks Mobile: > +1-603-377-1162 > Westford, MA, USA PGP Key: 0xAB6E02A5 > > > On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight > Time), Richard > Graveman proclaimed ... > > > > David, > > > > I read the draft carefully after the meeting and > realize that my > > comments missed the... > > > . > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > > iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr > 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN > =3DkitD > -----END PGP SIGNATURE----- > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.o... > > 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. From rodunn@cisco.com Mon Aug 16 18:34:16 2010 Return-Path: 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 D098C3A6781 for ; Mon, 16 Aug 2010 18:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZmYwDV2y+e4T for ; Mon, 16 Aug 2010 18:34:10 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 3952A3A67C0 for ; Mon, 16 Aug 2010 18:34:09 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7H1Yhga013288; Mon, 16 Aug 2010 21:34:43 -0400 (EDT) Received: from rtp-rodunn-8714.cisco.com (rtp-rodunn-8714.cisco.com [10.116.190.133]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7H1Ye2D022221; Mon, 16 Aug 2010 21:34:40 -0400 (EDT) Message-ID: <4C69E72F.6090608@cisco.com> Date: Mon, 16 Aug 2010 21:34:39 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Smith, Donald" References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'draft-dugal-opsec-protect-control-plane@tools.ietf.org'" , "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 01:34:16 -0000 Donald, First thanks for the comment. It's a good one. We actually originally had it with a default drop for the all IP and default classes. However, after a good bit of discussion we (both Cisco and Juniper) felt that we should soften it up just a bit. We agreed to add the explicit match for the ALLIP class so it could be monitored and then tightened down further. We realized there were various opinions on how that should be done. ie: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html Thanks, Rodney On 8/16/10 5:16 PM, Smith, Donald wrote: > > For undesirables in JTK's paper here he specifically did a deny ip any any at the end of the cpp policy for that. > > http://aharp.ittns.northwestern.edu/papers/copp.html > > The default term for juniper is log and discard. > > There isn't a deny ip any any in the draft. > > > > (coffee != sleep)& (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Rob Bird >> Sent: Friday, March 26, 2010 11:28 AM >> To: David Dugal >> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >> opsec@ietf.org >> Subject: Re: [OPSEC] OPSEC control plane protection draft >> >> This is most excellent. I was just advising a customer this >> morning on this very issue (again). >> >> I look forward to working on this. >> Rob >> >> - >> Rob Bird, Chief Technology Officer >> Red Lambda, Inc. >> "Network security at global scale" >> www.redlambda.com >> >> On Mar 26, 2010 1:03 PM, "David Dugal" >> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Richard. >> >> Thank you very much for the scrutiny, analysis and feedback. As >> mentioned during my brief presentation, our hope is that this >> recommendation by example will provide awareness of a >> possible attack >> surface occasionally overlooked, especially by smaller or newer >> installations. >> >> I appreciate the feedback and will enhance the draft to >> make reference >> to cryptographic security, as well as attempt to make >> the document IP >> version agnostic. >> >> Thank you for your support, both in carefully reading >> the document, and >> for your willingness to have our draft taken under the >> OPSEC WG wing. >> >> - --- >> David G. Dugal Support: >> +1-408-745-9500 >> Security Incident Response Team Direct: >> +1-978-589-0719 >> Juniper Networks Mobile: >> +1-603-377-1162 >> Westford, MA, USA PGP Key: 0xAB6E02A5 >> >> >> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >> Time), Richard >> Graveman proclaimed ... >> >> >> > David, >> > >> > I read the draft carefully after the meeting and >> realize that my >> > comments missed the... >> >> > . >> > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (MingW32) >> >> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr >> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >> =kitD >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.o... >> >> > > 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. > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From christopher.morrow@gmail.com Mon Aug 16 18:58:10 2010 Return-Path: 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 083AC3A6876 for ; Mon, 16 Aug 2010 18:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, 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 npRFSODn-m1i for ; Mon, 16 Aug 2010 18:58:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 3B8333A689C for ; Mon, 16 Aug 2010 18:58:08 -0700 (PDT) Received: by eyb7 with SMTP id 7so3048485eyb.31 for ; Mon, 16 Aug 2010 18:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nWW4oNCgNCM+bI5gBWYd+f6VY7zfYqlnW2O1ZhU1jWQ=; b=KP/vedAn0hXW0BgM1ilj7b2idjzgSaV2wCxF4yy6XoXMwFMxqs2vrNqeax0eMWBRph PTHgALA1dNoS2dz+xAyIJV2zva1v8wX9hFUJWSrVkkWgCOZQKIHhuuR48zq35yCRXZU0 3iP8d7fIkezro6xlj+6P+38hvCsFRqu7eSl/I= 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=gX94VERvpT66CHVsgF4piHJ378NOrzSjwTDXzqCkDxDtTB7N/0T9tzc6hKRLFQYQma Z3rvXaG6kDw0ZWMbqtI6gPlCiOgw4CJFViy59l75ACHEAFCejC73UEqzEy87y5AzhIyh Ik5qrIidN91Xc+wFZfmBq2g/IsAZIgCa1BfjY= MIME-Version: 1.0 Received: by 10.213.112.201 with SMTP id x9mr1474501ebp.56.1282010323172; Mon, 16 Aug 2010 18:58:43 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.106.4 with HTTP; Mon, 16 Aug 2010 18:58:43 -0700 (PDT) In-Reply-To: <4C69E72F.6090608@cisco.com> References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> Date: Mon, 16 Aug 2010 21:58:43 -0400 X-Google-Sender-Auth: RIJwwZPHOx_V0dHGcDgp_wjZ0gM Message-ID: From: Christopher Morrow To: rodunn@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-dugal-opsec-protect-control-plane@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 01:58:10 -0000 On Mon, Aug 16, 2010 at 9:34 PM, Rodney Dunn wrote: > Donald, > > First thanks for the comment. It's a good one. We actually originally had= it > with a default drop for the all IP and default classes. However, after a > good bit of discussion we (both Cisco and Juniper) felt that we should > soften it up just a bit. We agreed to add the explicit match for the ALLI= P > class so it could be monitored and then tightened down further. > > We realized there were various opinions on how that should be done. can we get a 'first verify complete COPP coverage, then deny all remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? It sounds like someone with a legal degree got to your final recommendation :) that, operationally, leaves the network with a whole to plug, and I can guarantee that someone with a scanning virus is gonna fill it for you :( -chris > ie: > > http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html > > > Thanks, > Rodney > > > > > > On 8/16/10 5:16 PM, Smith, Donald wrote: >> >> For undesirables in JTK's paper here he specifically did a deny ip any a= ny >> at the end of the cpp policy for that. >> >> http://aharp.ittns.northwestern.edu/papers/copp.html >> >> The default term for juniper is log and discard. >> >> There isn't a deny ip any any in the draft. >> >> >> >> (coffee !=3D sleep)& =A0(!coffee =3D=3D sleep) >> Donald.Smith@qwest.com gcia >> >>> -----Original Message----- >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>> On Behalf Of Rob Bird >>> Sent: Friday, March 26, 2010 11:28 AM >>> To: David Dugal >>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >>> opsec@ietf.org >>> Subject: Re: [OPSEC] OPSEC control plane protection draft >>> >>> This is most excellent. I was just advising a customer this >>> morning on this very issue (again). >>> >>> I look forward to working on this. >>> Rob >>> >>> - >>> Rob Bird, Chief Technology Officer >>> Red Lambda, Inc. >>> "Network security at global scale" >>> www.redlambda.com >>> >>> =A0 =A0 =A0 On Mar 26, 2010 1:03 PM, "David Dugal" >>> =A0wrote: >>> >>> =A0 =A0 =A0 -----BEGIN PGP SIGNED MESSAGE----- >>> =A0 =A0 =A0 Hash: SHA1 >>> >>> =A0 =A0 =A0 Hi Richard. >>> >>> =A0 =A0 =A0 Thank you very much for the scrutiny, analysis and feedback= . =A0As >>> =A0 =A0 =A0 mentioned during my brief presentation, our hope is that th= is >>> =A0 =A0 =A0 recommendation by example will provide awareness of a >>> possible attack >>> =A0 =A0 =A0 surface occasionally overlooked, especially by smaller or n= ewer >>> =A0 =A0 =A0 installations. >>> >>> =A0 =A0 =A0 I appreciate the feedback and will enhance the draft to >>> make reference >>> =A0 =A0 =A0 to cryptographic security, as well as attempt to make >>> the document IP >>> =A0 =A0 =A0 version agnostic. >>> >>> =A0 =A0 =A0 Thank you for your support, both in carefully reading >>> the document, and >>> =A0 =A0 =A0 for your willingness to have our draft taken under the >>> OPSEC WG wing. >>> >>> =A0 =A0 =A0 - --- >>> =A0 =A0 =A0 David G. Dugal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Support: >>> +1-408-745-9500 >>> =A0 =A0 =A0 Security Incident Response Team =A0 =A0 =A0 =A0 =A0Direct: >>> +1-978-589-0719 >>> =A0 =A0 =A0 Juniper Networks =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Mobile: >>> +1-603-377-1162 >>> =A0 =A0 =A0 Westford, MA, USA =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0PGP Key: 0xAB6E02A5 >>> >>> >>> =A0 =A0 =A0 On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >>> Time), Richard >>> =A0 =A0 =A0 Graveman =A0proclaimed ... >>> >>> >>> =A0 =A0 =A0 > =A0David, >>> =A0 =A0 =A0 > >>> =A0 =A0 =A0 > =A0I read the draft carefully after the meeting and >>> realize that my >>> =A0 =A0 =A0 > =A0comments missed the... >>> >>> =A0 =A0 =A0 > =A0. >>> =A0 =A0 =A0 > >>> =A0 =A0 =A0 -----BEGIN PGP SIGNATURE----- >>> =A0 =A0 =A0 Version: GnuPG v1.4.10 (MingW32) >>> >>> =A0 =A0 =A0 iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aO= ITHRr >>> =A0 =A0 =A0 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >>> =A0 =A0 =A0 =3DkitD >>> =A0 =A0 =A0 -----END PGP SIGNATURE----- >>> >>> >>> =A0 =A0 =A0 _______________________________________________ >>> =A0 =A0 =A0 OPSEC mailing list >>> =A0 =A0 =A0 OPSEC@ietf.org >>> =A0 =A0 =A0 https://www.ietf.o... >>> >>> >> >> This communication is the property of Qwest and may contain confidential >> or >> privileged information. Unauthorized use of this communication is strict= ly >> prohibited and may be unlawful. =A0If you have received this communicati= on >> in error, please immediately notify the sender by reply e-mail and destr= oy >> all copies of the communication and any attachments. >> _______________________________________________ >> 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 > From Donald.Smith@qwest.com Tue Aug 17 08:29:52 2010 Return-Path: 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 1BAE33A69E7 for ; Tue, 17 Aug 2010 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 Z3H4cZq1wzNi for ; Tue, 17 Aug 2010 08:29:50 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 4FB593A6862 for ; Tue, 17 Aug 2010 08:29:49 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o7HFUMxn010000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Aug 2010 09:30:22 -0600 (MDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id o7HFUGoo019514; Tue, 17 Aug 2010 10:30:16 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 17 Aug 2010 09:30:16 -0600 From: "Smith, Donald" To: "'Christopher Morrow'" , "'rodunn@cisco.com'" Date: Tue, 17 Aug 2010 09:30:15 -0600 Thread-Topic: [OPSEC] OPSEC control plane protection draft Thread-Index: Acs9r7pt/v6zn+1RQhOkR4PDhs7HXwAcFy8w Message-ID: References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'draft-dugal-opsec-protect-control-plane@tools.ietf.org'" , "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:29:52 -0000 While difficult to get right leaving a hole to allow "unknown stuff" to go = to the control plane is counter-intuitive if we are talking about protectin= g the control plane. When I write about mitigations for router vulnerabilities within our networ= k one of the things I often include in the mitigations is the fact that the= services and control plane of the routers is locked down. Almost locked do= wn with a hole that may or may not allow something that could trigger the v= ulnerability is not as good:) This is one of the reasons we had that whole logging of exceptions/dropped = traffic discussion a while back. Not just a counter actual logging (sampled ok, syslog or snmp ... ok ... bu= t some logging of traffic similar to a netflow record would be helpful). (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: christopher.morrow@gmail.com > [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow > Sent: Monday, August 16, 2010 7:59 PM > To: rodunn@cisco.com > Cc: Smith, Donald; > draft-dugal-opsec-protect-control-plane@tools.ietf.org; opsec@ietf.org > Subject: Re: [OPSEC] OPSEC control plane protection draft > > On Mon, Aug 16, 2010 at 9:34 PM, Rodney Dunn wrote: > > Donald, > > > > First thanks for the comment. It's a good one. We actually > originally had it > > with a default drop for the all IP and default classes. > However, after a > > good bit of discussion we (both Cisco and Juniper) felt > that we should > > soften it up just a bit. We agreed to add the explicit > match for the ALLIP > > class so it could be monitored and then tightened down further. > > > > We realized there were various opinions on how that should be done. > > can we get a 'first verify complete COPP coverage, then deny all > remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? > > It sounds like someone with a legal degree got to your final > recommendation :) that, operationally, leaves the network with a whole > to plug, and I can guarantee that someone with a scanning virus is > gonna fill it for you :( > > -chris > > > ie: > > > > http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html > > > > > > Thanks, > > Rodney > > > > > > > > > > > > On 8/16/10 5:16 PM, Smith, Donald wrote: > >> > >> For undesirables in JTK's paper here he specifically did a > deny ip any any > >> at the end of the cpp policy for that. > >> > >> http://aharp.ittns.northwestern.edu/papers/copp.html > >> > >> The default term for juniper is log and discard. > >> > >> There isn't a deny ip any any in the draft. > >> > >> > >> > >> (coffee !=3D sleep)& (!coffee =3D=3D sleep) > >> Donald.Smith@qwest.com gcia > >> > >>> -----Original Message----- > >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > >>> On Behalf Of Rob Bird > >>> Sent: Friday, March 26, 2010 11:28 AM > >>> To: David Dugal > >>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; > >>> opsec@ietf.org > >>> Subject: Re: [OPSEC] OPSEC control plane protection draft > >>> > >>> This is most excellent. I was just advising a customer this > >>> morning on this very issue (again). > >>> > >>> I look forward to working on this. > >>> Rob > >>> > >>> - > >>> Rob Bird, Chief Technology Officer > >>> Red Lambda, Inc. > >>> "Network security at global scale" > >>> www.redlambda.com > >>> > >>> On Mar 26, 2010 1:03 PM, "David Dugal" > >>> wrote: > >>> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> Hi Richard. > >>> > >>> Thank you very much for the scrutiny, analysis and > feedback. As > >>> mentioned during my brief presentation, our hope is > that this > >>> recommendation by example will provide awareness of a > >>> possible attack > >>> surface occasionally overlooked, especially by > smaller or newer > >>> installations. > >>> > >>> I appreciate the feedback and will enhance the draft to > >>> make reference > >>> to cryptographic security, as well as attempt to make > >>> the document IP > >>> version agnostic. > >>> > >>> Thank you for your support, both in carefully reading > >>> the document, and > >>> for your willingness to have our draft taken under the > >>> OPSEC WG wing. > >>> > >>> - --- > >>> David G. Dugal Support: > >>> +1-408-745-9500 > >>> Security Incident Response Team Direct: > >>> +1-978-589-0719 > >>> Juniper Networks Mobile: > >>> +1-603-377-1162 > >>> Westford, MA, USA PGP Key: 0xAB6E02A5 > >>> > >>> > >>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight > >>> Time), Richard > >>> Graveman proclaimed ... > >>> > >>> > >>> > David, > >>> > > >>> > I read the draft carefully after the meeting and > >>> realize that my > >>> > comments missed the... > >>> > >>> > . > >>> > > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG v1.4.10 (MingW32) > >>> > >>> > iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr > >>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN > >>> =3DkitD > >>> -----END PGP SIGNATURE----- > >>> > >>> > >>> _______________________________________________ > >>> OPSEC mailing list > >>> OPSEC@ietf.org > >>> https://www.ietf.o... > >>> > >>> > >> > >> 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. > >> _______________________________________________ > >> 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. From christopher.morrow@gmail.com Tue Aug 17 10:42:51 2010 Return-Path: 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 66DCB3A6845 for ; Tue, 17 Aug 2010 10:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HohwnavplvV4 for ; Tue, 17 Aug 2010 10:42:50 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 159023A6988 for ; Tue, 17 Aug 2010 10:42:38 -0700 (PDT) Received: by gwb20 with SMTP id 20so44674gwb.31 for ; Tue, 17 Aug 2010 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O9OFh9tv1x+0RlEHTnDwW3eHOb1ibI7X9/j9+C7xDXM=; b=dNTpO3F7NHepiSQ7Tf7qYSEXmKun7mWoHVywNqaziy9af5zTBCkmJYJP1RDU8r5wcg qx8blQbiXVUui+JGrsrEkD7DbAQpH/jDm9wtb7b4dfDMy1jqgCYrePBxwmutqHaNip1A WrIuUevSBNEQ0Knd//zNbJ/jayr+SrpYUzrDk= 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=ekdZL5GzMSyNswQZbe0VFRhVcls9/gj/XCYfkBYSppO4p/OG2Tel7cgNhyUr18yRYR DyCiy4ZrBP9ooUMxY61tAZ73+/V0otp6u4KwEXjeJUcTi9woUWJWZZ2qnWPa1Qq1YZBM rewGo/+C3j76SdPGH1Y0baThDABlqP3fIcQD8= MIME-Version: 1.0 Received: by 10.231.174.72 with SMTP id s8mr8068447ibz.41.1282066993040; Tue, 17 Aug 2010 10:43:13 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.156.203 with HTTP; Tue, 17 Aug 2010 10:43:12 -0700 (PDT) In-Reply-To: References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> Date: Tue, 17 Aug 2010 13:43:12 -0400 X-Google-Sender-Auth: o9prawHORO4JffT3OZ8LBzWC4rg Message-ID: From: Christopher Morrow To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-dugal-opsec-protect-control-plane@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:42:51 -0000 On Tue, Aug 17, 2010 at 11:30 AM, Smith, Donald wr= ote: > While difficult to get right leaving a hole to allow "unknown stuff" to g= o to the control plane is counter-intuitive if we are talking about protect= ing the control plane. > > When I write about mitigations for router vulnerabilities within our netw= ork one of the things I often include in the mitigations is the fact that t= he services and control plane of the routers is locked down. Almost locked = down with a hole that may or may not allow something that could trigger the= vulnerability is not as good:) > > This is one of the reasons we had that whole logging of exceptions/droppe= d traffic discussion a while back. > Not just a counter actual logging (sampled ok, syslog or snmp ... ok ... = but some logging of traffic similar to a netflow record would be helpful). +1 to the entire message here... you just don't want to leave open holes, ever, in critical infrastructure. -chris > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: christopher.morrow@gmail.com >> [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow >> Sent: Monday, August 16, 2010 7:59 PM >> To: rodunn@cisco.com >> Cc: Smith, Donald; >> draft-dugal-opsec-protect-control-plane@tools.ietf.org; opsec@ietf.org >> Subject: Re: [OPSEC] OPSEC control plane protection draft >> >> On Mon, Aug 16, 2010 at 9:34 PM, Rodney Dunn wrote: >> > Donald, >> > >> > First thanks for the comment. It's a good one. We actually >> originally had it >> > with a default drop for the all IP and default classes. >> However, after a >> > good bit of discussion we (both Cisco and Juniper) felt >> that we should >> > soften it up just a bit. We agreed to add the explicit >> match for the ALLIP >> > class so it could be monitored and then tightened down further. >> > >> > We realized there were various opinions on how that should be done. >> >> can we get a 'first verify complete COPP coverage, then deny all >> remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? >> >> It sounds like someone with a legal degree got to your final >> recommendation :) that, operationally, leaves the network with a whole >> to plug, and I can guarantee that someone with a scanning virus is >> gonna fill it for you :( >> >> -chris >> >> > ie: >> > >> > http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html >> > >> > >> > Thanks, >> > Rodney >> > >> > >> > >> > >> > >> > On 8/16/10 5:16 PM, Smith, Donald wrote: >> >> >> >> For undesirables in JTK's paper here he specifically did a >> deny ip any any >> >> at the end of the cpp policy for that. >> >> >> >> http://aharp.ittns.northwestern.edu/papers/copp.html >> >> >> >> The default term for juniper is log and discard. >> >> >> >> There isn't a deny ip any any in the draft. >> >> >> >> >> >> >> >> (coffee !=3D sleep)& =A0(!coffee =3D=3D sleep) >> >> Donald.Smith@qwest.com gcia >> >> >> >>> -----Original Message----- >> >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> >>> On Behalf Of Rob Bird >> >>> Sent: Friday, March 26, 2010 11:28 AM >> >>> To: David Dugal >> >>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >> >>> opsec@ietf.org >> >>> Subject: Re: [OPSEC] OPSEC control plane protection draft >> >>> >> >>> This is most excellent. I was just advising a customer this >> >>> morning on this very issue (again). >> >>> >> >>> I look forward to working on this. >> >>> Rob >> >>> >> >>> - >> >>> Rob Bird, Chief Technology Officer >> >>> Red Lambda, Inc. >> >>> "Network security at global scale" >> >>> www.redlambda.com >> >>> >> >>> =A0 =A0 =A0 On Mar 26, 2010 1:03 PM, "David Dugal" >> >>> =A0wrote: >> >>> >> >>> =A0 =A0 =A0 -----BEGIN PGP SIGNED MESSAGE----- >> >>> =A0 =A0 =A0 Hash: SHA1 >> >>> >> >>> =A0 =A0 =A0 Hi Richard. >> >>> >> >>> =A0 =A0 =A0 Thank you very much for the scrutiny, analysis and >> feedback. =A0As >> >>> =A0 =A0 =A0 mentioned during my brief presentation, our hope is >> that this >> >>> =A0 =A0 =A0 recommendation by example will provide awareness of a >> >>> possible attack >> >>> =A0 =A0 =A0 surface occasionally overlooked, especially by >> smaller or newer >> >>> =A0 =A0 =A0 installations. >> >>> >> >>> =A0 =A0 =A0 I appreciate the feedback and will enhance the draft to >> >>> make reference >> >>> =A0 =A0 =A0 to cryptographic security, as well as attempt to make >> >>> the document IP >> >>> =A0 =A0 =A0 version agnostic. >> >>> >> >>> =A0 =A0 =A0 Thank you for your support, both in carefully reading >> >>> the document, and >> >>> =A0 =A0 =A0 for your willingness to have our draft taken under the >> >>> OPSEC WG wing. >> >>> >> >>> =A0 =A0 =A0 - --- >> >>> =A0 =A0 =A0 David G. Dugal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Support: >> >>> +1-408-745-9500 >> >>> =A0 =A0 =A0 Security Incident Response Team =A0 =A0 =A0 =A0 =A0Direc= t: >> >>> +1-978-589-0719 >> >>> =A0 =A0 =A0 Juniper Networks =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Mobile: >> >>> +1-603-377-1162 >> >>> =A0 =A0 =A0 Westford, MA, USA =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0PGP Key: 0xAB6E02A5 >> >>> >> >>> >> >>> =A0 =A0 =A0 On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >> >>> Time), Richard >> >>> =A0 =A0 =A0 Graveman =A0proclaimed ... >> >>> >> >>> >> >>> =A0 =A0 =A0 > =A0David, >> >>> =A0 =A0 =A0 > >> >>> =A0 =A0 =A0 > =A0I read the draft carefully after the meeting and >> >>> realize that my >> >>> =A0 =A0 =A0 > =A0comments missed the... >> >>> >> >>> =A0 =A0 =A0 > =A0. >> >>> =A0 =A0 =A0 > >> >>> =A0 =A0 =A0 -----BEGIN PGP SIGNATURE----- >> >>> =A0 =A0 =A0 Version: GnuPG v1.4.10 (MingW32) >> >>> >> >>> >> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr >> >>> =A0 =A0 =A0 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >> >>> =A0 =A0 =A0 =3DkitD >> >>> =A0 =A0 =A0 -----END PGP SIGNATURE----- >> >>> >> >>> >> >>> =A0 =A0 =A0 _______________________________________________ >> >>> =A0 =A0 =A0 OPSEC mailing list >> >>> =A0 =A0 =A0 OPSEC@ietf.org >> >>> =A0 =A0 =A0 https://www.ietf.o... >> >>> >> >>> >> >> >> >> 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. =A0If 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. >> >> _______________________________________________ >> >> 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 strictl= y > prohibited and may be unlawful. =A0If you have received this communicatio= n > in error, please immediately notify the sender by reply e-mail and destro= y > all copies of the communication and any attachments. > From jared@puck.nether.net Tue Aug 17 11:21:15 2010 Return-Path: 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 B32CA3A6804 for ; Tue, 17 Aug 2010 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 LHwxQzFCbJtu for ; Tue, 17 Aug 2010 11:21:14 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id B485D3A659C for ; Tue, 17 Aug 2010 11:21:14 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id o7HIN2uB072154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Aug 2010 14:23:03 -0400 (EDT) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 17 Aug 2010 14:21:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (puck.nether.net [204.42.254.5]); Tue, 17 Aug 2010 14:23:03 -0400 (EDT) Cc: "draft-dugal-opsec-protect-control-plane@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:21:15 -0000 On Aug 17, 2010, at 1:43 PM, Christopher Morrow wrote: > On Tue, Aug 17, 2010 at 11:30 AM, Smith, Donald = wrote: >> While difficult to get right leaving a hole to allow "unknown stuff" = to go to the control plane is counter-intuitive if we are talking about = protecting the control plane. >>=20 >> When I write about mitigations for router vulnerabilities within our = network one of the things I often include in the mitigations is the fact = that the services and control plane of the routers is locked down. = Almost locked down with a hole that may or may not allow something that = could trigger the vulnerability is not as good:) >>=20 >> This is one of the reasons we had that whole logging of = exceptions/dropped traffic discussion a while back. >> Not just a counter actual logging (sampled ok, syslog or snmp ... ok = ... but some logging of traffic similar to a netflow record would be = helpful). >=20 > +1 to the entire message here... you just don't want to leave open > holes, ever, in critical infrastructure. +2 - Jared= From rodunn@cisco.com Tue Aug 17 13:02:55 2010 Return-Path: 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 0FF333A685C for ; Tue, 17 Aug 2010 13:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 XqFqxEMsPgFc for ; Tue, 17 Aug 2010 13:02:50 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 8AEE13A67F3 for ; Tue, 17 Aug 2010 13:02:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7HK3PtX006144; Tue, 17 Aug 2010 16:03:25 -0400 (EDT) Received: from dhcp-64-102-220-209.cisco.com (dhcp-64-102-220-209.cisco.com [64.102.220.209]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7HK3OPh006942; Tue, 17 Aug 2010 16:03:24 -0400 (EDT) Message-ID: <4C6AEB97.2010501@cisco.com> Date: Tue, 17 Aug 2010 16:05:43 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Christopher Morrow References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:02:55 -0000 We agree that the end goal should be to lock the device down to the most granular degree possible. We made an effort to highlight that at various places in the document. I like your suggestion to add an additional paragraph specifically highlighting the importance of getting to a point where the default traffic would be a drop. Could you review the paragraph below between *-*'s and make suggestions to wording if it's not explicit or clear enough? Thanks, Rodney Some references already in the document are... ie: Section 3.2 Filter Design ..By adjusting the granularity and order of the filters more granular forensics can be performed... In addition to the filters, rate-limiters for certain classes of traffic are also installed in the forwarding plane as defined in Section 3.1. These rate limiters help futher control the traffic that will reach the control plane for each filtered class as well as all traffic not matching an explicit class. The actual rates selected for various classes is network deployment specific and analysis of required rates for stability should be done periodically. and the note for the catch all: Syntactically, these filters explicitly define "allowed" traffic (including IP addresses, protocols, and ports), define acceptable actions for these acceptable traffic profiles (e.g., rate-limit or simply permit the traffic), and then drop to the bit bucket all traffic destined to the router control plane that is not within the specifications of the policy definition. and in Section 3.3 we wanted to articulate the importance of locking it down as granular as possible: ...The goal of the method for protecting the router control plane is to minimize the possibility for disruptions by reducing the vulnerable surface. The latter is inversely proportional to the granularity of the filter design. The finer the granularity of the filter design (e.g., isolating a more targeted subset of traffic from the rest of the policed traffic, or isolating valid source addresses into a different class or classes) the smaller the probability of disruption. ... What about if we add this in the Design Trade-Off section to address the concern so we will be more precise. *In addition to the traffic matching explicit classes care should be taken on the policy decision that governs the handling of traffic that would fall through the policy. Typically that traffic is referred to as traffic falling in the default class. It may also be traffic that matches a generic protocol specific class where previous classes that have more granular matching did not match all packets for that specific protocol. The ideal policy would have explicit classes to match only the traffic specifically required at the control plane and drop all other traffic. This approach requires rigorous traffic pattern identification such that a default drop policy does not break existing functionality of the device. The approach defined in this document allows the default traffic and rate limits it rather than just dropping it. This approach was highlighted as a way to give time to the implementer to evaluate the traffic in a production scenario prior to dropping all traffic not explicitly matched and permitted. However, it is highly recommended that after monitoring the traffic matching the default class explicit classes should be defined such that the default class could be configured to drop traffic falling through the policy.* Rodney On 8/16/10 9:58 PM, Christopher Morrow wrote: > On Mon, Aug 16, 2010 at 9:34 PM, Rodney Dunn wrote: >> Donald, >> >> First thanks for the comment. It's a good one. We actually originally had it >> with a default drop for the all IP and default classes. However, after a >> good bit of discussion we (both Cisco and Juniper) felt that we should >> soften it up just a bit. We agreed to add the explicit match for the ALLIP >> class so it could be monitored and then tightened down further. >> >> We realized there were various opinions on how that should be done. > > can we get a 'first verify complete COPP coverage, then deny all > remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? > > It sounds like someone with a legal degree got to your final > recommendation :) that, operationally, leaves the network with a whole > to plug, and I can guarantee that someone with a scanning virus is > gonna fill it for you :( > > -chris > >> ie: >> >> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html >> >> >> Thanks, >> Rodney >> >> >> >> >> >> On 8/16/10 5:16 PM, Smith, Donald wrote: >>> >>> For undesirables in JTK's paper here he specifically did a deny ip any any >>> at the end of the cpp policy for that. >>> >>> http://aharp.ittns.northwestern.edu/papers/copp.html >>> >>> The default term for juniper is log and discard. >>> >>> There isn't a deny ip any any in the draft. >>> >>> >>> >>> (coffee != sleep)& (!coffee == sleep) >>> Donald.Smith@qwest.com gcia >>> >>>> -----Original Message----- >>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>> On Behalf Of Rob Bird >>>> Sent: Friday, March 26, 2010 11:28 AM >>>> To: David Dugal >>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >>>> opsec@ietf.org >>>> Subject: Re: [OPSEC] OPSEC control plane protection draft >>>> >>>> This is most excellent. I was just advising a customer this >>>> morning on this very issue (again). >>>> >>>> I look forward to working on this. >>>> Rob >>>> >>>> - >>>> Rob Bird, Chief Technology Officer >>>> Red Lambda, Inc. >>>> "Network security at global scale" >>>> www.redlambda.com >>>> >>>> On Mar 26, 2010 1:03 PM, "David Dugal" >>>> wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi Richard. >>>> >>>> Thank you very much for the scrutiny, analysis and feedback. As >>>> mentioned during my brief presentation, our hope is that this >>>> recommendation by example will provide awareness of a >>>> possible attack >>>> surface occasionally overlooked, especially by smaller or newer >>>> installations. >>>> >>>> I appreciate the feedback and will enhance the draft to >>>> make reference >>>> to cryptographic security, as well as attempt to make >>>> the document IP >>>> version agnostic. >>>> >>>> Thank you for your support, both in carefully reading >>>> the document, and >>>> for your willingness to have our draft taken under the >>>> OPSEC WG wing. >>>> >>>> - --- >>>> David G. Dugal Support: >>>> +1-408-745-9500 >>>> Security Incident Response Team Direct: >>>> +1-978-589-0719 >>>> Juniper Networks Mobile: >>>> +1-603-377-1162 >>>> Westford, MA, USA PGP Key: 0xAB6E02A5 >>>> >>>> >>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >>>> Time), Richard >>>> Graveman proclaimed ... >>>> >>>> >>>> > David, >>>> > >>>> > I read the draft carefully after the meeting and >>>> realize that my >>>> > comments missed the... >>>> >>>> > . >>>> > >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.10 (MingW32) >>>> >>>> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr >>>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >>>> =kitD >>>> -----END PGP SIGNATURE----- >>>> >>>> >>>> _______________________________________________ >>>> OPSEC mailing list >>>> OPSEC@ietf.org >>>> https://www.ietf.o... >>>> >>>> >>> >>> 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. >>> _______________________________________________ >>> 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 >> From Donald.Smith@qwest.com Tue Aug 17 13:24:44 2010 Return-Path: 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 044353A687D for ; Tue, 17 Aug 2010 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 zc6ApHFAgWUc for ; Tue, 17 Aug 2010 13:24:42 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 45BAD3A687A for ; Tue, 17 Aug 2010 13:24:42 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o7HKPFAh008782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Aug 2010 14:25:15 -0600 (MDT) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o7HKP9IY003561; Tue, 17 Aug 2010 15:25:09 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Tue, 17 Aug 2010 14:25:09 -0600 From: "Smith, Donald" To: "'rodunn@cisco.com'" , "'Christopher Morrow'" Date: Tue, 17 Aug 2010 14:25:07 -0600 Thread-Topic: [OPSEC] OPSEC control plane protection draft Thread-Index: Acs+R0KFdj34IMMFT4i9mq/b63VIzwAAnYqA Message-ID: References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> <4C6AEB97.2010501@cisco.com> In-Reply-To: <4C6AEB97.2010501@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:24:44 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Rodney Dunn [mailto:rodunn@cisco.com] > Sent: Tuesday, August 17, 2010 2:06 PM > To: Christopher Morrow > Cc: Smith, Donald; opsec@ietf.org; opsec@ietf.org > Subject: Re: [OPSEC] OPSEC control plane protection draft > > We agree that the end goal should be to lock the device down > to the most > granular degree possible. We made an effort to highlight that > at various > places in the document. I like your suggestion to add an additional > paragraph specifically highlighting the importance of getting > to a point > where the default traffic would be a drop. Could you review the > paragraph below between *-*'s and make suggestions to wording if it's > not explicit or clear enough? > > Thanks, > Rodney > > Some references already in the document are... > > ie: Section 3.2 Filter Design > > ..By adjusting the granularity and order of the filters more > granular forensics can be performed... > > In addition to the filters, rate-limiters for certain classes of > traffic are also installed in the forwarding plane as defined in > Section 3.1. These rate limiters help futher control the traffic > that will reach the control plane for each filtered class > as well as > all traffic not matching an explicit class. The actual rates > selected for various classes is network deployment specific and > analysis of required rates for stability should be done > periodically. > > and the note for the catch all: > > Syntactically, these filters explicitly define "allowed" traffic > (including IP addresses, protocols, and ports), define acceptable > actions for these acceptable traffic profiles (e.g., rate-limit or > simply permit the traffic), and then drop to the bit bucket all > traffic destined to the router control plane that is not > within the > specifications of the policy definition. > > > and in Section 3.3 we wanted to articulate the importance of > locking it > down as granular as possible: > > ...The goal of the method for protecting the router control > plane is to > minimize the possibility for disruptions by reducing the > vulnerable > surface. The latter is inversely proportional to the > granularity of > the filter design. The finer the granularity of the filter design > (e.g., isolating a more targeted subset of traffic from > the rest of > the policed traffic, or isolating valid source addresses into a > different class or classes) the smaller the probability of > disruption. > ... > > What about if we add this in the Design > Trade-Off section to address the concern so we will be more precise. > > *In addition to the traffic matching explicit classes care should be > taken on the policy decision that governs the handling of > traffic that > would fall through the policy. Do we need to say that by convention there is no default deny at the end of= a cpp policy? >Typically that traffic is > referred to as > traffic falling in the default class. It may also be traffic that into the default ... > matches a generic protocol specific class where previous classes that > have more granular matching did not match all packets for > that specific > protocol. The ideal policy would have explicit classes to > match only the > traffic specifically required at the control plane and drop all other > traffic. This approach requires rigorous traffic pattern > identification > such that a default drop policy does not break existing > functionality of > the device. The approach defined in this document allows the default > traffic and rate limits it rather than just dropping it. This > approach > was highlighted as a way to give time to the implementer to > evaluate the > traffic in a production scenario prior to dropping all traffic not > explicitly matched and permitted. However, it is highly > recommended that > after monitoring the traffic matching the default class > explicit classes > should be defined such that the default class could be configured to > drop traffic falling through the policy.* Can we add a COMMENTED OUT deny ip any any in the default policy with a "do not enable until throughly tested in production ..." type statement. > > > Rodney > > > > On 8/16/10 9:58 PM, Christopher Morrow wrote: > > On Mon, Aug 16, 2010 at 9:34 PM, Rodney > Dunn wrote: > >> Donald, > >> > >> First thanks for the comment. It's a good one. We actually > originally had it > >> with a default drop for the all IP and default classes. > However, after a > >> good bit of discussion we (both Cisco and Juniper) felt > that we should > >> soften it up just a bit. We agreed to add the explicit > match for the ALLIP > >> class so it could be monitored and then tightened down further. > >> > >> We realized there were various opinions on how that should be done. > > > > can we get a 'first verify complete COPP coverage, then deny all > > remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? > > > > It sounds like someone with a legal degree got to your final > > recommendation :) that, operationally, leaves the network > with a whole > > to plug, and I can guarantee that someone with a scanning virus is > > gonna fill it for you :( > > > > -chris > > > >> ie: > >> > >> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html > >> > >> > >> Thanks, > >> Rodney > >> > >> > >> > >> > >> > >> On 8/16/10 5:16 PM, Smith, Donald wrote: > >>> > >>> For undesirables in JTK's paper here he specifically did > a deny ip any any > >>> at the end of the cpp policy for that. > >>> > >>> http://aharp.ittns.northwestern.edu/papers/copp.html > >>> > >>> The default term for juniper is log and discard. > >>> > >>> There isn't a deny ip any any in the draft. > >>> > >>> > >>> > >>> (coffee !=3D sleep)& (!coffee =3D=3D sleep) > >>> Donald.Smith@qwest.com gcia > >>> > >>>> -----Original Message----- > >>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > >>>> On Behalf Of Rob Bird > >>>> Sent: Friday, March 26, 2010 11:28 AM > >>>> To: David Dugal > >>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; > >>>> opsec@ietf.org > >>>> Subject: Re: [OPSEC] OPSEC control plane protection draft > >>>> > >>>> This is most excellent. I was just advising a customer this > >>>> morning on this very issue (again). > >>>> > >>>> I look forward to working on this. > >>>> Rob > >>>> > >>>> - > >>>> Rob Bird, Chief Technology Officer > >>>> Red Lambda, Inc. > >>>> "Network security at global scale" > >>>> www.redlambda.com > >>>> > >>>> On Mar 26, 2010 1:03 PM, "David Dugal" > >>>> wrote: > >>>> > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> Hi Richard. > >>>> > >>>> Thank you very much for the scrutiny, analysis > and feedback. As > >>>> mentioned during my brief presentation, our hope > is that this > >>>> recommendation by example will provide awareness of a > >>>> possible attack > >>>> surface occasionally overlooked, especially by > smaller or newer > >>>> installations. > >>>> > >>>> I appreciate the feedback and will enhance the draft to > >>>> make reference > >>>> to cryptographic security, as well as attempt to make > >>>> the document IP > >>>> version agnostic. > >>>> > >>>> Thank you for your support, both in carefully reading > >>>> the document, and > >>>> for your willingness to have our draft taken under the > >>>> OPSEC WG wing. > >>>> > >>>> - --- > >>>> David G. Dugal Support: > >>>> +1-408-745-9500 > >>>> Security Incident Response Team Direct: > >>>> +1-978-589-0719 > >>>> Juniper Networks Mobile: > >>>> +1-603-377-1162 > >>>> Westford, MA, USA PGP Key: > 0xAB6E02A5 > >>>> > >>>> > >>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight > >>>> Time), Richard > >>>> Graveman proclaimed ... > >>>> > >>>> > >>>> > David, > >>>> > > >>>> > I read the draft carefully after the meeting and > >>>> realize that my > >>>> > comments missed the... > >>>> > >>>> > . > >>>> > > >>>> -----BEGIN PGP SIGNATURE----- > >>>> Version: GnuPG v1.4.10 (MingW32) > >>>> > >>>> > iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr > >>>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN > >>>> =3DkitD > >>>> -----END PGP SIGNATURE----- > >>>> > >>>> > >>>> _______________________________________________ > >>>> OPSEC mailing list > >>>> OPSEC@ietf.org > >>>> https://www.ietf.o... > >>>> > >>>> > >>> > >>> 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. > >>> _______________________________________________ > >>> 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. From rodunn@cisco.com Tue Aug 17 13:47:17 2010 Return-Path: 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 3AABD3A6A25 for ; Tue, 17 Aug 2010 13:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mHEXQCDxf9i3 for ; Tue, 17 Aug 2010 13:47:15 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id E950C3A6A1F for ; Tue, 17 Aug 2010 13:47:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7HKln6u009470; Tue, 17 Aug 2010 16:47:49 -0400 (EDT) Received: from dhcp-64-102-220-209.cisco.com (dhcp-64-102-220-209.cisco.com [64.102.220.209]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7HKlnZK024150; Tue, 17 Aug 2010 16:47:49 -0400 (EDT) Message-ID: <4C6AF600.8030504@cisco.com> Date: Tue, 17 Aug 2010 16:50:08 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Smith, Donald" References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> <4C6AEB97.2010501@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:47:17 -0000 >> What about if we add this in the Design >> Trade-Off section to address the concern so we will be more precise. >> >> *In addition to the traffic matching explicit classes care should be >> taken on the policy decision that governs the handling of >> traffic that >> would fall through the policy. > Do we need to say that by convention there is no default deny at the end of a cpp policy? > > Another good catch...how about this: ....Typically that traffic is referred to as traffic falling in the default class. It may also be traffic that matches a generic protocol specific class where previous classes that have more granular matching did not match all packets for that specific protocol. The ideal policy would have explicit classes to match only the traffic specifically required at the control plane and drop all other traffic. *As most vendor implementations permit all traffic hitting the default class an explicit drop action would need to be configured in the policy such that the traffic hitting that default class would be dropped versus being delivered up to the control plane.* This approach requires rigorous traffic pattern identification such that a default drop policy does not break existing functionality of the device..... >> after monitoring the traffic matching the default class >> explicit classes >> should be defined such that the default class could be configured to >> drop traffic falling through the policy.* > > Can we add a COMMENTED OUT deny ip any any in the default policy with a > "do not enable until throughly tested in production ..." type statement. > I would prefer we cover it in the text section because that would make it harder to link the Legitimate Traffic (Section 3.1) definition to the actual configuration in the document. Rodney >> >> >> Rodney >> >> >> >> On 8/16/10 9:58 PM, Christopher Morrow wrote: >>> On Mon, Aug 16, 2010 at 9:34 PM, Rodney >> Dunn wrote: >>>> Donald, >>>> >>>> First thanks for the comment. It's a good one. We actually >> originally had it >>>> with a default drop for the all IP and default classes. >> However, after a >>>> good bit of discussion we (both Cisco and Juniper) felt >> that we should >>>> soften it up just a bit. We agreed to add the explicit >> match for the ALLIP >>>> class so it could be monitored and then tightened down further. >>>> >>>> We realized there were various opinions on how that should be done. >>> >>> can we get a 'first verify complete COPP coverage, then deny all >>> remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? >>> >>> It sounds like someone with a legal degree got to your final >>> recommendation :) that, operationally, leaves the network >> with a whole >>> to plug, and I can guarantee that someone with a scanning virus is >>> gonna fill it for you :( >>> >>> -chris >>> >>>> ie: >>>> >>>> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html >>>> >>>> >>>> Thanks, >>>> Rodney >>>> >>>> >>>> >>>> >>>> >>>> On 8/16/10 5:16 PM, Smith, Donald wrote: >>>>> >>>>> For undesirables in JTK's paper here he specifically did >> a deny ip any any >>>>> at the end of the cpp policy for that. >>>>> >>>>> http://aharp.ittns.northwestern.edu/papers/copp.html >>>>> >>>>> The default term for juniper is log and discard. >>>>> >>>>> There isn't a deny ip any any in the draft. >>>>> >>>>> >>>>> >>>>> (coffee != sleep)& (!coffee == sleep) >>>>> Donald.Smith@qwest.com gcia >>>>> >>>>>> -----Original Message----- >>>>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>>>> On Behalf Of Rob Bird >>>>>> Sent: Friday, March 26, 2010 11:28 AM >>>>>> To: David Dugal >>>>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >>>>>> opsec@ietf.org >>>>>> Subject: Re: [OPSEC] OPSEC control plane protection draft >>>>>> >>>>>> This is most excellent. I was just advising a customer this >>>>>> morning on this very issue (again). >>>>>> >>>>>> I look forward to working on this. >>>>>> Rob >>>>>> >>>>>> - >>>>>> Rob Bird, Chief Technology Officer >>>>>> Red Lambda, Inc. >>>>>> "Network security at global scale" >>>>>> www.redlambda.com >>>>>> >>>>>> On Mar 26, 2010 1:03 PM, "David Dugal" >>>>>> wrote: >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Hi Richard. >>>>>> >>>>>> Thank you very much for the scrutiny, analysis >> and feedback. As >>>>>> mentioned during my brief presentation, our hope >> is that this >>>>>> recommendation by example will provide awareness of a >>>>>> possible attack >>>>>> surface occasionally overlooked, especially by >> smaller or newer >>>>>> installations. >>>>>> >>>>>> I appreciate the feedback and will enhance the draft to >>>>>> make reference >>>>>> to cryptographic security, as well as attempt to make >>>>>> the document IP >>>>>> version agnostic. >>>>>> >>>>>> Thank you for your support, both in carefully reading >>>>>> the document, and >>>>>> for your willingness to have our draft taken under the >>>>>> OPSEC WG wing. >>>>>> >>>>>> - --- >>>>>> David G. Dugal Support: >>>>>> +1-408-745-9500 >>>>>> Security Incident Response Team Direct: >>>>>> +1-978-589-0719 >>>>>> Juniper Networks Mobile: >>>>>> +1-603-377-1162 >>>>>> Westford, MA, USA PGP Key: >> 0xAB6E02A5 >>>>>> >>>>>> >>>>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >>>>>> Time), Richard >>>>>> Graveman proclaimed ... >>>>>> >>>>>> >>>>>> > David, >>>>>> > >>>>>> > I read the draft carefully after the meeting and >>>>>> realize that my >>>>>> > comments missed the... >>>>>> >>>>>> > . >>>>>> > >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v1.4.10 (MingW32) >>>>>> >>>>>> >> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr >>>>>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >>>>>> =kitD >>>>>> -----END PGP SIGNATURE----- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OPSEC mailing list >>>>>> OPSEC@ietf.org >>>>>> https://www.ietf.o... >>>>>> >>>>>> >>>>> >>>>> 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. >>>>> _______________________________________________ >>>>> 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. From rodunn@cisco.com Thu Aug 19 13:39:22 2010 Return-Path: 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 8E1CD3A6802 for ; Thu, 19 Aug 2010 13:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 p1i6OAeZcOvF for ; Thu, 19 Aug 2010 13:39:20 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1FA523A67AC for ; Thu, 19 Aug 2010 13:39:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7JKdsZB010306; Thu, 19 Aug 2010 16:39:54 -0400 (EDT) Received: from dhcp-64-102-157-1.cisco.com (dhcp-64-102-157-1.cisco.com [64.102.157.1]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7JKdpU4023168; Thu, 19 Aug 2010 16:39:51 -0400 (EDT) Message-ID: <4C6D9725.4080505@cisco.com> Date: Thu, 19 Aug 2010 16:42:13 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: rodunn@cisco.com References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> <4C6AEB97.2010501@cisco.com> <4C6AF600.8030504@cisco.com> In-Reply-To: <4C6AF600.8030504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:39:22 -0000 The current proposal on the table is the additional paragraph in Section 3.3 "Design Trade-offs" section to add the following paragraph between *-*'s. The purpose of this paragraph is to highlight that the end goal would be to have a COPP policy that is as explicit as possible on what to permit and dropping all other traffic. Does the list agree that this paragraph accurately reflects that desire? Section 3.3 "Design Trade-offs" ... The goal of the method for protecting the router control plane is to minimize the possibility for disruptions by reducing the vulnerable surface. The latter is inversely proportional to the granularity of the filter design. The finer the granularity of the filter design (e.g., isolating a more targeted subset of traffic from the rest of the policed traffic, or isolating valid source addresses into a different class or classes) the smaller the probability of disruption. *In addition to the traffic matching explicit classes care should be taken on the policy decision that governs the handling of traffic that would fall through the policy. Typically that traffic is referred to as traffic that gets matched in a default class. It may also be traffic that matches a protocol specific class where previous classes that have more granular matching did not match all packets for that specific protocol. The ideal policy would have explicit classes to match only the traffic specifically required at the control plane and drop all other traffic that does not mach a predefined class. As most vendor implementations permit all traffic hitting the default class an explicit drop action would need to be configured in the policy such that the traffic hitting that default class would be dropped versus permitted and then delivered to the control plane. This approach requires rigorous traffic pattern identification such that a default drop policy does not break existing functionality of the device. The approach defined in this document allows the default traffic and rate limits it rather than just dropping it. This approach was highlighted as a way to give time for the implementer to evaluate the traffic in a production scenario prior to dropping all traffic not explicitly matched and permitted. However, it is highly recommended that after monitoring the traffic matching the default class that explicit classes be defined to catch the legitimate traffic. After all legitimate traffic is being explicitly matched the default class should be configured to drop any remaining traffic. * Additionally, the baselining and monitoring of traffic flows to the router's control plane are critical in determining both the rates and granularity of the policies being applied. This is important to validate the existing policies and rules or update them as the network evolves and its traffic dynamics change. Some possible ways to achieve this include individual policy counters that can be exported or retrieved for example via SNMP, and logging of filtering actions. .... On 8/17/10 4:50 PM, Rodney Dunn wrote: > >>> What about if we add this in the Design >>> Trade-Off section to address the concern so we will be more precise. >>> >>> *In addition to the traffic matching explicit classes care should be >>> taken on the policy decision that governs the handling of >>> traffic that >>> would fall through the policy. >> Do we need to say that by convention there is no default deny at the >> end of a cpp policy? >> >> > > Another good catch...how about this: > > ....Typically that traffic is referred to as traffic falling in the > default class. It may also be traffic that matches a generic protocol > specific class where previous classes that have more granular matching > did not match all packets for that specific protocol. The ideal policy > would have explicit classes to match only the traffic specifically > required at the control plane and drop all other traffic. *As most > vendor implementations permit all traffic hitting the default class an > explicit drop action would need to be configured in the policy such that > the traffic hitting that default class would be dropped versus being > delivered up to the control plane.* This approach requires rigorous > traffic pattern identification such that a default drop policy does not > break existing functionality of the device..... > > > >>> after monitoring the traffic matching the default class >>> explicit classes >>> should be defined such that the default class could be configured to >>> drop traffic falling through the policy.* >> >> Can we add a COMMENTED OUT deny ip any any in the default policy with a >> "do not enable until throughly tested in production ..." type statement. >> > > I would prefer we cover it in the text section because that would make > it harder to link the Legitimate Traffic (Section 3.1) definition to the > actual configuration in the document. > > Rodney > > >>> >>> >>> Rodney >>> >>> >>> >>> On 8/16/10 9:58 PM, Christopher Morrow wrote: >>>> On Mon, Aug 16, 2010 at 9:34 PM, Rodney >>> Dunn wrote: >>>>> Donald, >>>>> >>>>> First thanks for the comment. It's a good one. We actually >>> originally had it >>>>> with a default drop for the all IP and default classes. >>> However, after a >>>>> good bit of discussion we (both Cisco and Juniper) felt >>> that we should >>>>> soften it up just a bit. We agreed to add the explicit >>> match for the ALLIP >>>>> class so it could be monitored and then tightened down further. >>>>> >>>>> We realized there were various opinions on how that should be done. >>>> >>>> can we get a 'first verify complete COPP coverage, then deny all >>>> remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? >>>> >>>> It sounds like someone with a legal degree got to your final >>>> recommendation :) that, operationally, leaves the network >>> with a whole >>>> to plug, and I can guarantee that someone with a scanning virus is >>>> gonna fill it for you :( >>>> >>>> -chris >>>> >>>>> ie: >>>>> >>>>> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html >>>>> >>>>> >>>>> Thanks, >>>>> Rodney >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 8/16/10 5:16 PM, Smith, Donald wrote: >>>>>> >>>>>> For undesirables in JTK's paper here he specifically did >>> a deny ip any any >>>>>> at the end of the cpp policy for that. >>>>>> >>>>>> http://aharp.ittns.northwestern.edu/papers/copp.html >>>>>> >>>>>> The default term for juniper is log and discard. >>>>>> >>>>>> There isn't a deny ip any any in the draft. >>>>>> >>>>>> >>>>>> >>>>>> (coffee != sleep)& (!coffee == sleep) >>>>>> Donald.Smith@qwest.com gcia >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>>>>> On Behalf Of Rob Bird >>>>>>> Sent: Friday, March 26, 2010 11:28 AM >>>>>>> To: David Dugal >>>>>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >>>>>>> opsec@ietf.org >>>>>>> Subject: Re: [OPSEC] OPSEC control plane protection draft >>>>>>> >>>>>>> This is most excellent. I was just advising a customer this >>>>>>> morning on this very issue (again). >>>>>>> >>>>>>> I look forward to working on this. >>>>>>> Rob >>>>>>> >>>>>>> - >>>>>>> Rob Bird, Chief Technology Officer >>>>>>> Red Lambda, Inc. >>>>>>> "Network security at global scale" >>>>>>> www.redlambda.com >>>>>>> >>>>>>> On Mar 26, 2010 1:03 PM, "David Dugal" >>>>>>> wrote: >>>>>>> >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> Hi Richard. >>>>>>> >>>>>>> Thank you very much for the scrutiny, analysis >>> and feedback. As >>>>>>> mentioned during my brief presentation, our hope >>> is that this >>>>>>> recommendation by example will provide awareness of a >>>>>>> possible attack >>>>>>> surface occasionally overlooked, especially by >>> smaller or newer >>>>>>> installations. >>>>>>> >>>>>>> I appreciate the feedback and will enhance the draft to >>>>>>> make reference >>>>>>> to cryptographic security, as well as attempt to make >>>>>>> the document IP >>>>>>> version agnostic. >>>>>>> >>>>>>> Thank you for your support, both in carefully reading >>>>>>> the document, and >>>>>>> for your willingness to have our draft taken under the >>>>>>> OPSEC WG wing. >>>>>>> >>>>>>> - --- >>>>>>> David G. Dugal Support: >>>>>>> +1-408-745-9500 >>>>>>> Security Incident Response Team Direct: >>>>>>> +1-978-589-0719 >>>>>>> Juniper Networks Mobile: >>>>>>> +1-603-377-1162 >>>>>>> Westford, MA, USA PGP Key: >>> 0xAB6E02A5 >>>>>>> >>>>>>> >>>>>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >>>>>>> Time), Richard >>>>>>> Graveman proclaimed ... >>>>>>> >>>>>>> >>>>>>> > David, >>>>>>> > >>>>>>> > I read the draft carefully after the meeting and >>>>>>> realize that my >>>>>>> > comments missed the... >>>>>>> >>>>>>> > . >>>>>>> > >>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>> Version: GnuPG v1.4.10 (MingW32) >>>>>>> >>>>>>> >>> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr >>>>>>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >>>>>>> =kitD >>>>>>> -----END PGP SIGNATURE----- >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OPSEC mailing list >>>>>>> OPSEC@ietf.org >>>>>>> https://www.ietf.o... >>>>>>> >>>>>>> >>>>>> >>>>>> 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. >>>>>> _______________________________________________ >>>>>> 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. > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From Donald.Smith@qwest.com Thu Aug 19 14:17:40 2010 Return-Path: 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 107933A680D for ; Thu, 19 Aug 2010 14:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 UTwu1Ujeec+K for ; Thu, 19 Aug 2010 14:17:38 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 18CB23A6A4C for ; Thu, 19 Aug 2010 14:17:38 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o7JLIBxP001636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Aug 2010 16:18:11 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id o7JLI5wu029571; Thu, 19 Aug 2010 16:18:06 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Thu, 19 Aug 2010 15:18:05 -0600 From: "Smith, Donald" To: "'rodunn@cisco.com'" Date: Thu, 19 Aug 2010 15:18:04 -0600 Thread-Topic: [OPSEC] OPSEC control plane protection draft Thread-Index: Acs/3rAP8kZzfUCyQ5y6FqxaDYO81QABUFBQ Message-ID: References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> <4C6AEB97.2010501@cisco.com> <4C6AF600.8030504@cisco.com> <4C6D9725.4080505@cisco.com> In-Reply-To: <4C6D9725.4080505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:17:40 -0000 Rodney, this looks good to me. You have addressed all of my concerns. Thank you. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Rodney Dunn [mailto:rodunn@cisco.com] > Sent: Thursday, August 19, 2010 2:42 PM > To: rodunn@cisco.com > Cc: Smith, Donald; 'opsec@ietf.org' > Subject: Re: [OPSEC] OPSEC control plane protection draft > > The current proposal on the table is the additional paragraph > in Section > 3.3 "Design Trade-offs" section to add the following > paragraph between > *-*'s. The purpose of this paragraph is to highlight that the > end goal > would be to have a COPP policy that is as explicit as > possible on what > to permit and dropping all other traffic. Does the list agree > that this > paragraph accurately reflects that desire? > > > Section 3.3 "Design Trade-offs" > > > ... > The goal of the method for protecting the router control plane is to > minimize the possibility for disruptions by reducing the vulnerable > surface. The latter is inversely proportional to the granularity of > the filter design. The finer the granularity of the filter design > (e.g., isolating a more targeted subset of traffic from the rest of > the policed traffic, or isolating valid source addresses into a > different class or classes) the smaller the probability of > disruption. > > *In addition to the traffic matching explicit classes care should be > taken on the policy decision that governs the handling of > traffic that > would fall through the policy. Typically that traffic is > referred to as > traffic that gets matched in a default class. It may also be traffic > that matches a protocol specific class where previous classes > that have > more granular matching did not match all packets for that specific > protocol. The ideal policy would have explicit classes to > match only the > traffic specifically required at the control plane and drop all other > traffic that does not mach a predefined class. As most vendor > implementations permit all traffic hitting the default class > an explicit > drop action would need to be configured in the policy such that the > traffic hitting that default class would be dropped versus > permitted and > then delivered to the control plane. This approach requires rigorous > traffic pattern identification such that a default drop > policy does not > break existing functionality of the device. The approach > defined in this > document allows the default traffic and rate limits it rather > than just > dropping it. This approach was highlighted as a way to give > time for the > implementer to evaluate the traffic in a production scenario prior to > dropping all traffic not explicitly matched and permitted. > However, it > is highly recommended that after monitoring the traffic matching the > default class that explicit classes be defined to catch the > legitimate > traffic. After all legitimate traffic is being explicitly matched the > default class should be configured to drop any remaining traffic. * > > > Additionally, the baselining and monitoring of traffic flows to the > router's control plane are critical in determining both the rates and > granularity of the policies being applied. This is important to > validate the existing policies and rules or update them as the > network evolves and its traffic dynamics change. Some possible ways > to achieve this include individual policy counters that can be > exported or retrieved for example via SNMP, and logging of filtering > actions. > > .... > > > > > On 8/17/10 4:50 PM, Rodney Dunn wrote: > > > >>> What about if we add this in the Design > >>> Trade-Off section to address the concern so we will be > more precise. > >>> > >>> *In addition to the traffic matching explicit classes > care should be > >>> taken on the policy decision that governs the handling of > >>> traffic that > >>> would fall through the policy. > >> Do we need to say that by convention there is no default > deny at the > >> end of a cpp policy? > >> > >> > > > > Another good catch...how about this: > > > > ....Typically that traffic is referred to as traffic falling in the > > default class. It may also be traffic that matches a > generic protocol > > specific class where previous classes that have more > granular matching > > did not match all packets for that specific protocol. The > ideal policy > > would have explicit classes to match only the traffic specifically > > required at the control plane and drop all other traffic. *As most > > vendor implementations permit all traffic hitting the > default class an > > explicit drop action would need to be configured in the > policy such that > > the traffic hitting that default class would be dropped versus being > > delivered up to the control plane.* This approach requires rigorous > > traffic pattern identification such that a default drop > policy does not > > break existing functionality of the device..... > > > > > > > >>> after monitoring the traffic matching the default class > >>> explicit classes > >>> should be defined such that the default class could be > configured to > >>> drop traffic falling through the policy.* > >> > >> Can we add a COMMENTED OUT deny ip any any in the default > policy with a > >> "do not enable until throughly tested in production ..." > type statement. > >> > > > > I would prefer we cover it in the text section because that > would make > > it harder to link the Legitimate Traffic (Section 3.1) > definition to the > > actual configuration in the document. > > > > Rodney > > > > > >>> > >>> > >>> Rodney > >>> > >>> > >>> > >>> On 8/16/10 9:58 PM, Christopher Morrow wrote: > >>>> On Mon, Aug 16, 2010 at 9:34 PM, Rodney > >>> Dunn wrote: > >>>>> Donald, > >>>>> > >>>>> First thanks for the comment. It's a good one. We actually > >>> originally had it > >>>>> with a default drop for the all IP and default classes. > >>> However, after a > >>>>> good bit of discussion we (both Cisco and Juniper) felt > >>> that we should > >>>>> soften it up just a bit. We agreed to add the explicit > >>> match for the ALLIP > >>>>> class so it could be monitored and then tightened down further. > >>>>> > >>>>> We realized there were various opinions on how that > should be done. > >>>> > >>>> can we get a 'first verify complete COPP coverage, then deny all > >>>> remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? > >>>> > >>>> It sounds like someone with a legal degree got to your final > >>>> recommendation :) that, operationally, leaves the network > >>> with a whole > >>>> to plug, and I can guarantee that someone with a > scanning virus is > >>>> gonna fill it for you :( > >>>> > >>>> -chris > >>>> > >>>>> ie: > >>>>> > >>>>> > http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Rodney > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 8/16/10 5:16 PM, Smith, Donald wrote: > >>>>>> > >>>>>> For undesirables in JTK's paper here he specifically did > >>> a deny ip any any > >>>>>> at the end of the cpp policy for that. > >>>>>> > >>>>>> http://aharp.ittns.northwestern.edu/papers/copp.html > >>>>>> > >>>>>> The default term for juniper is log and discard. > >>>>>> > >>>>>> There isn't a deny ip any any in the draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> (coffee !=3D sleep)& (!coffee =3D=3D sleep) > >>>>>> Donald.Smith@qwest.com gcia > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > >>>>>>> On Behalf Of Rob Bird > >>>>>>> Sent: Friday, March 26, 2010 11:28 AM > >>>>>>> To: David Dugal > >>>>>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; > >>>>>>> opsec@ietf.org > >>>>>>> Subject: Re: [OPSEC] OPSEC control plane protection draft > >>>>>>> > >>>>>>> This is most excellent. I was just advising a customer this > >>>>>>> morning on this very issue (again). > >>>>>>> > >>>>>>> I look forward to working on this. > >>>>>>> Rob > >>>>>>> > >>>>>>> - > >>>>>>> Rob Bird, Chief Technology Officer > >>>>>>> Red Lambda, Inc. > >>>>>>> "Network security at global scale" > >>>>>>> www.redlambda.com > >>>>>>> > >>>>>>> On Mar 26, 2010 1:03 PM, "David Dugal" > >>>>>>> wrote: > >>>>>>> > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>> Hash: SHA1 > >>>>>>> > >>>>>>> Hi Richard. > >>>>>>> > >>>>>>> Thank you very much for the scrutiny, analysis > >>> and feedback. As > >>>>>>> mentioned during my brief presentation, our hope > >>> is that this > >>>>>>> recommendation by example will provide awareness of a > >>>>>>> possible attack > >>>>>>> surface occasionally overlooked, especially by > >>> smaller or newer > >>>>>>> installations. > >>>>>>> > >>>>>>> I appreciate the feedback and will enhance the draft to > >>>>>>> make reference > >>>>>>> to cryptographic security, as well as attempt to make > >>>>>>> the document IP > >>>>>>> version agnostic. > >>>>>>> > >>>>>>> Thank you for your support, both in carefully reading > >>>>>>> the document, and > >>>>>>> for your willingness to have our draft taken under the > >>>>>>> OPSEC WG wing. > >>>>>>> > >>>>>>> - --- > >>>>>>> David G. Dugal Support: > >>>>>>> +1-408-745-9500 > >>>>>>> Security Incident Response Team Direct: > >>>>>>> +1-978-589-0719 > >>>>>>> Juniper Networks Mobile: > >>>>>>> +1-603-377-1162 > >>>>>>> Westford, MA, USA PGP Key: > >>> 0xAB6E02A5 > >>>>>>> > >>>>>>> > >>>>>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight > >>>>>>> Time), Richard > >>>>>>> Graveman proclaimed ... > >>>>>>> > >>>>>>> > >>>>>>> > David, > >>>>>>> > > >>>>>>> > I read the draft carefully after the meeting and > >>>>>>> realize that my > >>>>>>> > comments missed the... > >>>>>>> > >>>>>>> > . > >>>>>>> > > >>>>>>> -----BEGIN PGP SIGNATURE----- > >>>>>>> Version: GnuPG v1.4.10 (MingW32) > >>>>>>> > >>>>>>> > >>> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr > >>>>>>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN > >>>>>>> =3DkitD > >>>>>>> -----END PGP SIGNATURE----- > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OPSEC mailing list > >>>>>>> OPSEC@ietf.org > >>>>>>> https://www.ietf.o... > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> 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. > >>>>>> _______________________________________________ > >>>>>> 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. > > _______________________________________________ > > 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. From rodunn@cisco.com Thu Aug 19 14:58:44 2010 Return-Path: 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 F02633A6899 for ; Thu, 19 Aug 2010 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KoQT-rMqWx1h for ; Thu, 19 Aug 2010 14:58:43 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id F0D953A68D7 for ; Thu, 19 Aug 2010 14:58:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7JLwoqo015952; Thu, 19 Aug 2010 17:58:50 -0400 (EDT) Received: from dhcp-64-102-157-1.cisco.com (dhcp-64-102-157-1.cisco.com [64.102.157.1]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7JLwkuB002050; Thu, 19 Aug 2010 17:58:47 -0400 (EDT) Message-ID: <4C6DA9A6.9010705@cisco.com> Date: Thu, 19 Aug 2010 18:01:10 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Smith, Donald" References: <45c8c21a1003260906j41580868p12466e6ed42ef3d0@mail.gmail.com> <4BACE777.3010000@juniper.net> <4C69E72F.6090608@cisco.com> <4C6AEB97.2010501@cisco.com> <4C6AF600.8030504@cisco.com> <4C6D9725.4080505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] OPSEC control plane protection draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:58:45 -0000 Thanks Donald. I'll update the xml source tomorrow with that and we'll wait for any additional comments. Thanks for the review. Rodney On 8/19/10 5:18 PM, Smith, Donald wrote: > Rodney, this looks good to me. You have addressed all of my concerns. > Thank you. > > (coffee != sleep)& (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: Rodney Dunn [mailto:rodunn@cisco.com] >> Sent: Thursday, August 19, 2010 2:42 PM >> To: rodunn@cisco.com >> Cc: Smith, Donald; 'opsec@ietf.org' >> Subject: Re: [OPSEC] OPSEC control plane protection draft >> >> The current proposal on the table is the additional paragraph >> in Section >> 3.3 "Design Trade-offs" section to add the following >> paragraph between >> *-*'s. The purpose of this paragraph is to highlight that the >> end goal >> would be to have a COPP policy that is as explicit as >> possible on what >> to permit and dropping all other traffic. Does the list agree >> that this >> paragraph accurately reflects that desire? >> >> >> Section 3.3 "Design Trade-offs" >> >> >> ... >> The goal of the method for protecting the router control plane is to >> minimize the possibility for disruptions by reducing the vulnerable >> surface. The latter is inversely proportional to the granularity of >> the filter design. The finer the granularity of the filter design >> (e.g., isolating a more targeted subset of traffic from the rest of >> the policed traffic, or isolating valid source addresses into a >> different class or classes) the smaller the probability of >> disruption. >> >> *In addition to the traffic matching explicit classes care should be >> taken on the policy decision that governs the handling of >> traffic that >> would fall through the policy. Typically that traffic is >> referred to as >> traffic that gets matched in a default class. It may also be traffic >> that matches a protocol specific class where previous classes >> that have >> more granular matching did not match all packets for that specific >> protocol. The ideal policy would have explicit classes to >> match only the >> traffic specifically required at the control plane and drop all other >> traffic that does not mach a predefined class. As most vendor >> implementations permit all traffic hitting the default class >> an explicit >> drop action would need to be configured in the policy such that the >> traffic hitting that default class would be dropped versus >> permitted and >> then delivered to the control plane. This approach requires rigorous >> traffic pattern identification such that a default drop >> policy does not >> break existing functionality of the device. The approach >> defined in this >> document allows the default traffic and rate limits it rather >> than just >> dropping it. This approach was highlighted as a way to give >> time for the >> implementer to evaluate the traffic in a production scenario prior to >> dropping all traffic not explicitly matched and permitted. >> However, it >> is highly recommended that after monitoring the traffic matching the >> default class that explicit classes be defined to catch the >> legitimate >> traffic. After all legitimate traffic is being explicitly matched the >> default class should be configured to drop any remaining traffic. * >> >> >> Additionally, the baselining and monitoring of traffic flows to the >> router's control plane are critical in determining both the rates and >> granularity of the policies being applied. This is important to >> validate the existing policies and rules or update them as the >> network evolves and its traffic dynamics change. Some possible ways >> to achieve this include individual policy counters that can be >> exported or retrieved for example via SNMP, and logging of filtering >> actions. >> >> .... >> >> >> >> >> On 8/17/10 4:50 PM, Rodney Dunn wrote: >>> >>>>> What about if we add this in the Design >>>>> Trade-Off section to address the concern so we will be >> more precise. >>>>> >>>>> *In addition to the traffic matching explicit classes >> care should be >>>>> taken on the policy decision that governs the handling of >>>>> traffic that >>>>> would fall through the policy. >>>> Do we need to say that by convention there is no default >> deny at the >>>> end of a cpp policy? >>>> >>>> >>> >>> Another good catch...how about this: >>> >>> ....Typically that traffic is referred to as traffic falling in the >>> default class. It may also be traffic that matches a >> generic protocol >>> specific class where previous classes that have more >> granular matching >>> did not match all packets for that specific protocol. The >> ideal policy >>> would have explicit classes to match only the traffic specifically >>> required at the control plane and drop all other traffic. *As most >>> vendor implementations permit all traffic hitting the >> default class an >>> explicit drop action would need to be configured in the >> policy such that >>> the traffic hitting that default class would be dropped versus being >>> delivered up to the control plane.* This approach requires rigorous >>> traffic pattern identification such that a default drop >> policy does not >>> break existing functionality of the device..... >>> >>> >>> >>>>> after monitoring the traffic matching the default class >>>>> explicit classes >>>>> should be defined such that the default class could be >> configured to >>>>> drop traffic falling through the policy.* >>>> >>>> Can we add a COMMENTED OUT deny ip any any in the default >> policy with a >>>> "do not enable until throughly tested in production ..." >> type statement. >>>> >>> >>> I would prefer we cover it in the text section because that >> would make >>> it harder to link the Legitimate Traffic (Section 3.1) >> definition to the >>> actual configuration in the document. >>> >>> Rodney >>> >>> >>>>> >>>>> >>>>> Rodney >>>>> >>>>> >>>>> >>>>> On 8/16/10 9:58 PM, Christopher Morrow wrote: >>>>>> On Mon, Aug 16, 2010 at 9:34 PM, Rodney >>>>> Dunn wrote: >>>>>>> Donald, >>>>>>> >>>>>>> First thanks for the comment. It's a good one. We actually >>>>> originally had it >>>>>>> with a default drop for the all IP and default classes. >>>>> However, after a >>>>>>> good bit of discussion we (both Cisco and Juniper) felt >>>>> that we should >>>>>>> soften it up just a bit. We agreed to add the explicit >>>>> match for the ALLIP >>>>>>> class so it could be monitored and then tightened down further. >>>>>>> >>>>>>> We realized there were various opinions on how that >> should be done. >>>>>> >>>>>> can we get a 'first verify complete COPP coverage, then deny all >>>>>> remaining traffic with $INSERT_PROPER_DENY_HERE' paragraph? >>>>>> >>>>>> It sounds like someone with a legal degree got to your final >>>>>> recommendation :) that, operationally, leaves the network >>>>> with a whole >>>>>> to plug, and I can guarantee that someone with a >> scanning virus is >>>>>> gonna fill it for you :( >>>>>> >>>>>> -chris >>>>>> >>>>>>> ie: >>>>>>> >>>>>>> >> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Rodney >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/16/10 5:16 PM, Smith, Donald wrote: >>>>>>>> >>>>>>>> For undesirables in JTK's paper here he specifically did >>>>> a deny ip any any >>>>>>>> at the end of the cpp policy for that. >>>>>>>> >>>>>>>> http://aharp.ittns.northwestern.edu/papers/copp.html >>>>>>>> >>>>>>>> The default term for juniper is log and discard. >>>>>>>> >>>>>>>> There isn't a deny ip any any in the draft. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (coffee != sleep)& (!coffee == sleep) >>>>>>>> Donald.Smith@qwest.com gcia >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>>>>>>> On Behalf Of Rob Bird >>>>>>>>> Sent: Friday, March 26, 2010 11:28 AM >>>>>>>>> To: David Dugal >>>>>>>>> Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org; >>>>>>>>> opsec@ietf.org >>>>>>>>> Subject: Re: [OPSEC] OPSEC control plane protection draft >>>>>>>>> >>>>>>>>> This is most excellent. I was just advising a customer this >>>>>>>>> morning on this very issue (again). >>>>>>>>> >>>>>>>>> I look forward to working on this. >>>>>>>>> Rob >>>>>>>>> >>>>>>>>> - >>>>>>>>> Rob Bird, Chief Technology Officer >>>>>>>>> Red Lambda, Inc. >>>>>>>>> "Network security at global scale" >>>>>>>>> www.redlambda.com >>>>>>>>> >>>>>>>>> On Mar 26, 2010 1:03 PM, "David Dugal" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>> Hash: SHA1 >>>>>>>>> >>>>>>>>> Hi Richard. >>>>>>>>> >>>>>>>>> Thank you very much for the scrutiny, analysis >>>>> and feedback. As >>>>>>>>> mentioned during my brief presentation, our hope >>>>> is that this >>>>>>>>> recommendation by example will provide awareness of a >>>>>>>>> possible attack >>>>>>>>> surface occasionally overlooked, especially by >>>>> smaller or newer >>>>>>>>> installations. >>>>>>>>> >>>>>>>>> I appreciate the feedback and will enhance the draft to >>>>>>>>> make reference >>>>>>>>> to cryptographic security, as well as attempt to make >>>>>>>>> the document IP >>>>>>>>> version agnostic. >>>>>>>>> >>>>>>>>> Thank you for your support, both in carefully reading >>>>>>>>> the document, and >>>>>>>>> for your willingness to have our draft taken under the >>>>>>>>> OPSEC WG wing. >>>>>>>>> >>>>>>>>> - --- >>>>>>>>> David G. Dugal Support: >>>>>>>>> +1-408-745-9500 >>>>>>>>> Security Incident Response Team Direct: >>>>>>>>> +1-978-589-0719 >>>>>>>>> Juniper Networks Mobile: >>>>>>>>> +1-603-377-1162 >>>>>>>>> Westford, MA, USA PGP Key: >>>>> 0xAB6E02A5 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri Mar 26 2010 09:06:40 GMT-0700 (Pacific Daylight >>>>>>>>> Time), Richard >>>>>>>>> Graveman proclaimed ... >>>>>>>>> >>>>>>>>> >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>> I read the draft carefully after the meeting and >>>>>>>>> realize that my >>>>>>>>>> comments missed the... >>>>>>>>> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>>>> Version: GnuPG v1.4.10 (MingW32) >>>>>>>>> >>>>>>>>> >>>>> iEYEARECAAYFAkus53cACgkQh59lzatuAqVE9wCgh53mgxNRPWUztlI27aOITHRr >>>>>>>>> 2zMAoPb5y3phm260P1zSoDu0LSbUjNcN >>>>>>>>> =kitD >>>>>>>>> -----END PGP SIGNATURE----- >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OPSEC mailing list >>>>>>>>> OPSEC@ietf.org >>>>>>>>> https://www.ietf.o... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>>> _______________________________________________ >>>>>>>> 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. >>> _______________________________________________ >>> 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. From iesg-secretary@ietf.org Fri Aug 20 14:56:38 2010 Return-Path: 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 735263A6A5A; Fri, 20 Aug 2010 14:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 A8zxmpmRwMWk; Fri, 20 Aug 2010 14:56:37 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0F43A6898; Fri, 20 Aug 2010 14:56:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100820215637.17794.15066.idtracker@localhost> Date: Fri, 20 Aug 2010 14:56:37 -0700 X-Mailman-Approved-At: Sat, 21 Aug 2010 11:24:29 -0700 Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:56:38 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-igp-crypto-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-igp-crypto-requirements/ No IPR declarations were found that appear related to this I-D. From rbonica@juniper.net Sat Aug 21 15:45:11 2010 Return-Path: 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 7D7C23A68D4; Sat, 21 Aug 2010 15:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.169 X-Spam-Level: X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 dW318RtyZsy5; Sat, 21 Aug 2010 15:45:09 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 7B8FB3A6845; Sat, 21 Aug 2010 15:45:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTHBXFOSonuOzjJngRKQAG89dS56QIUvR@postini.com; Sat, 21 Aug 2010 15:45:44 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 21 Aug 2010 15:32:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sat, 21 Aug 2010 18:32:55 -0400 From: Ronald Bonica To: "opsec@ietf.org" Date: Sat, 21 Aug 2010 18:32:43 -0400 Thread-Topic: WG chairs Thread-Index: ActBgMVCRkluZvOZRDi6++bRqqW+3Q== Message-ID: <13205C286662DE4387D9AF3AC30EF456B00B281AB3@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: GADy I1LC LmVM L3Kl Owrk Z/6o blHY cmcJ hn9P mIP5 z9Ks 28/V 3PdA 7r+o 78TW +bud; 5; aQBlAHQAZgAtAHMAZQBjAHIAZQB0AGEAcgBpAGEAdABAAGkAZQB0AGYALgBvAHIAZwA7AGoAYQBiAGwAZQB5AEAAYwBhAC4AYQBmAGkAbABpAGEAcwAuAGkAbgBmAG8AOwBqAG8AZQBsAGoAYQBAAGIAbwBnAHUAcwAuAGMAbwBtADsAbwBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAdwBrAHUAbQBhAHIAaQBAAGcAbwBvAGcAbABlAC4AYwBvAG0A; Sosha1_v1; 7; {9D7E62AA-DAA8-46C4-9D16-FAABAA297C7E}; cgBiAG8AbgBpAGMAYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Sat, 21 Aug 2010 22:32:43 GMT;VwBHACAAYwBoAGEAaQByAHMA x-cr-puzzleid: {9D7E62AA-DAA8-46C4-9D16-FAABAA297C7E} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Warren Kumari , IETF Secretariat , "jabley@ca.afilias.info" Subject: [OPSEC] WG chairs X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 22:45:11 -0000 Folks, Please join me in thanking Joel Jaeggli for his efforts toward the revitali= zation of the IETF OPSEC WG. I think that we can all agree that Joel has do= ne an outstanding job. Effective immediately, Joel will step down and OPSEC co-chair and will beco= me co-chairman of the V6OPS WG. We look forward to the same kind of active = leadership in v6ops that we have seen in OPSEC. Warren Kumari will replace Joel as OPSEC co-chair, serving with Joe Abley. = Please join me in wishing Warren well in his new endeavor. Ron Co-chair, IETF O&M Ar= ea From joelja@bogus.com Sun Aug 22 12:51:55 2010 Return-Path: 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 154523A6954; Sun, 22 Aug 2010 12:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PgdTtLxUwD0C; Sun, 22 Aug 2010 12:51:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id EB5493A689B; Sun, 22 Aug 2010 12:51:53 -0700 (PDT) Received: from [192.168.2.100] (m410536d0.tmodns.net [208.54.5.65]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o7MJqO8k015297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 22 Aug 2010 19:52:25 GMT (envelope-from joelja@bogus.com) References: <20100820215637.17794.15066.idtracker@localhost> <6.2.5.6.2.20100822101026.09d33a70@resistor.net> Message-Id: <1836A56C-CC63-45C1-8D08-343406B67AA9@bogus.com> From: Joel Jaeggli To: SM In-Reply-To: <6.2.5.6.2.20100822101026.09d33a70@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B405) Date: Sun, 22 Aug 2010 12:09:44 -0700 X-Mailer: iPad Mail (7B405) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 22 Aug 2010 19:52:26 +0000 (UTC) Cc: "opsec@ietf.org" , "ietf@ietf.org" Subject: Re: [OPSEC] Last Call: (Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 19:51:55 -0000 The distinction I think reflects the fact that that as good as we = believe that these recommendations are at this time that they are = subject to change. It was the opinion of the authors and the chairs that = the opinion should be expressed without setting to high a bar for = challenging it. This is also reflected in the removal of 2119 language = in that this is advice on protocol requirements not requirements as = well. I realize that may sound like I'm trying to thread the needle, but it = reflects the fact that the work done as a product of this document will = not be done in opsec, or even in the ops area. Joel's iPad On Aug 22, 2010, at 10:57, SM wrote: > At 14:56 20-08-10, The IESG wrote: >> The IESG has received a request from the Operational Security >> Capabilities for IP Network Infrastructure WG (opsec) to consider the >> following document: >> - 'Cryptographic Authentication Algorithm Implementation Best = Practices >> for Routing Protocols' >> as an = Informational >> RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >=20 > If it was the view of the opsec WG that this document represents best = practices, it could have chosen an intended status of BCP instead of = Informational. Quoting Section 8: >=20 > "We expect that new revisions of this document will be issued > in the future to reflect current thinking on best practice > in this area." >=20 > Does this document reflect best practice in this area? >=20 > As a nit, there are two occurrences of the RFC2119 boilerplate. >=20 > Regards, > -sm >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From root@core3.amsl.com Mon Aug 23 07:30:19 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 68C113A69F8; Mon, 23 Aug 2010 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100823143007.68C113A69F8@core3.amsl.com> Date: Mon, 23 Aug 2010 07:30:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:30:19 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Protecting The Router Control Plane Author(s) : D. Dugal, et al. Filename : draft-ietf-opsec-protect-control-plane-03.txt Pages : 23 Date : 2010-08-23 This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane or rate limited to an acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-control-plane-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-protect-control-plane-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-23072639.I-D@ietf.org> --NextPart-- From rodunn@cisco.com Mon Aug 23 07:43:33 2010 Return-Path: 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 7CC043A6A5C for ; Mon, 23 Aug 2010 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xO3gNEZYjo3c for ; Mon, 23 Aug 2010 07:43:32 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1330F3A689C for ; Mon, 23 Aug 2010 07:43:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7NEi5Nj001803 for ; Mon, 23 Aug 2010 10:44:05 -0400 (EDT) Received: from dhcp-64-102-157-1.cisco.com (dhcp-64-102-157-1.cisco.com [64.102.157.1]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o7NEi4Ai004383 for ; Mon, 23 Aug 2010 10:44:04 -0400 (EDT) Message-ID: <4C7289CB.9040105@cisco.com> Date: Mon, 23 Aug 2010 10:46:35 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: multipart/mixed; boundary="------------020605090006090100090801" Subject: [OPSEC] Fwd: I-D Action:draft-ietf-opsec-protect-control-plane-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:43:33 -0000 This is a multi-part message in MIME format. --------------020605090006090100090801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to Chris, Donald, Jared, and others for the recent round of reviews. The -03 update includes the paragraph addressing the feedback from the list on the default traffic handling along with a few editorial changes in the spirit of easier reading and clarity. Diff view as a quick reference: http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-protect-control-plane-03 Rodney -------- Original Message -------- Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-03.txt Date: Mon, 23 Aug 2010 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: opsec@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Protecting The Router Control Plane Author(s) : D. Dugal, et al. Filename : draft-ietf-opsec-protect-control-plane-03.txt Pages : 23 Date : 2010-08-23 This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane or rate limited to an acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-control-plane-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020605090006090100090801 Content-Type: Message/External-body; name="draft-ietf-opsec-protect-control-plane-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-opsec-protect-control-plane-03.txt" Content-Type: text/plain Content-ID: <2010-08-23072639.I-D@ietf.org> --------------020605090006090100090801 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --------------020605090006090100090801-- From warren@kumari.net Tue Aug 24 12:16:44 2010 Return-Path: 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 E58F53A691B for ; Tue, 24 Aug 2010 12:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tVOG0s29jgBG for ; Tue, 24 Aug 2010 12:16:41 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 9CC7A3A68CE for ; Tue, 24 Aug 2010 12:16:41 -0700 (PDT) Received: from dhcp-172-29-46-185.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 19D662284997; Tue, 24 Aug 2010 15:15:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B00B281AB3@EMBX01-WF.jnpr.net> Date: Tue, 24 Aug 2010 15:17:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31E61F20-2988-4C81-A46F-2156AC769691@kumari.net> References: <13205C286662DE4387D9AF3AC30EF456B00B281AB3@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1078) Cc: jabley@ca.afilias.info, opsec@ietf.org Subject: Re: [OPSEC] WG chairs X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 19:16:44 -0000 On Aug 21, 2010, at 6:32 PM, Ronald Bonica wrote: > Folks, >=20 > Please join me in thanking Joel Jaeggli for his efforts toward the = revitalization of the IETF OPSEC WG. I think that we can all agree that = Joel has done an outstanding job. >=20 Yes... and luckily for everyone concerned Joel has promised to still be = around and help get me spun up, provide guidance, etc. =20 I have a favor to ask the working group: I'll do my best to make a good show of this, but this is my first time = co-chairing a WG -- please keep this in mind and feel free to tell me = when I'm messing up, when I'm not doing what I should and when I am = doing things that I shouldn't... I believe that Joel was doing an awesome job, I'll try to live up to the = level that he set... W > Effective immediately, Joel will step down and OPSEC co-chair and will = become co-chairman of the V6OPS WG. We look forward to the same kind of = active leadership in v6ops that we have seen in OPSEC. >=20 > Warren Kumari will replace Joel as OPSEC co-chair, serving with Joe = Abley. Please join me in wishing Warren well in his new endeavor. >=20 > Ron > Co-chair, IETF = O&M Area >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From sm@resistor.net Sun Aug 22 11:10:22 2010 Return-Path: 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 5D19A3A693B; Sun, 22 Aug 2010 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, 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 FpSZ2fmhZe0o; Sun, 22 Aug 2010 11:10:18 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id AB8AB3A688F; Sun, 22 Aug 2010 11:10:15 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o7MIAWdX002294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Aug 2010 11:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1282500645; x=1282587045; bh=QkDoEjfqW0BOYtoc9bx1/SoaNsGQzQp9MemMnKkRRXU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ETSNcsQ/QpCn/97okx+CYhNZQex7wSy/Zuq/F2S6as2Qr7W5Yzn50vsfqvtFrhdbk EAUDotJqq5uUv4T72PoSfYbh+WUXBn2VSiTID4GenvBbUABCHfJ12xaGqXo5DBKtzw 18QmTF3Wj6Ri2ri33dtJeX6ecoNLrqceecJauawI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1282500645; x=1282587045; bh=QkDoEjfqW0BOYtoc9bx1/SoaNsGQzQp9MemMnKkRRXU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=XfqHrVzIct5vYKpepz1WUCBhb8jUaiXGUNju/BuO2YSzolHc+VQkWuOcgPerOdtpT 9gv14xup6bCTvVKSc3787qsxzDbmku24GQIlijhmD1I/lVMPiH+nVaSYhFzqvRl0nM ECYZ2NizmJu+E1uDqLIhZ8fN22LR/rfVMjOL5IAI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=bU+SMMo7DhHynbQS6VAAkLT+1007qmqZMO0/kxgX28ro8P05yXpW3/KsTCbf+yHmX f4VKsS/fr/GaQDj7Exy0D7KE2eDHr1tn1GZLrL9lTWwUz9tEvWmAPZubeC7Oa8MjJbS 3seqF7DCUyaP6uotYRxyHmAJLTzAgYeDul0Ya3k= Message-Id: <6.2.5.6.2.20100822101026.09d33a70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Aug 2010 10:57:57 -0700 To: ietf@ietf.org From: SM In-Reply-To: <20100820215637.17794.15066.idtracker@localhost> References: <20100820215637.17794.15066.idtracker@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 25 Aug 2010 22:29:08 -0700 Cc: opsec@ietf.org Subject: Re: [OPSEC] Last Call: (Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 18:10:22 -0000 At 14:56 20-08-10, The IESG wrote: >The IESG has received a request from the Operational Security >Capabilities for IP Network Infrastructure WG (opsec) to consider the >following document: >- 'Cryptographic Authentication Algorithm Implementation Best Practices > for Routing Protocols' > as an Informational >RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the If it was the view of the opsec WG that this document represents best practices, it could have chosen an intended status of BCP instead of Informational. Quoting Section 8: "We expect that new revisions of this document will be issued in the future to reflect current thinking on best practice in this area." Does this document reflect best practice in this area? As a nit, there are two occurrences of the RFC2119 boilerplate. Regards, -sm From root@core3.amsl.com Tue Aug 31 17:00:01 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ABC5B3A68AE; Tue, 31 Aug 2010 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100901000001.ABC5B3A68AE@core3.amsl.com> Date: Tue, 31 Aug 2010 17:00:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D ACTION:draft-ietf-opsec-routing-protocols-crypto-issues-07.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Issues with existing Cryptographic Protection Methods for Routing Protocols Author(s) : J. Jaeggli, S. Hares, M. Bhatia, V. Manral, R. White Filename : draft-ietf-opsec-routing-protocols-crypto-issues-07.txt Pages : 20 Date : 2010-8-31 Routing protocols have over time been extended to use cryptographic mechanisms to validate data being received from a neighboring router to ensure that: o It has not been modified in transit. o Actually originated from an authorized neighboring router. The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet. This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-routing-protocols-crypto-issues-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-8-31165142.I-D@ietf.org> --NextPart-- From warren@kumari.net Tue Aug 31 18:31:10 2010 Return-Path: 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 458C03A694A for ; Tue, 31 Aug 2010 18:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 f6Muii1IGUJy for ; Tue, 31 Aug 2010 18:31:06 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 7930C3A6A03 for ; Tue, 31 Aug 2010 18:31:01 -0700 (PDT) Received: from [172.26.56.197] (unknown [72.14.228.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9867E22842D2; Tue, 31 Aug 2010 21:29:40 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2010 21:31:27 -0400 Message-Id: To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: cpignata@cisco.com Subject: [OPSEC] Working Group last call for draft-ietf-opsec-protect-control-plane X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 01:31:10 -0000 This is the Working Group Last call for = draft-ietf-opsec-protect-control-plane. Please review the current draft: http://tools.ietf.org/html/draft-ietf-opsec-protect-control-plane-03 Deadline for Comments is 0000 UTC, Wed SEP 15th 2010. Thanks, Warren=