From root@core3.amsl.com Fri Oct 1 13:45:04 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 55DD03A6CEF; Fri, 1 Oct 2010 13:45: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: <20101001204502.55DD03A6CEF@core3.amsl.com> Date: Fri, 1 Oct 2010 13:45:02 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D ACTION:draft-ietf-opsec-igp-crypto-requirements-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, 01 Oct 2010 20:45:04 -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 : Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols Author(s) : M. Bhatia, V. Manral Filename : draft-ietf-opsec-igp-crypto-requirements-02.txt Pages : 10 Date : 2010-10-1 The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS) and Routing Information Protocol (RIP) currently define Clear Text and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS and OSPF. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms thereby ensuring that there is at least one algorithm that all implementations will have in common. This document examines the current set of available algorithms with interoperability and effective cryptographic authentication protection being the principle considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-igp-crypto-requirements-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-igp-crypto-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-1133115.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Oct 9 22:30:33 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 85B7C3A67D4; Sat, 9 Oct 2010 22:30:02 -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: <20101010053021.85B7C3A67D4@core3.amsl.com> Date: Sat, 9 Oct 2010 22:30:03 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-igp-crypto-requirements-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: Sun, 10 Oct 2010 05:30:39 -0000 X-List-Received-Date: Sun, 10 Oct 2010 05:30:39 -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 : Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols Author(s) : M. Bhatia, V. Manral Filename : draft-ietf-opsec-igp-crypto-requirements-03.txt Pages : 19 Date : 2010-10-09 The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS) and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS and OSPF. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms thereby ensuring that there is at least one algorithm that all implementations will have in common. Similarly RIPng and OSPFv3 support IPSec algorithms for authenticating their protocol packets. This document examines the current set of available algorithms with interoperability and effective cryptographic authentication protection being the principle considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-igp-crypto-requirements-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-igp-crypto-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-09221650.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 11 16:30:03 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 95F8A3A6832; Mon, 11 Oct 2010 16:30:02 -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: <20101011233002.95F8A3A6832@core3.amsl.com> Date: Mon, 11 Oct 2010 16:30:02 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-igp-crypto-requirements-04.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, 11 Oct 2010 23:30:03 -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 : Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols Author(s) : M. Bhatia, V. Manral Filename : draft-ietf-opsec-igp-crypto-requirements-04.txt Pages : 19 Date : 2010-10-11 The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS) and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS and OSPF. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms thereby ensuring that there is at least one algorithm that all implementations will have in common. Similarly RIPng and OSPFv3 support IPSec algorithms for authenticating their protocol packets. This document examines the current set of available algorithms with interoperability and effective cryptographic authentication protection being the principle considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-igp-crypto-requirements-04.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-igp-crypto-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11161708.I-D@ietf.org> --NextPart-- From warren@kumari.net Wed Oct 20 14:42:50 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 6C3613A69CA for ; Wed, 20 Oct 2010 14:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.932 X-Spam-Level: X-Spam-Status: No, score=-97.932 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067, 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 ilwmpgbruqJX for ; Wed, 20 Oct 2010 14:42:37 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id BD58F3A699D for ; Wed, 20 Oct 2010 14:40:08 -0700 (PDT) Received: from 106.2.128.10.in-addr.arpa.noptr.antlabs.com (h-66-134-100-50.mclnva23.static.covad.net [66.134.100.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9FF50DEE001; Wed, 20 Oct 2010 17:40:07 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 17:42:04 -0400 Message-Id: <47824788-562A-426C-AE1E-BFD305EFB648@kumari.net> To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Warren Kumari Subject: [OPSEC] RFC 6039 -- 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, 20 Oct 2010 21:42:50 -0000 Hello everyone, I just wanted to let y'all know that = draft-ietf-opsec-routing-protocols-crypto-issues has progressed to = AUTH48 state... Please join me in congratulating the authors and thanking them for = getting it this far... W= From root@core3.amsl.com Wed Oct 20 22:00:13 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 BB2B83A6987; Wed, 20 Oct 2010 22: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: <20101021050011.BB2B83A6987@core3.amsl.com> Date: Wed, 20 Oct 2010 22:00:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-ip-security-04.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: Thu, 21 Oct 2010 05:00:13 -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 : Security Assessment of the Internet Protocol version 4 Author(s) : F. Gont Filename : draft-ietf-opsec-ip-security-04.txt Pages : 77 Date : 2010-10-20 This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-ip-security-04.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-ip-security-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20215633.I-D@ietf.org> --NextPart-- From rbonica@juniper.net Fri Oct 22 11:59:50 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 41BDB3A68BF for ; Fri, 22 Oct 2010 11:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, 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 6WI+5XEd-9Ze for ; Fri, 22 Oct 2010 11:59:49 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 5D6363A68AD for ; Fri, 22 Oct 2010 11:59:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTMHfhCe4LaN4+nU/4WdKP4QdgKOameiX@postini.com; Fri, 22 Oct 2010 12:01:28 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Oct 2010 12:00:05 -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; Fri, 22 Oct 2010 15:00:04 -0400 From: Ronald Bonica To: "opsec@ietf.org" Date: Fri, 22 Oct 2010 15:00:01 -0400 Thread-Topic: AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: ActyG1Qbg9l6+m52SIysQjVoZwzlvA== Message-ID: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AX3x AeX3 BevO D7j7 EA00 ELK+ EQd9 EXMZ Envs GyHf G3Hk HD9k IGDH IJUW J/lW Lkwl; 1; bwBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {AC3A5FF3-4340-404B-A62C-7BEA85CD3D80}; cgBiAG8AbgBpAGMAYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Fri, 22 Oct 2010 19:00:01 GMT; QQBEACAAUgBlAHYAaQBlAHcAIABvAGYAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbwBwAHMAZQBjAC0AcAByAG8AdABlAGMAdAAtAGMAbwBuAHQAcgBvAGwALQBwAGwAYQBuAGUALQAwADMA x-cr-puzzleid: {AC3A5FF3-4340-404B-A62C-7BEA85CD3D80} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 22 Oct 2010 18:59:50 -0000 Folks, Having reviewed draft-ietf-opsec-protect-control-plane-03, I find that it i= s nearly ready for publication. However, I have the following comments: - editorial: the document editor might want to take one more scan through t= he document looking for grammatical errors (word duplication, missing words= , etc.) Also, please make sure that all acronyms and expanded the first tim= e that they are used. - technical: You apply the following filter on the interface between the co= ntrol and forwarding planes: - drop all fragmented packets - allow all OSPF from known peers - allow all iBGP from known peers - allow all eBGP from known peers - allow all SNMP from known managers - allow all NTP from known NTPs - allow all SSH from know managers - rate limit ICMP - rate limit non-IP - rate limit everything else First, do you want to drop all IPv4 optioned packets? IPv6 packets that inc= lude hop-by-hop options?=20 This filter is simple considering that the example doesn't include any prot= ocols that rely on IP options. If we were running a protocol like RSVP, the= filter would be slightly more complex. Filtering optioned packets protects you from "packet-o-death attacks" where= a single a single crafted packet with malformed options causes the router = control plane to crash. Your router may not be vulnerable to such attacks, = but why find out the hard way? Second, do you want to rate limit or drop all packets that are not specific= ally identified by your filter. If you rate limit them, you protect yoursel= f from DoS attacks. You also protect yourself from your own mistakes. If yo= u have forgotten to allow some class of required traffic, it will get throu= gh. If you drop all non-specified traffic, you protect yourself from some "pack= et-o-death" attacks, where a single crafted packet causes the control plane= to fall over. However, you don't protect yourself from your own mistakes. Which way do we want to go? Ron Ron From manav.bhatia@alcatel-lucent.com Fri Oct 22 14:22:02 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 D17FD3A6918 for ; Fri, 22 Oct 2010 14:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 gQS+5ZSxKBdi for ; Fri, 22 Oct 2010 14:22:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8A58A3A6805 for ; Fri, 22 Oct 2010 14:22:00 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9MLNWXU021986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Oct 2010 16:23:36 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9MLNW7C017770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 23 Oct 2010 02:53:32 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 23 Oct 2010 02:53:32 +0530 From: "Bhatia, Manav (Manav)" To: Ronald Bonica , "opsec@ietf.org" Date: Sat, 23 Oct 2010 02:53:30 +0530 Thread-Topic: AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: ActyG1Qbg9l6+m52SIysQjVoZwzlvAAEiFbw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3FE7D09@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 22 Oct 2010 21:22:02 -0000 Hi, > - technical: You apply the following filter on the interface=20 > between the control and forwarding planes: >=20 > - drop all fragmented packets > - allow all OSPF from known peers > - allow all iBGP from known peers > - allow all eBGP from known peers > - allow all SNMP from known managers > - allow all NTP from known NTPs > - allow all SSH from know managers A question - When we say allow, are we saying that there is no user configu= red rate limiting done? Wouldn't we also want to include FTP and TFTP for i= mage upgrade/large config load above? > - rate limit ICMP > - rate limit non-IP What is non-IP - L2 traffic like STP, LACP, dot1AG, CFM, etc? If Yes, then = would be helpful to point that out. > - rate limit everything else >=20 > First, do you want to drop all IPv4 optioned packets? IPv6=20 I couldn't find any text that says this. > packets that include hop-by-hop options?=20 > This filter is simple considering that the example doesn't=20 > include any protocols that rely on IP options. If we were=20 > running a protocol like RSVP, the filter would be slightly=20 > more complex. The draft can mention that packets with IPv4 options MUST be allowed if MPL= S is enabled. Manav >=20 > Filtering optioned packets protects you from "packet-o-death=20 > attacks" where a single a single crafted packet with=20 > malformed options causes the router control plane to crash.=20 > Your router may not be vulnerable to such attacks, but why=20 > find out the hard way? >=20 > Second, do you want to rate limit or drop all packets that=20 > are not specifically identified by your filter. If you rate=20 > limit them, you protect yourself from DoS attacks. You also=20 > protect yourself from your own mistakes. If you have=20 > forgotten to allow some class of required traffic, it will=20 > get through. >=20 > If you drop all non-specified traffic, you protect yourself=20 > from some "packet-o-death" attacks, where a single crafted=20 > packet causes the control plane to fall over. However, you=20 > don't protect yourself from your own mistakes. >=20 > Which way do we want to go? >=20 > Ron >=20 >=20 >=20 > Ron >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From rbonica@juniper.net Fri Oct 22 14:45: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 85EEA3A6976 for ; Fri, 22 Oct 2010 14:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_32=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 buqXMTIZR4bq for ; Fri, 22 Oct 2010 14:45:31 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 0FA8B3A6916 for ; Fri, 22 Oct 2010 14:45:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTMIGXR/HjJZIazBrgwQakyuRoRTN/Q+f@postini.com; Fri, 22 Oct 2010 14:47:10 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Oct 2010 14:45:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 22 Oct 2010 17:45:32 -0400 From: Ronald Bonica To: "Bhatia, Manav (Manav)" , "opsec@ietf.org" Date: Fri, 22 Oct 2010 17:45:30 -0400 Thread-Topic: AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: ActyG1Qbg9l6+m52SIysQjVoZwzlvAAEiFbwAAEc+3A= Message-ID: <13205C286662DE4387D9AF3AC30EF456B02138080F@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> <7C362EEF9C7896468B36C9B79200D8350CF3FE7D09@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3FE7D09@INBANSXCHMBSA1.in.alcatel-lucent.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 Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 22 Oct 2010 21:45:33 -0000 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, October 22, 2010 5:24 PM > To: Ronald Bonica; opsec@ietf.org > Subject: RE: AD Review of draft-ietf-opsec-protect-control-plane-03 >=20 > Hi, >=20 > > - technical: You apply the following filter on the interface > > between the control and forwarding planes: > > > > - drop all fragmented packets > > - allow all OSPF from known peers > > - allow all iBGP from known peers > > - allow all eBGP from known peers > > - allow all SNMP from known managers > > - allow all NTP from known NTPs > > - allow all SSH from know managers >=20 > A question - When we say allow, are we saying that there is no user > configured rate limiting done? Wouldn't we also want to include FTP and > TFTP for image upgrade/large config load above? We probably don't want to allow FTP at all. SCP is safer. >=20 > > - rate limit ICMP > > - rate limit non-IP >=20 > What is non-IP - L2 traffic like STP, LACP, dot1AG, CFM, etc? If Yes, > then would be helpful to point that out. I was thinking of PPP, HDLC, stuff like that. The authors might want to poi= nt that out. >=20 > > - rate limit everything else > > > > First, do you want to drop all IPv4 optioned packets? IPv6 >=20 > I couldn't find any text that says this. >=20 > > packets that include hop-by-hop options? > > This filter is simple considering that the example doesn't > > include any protocols that rely on IP options. If we were > > running a protocol like RSVP, the filter would be slightly > > more complex. >=20 > The draft can mention that packets with IPv4 options MUST be allowed if > MPLS is enabled. Currently, they are allowed. That's exactly my point. They shouldn't be! Ron >=20 > Manav >=20 > > > > Filtering optioned packets protects you from "packet-o-death > > attacks" where a single a single crafted packet with > > malformed options causes the router control plane to crash. > > Your router may not be vulnerable to such attacks, but why > > find out the hard way? > > > > Second, do you want to rate limit or drop all packets that > > are not specifically identified by your filter. If you rate > > limit them, you protect yourself from DoS attacks. You also > > protect yourself from your own mistakes. If you have > > forgotten to allow some class of required traffic, it will > > get through. > > > > If you drop all non-specified traffic, you protect yourself > > from some "packet-o-death" attacks, where a single crafted > > packet causes the control plane to fall over. However, you > > don't protect yourself from your own mistakes. > > > > Which way do we want to go? > > > > Ron > > > > > > > > Ron > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > From wwwrun@rfc-editor.org Fri Oct 22 18:35:12 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 DEDC828C13E; Fri, 22 Oct 2010 18:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 FZ4MFycMrG4u; Fri, 22 Oct 2010 18:35:10 -0700 (PDT) Received: from rfc-editor.org (rfcpa [64.170.98.47]) by core3.amsl.com (Postfix) with ESMTP id A52EF28C13C; Fri, 22 Oct 2010 18:35:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 177DCE070B; Fri, 22 Oct 2010 18:36:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101023013648.177DCE070B@rfc-editor.org> Date: Fri, 22 Oct 2010 18:36:48 -0700 (PDT) Cc: opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] RFC 6039 on Issues with Existing Cryptographic Protection Methods for Routing Protocols 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, 23 Oct 2010 01:35:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6039 Title: Issues with Existing Cryptographic Protection Methods for Routing Protocols Author: V. Manral, M. Bhatia, J. Jaeggli, R. White Status: Informational Stream: IETF Date: October 2010 Mailbox: vishwas@ipinfusion.com, manav.bhatia@alcatel-lucent.com, joel.jaeggli@nokia.com, riw@cisco.com Pages: 21 Characters: 50788 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-routing-protocols-crypto-issues-07.txt URL: http://www.rfc-editor.org/rfc/rfc6039.txt Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and 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. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From iesg-secretary@ietf.org Mon Oct 25 13:07: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 A450B3A6ABF; Mon, 25 Oct 2010 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 XgjG-MXrpBWg; Mon, 25 Oct 2010 13:07:37 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2743A67B3; Mon, 25 Oct 2010 13:07: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: <20101025200737.8538.23807.idtracker@localhost> Date: Mon, 25 Oct 2010 13:07:37 -0700 Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (Security Assessment of the Internet Protocol version 4) 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: Mon, 25 Oct 2010 20:07:38 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Security Assessment of the Internet Protocol version 4' 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-11-08. 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 https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ No IPR declarations were found that appear related to this I-D. From root@core3.amsl.com Mon Oct 25 17:00:03 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 D4B0A3A6C03; Mon, 25 Oct 2010 17:00:02 -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: <20101026000002.D4B0A3A6C03@core3.amsl.com> Date: Mon, 25 Oct 2010 17:00:02 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-04.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: Tue, 26 Oct 2010 00:00:03 -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-04.txt Pages : 23 Date : 2010-10-25 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25165709.I-D@ietf.org> --NextPart-- From cpignata@cisco.com Mon Oct 25 17:29:06 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 2A30F3A6BEF for ; Mon, 25 Oct 2010 17:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.228 X-Spam-Level: X-Spam-Status: No, score=-110.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 usKXw8LOJ71e for ; Mon, 25 Oct 2010 17:29:04 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 94B533A6BCF for ; Mon, 25 Oct 2010 17:29:04 -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 o9Q0UoxP014660; Mon, 25 Oct 2010 20:30:50 -0400 (EDT) Received: from [10.116.85.227] (rtp-cpignata-8712.cisco.com [10.116.85.227]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9Q0UkT8007924; Mon, 25 Oct 2010 20:30:46 -0400 (EDT) Message-ID: <4CC62135.6030803@cisco.com> Date: Mon, 25 Oct 2010 20:30:45 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Ronald Bonica References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 26 Oct 2010 00:29:06 -0000 Hi Ron, Many thanks for reviewing the document. We have submitted a new revision addressing (we believe) your comments, please see inline. On 10/22/2010 3:00 PM, Ronald Bonica wrote: > Folks, > > Having reviewed draft-ietf-opsec-protect-control-plane-03, I find > that it is nearly ready for publication. Thanks ! > However, I have the following comments: > > - editorial: the document editor might want to take one more scan > through the document looking for grammatical errors (word > duplication, missing words, etc.) Also, please make sure that all > acronyms and expanded the first time that they are used. Ack -- we've gone through the document with the fine comb, a couple of times, and did find grammos to fix. Thanks for pointing out, hopefully readability improved now. > > - technical: You apply the following filter on the interface between > the control and forwarding planes:> > > - drop all fragmented packets > - allow all OSPF from known peers > - allow all iBGP from known peers > - allow all eBGP from known peers > - allow all SNMP from known managers > - allow all NTP from known NTPs > - allow all SSH from know managers > - rate limit ICMP > - rate limit non-IP > - rate limit everything else > > First, do you want to drop all IPv4 optioned packets? IPv6 packets > that include hop-by-hop options? This filter is simple considering > that the example doesn't include any protocols that rely on IP > options. If we were running a protocol like RSVP, the filter would be > slightly more complex. We had discussed this, and agreed that since there are documents with more specific matches to the subject, that we would take a general pros/cons description on the topic and no configs; please see next comment. > > Filtering optioned packets protects you from "packet-o-death attacks" > where a single a single crafted packet with malformed options causes > the router control plane to crash. Your router may not be vulnerable > to such attacks, but why find out the hard way? Agreed there's this tradeoff. That's why we had the existing text already in the document: 3.3. Design Trade-offs Two types of traffic that need special consideration are IP fragments and IP optioned packets. [...] Similarly, some deployments may chose to drop all IP Optioned Packets. Others may need to losen the constraint to allow for protocols that require IP Optioned packets such as RSVP. and then: 4. Security Considerations Additional considerations pertaining to the usage and handling of traffic that utilizes the IP Router Alert Options can be found at [I-D.ietf-intarea-router-alert-considerations], and additional IP Options filtering explanations can be found at [I-D.gont-opsec-ip-options-filtering]. But to your point, we have expanded the "S3.3. Design Trade-offs" paragraph significantly in this new rev -04. Please do let us know if you feel the additions do not address your concern explicitly enough. > > Second, do you want to rate limit or drop all packets that are not > specifically identified by your filter. If you rate limit them, you > protect yourself from DoS attacks. You also protect yourself from > your own mistakes. If you have forgotten to allow some class of > required traffic, it will get through. > > If you drop all non-specified traffic, you protect yourself from some > "packet-o-death" attacks, where a single crafted packet causes the > control plane to fall over. However, you don't protect yourself from > your own mistakes. > > Which way do we want to go? Similarly, we do agree and we do discussed this topic extensively. The position we took is that we protect the operator from "allow omissions" in the example and we describe in great detail the process of selecting what to do here. In fact, we had a final/default "drop all" and we changed it and add the description based on feedback. On the document you will find this: 3.2. Filter Design In an actual production environment, predicting a complete and exhaustive list of traffic necessary to reach the router's control plane for day-to-day operation may not be this obvious. One recommended method to gauge this set of traffic is to allow all traffic initially, and audit the traffic that reaches the router control plane before applying any explicit filters or rate limits. See the Section 3.3 section below for more discussion of this topic. 3.3. Design Trade-offs 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 classification. Typically that traffic is referred to as traffic that gets matched in a default class. It may also be traffic that matches a blanket protocol specific class where previous classes that have more granular classification 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 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 and characterize 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 allowed the default class should be configured to drop any remaining traffic. There are also other related passages. Do you think that this addresses your concern? Thanks again, Ron ! -- Carlos. > > Ron > > > > Ron > > _______________________________________________ OPSEC mailing list > OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec > From rbonica@juniper.net Tue Oct 26 14:28:47 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 B89A83A6879 for ; Tue, 26 Oct 2010 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 BYfEZWkHvZeE for ; Tue, 26 Oct 2010 14:28:38 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 0E0AA3A682C for ; Tue, 26 Oct 2010 14:28:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTMdIcinO7ouXeVPDebr33gDYDDjtoORx@postini.com; Tue, 26 Oct 2010 14:30:26 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Oct 2010 14:30:16 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 26 Oct 2010 17:30:16 -0400 From: Ronald Bonica To: Carlos Pignataro Date: Tue, 26 Oct 2010 17:30:15 -0400 Thread-Topic: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: Act0pQyVsOTKjcXzQiK+xs0lOiMXZQArupyg Message-ID: <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> <4CC62135.6030803@cisco.com> In-Reply-To: <4CC62135.6030803@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] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 26 Oct 2010 21:28:47 -0000 > -----Original Message----- > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Monday, October 25, 2010 8:31 PM > To: Ronald Bonica > Cc: opsec@ietf.org > Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > plane-03 >=20 > Hi Ron, >=20 > Many thanks for reviewing the document. We have submitted a new > revision > addressing (we believe) your comments, please see inline. >=20 > On 10/22/2010 3:00 PM, Ronald Bonica wrote: > > Folks, > > > > Having reviewed draft-ietf-opsec-protect-control-plane-03, I find > > that it is nearly ready for publication. >=20 > Thanks ! >=20 > > However, I have the following comments: > > > > - editorial: the document editor might want to take one more scan > > through the document looking for grammatical errors (word > > duplication, missing words, etc.) Also, please make sure that all > > acronyms and expanded the first time that they are used. >=20 > Ack -- we've gone through the document with the fine comb, a couple of > times, and did find grammos to fix. Thanks for pointing out, hopefully > readability improved now. >=20 > > > > - technical: You apply the following filter on the interface between > > the control and forwarding planes:> > > > > - drop all fragmented packets > > - allow all OSPF from known peers > > - allow all iBGP from known peers > > - allow all eBGP from known peers > > - allow all SNMP from known managers > > - allow all NTP from known NTPs > > - allow all SSH from know managers > > - rate limit ICMP > > - rate limit non-IP > > - rate limit everything else > > > > First, do you want to drop all IPv4 optioned packets? IPv6 packets > > that include hop-by-hop options? This filter is simple considering > > that the example doesn't include any protocols that rely on IP > > options. If we were running a protocol like RSVP, the filter would be > > slightly more complex. >=20 > We had discussed this, and agreed that since there are documents with > more specific matches to the subject, that we would take a general > pros/cons description on the topic and no configs; please see next > comment. >=20 > > > > Filtering optioned packets protects you from "packet-o-death attacks" > > where a single a single crafted packet with malformed options causes > > the router control plane to crash. Your router may not be vulnerable > > to such attacks, but why find out the hard way? >=20 > Agreed there's this tradeoff. That's why we had the existing text > already in the document: >=20 > 3.3. Design Trade-offs >=20 > Two types of traffic that need special consideration are IP > fragments > and IP optioned packets. > [...] > Similarly, some deployments may chose to drop all IP Optioned > Packets. Others may need to losen the constraint to allow for > protocols that require IP Optioned packets such as RSVP. >=20 > and then: >=20 > 4. Security Considerations >=20 > Additional considerations pertaining to the usage and handling of > traffic that utilizes the IP Router Alert Options can be found at > [I-D.ietf-intarea-router-alert-considerations], and additional IP > Options filtering explanations can be found at > [I-D.gont-opsec-ip-options-filtering]. >=20 >=20 > But to your point, we have expanded the "S3.3. Design Trade-offs" > paragraph significantly in this new rev -04. >=20 > Please do let us know if you feel the additions do not address your > concern explicitly enough. OK.. I'll go along with that. >=20 > > > > Second, do you want to rate limit or drop all packets that are not > > specifically identified by your filter. If you rate limit them, you > > protect yourself from DoS attacks. You also protect yourself from > > your own mistakes. If you have forgotten to allow some class of > > required traffic, it will get through. > > > > If you drop all non-specified traffic, you protect yourself from some > > "packet-o-death" attacks, where a single crafted packet causes the > > control plane to fall over. However, you don't protect yourself from > > your own mistakes. > > > > Which way do we want to go? >=20 > Similarly, we do agree and we do discussed this topic extensively. The > position we took is that we protect the operator from "allow omissions" > in the example and we describe in great detail the process of selecting > what to do here. >=20 > In fact, we had a final/default "drop all" and we changed it and add > the > description based on feedback. >=20 > On the document you will find this: >=20 > 3.2. Filter Design >=20 > In an actual production environment, predicting a complete and > exhaustive list of traffic necessary to reach the router's control > plane for day-to-day operation may not be this obvious. One > recommended method to gauge this set of traffic is to allow all > traffic initially, and audit the traffic that reaches the router > control plane before applying any explicit filters or rate limits. > See the Section 3.3 section below for more discussion of this topic. >=20 > 3.3. Design Trade-offs >=20 > 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 classification. Typically that traffic > is referred to as traffic that gets matched in a default class. It > may also be traffic that matches a blanket protocol specific class > where previous classes that have more granular classification 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 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 and characterize 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 allowed the default class > should be configured to drop any remaining traffic. >=20 > There are also other related passages. >=20 > Do you think that this addresses your concern? I am OK with rate-limiting other for a short time to discover what traffic = has been ignored by the filter. When you discover something that you should= have allowed, you add it to the filter and continue the experiment. At som= e point, when the rate-limit other clause hasn't caught anything for a whil= e, you should drop other. Rate-limit other should be a temporary thing Ron >=20 > Thanks again, Ron ! >=20 > -- Carlos. >=20 > > > > Ron > > > > > > > > Ron > > > > _______________________________________________ OPSEC mailing list > > OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec > > From rodunn@cisco.com Tue Oct 26 16:33:48 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 792713A689F for ; Tue, 26 Oct 2010 16:33:48 -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 rnf--W4QQrj8 for ; Tue, 26 Oct 2010 16:33:44 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 9D7993A6899 for ; Tue, 26 Oct 2010 16:33:44 -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 o9QNZWgO017350; Tue, 26 Oct 2010 19:35:32 -0400 (EDT) Received: from dhcp-64-102-221-214.cisco.com (dhcp-64-102-221-214.cisco.com [64.102.221.214]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QNZSeO014801; Tue, 26 Oct 2010 19:35:28 -0400 (EDT) Message-ID: <4CC766EC.2020509@cisco.com> Date: Tue, 26 Oct 2010 19:40:28 -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.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Ronald Bonica References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> <4CC62135.6030803@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Carlos Pignataro , "opsec@ietf.org" Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 26 Oct 2010 23:33:48 -0000 Ron, We 100% agree. We had added verbage in Section 3.3 directly targeted at this exact deployment point. Is it comprehensive and direct enough? 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 classification. Typically that traffic is referred to as traffic that gets matched in a default class. It may also be traffic that matches a blanket protocol specific class where previous classes that have more granular classification 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 match 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 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 and characterize 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 allowed the default class should be configured to drop any remaining traffic. Rodney On 10/26/10 5:30 PM, Ronald Bonica wrote: > I am OK with rate-limiting other for a short time to discover what traffic has been ignored by the filter. When you discover something that you should have allowed, you add it to the filter and continue the experiment. At some point, when the rate-limit other clause hasn't caught anything for a while, you should drop other. > > > Rate-limit other should be a temporary thing > > Ron From rbonica@juniper.net Wed Oct 27 11:17: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 BFCB73A691A for ; Wed, 27 Oct 2010 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, 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 OKzB+8tnsnWZ for ; Wed, 27 Oct 2010 11:17:07 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 86BC03A6803 for ; Wed, 27 Oct 2010 11:16:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTMhtBwpl346WoarUuLHtzdEtuODxT8V+@postini.com; Wed, 27 Oct 2010 11:18:48 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Oct 2010 11:16:58 -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; Wed, 27 Oct 2010 14:16:57 -0400 From: Ronald Bonica To: "rodunn@cisco.com" Date: Wed, 27 Oct 2010 14:16:56 -0400 Thread-Topic: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: Act1Zn1xGTnnJp2HSBm03Sj/vPdWvAAnBtKg Message-ID: <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> <4CC62135.6030803@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> <4CC766EC.2020509@cisco.com> In-Reply-To: <4CC766EC.2020509@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: Carlos Pignataro , "opsec@ietf.org" Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 27 Oct 2010 18:17:15 -0000 Rodney, I think that we are very close to converging. We agree that: - while an operator is in the process of identifying legitimate traffic, th= e default action is to rate-limit - when the operator has identified all legitimate traffic, the default acti= on is to drop We agree that both states need to be mentioned in the document. But which s= hould be demonstrated? I think that later/permanent state. Ron > -----Original Message----- > From: Rodney Dunn [mailto:rodunn@cisco.com] > Sent: Tuesday, October 26, 2010 7:40 PM > To: Ronald Bonica > Cc: Carlos Pignataro; opsec@ietf.org > Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > plane-03 >=20 > Ron, >=20 > We 100% agree. We had added verbage in Section 3.3 directly targeted at > this exact deployment point. >=20 > Is it comprehensive and direct enough? >=20 > > 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 classification. Typically that traffic > is referred to as traffic that gets matched in a default class. It > may also be traffic that matches a blanket protocol specific class > where previous classes that have more granular classification 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 match > 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 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 and characterize 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 allowed the default class > should be configured to drop any remaining traffic. >=20 > >=20 > Rodney >=20 >=20 >=20 >=20 > On 10/26/10 5:30 PM, Ronald Bonica wrote: > > I am OK with rate-limiting other for a short time to discover what > traffic has been ignored by the filter. When you discover something > that you should have allowed, you add it to the filter and continue the > experiment. At some point, when the rate-limit other clause hasn't > caught anything for a while, you should drop other. > > > > > > Rate-limit other should be a temporary thing > > > > Ron From cpignata@cisco.com Wed Oct 27 11:54:58 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 E2EE43A6803 for ; Wed, 27 Oct 2010 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dpLIsk4yPjDm for ; Wed, 27 Oct 2010 11:54:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 429893A67F9 for ; Wed, 27 Oct 2010 11:54:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="175685097" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2010 18:56:47 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9RIuka9018838; Wed, 27 Oct 2010 18:56:46 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:56:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2010 13:56:41 -0500 Message-ID: <960EC8F9A775AB40BF58D8953342D86302FBB43A@XMB-RCD-206.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: Act1Zn1xGTnnJp2HSBm03Sj/vPdWvAAnBtKgAACa+xA= References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net><4CC62135.6030803@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> <4CC766EC.2020509@cisco.com> <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> From: "Carlos Pignataro (cpignata)" To: "Ronald Bonica" , "Rodney Dunn (rodunn)" X-OriginalArrivalTime: 27 Oct 2010 18:56:47.0299 (UTC) FILETIME=[B4A92130:01CB7608] Cc: opsec@ietf.org Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 27 Oct 2010 18:54:59 -0000 Ron, Good summary, thanks. Our thought is that we want to demonstrate the _initial_ state, not the permanent; the rational is to minimize potential self-blackholing when first implementing, and to give time to get to the permanent state. The spirit and philosophy of this document is that it present a minimalistic and initial state in the demonstration in the Appendix, that needs to evolve from there. Do you think this safer approach is OK? and if so that we need to further clarify the intent beyond the excerpt included below? Thanks, -- Carlos. -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net]=20 Sent: Wednesday, October 27, 2010 2:17 PM To: Rodney Dunn (rodunn) Cc: Carlos Pignataro (cpignata); opsec@ietf.org Subject: RE: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Rodney, I think that we are very close to converging. We agree that: - while an operator is in the process of identifying legitimate traffic, the default action is to rate-limit - when the operator has identified all legitimate traffic, the default action is to drop We agree that both states need to be mentioned in the document. But which should be demonstrated? I think that later/permanent state. Ron > -----Original Message----- > From: Rodney Dunn [mailto:rodunn@cisco.com] > Sent: Tuesday, October 26, 2010 7:40 PM > To: Ronald Bonica > Cc: Carlos Pignataro; opsec@ietf.org > Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > plane-03 >=20 > Ron, >=20 > We 100% agree. We had added verbage in Section 3.3 directly targeted at > this exact deployment point. >=20 > Is it comprehensive and direct enough? >=20 > > 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 classification. Typically that traffic > is referred to as traffic that gets matched in a default class. It > may also be traffic that matches a blanket protocol specific class > where previous classes that have more granular classification 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 match > 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 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 and characterize 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 allowed the default class > should be configured to drop any remaining traffic. >=20 > >=20 > Rodney >=20 >=20 >=20 >=20 > On 10/26/10 5:30 PM, Ronald Bonica wrote: > > I am OK with rate-limiting other for a short time to discover what > traffic has been ignored by the filter. When you discover something > that you should have allowed, you add it to the filter and continue the > experiment. At some point, when the rate-limit other clause hasn't > caught anything for a while, you should drop other. > > > > > > Rate-limit other should be a temporary thing > > > > Ron From Donald.Smith@qwest.com Wed Oct 27 11:59:36 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 EFB163A67F9 for ; Wed, 27 Oct 2010 11:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 03MlnNmYz4Kx for ; Wed, 27 Oct 2010 11:59:32 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 67ECF3A6818 for ; Wed, 27 Oct 2010 11:59:31 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o9RJ1Fsc005388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 14:01:15 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0C16F1E005B; Wed, 27 Oct 2010 14:01:10 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E42D91E0049; Wed, 27 Oct 2010 14:01:09 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o9RJ16Kc001214; Wed, 27 Oct 2010 14:01:09 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 27 Oct 2010 13:00:43 -0600 From: "Smith, Donald" To: "'Ronald Bonica'" , "'rodunn@cisco.com'" Date: Wed, 27 Oct 2010 13:00:42 -0600 Thread-Topic: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: Act1Zn1xGTnnJp2HSBm03Sj/vPdWvAAnBtKgAAGodUA= Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net> <4CC62135.6030803@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> <4CC766EC.2020509@cisco.com> <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> 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 X-CFilter-Loop: Reflected Cc: 'Carlos Pignataro' , "'opsec@ietf.org'" Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 27 Oct 2010 18:59:36 -0000 +1 (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 Ronald Bonica > Sent: Wednesday, October 27, 2010 12:17 PM > To: rodunn@cisco.com > Cc: Carlos Pignataro; opsec@ietf.org > Subject: Re: [OPSEC] AD Review of > draft-ietf-opsec-protect-control-plane-03 > > Rodney, > > I think that we are very close to converging. We agree that: > > - while an operator is in the process of identifying > legitimate traffic, the default action is to rate-limit > - when the operator has identified all legitimate traffic, > the default action is to drop > > We agree that both states need to be mentioned in the > document. But which should be demonstrated? I think that > later/permanent state. > > Ron > > > > -----Original Message----- > > From: Rodney Dunn [mailto:rodunn@cisco.com] > > Sent: Tuesday, October 26, 2010 7:40 PM > > To: Ronald Bonica > > Cc: Carlos Pignataro; opsec@ietf.org > > Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > > plane-03 > > > > Ron, > > > > We 100% agree. We had added verbage in Section 3.3 directly > targeted at > > this exact deployment point. > > > > Is it comprehensive and direct enough? > > > > > > 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 classification. Typically > that traffic > > is referred to as traffic that gets matched in a > default class. It > > may also be traffic that matches a blanket protocol > specific class > > where previous classes that have more granular > classification 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 match > > 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 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 and characterize > 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 allowed the default class > > should be configured to drop any remaining traffic. > > > > > > > > Rodney > > > > > > > > > > On 10/26/10 5:30 PM, Ronald Bonica wrote: > > > I am OK with rate-limiting other for a short time to discover what > > traffic has been ignored by the filter. When you discover something > > that you should have allowed, you add it to the filter and > continue the > > experiment. At some point, when the rate-limit other clause hasn't > > caught anything for a while, you should drop other. > > > > > > > > > Rate-limit other should be a temporary thing > > > > > > Ron > _______________________________________________ > 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 rbonica@juniper.net Wed Oct 27 12:13:31 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 D10743A67F9 for ; Wed, 27 Oct 2010 12:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, 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 tD5EfitcIzyB for ; Wed, 27 Oct 2010 12:13:29 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 4AABE3A6803 for ; Wed, 27 Oct 2010 12:13:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTMh6QgM4MZtjZ4X7PQOhchMYXeApbzgP@postini.com; Wed, 27 Oct 2010 12:15:20 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; Wed, 27 Oct 2010 12:14:59 -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; Wed, 27 Oct 2010 15:14:58 -0400 From: Ronald Bonica To: "Carlos Pignataro (cpignata)" , "Rodney Dunn (rodunn)" Date: Wed, 27 Oct 2010 15:14:57 -0400 Thread-Topic: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: Act1Zn1xGTnnJp2HSBm03Sj/vPdWvAAnBtKgAACa+xAAAWl4sA== Message-ID: <13205C286662DE4387D9AF3AC30EF456B0216B040C@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net><4CC62135.6030803@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> <4CC766EC.2020509@cisco.com> <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> <960EC8F9A775AB40BF58D8953342D86302FBB43A@XMB-RCD-206.cisco.com> In-Reply-To: <960EC8F9A775AB40BF58D8953342D86302FBB43A@XMB-RCD-206.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] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 27 Oct 2010 19:13:32 -0000 Carlos, This is really a hard call. Whichever way you present the document, the rea= der is prone to mistakes. If you present the initial state only, some reade= rs will stay in the initial state forever. They will not be protected from = packets-o-death. If you present the final state only, some readers will pro= gress to the final state prematurely. They will cause their own death. Either way...... Why don't we let a few others weigh in. I will go along with WG consensus. Ron > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, October 27, 2010 2:57 PM > To: Ronald Bonica; Rodney Dunn (rodunn) > Cc: opsec@ietf.org > Subject: RE: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > plane-03 >=20 > Ron, >=20 > Good summary, thanks. >=20 > Our thought is that we want to demonstrate the _initial_ state, not the > permanent; the rational is to minimize potential self-blackholing when > first implementing, and to give time to get to the permanent state. >=20 > The spirit and philosophy of this document is that it present a > minimalistic and initial state in the demonstration in the Appendix, > that needs to evolve from there. >=20 > Do you think this safer approach is OK? and if so that we need to > further clarify the intent beyond the excerpt included below? >=20 > Thanks, >=20 > -- Carlos. >=20 > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Wednesday, October 27, 2010 2:17 PM > To: Rodney Dunn (rodunn) > Cc: Carlos Pignataro (cpignata); opsec@ietf.org > Subject: RE: [OPSEC] AD Review of > draft-ietf-opsec-protect-control-plane-03 >=20 > Rodney, >=20 > I think that we are very close to converging. We agree that: >=20 > - while an operator is in the process of identifying legitimate > traffic, > the default action is to rate-limit > - when the operator has identified all legitimate traffic, the default > action is to drop >=20 > We agree that both states need to be mentioned in the document. But > which should be demonstrated? I think that later/permanent state. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Rodney Dunn [mailto:rodunn@cisco.com] > > Sent: Tuesday, October 26, 2010 7:40 PM > > To: Ronald Bonica > > Cc: Carlos Pignataro; opsec@ietf.org > > Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > > plane-03 > > > > Ron, > > > > We 100% agree. We had added verbage in Section 3.3 directly targeted > at > > this exact deployment point. > > > > Is it comprehensive and direct enough? > > > > > > 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 classification. Typically that > traffic > > is referred to as traffic that gets matched in a default class. > It > > may also be traffic that matches a blanket protocol specific > class > > where previous classes that have more granular classification 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 > match > > 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 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 and characterize 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 allowed the default class > > should be configured to drop any remaining traffic. > > > > > > > > Rodney > > > > > > > > > > On 10/26/10 5:30 PM, Ronald Bonica wrote: > > > I am OK with rate-limiting other for a short time to discover what > > traffic has been ignored by the filter. When you discover something > > that you should have allowed, you add it to the filter and continue > the > > experiment. At some point, when the rate-limit other clause hasn't > > caught anything for a while, you should drop other. > > > > > > > > > Rate-limit other should be a temporary thing > > > > > > Ron From cpignata@cisco.com Wed Oct 27 12:22:24 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 63A1C3A691A for ; Wed, 27 Oct 2010 12:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ycWRi0GqatS6 for ; Wed, 27 Oct 2010 12:22:23 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2488B3A6981 for ; Wed, 27 Oct 2010 12:22:22 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="175694709" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2010 19:24:12 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o9RJOBqe023412; Wed, 27 Oct 2010 19:24:12 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 14:24:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2010 14:24:10 -0500 Message-ID: <960EC8F9A775AB40BF58D8953342D86302FBB467@XMB-RCD-206.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0216B040C@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Thread-Index: Act1Zn1xGTnnJp2HSBm03Sj/vPdWvAAnBtKgAACa+xAAAWl4sAAARhuA References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net><4CC62135.6030803@cisco.com><13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net><4CC766EC.2020509@cisco.com><13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net><960EC8F9A775AB40BF58D8953342D86302FBB43A@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B0216B040C@EMBX01-WF.jnpr.net> From: "Carlos Pignataro (cpignata)" To: "Ronald Bonica" , "Rodney Dunn (rodunn)" X-OriginalArrivalTime: 27 Oct 2010 19:24:12.0357 (UTC) FILETIME=[89310F50:01CB760C] Cc: opsec@ietf.org Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 27 Oct 2010 19:22:24 -0000 Ron, Sounds good. [I too see both sides (and both cons), and we can go with what makes more sense to the group.] Thanks, -- Carlos. -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Wednesday, October 27, 2010 3:15 PM To: Carlos Pignataro (cpignata); Rodney Dunn (rodunn) Cc: opsec@ietf.org Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 Carlos, This is really a hard call. Whichever way you present the document, the reader is prone to mistakes. If you present the initial state only, some readers will stay in the initial state forever. They will not be protected from packets-o-death. If you present the final state only, some readers will progress to the final state prematurely. They will cause their own death. Either way...... Why don't we let a few others weigh in. I will go along with WG consensus. Ron > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, October 27, 2010 2:57 PM > To: Ronald Bonica; Rodney Dunn (rodunn) > Cc: opsec@ietf.org > Subject: RE: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > plane-03 >=20 > Ron, >=20 > Good summary, thanks. >=20 > Our thought is that we want to demonstrate the _initial_ state, not the > permanent; the rational is to minimize potential self-blackholing when > first implementing, and to give time to get to the permanent state. >=20 > The spirit and philosophy of this document is that it present a > minimalistic and initial state in the demonstration in the Appendix, > that needs to evolve from there. >=20 > Do you think this safer approach is OK? and if so that we need to > further clarify the intent beyond the excerpt included below? >=20 > Thanks, >=20 > -- Carlos. >=20 > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Wednesday, October 27, 2010 2:17 PM > To: Rodney Dunn (rodunn) > Cc: Carlos Pignataro (cpignata); opsec@ietf.org > Subject: RE: [OPSEC] AD Review of > draft-ietf-opsec-protect-control-plane-03 >=20 > Rodney, >=20 > I think that we are very close to converging. We agree that: >=20 > - while an operator is in the process of identifying legitimate > traffic, > the default action is to rate-limit > - when the operator has identified all legitimate traffic, the default > action is to drop >=20 > We agree that both states need to be mentioned in the document. But > which should be demonstrated? I think that later/permanent state. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Rodney Dunn [mailto:rodunn@cisco.com] > > Sent: Tuesday, October 26, 2010 7:40 PM > > To: Ronald Bonica > > Cc: Carlos Pignataro; opsec@ietf.org > > Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- > > plane-03 > > > > Ron, > > > > We 100% agree. We had added verbage in Section 3.3 directly targeted > at > > this exact deployment point. > > > > Is it comprehensive and direct enough? > > > > > > 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 classification. Typically that > traffic > > is referred to as traffic that gets matched in a default class. > It > > may also be traffic that matches a blanket protocol specific > class > > where previous classes that have more granular classification 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 > match > > 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 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 and characterize 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 allowed the default class > > should be configured to drop any remaining traffic. > > > > > > > > Rodney > > > > > > > > > > On 10/26/10 5:30 PM, Ronald Bonica wrote: > > > I am OK with rate-limiting other for a short time to discover what > > traffic has been ignored by the filter. When you discover something > > that you should have allowed, you add it to the filter and continue > the > > experiment. At some point, when the rate-limit other clause hasn't > > caught anything for a while, you should drop other. > > > > > > > > > Rate-limit other should be a temporary thing > > > > > > Ron _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From warren@kumari.net Wed Oct 27 16:15:23 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 25A933A67D0 for ; Wed, 27 Oct 2010 16:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 JrvWB8jkKras for ; Wed, 27 Oct 2010 16:15:21 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id DE2D63A63D2 for ; Wed, 27 Oct 2010 16:15:20 -0700 (PDT) Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 257FE228479E; Wed, 27 Oct 2010 19:15:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0216B040C@EMBX01-WF.jnpr.net> Date: Wed, 27 Oct 2010 19:18:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83A71A81-666C-410A-A019-FF9FF2A604C9@kumari.net> References: <13205C286662DE4387D9AF3AC30EF456B0213805A6@EMBX01-WF.jnpr.net><4CC62135.6030803@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02161BD0B@EMBX01-WF.jnpr.net> <4CC766EC.2020509@cisco.com> <13205C286662DE4387D9AF3AC30EF456B0216B02EA@EMBX01-WF.jnpr.net> <960EC8F9A775AB40BF58D8953342D86302FBB43A@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B0216B040C@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1081) Cc: "Carlos Pignataro \(cpignata\)" , "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control-plane-03 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, 27 Oct 2010 23:15:23 -0000 On Oct 27, 2010, at 3:14 PM, Ronald Bonica wrote: > Carlos, >=20 > This is really a hard call. Whichever way you present the document, = the reader is prone to mistakes. If you present the initial state only, = some readers will stay in the initial state forever. They will not be = protected from packets-o-death. If you present the final state only, = some readers will progress to the final state prematurely. They will = cause their own death. >=20 > Either way...... >=20 > Why don't we let a few others weigh in. I will go along with WG = consensus. I guess it depends on which death is preferable -- personally I think = the latter one. I'd much rather have folk progress to the final state, = realize that they have just shot themselves in the foot and revert the = offending bit than have folk get sidetracked while in the "fiddling" = stage and not be fully protected (or, worse yet, rate-limiting at a = level that works much of the time, but not quite at busy times, which = leads to debugging entertainment...) Warren "No Hats" Kumari. >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: Wednesday, October 27, 2010 2:57 PM >> To: Ronald Bonica; Rodney Dunn (rodunn) >> Cc: opsec@ietf.org >> Subject: RE: [OPSEC] AD Review of draft-ietf-opsec-protect-control- >> plane-03 >>=20 >> Ron, >>=20 >> Good summary, thanks. >>=20 >> Our thought is that we want to demonstrate the _initial_ state, not = the >> permanent; the rational is to minimize potential self-blackholing = when >> first implementing, and to give time to get to the permanent state. >>=20 >> The spirit and philosophy of this document is that it present a >> minimalistic and initial state in the demonstration in the Appendix, >> that needs to evolve from there. >>=20 >> Do you think this safer approach is OK? and if so that we need to >> further clarify the intent beyond the excerpt included below? >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> -----Original Message----- >> From: Ronald Bonica [mailto:rbonica@juniper.net] >> Sent: Wednesday, October 27, 2010 2:17 PM >> To: Rodney Dunn (rodunn) >> Cc: Carlos Pignataro (cpignata); opsec@ietf.org >> Subject: RE: [OPSEC] AD Review of >> draft-ietf-opsec-protect-control-plane-03 >>=20 >> Rodney, >>=20 >> I think that we are very close to converging. We agree that: >>=20 >> - while an operator is in the process of identifying legitimate >> traffic, >> the default action is to rate-limit >> - when the operator has identified all legitimate traffic, the = default >> action is to drop >>=20 >> We agree that both states need to be mentioned in the document. But >> which should be demonstrated? I think that later/permanent state. >>=20 >> Ron >>=20 >>=20 >>> -----Original Message----- >>> From: Rodney Dunn [mailto:rodunn@cisco.com] >>> Sent: Tuesday, October 26, 2010 7:40 PM >>> To: Ronald Bonica >>> Cc: Carlos Pignataro; opsec@ietf.org >>> Subject: Re: [OPSEC] AD Review of draft-ietf-opsec-protect-control- >>> plane-03 >>>=20 >>> Ron, >>>=20 >>> We 100% agree. We had added verbage in Section 3.3 directly targeted >> at >>> this exact deployment point. >>>=20 >>> Is it comprehensive and direct enough? >>>=20 >>> >>> 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 classification. Typically that >> traffic >>> is referred to as traffic that gets matched in a default class. >> It >>> may also be traffic that matches a blanket protocol specific >> class >>> where previous classes that have more granular classification 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 >> match >>> 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 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 and characterize 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 allowed the default class >>> should be configured to drop any remaining traffic. >>>=20 >>> >>>=20 >>> Rodney >>>=20 >>>=20 >>>=20 >>>=20 >>> On 10/26/10 5:30 PM, Ronald Bonica wrote: >>>> I am OK with rate-limiting other for a short time to discover what >>> traffic has been ignored by the filter. When you discover something >>> that you should have allowed, you add it to the filter and continue >> the >>> experiment. At some point, when the rate-limit other clause hasn't >>> caught anything for a while, you should drop other. >>>>=20 >>>>=20 >>>> Rate-limit other should be a temporary thing >>>>=20 >>>> Ron >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec