From root@core3.amsl.com Sat Jul 3 22:45:10 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 8061E3A692C; Sat, 3 Jul 2010 22: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: <20100704054506.8061E3A692C@core3.amsl.com> Date: Sat, 3 Jul 2010 22:45:02 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.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, 04 Jul 2010 05:45:10 -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-00.txt Pages : 17 Date : 2010-06-29 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-03224017.I-D@ietf.org> --NextPart-- From manav.bhatia@alcatel-lucent.com Mon Jul 5 03:45: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 B39D03A63EC for ; Mon, 5 Jul 2010 03:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xXAiEQ7bR422 for ; Mon, 5 Jul 2010 03:45:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id BD3493A6874 for ; Mon, 5 Jul 2010 03:45:30 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o65AjQB1008803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Jul 2010 05:45:28 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o65AjOhN003650 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 5 Jul 2010 16:15:25 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 5 Jul 2010 16:15:24 +0530 From: "Bhatia, Manav (Manav)" To: "'opsec@ietf.org'" Date: Mon, 5 Jul 2010 16:15:23 +0530 Thread-Topic: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt Thread-Index: AcsbPBmVEdypGtwrRLqqlWJ125R1LgA7hVlQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20100704054506.8061E3A692C@core3.amsl.com> In-Reply-To: <20100704054506.8061E3A692C@core3.amsl.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.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, 05 Jul 2010 10:45:31 -0000 Hi, Couple of comments: o Just like OSPF, you should probably also add some filters for link level = LDP as you don't want LDP to start exchanging MPLS labels with all the peer= s it receives HELLOs from.=20 o Can some filters be added for IS-IS? o It might also be a good idea to add some text on what some implementation= s do to protect the control plane without any manual configs. This would fo= r example be, rate limiting all traffic for which ARP is unresolved or rate= limiting all traffic for which there is no route in the routing table, etc= .=20 o Related to the above point you should also add some configs about how pro= viders can rate limit all the ICMP host/network unreachables that it sends = out, etc. Cheers, Manav > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of Internet-Drafts@ietf.org > Sent: Sunday, July 04, 2010 11.15 AM > To: i-d-announce@ietf.org > Cc: opsec@ietf.org > Subject: [OPSEC] I-D=20 > Action:draft-ietf-opsec-protect-control-plane-00.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Operational Security=20 > Capabilities for IP Network Infrastructure Working Group of the IETF. >=20 >=20 > Title : Protecting The Router Control Plane > Author(s) : D. Dugal, et al. > Filename : draft-ietf-opsec-protect-control-plane-00.txt > Pages : 17 > Date : 2010-06-29 >=20 > 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-c > ontrol-plane-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From joelja@bogus.com Mon Jul 5 15:00:41 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 10FDB3A6A10 for ; Mon, 5 Jul 2010 15:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Xi6-ZWxLrmMu for ; Mon, 5 Jul 2010 15:00:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 290DF3A6A13 for ; Mon, 5 Jul 2010 15:00:38 -0700 (PDT) Received: from [192.168.11.112] (c-67-189-76-178.hsd1.wa.comcast.net [67.189.76.178]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o65M0OFA085546 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 5 Jul 2010 22:00:37 GMT (envelope-from joelja@bogus.com) Message-ID: <4C3255F0.9040204@bogus.com> Date: Mon, 05 Jul 2010 15:00:16 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 05 Jul 2010 22:00:40 +0000 (UTC) Subject: [OPSEC] FYI Fwd: Document shepherd review for draft-ietf-opsec-igp-crypto-requirements-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 22:00:41 -0000 -------- Original Message -------- Subject: Document shepherd review for draft-ietf-opsec-igp-crypto-requirements-00 Date: Mon, 05 Jul 2010 14:58:54 -0700 From: Joel Jaeggli To: Ron Bonica , Joe Abley , "Bhatia, Manav (Manav)" , "vishwas.ietf@gmail.com" Document shepherd writeup for: draft-ietf-opsec-igp-crypto-requirements-00.txt http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00.txt Prepared by: Joel Jaeggli 6/21/2010 1.a The Document Shepherd is Joel Jaeggli, Opsec WG co-chair. The Document Shepherd has reviewed Draft 00 of draft-ietf-opsec-igp-crypto-requirements and concluded that the document is prepared for IESG review and publication as an informational document. 1.b The document was widely socialized within the routing area working groups where protocol maintenance is being performed prior to being brought to the opsec working group. With opsec working group input the focus has changed somewhat for altering the cryptogrphica protocal usage of igp protocols to enumerating what the likely requirements should be and the basis for those recommendations. 1.c Insofar as the the doucument shepherd is concerned, further review of future changes in state of cryptogrphic protection for IGP and EGP protocols should be performed in working groups tasked with the protocol maintenance activities or in working groups chartered to solve the cyrpto-problem, such as the karp working group. This document represents the consensus view of the authors and the working group on what the requirements for such protocols should be. 1.d One concern of the shepherd is that the working title while accurate at the inception of the document somewhat overstates the fairly modest goals of the document in it's present form. The long form title is altogether more representative of the goals of the document. Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols 1.e Working group consensus has been solidly behind this draft following revision is it's current form. Since presentation of the Updated draft in Aanuary the document has been accepted as a working group document and subsequently lasted called. Serious objections were not raised in either case. Prior to the revision, the draft have been presented in the working group meeting, discussed on the list, and had received contributions from working-group participants, however concern with the scope and the goal of changing protocol specifications in an ops area working group had precluded acceptance. 1.f No appeals or discontent are noted in the working group regarding the current draft at this time. 1.g IDnits notes the existence of several dated references many of which are required for historical treatment of the subject matter. Not major nits are noted. 1.h The draft divides references between normative and informative. This document's advancement is not blocked on the advancement of normatively referenced material. 1.i The draft makes no requests of IANA. Authentication methods (example OSPFv2 RFC 2328 Appendix D) are typically reserved through an IANA registry, so documents referencing this document or subsequent work will make IANA requests as a product of recommendations made in this document. 1.j No formal language schema is in use in this document. 1.k Document Announcement Write-up Summary: The routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and MD5 (Message Digest 5) [RFC1321] 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 [RFC4822], IS-IS [RFC5310] and OSPF [RFC5709]. 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. Working Group Summary: The document was accepted as a workring group item on the mailing list on 1/24/2010.Working Group last call was performed for two weeks, ending on 5/29/2010. With no objections. Document Quality: The document covers the use of cryptographic protections in five igp protocols while it's is likely that the utility of recommendations made in this document will age or be rendered obsolete at different rates. Recommendations conveyed by the document are both informational in nature and temporally limited. From rodunn@cisco.com Tue Jul 6 04:54:35 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3713A67A1 for ; Tue, 6 Jul 2010 04:54:35 -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 ZaoS-KEyczH6 for ; Tue, 6 Jul 2010 04:54:34 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 8F4C53A6940 for ; Tue, 6 Jul 2010 04:54:34 -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 o66BsaNv028606 for ; Tue, 6 Jul 2010 07:54:36 -0400 (EDT) Received: from rtp-rodunn-8711.cisco.com (rtp-rodunn-8711.cisco.com [10.116.190.130]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o66BsZFA010599 for ; Tue, 6 Jul 2010 07:54:36 -0400 (EDT) Message-ID: <4C33197B.8040004@cisco.com> Date: Tue, 06 Jul 2010 07:54:35 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: multipart/mixed; boundary="------------060504050002000101080703" Subject: [OPSEC] Fwd: I-D Action:draft-ietf-opsec-protect-control-plane-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 11:54:35 -0000 This is a multi-part message in MIME format. --------------060504050002000101080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First, thanks for all those that provided comments so far. We have made changes based on the feedback thus far minus the IPV6 updates. We are working on that next. Rodney -------- Original Message -------- Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt Date: Sat, 3 Jul 2010 22:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: opsec@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Protecting The Router Control Plane Author(s) : D. Dugal, et al. Filename : draft-ietf-opsec-protect-control-plane-00.txt Pages : 17 Date : 2010-06-29 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-00.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. --------------060504050002000101080703 Content-Type: Message/External-body; name="draft-ietf-opsec-protect-control-plane-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-opsec-protect-control-plane-00.txt" Content-Type: text/plain Content-ID: <2010-07-03224017.I-D@ietf.org> --------------060504050002000101080703 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --------------060504050002000101080703-- From rodunn@cisco.com Tue Jul 6 08:50:25 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 91DB83A69A3 for ; Tue, 6 Jul 2010 08:50:25 -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 PMmBQlhDKQ2f for ; Tue, 6 Jul 2010 08:50:24 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 5C1213A69A0 for ; Tue, 6 Jul 2010 08:50:24 -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 o66FoOxx017366; Tue, 6 Jul 2010 11:50:24 -0400 (EDT) Received: from dhcp-64-102-157-1.cisco.com (dhcp-64-102-157-1.cisco.com [64.102.157.1]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o66FoNCQ008590; Tue, 6 Jul 2010 11:50:24 -0400 (EDT) Message-ID: <4C3350F4.1030109@cisco.com> Date: Tue, 06 Jul 2010 11:51:16 -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.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 15:50:25 -0000 Manav, Thanks for the review. Comments inline at rd> On 7/5/10 6:45 AM, Bhatia, Manav (Manav) wrote: > Hi, > > Couple of comments: > > o Just like OSPF, you should probably also add some filters for link level LDP as you don't want LDP to start exchanging MPLS labels with all the peers it receives HELLOs from. > rd> We felt the OSPF example coupled with the Applicability Statement would be enough for the user to understand the concept enough to extend the configuration to cover MPLS. > o Can some filters be added for IS-IS? rd> Those would be captured in the default and "family any" IOS and JUNOS examples. > > o It might also be a good idea to add some text on what some implementations do to protect the control plane without any manual configs. This would for example be, rate limiting all traffic for which ARP is unresolved or rate limiting all traffic for which there is no route in the routing table, etc. > Good idea. There are a lot of one off implementations in this area that are Vendor/platform specific so we should keep it generic. How about in the Introduction we add? "There may be additional implementation specific protections that are on-by-default or always-on that apply to specific traffic punt causes that are outside the scope of this document." > o Related to the above point you should also add some configs about how providers can rate limit all the ICMP host/network unreachables that it sends out, etc. > rd> We made reference to that in the Security Considerations section: "Specifically, the generation of ICMP Unreachable messages by the router control plane needs to be rate-limited, either implicitly within the router's architecture or explicitly through configuration." Rodney > Cheers, Manav > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >> Sent: Sunday, July 04, 2010 11.15 AM >> To: i-d-announce@ietf.org >> Cc: opsec@ietf.org >> Subject: [OPSEC] I-D >> Action:draft-ietf-opsec-protect-control-plane-00.txt >> >> 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-00.txt >> Pages : 17 >> Date : 2010-06-29 >> >> 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-c >> ontrol-plane-00.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. >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From root@core3.amsl.com Fri Jul 9 02:00:02 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 F339C3A6BA2; Fri, 9 Jul 2010 02: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: <20100709090001.F339C3A6BA2@core3.amsl.com> Date: Fri, 9 Jul 2010 02:00:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-01.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, 09 Jul 2010 09:00:02 -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-01.txt Pages : 17 Date : 2010-07-09 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-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09015150.I-D@ietf.org> --NextPart-- From rodunn@cisco.com Fri Jul 9 05:44:32 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 B78FF3A6A3E for ; Fri, 9 Jul 2010 05:44:32 -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 TXqWGCNNV4L0 for ; Fri, 9 Jul 2010 05:44:31 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 87DF93A6A40 for ; Fri, 9 Jul 2010 05:44:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o69CiZXE010165; Fri, 9 Jul 2010 08:44:35 -0400 (EDT) Received: from rtp-rodunn-8711.cisco.com (rtp-rodunn-8711.cisco.com [10.116.190.130]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o69CiWr6005384; Fri, 9 Jul 2010 08:44:32 -0400 (EDT) Message-ID: <4C3719B0.6060804@cisco.com> Date: Fri, 09 Jul 2010 08:44:32 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: rodunn@cisco.com References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> In-Reply-To: <4C3350F4.1030109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 12:44:32 -0000 Manav, We updated the applicability statement per your suggestion: "Additionally, there may be other vendor or implementation specific protection mechanisms that are on-by-default or always-on. Those approaches may apply in conjunction with or in addition to the method described in Section 3 and illustrated in Appendices A and B. Those implementations should be considered as part of an overall traffic management plan but are outside the scope of this document. " Rodney On 7/6/10 11:51 AM, Rodney Dunn wrote: > Manav, > > Thanks for the review. Comments inline at rd> > > > > On 7/5/10 6:45 AM, Bhatia, Manav (Manav) wrote: >> Hi, >> >> Couple of comments: >> >> o Just like OSPF, you should probably also add some filters for link >> level LDP as you don't want LDP to start exchanging MPLS labels with >> all the peers it receives HELLOs from. >> > > rd> We felt the OSPF example coupled with the Applicability Statement > would be enough for the user to understand the concept enough to extend > the configuration to cover MPLS. > > >> o Can some filters be added for IS-IS? > > rd> Those would be captured in the default and "family any" IOS and > JUNOS examples. > >> >> o It might also be a good idea to add some text on what some >> implementations do to protect the control plane without any manual >> configs. This would for example be, rate limiting all traffic for >> which ARP is unresolved or rate limiting all traffic for which there >> is no route in the routing table, etc. >> > > Good idea. There are a lot of one off implementations in this area that > are Vendor/platform specific so we should keep it generic. How about in > the Introduction we add? > > "There may be additional implementation specific protections that are > on-by-default or always-on that apply to specific traffic punt causes > that are outside the scope of this document." > > > > >> o Related to the above point you should also add some configs about >> how providers can rate limit all the ICMP host/network unreachables >> that it sends out, etc. >> > > rd> We made reference to that in the Security Considerations section: > > "Specifically, the generation of ICMP Unreachable messages by the router > control plane needs to be rate-limited, either implicitly within the > router's architecture or explicitly through configuration." > > Rodney > > > > >> Cheers, Manav >> >>> -----Original Message----- >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>> On Behalf Of Internet-Drafts@ietf.org >>> Sent: Sunday, July 04, 2010 11.15 AM >>> To: i-d-announce@ietf.org >>> Cc: opsec@ietf.org >>> Subject: [OPSEC] I-D >>> Action:draft-ietf-opsec-protect-control-plane-00.txt >>> >>> 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-00.txt >>> Pages : 17 >>> Date : 2010-06-29 >>> >>> 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-c >>> ontrol-plane-00.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. >>> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From Donald.Smith@qwest.com Fri Jul 9 09:38:34 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 284453A698E for ; Fri, 9 Jul 2010 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 dcKCZDHt3KVm for ; Fri, 9 Jul 2010 09:38:33 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 043F13A6877 for ; Fri, 9 Jul 2010 09:38:32 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o69GcZUX028658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jul 2010 11:38:35 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id o69GcTIT024168; Fri, 9 Jul 2010 10:38:30 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 9 Jul 2010 10:38:29 -0600 From: "Smith, Donald" To: "'rodunn@cisco.com'" , "'Bhatia, Manav (Manav)'" Date: Fri, 9 Jul 2010 10:38:28 -0600 Thread-Topic: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt Thread-Index: AcsdIxEQUfiCK/pGQnKaTGiN6f1SPQCYHbIA Message-ID: References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> In-Reply-To: <4C3350F4.1030109@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] I-D Action:draft-ietf-opsec-protect-control-plane-00.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, 09 Jul 2010 16:38:34 -0000 (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 Rodney Dunn > Sent: Tuesday, July 06, 2010 9:51 AM > To: Bhatia, Manav (Manav) > Cc: 'opsec@ietf.org' > Subject: Re: [OPSEC] I-D > Action:draft-ietf-opsec-protect-control-plane-00.txt > > Manav, > > Thanks for the review. Comments inline at rd> > > > > On 7/5/10 6:45 AM, Bhatia, Manav (Manav) wrote: > > Hi, > > > > Couple of comments: > > > > o Just like OSPF, you should probably also add some filters > for link level LDP as you don't want LDP to start exchanging > MPLS labels with all the peers it receives HELLOs from. > > > > rd> We felt the OSPF example coupled with the Applicability Statement > would be enough for the user to understand the concept enough > to extend > the configuration to cover MPLS. > > > > o Can some filters be added for IS-IS? > > rd> Those would be captured in the default and "family any" IOS and > JUNOS examples. > > > > > o It might also be a good idea to add some text on what > some implementations do to protect the control plane without > any manual configs. This would for example be, rate limiting > all traffic for which ARP is unresolved or rate limiting all > traffic for which there is no route in the routing table, etc. > > > > Good idea. There are a lot of one off implementations in this > area that > are Vendor/platform specific so we should keep it generic. > How about in > the Introduction we add? > > "There may be additional implementation specific protections that are > on-by-default or always-on that apply to specific traffic punt causes > that are outside the scope of this document." > > > > > > o Related to the above point you should also add some > configs about how providers can rate limit all the ICMP > host/network unreachables that it sends out, etc. > > > > rd> We made reference to that in the Security Considerations section: > > "Specifically, the generation of ICMP Unreachable messages by > the router > control plane needs to be rate-limited, either implicitly within the > router's architecture or explicitly through configuration." Implicity rate-limiting is a pain to troubleshoot unless very well document= ed. Most router heads would rather put in their OWN tested and validated rateli= mits and be able to review them. Also I may have missed it but bps is NOT the right measurement for ratelimi= ting. PPS is much more important. I realize most ratelimiting today is done with bps but it is pps that has t= he real impact on the RE/CPU. > > Rodney > > > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > >> On Behalf Of Internet-Drafts@ietf.org > >> Sent: Sunday, July 04, 2010 11.15 AM > >> To: i-d-announce@ietf.org > >> Cc: opsec@ietf.org > >> Subject: [OPSEC] I-D > >> Action:draft-ietf-opsec-protect-control-plane-00.txt > >> > >> 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-00.txt > >> Pages : 17 > >> Date : 2010-06-29 > >> > >> 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-c > >> ontrol-plane-00.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. > >> > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From glen.kent@gmail.com Fri Jul 9 09:47: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 7AEDF3A6845 for ; Fri, 9 Jul 2010 09:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 D9vzEW9dBxvA for ; Fri, 9 Jul 2010 09:47:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6C04D3A6946 for ; Fri, 9 Jul 2010 09:47:32 -0700 (PDT) Received: by vws14 with SMTP id 14so2849630vws.31 for ; Fri, 09 Jul 2010 09:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Ji1AzymUUepyK8GKkD1mcdSSUWMq7ecb8lz+LpPwaf8=; b=wrHRw8FjZ977jX5oLpvATNzRsKkOfSN44O26OUJCIwe1mmg7Eoq14Ru57yBINEWKKu AJpZy5RZ8wNhrm2ME+4Liat7WKT2nG5d+lm3iePlVokQF5fmN4lWZZ4LOn9E7ZsY44tg hbsQY3aDS/Yyam8hY+h6LXbUfjPtSy7fJ6nXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x3c2XtVgeUawscZpX9Hb9rRO2cHdu0I2pv7TA9x2iaRma77E4KoDgQ3gsPQG16AxLr YGDLiSrJFQJl9eWdPr1xQhkRxn/t0eogBeKMsTSPriKVkfRbEiLy59np1r831FdZhlE0 Zkjh0EKg7u8OMmgjc7UDxTzSyXzPu6N4ikdQg= MIME-Version: 1.0 Received: by 10.220.125.4 with SMTP id w4mr5380328vcr.31.1278694054758; Fri, 09 Jul 2010 09:47:34 -0700 (PDT) Received: by 10.220.194.129 with HTTP; Fri, 9 Jul 2010 09:47:34 -0700 (PDT) In-Reply-To: References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> Date: Fri, 9 Jul 2010 22:17:34 +0530 Message-ID: From: Glen Kent To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.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, 09 Jul 2010 16:47:36 -0000 > > Implicity rate-limiting is a pain to troubleshoot unless very well documented. > Most router heads would rather put in their OWN tested and validated ratelimits and be able to review them. > > Also I may have missed it but bps is NOT the right measurement for ratelimiting. PPS is much more important. > I realize most ratelimiting today is done with bps but it is pps that has the real impact on the RE/CPU. Wouldnt there be a strong correlation between bps and pps? Glen From rodunn@cisco.com Fri Jul 9 10:16:00 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 A1D783A68F1 for ; Fri, 9 Jul 2010 10:16:00 -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 9wHnJHS55e6L for ; Fri, 9 Jul 2010 10:15:59 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 5CF323A67B3 for ; Fri, 9 Jul 2010 10:15:59 -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 o69HFxBa000597; Fri, 9 Jul 2010 13:15:59 -0400 (EDT) Received: from dhcp-64-102-157-1.cisco.com (dhcp-64-102-157-1.cisco.com [64.102.157.1]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o69HFwjg015218; Fri, 9 Jul 2010 13:15:58 -0400 (EDT) Message-ID: <4C375989.7000300@cisco.com> Date: Fri, 09 Jul 2010 13:16:57 -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.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Smith, Donald" References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:16:00 -0000 Thanks Donald... >> >> >>> o Related to the above point you should also add some >> configs about how providers can rate limit all the ICMP >> host/network unreachables that it sends out, etc. >>> >> >> rd> We made reference to that in the Security Considerations section: >> >> "Specifically, the generation of ICMP Unreachable messages by >> the router >> control plane needs to be rate-limited, either implicitly within the >> router's architecture or explicitly through configuration." > > Implicity rate-limiting is a pain to troubleshoot unless very well documented. > Most router heads would rather put in their OWN tested and validated ratelimits and be able to review them. > I agree with that. I added that note "*..*" "Specifically, the generation of ICMP Unreachable messages by the router control plane needs to be rate-limited, either implicitly within the router's architecture or explicitly through configuration. *It is recommended to deploy explicit rate limiters where possible to improve troubleshooting and monitoring capability.*" > Also I may have missed it but bps is NOT the right measurement for ratelimiting. PPS is much more important. > I realize most ratelimiting today is done with bps but it is pps that has the real impact on the RE/CPU. > Yep. In the Filter_Design section I added the *..* text: " In addition to the filters, rate-limiters for certain classes of traffic are also installed in the forwarding plane as defined in . These rate limiters help futher control the traffic that will reach the control plane for each filtered class as well as all traffic not matching an explicit class. The actual rates selected for various classes is network deployment specific and analysis of required rates for stability should be done periodically. *It's important to note that the most significant factor to consider regarding the traffic profile going to the router control plane is the packets per second (pps) rate. Therefore, consideration should be taken when defining the rate limiters for various packet size distributions the potential packet rates that would be allowed.* Those both look ok? > >> >> Rodney >> >> >> >> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>> On Behalf Of Internet-Drafts@ietf.org >>>> Sent: Sunday, July 04, 2010 11.15 AM >>>> To: i-d-announce@ietf.org >>>> Cc: opsec@ietf.org >>>> Subject: [OPSEC] I-D >>>> Action:draft-ietf-opsec-protect-control-plane-00.txt >>>> >>>> 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-00.txt >>>> Pages : 17 >>>> Date : 2010-06-29 >>>> >>>> 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-c >>>> ontrol-plane-00.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. >>>> >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. From rodunn@cisco.com Fri Jul 9 10:24:42 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 720D83A69E3 for ; Fri, 9 Jul 2010 10:24:42 -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 AtU8e-YvEnK3 for ; Fri, 9 Jul 2010 10:24:40 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 45BEC3A67B3 for ; Fri, 9 Jul 2010 10:24:37 -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 o69HOfO0001273; Fri, 9 Jul 2010 13:24:41 -0400 (EDT) Received: from dhcp-64-102-157-1.cisco.com (dhcp-64-102-157-1.cisco.com [64.102.157.1]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o69HOfYo024266; Fri, 9 Jul 2010 13:24:41 -0400 (EDT) Message-ID: <4C375B94.3030100@cisco.com> Date: Fri, 09 Jul 2010 13:25:40 -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.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Glen Kent References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:24:42 -0000 On 7/9/10 12:47 PM, Glen Kent wrote: >> >> Implicity rate-limiting is a pain to troubleshoot unless very well documented. >> Most router heads would rather put in their OWN tested and validated ratelimits and be able to review them. >> >> Also I may have missed it but bps is NOT the right measurement for ratelimiting. PPS is much more important. >> I realize most ratelimiting today is done with bps but it is pps that has the real impact on the RE/CPU. > > Wouldnt there be a strong correlation between bps and pps? Yep. But I do agree that calling it out more clearly would hopefully encourage implementers to think about how they are correlated so I added a bit of text around it. Rodney > > Glen > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From Donald.Smith@qwest.com Fri Jul 9 11:52:45 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 2026E3A68CD for ; Fri, 9 Jul 2010 11:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BOHY-6AiSGe2 for ; Fri, 9 Jul 2010 11:52:44 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 1EBC03A69B9 for ; Fri, 9 Jul 2010 11:52:44 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o69IqmJc018973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jul 2010 13:52:48 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id o69Iqgtp024505; Fri, 9 Jul 2010 12:52:42 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Fri, 9 Jul 2010 12:52:38 -0600 From: "Smith, Donald" To: "'Glen Kent'" Date: Fri, 9 Jul 2010 12:52:36 -0600 Thread-Topic: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt Thread-Index: AcsfhnCKV3pdlsoVTo2546V1P0d37wAER4lw Message-ID: References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.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, 09 Jul 2010 18:52:45 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com] > Sent: Friday, July 09, 2010 10:48 AM > To: Smith, Donald > Cc: opsec@ietf.org > Subject: Re: [OPSEC] I-D > Action:draft-ietf-opsec-protect-control-plane-00.txt > > > > > Implicity rate-limiting is a pain to troubleshoot unless > very well documented. > > Most router heads would rather put in their OWN tested and > validated ratelimits and be able to review them. > > > > Also I may have missed it but bps is NOT the right > measurement for ratelimiting. PPS is much more important. > > I realize most ratelimiting today is done with bps but it > is pps that has the real impact on the RE/CPU. > > Wouldnt there be a strong correlation between bps and pps? There is a correlation but its not as strong as you might think. Most attack traffic tends to be small (40-50 bytes) , voip and other stream= ing protocols tend towards small (60ish bytes), most downloads are large (M= TU). Since we are doing this to protect the control plane I am more concerned ab= out the small fast packets. You could also measure this in "cell length" that would probably be the bes= t measurement but not ever router vendor even talks about the inner cross b= ar switch cell length:) > > Glen > 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 glen.kent@gmail.com Sat Jul 10 17:25:52 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A913A67F0 for ; Sat, 10 Jul 2010 17:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QpZsjb-ry0W0 for ; Sat, 10 Jul 2010 17:25:49 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7E5603A6452 for ; Sat, 10 Jul 2010 17:25:49 -0700 (PDT) Received: by qwe5 with SMTP id 5so1024894qwe.31 for ; Sat, 10 Jul 2010 17:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D32hW+sxVEoANFhKZmfPai2Ce9p3JZzy1zED2BJ55Ss=; b=wjya+3/OiEQh0QIDGrhn/4C5ve0IwqSkcrp/ZG/ktVubGc5JoJ49bO1qhgomhn1p4h xv2mBEm3WWJudVLhR5bbNMxJiXbYBiEbsZc3OISBSLKCUZvfXAq/wHfeBNiBeUW0Lc9R K3nSsviyxvBTj22DzHMqw37PWHTWS/rhw8Ghg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XGE65lQtGCwoRLbzGtlapt6QdzYwQyZyezIP/EXxN5ql/eK3yHsfmIFAT4ETRH5qUp 2Ynd5XEfsQV2nGeJ4pkflGoM2UjCllkXTrqWm4Xa7aZj0pC6DUtlEViUJQf5/Ne1J1GN 1PwpOvRP3zOiYfxBQ+el1JOtUxppl7Dz7ld4w= MIME-Version: 1.0 Received: by 10.229.230.132 with SMTP id jm4mr7304233qcb.29.1278807952912; Sat, 10 Jul 2010 17:25:52 -0700 (PDT) Received: by 10.220.194.129 with HTTP; Sat, 10 Jul 2010 17:25:52 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Jul 2010 05:55:52 +0530 Message-ID: From: Glen Kent To: wei.yinxing@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: opsec wg mailing list Subject: Re: [OPSEC] [karp] please review draft-wei-karp-analysis-rp-sa-00.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, 11 Jul 2010 00:25:52 -0000 2010/7/10 Glen Kent : > Hi Wei, > > I am not sure i understand the objective and the motivation behind > this draft. Would be really helpful if you could elaborate on that. > > Glen > > 2010/7/10 : >> >> Hello, Folks: >> >> A new draft is availiable >> (http://tools.ietf.org/html/draft-wei-karp-analysis-rp-sa-00.txt), the >> abstract is as follows: >> This document analyzes the security associations used by current routing >> protocols, including RIPv2, OSPFv2, ISIS, BFD, and BGP. It also discuss= es >> the possible methods for the diversity issue of routing protocol securit= y >> association (SA). >> >> Please review it and give us some comments. Your comments are highly >> appreciated. >> >> Best Regards=A3=A1 >> Wei >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is= confidential. Recipients named above are obligated to maintain secrecy and= are not permitted to disclose the contents of this communication to others= . >> This email and any files transmitted with it are confidential and intend= ed solely for the use of the individual or entity to whom they are addresse= d. If you have received this email in error please notify the originator of= the message. Any views expressed in this message are those of the individu= al sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam syst= em. >> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> >> > From wei.yinxing@zte.com.cn Sun Jul 11 22:55:43 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 8D23B3A6A6E; Sun, 11 Jul 2010 22:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.26 X-Spam-Level: X-Spam-Status: No, score=-97.26 tagged_above=-999 required=5 tests=[AWL=-2.825, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 qogIG4M2XsJf; Sun, 11 Jul 2010 22:55:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6E68F3A6A3C; Sun, 11 Jul 2010 22:55:36 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 552341792907044; Mon, 12 Jul 2010 13:54:24 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.3625207539; Mon, 12 Jul 2010 13:55:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6C5sTfT065071; Mon, 12 Jul 2010 13:54:36 +0800 (CST) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Glen Kent MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 12 Jul 2010 13:54:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-12 13:54:29, Serialize complete at 2010-07-12 13:54:29 Content-Type: multipart/alternative; boundary="=_alternative 002072024825775E_=" X-MAIL: mse2.zte.com.cn o6C5sTfT065071 X-Mailman-Approved-At: Mon, 12 Jul 2010 03:16:29 -0700 Cc: opsec wg mailing list , karp@ietf.org Subject: Re: [OPSEC] [karp] please review draft-wei-karp-analysis-rp-sa-00.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, 12 Jul 2010 05:55:44 -0000 This is a multipart message in MIME format. --=_alternative 002072024825775E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR2xlbiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KVGhlIGRhcmYgd2Ugc3VibWl0 dGVkIGlzIGludGVuZGVkIHRvIG1ha2UgY29udHJpYnV0aW9uIHRvIEtBUlAgV0cuIEtBUlAgaXMg DQpkZWRpY2F0ZWQgdG8gc2VjdXJlIHRoZSByb3V0aW5nIHByb3RvY29scycgcGFja2V0cyBvbiB0 aGUgd2lyZSwgYW5kIA0KZGVmaW5lcyB0d28gbWFpbiB3b3JrIHBoYXNlcyBmb3IgZWFjaCByb3V0 aW5nIHByb3RvY29sIGluIGl0cyByb2FkbWFwIA0KKHBsZWFzZSByZWZlciB0byANCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1rYXJwLWRlc2lnbi1ndWlkZS8pLiBJ biBwaGFzZSANCkksIHRoZSB3b3JrIGlzIHRvIGVuaGFuY2UgdGhlIHJvdXRpbmcgcHJvdG9jb2wn cyBjdXJyZW50IGF1dGhlbnRpY2F0aW9uIA0KbWVjaGFuaXNtIHdpdGhvdXQgS01QIChLZXkgTWFu YWdlbWVudCBQcm90b2NvbCksIGFuZCBpbmNsdWRlcyANCmNoYXJhY3Rlcml6aW5nIFJQIChSb3V0 aW5nIFByb3RvY29sKSBhbmQgZ2FwIGFuYWx5c2lzIGJldHdlZW4gY3VycmVudCANCnNlY3VyaXR5 IHN0YXRlIGFuZCB0aGUgb3B0aW1hbCBzdGF0ZSBvZiBSUC4gQW5kIGluIHBoYXNlIElJLCB0aGUg d29yayBpcyANCnRvIGRldmVsb3AgYW4gYXV0b21hdGVkIGtleWluZyBmcmFtZXdvcmssIGFuZCBp bmNsdWRlcyBLTVAgYW5hbHlzaXMgYW5kIA0KZ2FwIGFuYWx5c2lzIGJldHdlZW4gY3VycmVudCBz ZWN1cml0eSBzdGF0ZSBhbmQgdGhlIG9wdGltYWwgc3RhdGUuIA0KDQpUaGUgd29yayB3ZSBkb25l IGluIG91ciBkcmFmdCBpcyB0byBhbmFseXplIHRoZSBjdXJyZW50IHNlY3VyaXR5IHN0YXRlIG9m IA0KUlAoUm91dGluZyBQcm90b2NvbCksIGFuZCBzcGVjaWZpY2FsbHksIHdlIGFuYWx5c2lzIHRo ZSBTQSAoU2VjdXJpdHkgDQpBc3NvY2lhdGlvbikgb2Ygc2V2ZXJhbCBSUHMsIGkuZS4sIFJJUHYy LCBPU1BGdjIsIElTSVMsIEJGRCwgYW5kIEJHUCwgDQplc3BlY2lhbGx5IHNvbWUgZmllbGRzIGlu Y2x1ZGluZyBrZXkgaWRlbnRpZmllciwgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gDQphbmQga2V5 LCBsaWZldGltZSwgYW5kIHNlcXVlbmNlIG51bWJlci4gSGVyZSB3ZSBjYWxsIGZvciBhdHRlbnRp b24gdG8gdGhlIA0KZGl2ZXJzaXR5IG9mIFNBcy4gVGhpcyBpc3N1ZSBtYXkgcGxheSBzb21lIGlt cGFjdHMgb24gdGhlIGRlc2lnbiBvZiBrYXJwIA0KZnJhbWV3b3JrIG9yIEtNUCBwcm90b2NvbC4g VGhpcyBkcmFmdCBtYXkgYmUgYWxzbyBoZWxwZnVsIGZvciBldmFsdWF0aW5nIA0KdGhlIHZ1bG5l cmFiaWxpdGllcyBvZiBjdXJyZW50IFJQJ3Mgc2VjdXJpdHkgbWVjaGFuaXNtcy4gDQoNClRoaXMg d29yayBjYW4gYmUgcmVnYXJkZWQgYXMgYSBnYXAgYW5hbHlzaXMgaW4gcGhhc2UgSS4gV2UgdGhp bmsgdGhpcyBpcyANCnRoZSBmaXJzdCBzdGVwIGJlZm9yZSB3ZSBkbyB0aGUgcGhhc2UgSSBhbmQg cGhhc2UgSUkgd29yay4gV2UgaG9wZSB0aGlzIA0KZHJhZnQgd2lsbCBiZSBoZWxwZnVsIHRvIGZ1 dHVyZSB3b3JrIGluIHRoZSBLQVJQIFdHLCBhbmQgd291bGQgbGlrZSB0byANCmhlYXIgY29tbWVu dHMgZnJvbSB5b3UgYWxsLg0KDQpCZXN0IFJlZ2FyZHMhDQpXZWkNCg0KDQoNCg0KR2xlbiBLZW50 IDxnbGVuLmtlbnRAZ21haWwuY29tPiANCjIwMTAtMDctMTEgMDg6MjUNCg0KytW8/sjLDQp3ZWku eWlueGluZ0B6dGUuY29tLmNuDQqzrcvNDQpvcHNlYyB3ZyBtYWlsaW5nIGxpc3QgPG9wc2VjQGll dGYub3JnPg0K1vfM4g0KUmU6IFtrYXJwXSBwbGVhc2UgcmV2aWV3IGRyYWZ0LXdlaS1rYXJwLWFu YWx5c2lzLXJwLXNhLTAwLnR4dA0KDQoNCg0KDQoNCg0KMjAxMC83LzEwIEdsZW4gS2VudCA8Z2xl bi5rZW50QGdtYWlsLmNvbT46DQo+IEhpIFdlaSwNCj4NCj4gSSBhbSBub3Qgc3VyZSBpIHVuZGVy c3RhbmQgdGhlIG9iamVjdGl2ZSBhbmQgdGhlIG1vdGl2YXRpb24gYmVoaW5kDQo+IHRoaXMgZHJh ZnQuIFdvdWxkIGJlIHJlYWxseSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBlbGFib3JhdGUgb24gdGhh dC4NCj4NCj4gR2xlbg0KPg0KPiAyMDEwLzcvMTAgIDx3ZWkueWlueGluZ0B6dGUuY29tLmNuPjoN Cj4+DQo+PiBIZWxsbywgRm9sa3M6DQo+Pg0KPj4gQSBuZXcgZHJhZnQgaXMgYXZhaWxpYWJsZQ0K Pj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaS1rYXJwLWFuYWx5c2lzLXJw LXNhLTAwLnR4dCksIHRoZQ0KPj4gYWJzdHJhY3QgaXMgYXMgZm9sbG93czoNCj4+IFRoaXMgZG9j dW1lbnQgYW5hbHl6ZXMgdGhlIHNlY3VyaXR5IGFzc29jaWF0aW9ucyB1c2VkIGJ5IGN1cnJlbnQg DQpyb3V0aW5nDQo+PiBwcm90b2NvbHMsIGluY2x1ZGluZyBSSVB2MiwgT1NQRnYyLCBJU0lTLCBC RkQsIGFuZCBCR1AuICBJdCBhbHNvIA0KZGlzY3Vzc2VzDQo+PiB0aGUgcG9zc2libGUgbWV0aG9k cyBmb3IgdGhlIGRpdmVyc2l0eSBpc3N1ZSBvZiByb3V0aW5nIHByb3RvY29sIA0Kc2VjdXJpdHkN Cj4+IGFzc29jaWF0aW9uIChTQSkuDQo+Pg0KPj4gUGxlYXNlIHJldmlldyBpdCBhbmQgZ2l2ZSB1 cyBzb21lIGNvbW1lbnRzLiBZb3VyIGNvbW1lbnRzIGFyZSBoaWdobHkNCj4+IGFwcHJlY2lhdGVk Lg0KPj4NCj4+IEJlc3QgUmVnYXJkc6OhDQo+PiBXZWkNCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g DQpvdGhlcnMuDQo+PiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSAN Cm9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSANCm9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4+IFRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gDQpzeXN0ZW0uDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IGthcnAgbWFpbGluZyBsaXN0DQo+PiBrYXJwQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2thcnANCj4+DQo+Pg0KPg0KDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 002072024825775E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdsZW4sPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGFua3MgZm9yIHlvdXIgY29t bWVudHMhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgZGFy ZiB3ZSBzdWJtaXR0ZWQgaXMgaW50ZW5kZWQgdG8NCm1ha2UgY29udHJpYnV0aW9uIHRvIEtBUlAg V0cuIEtBUlAgaXMgZGVkaWNhdGVkIHRvIHNlY3VyZSB0aGUgcm91dGluZyBwcm90b2NvbHMnDQpw YWNrZXRzIG9uIHRoZSB3aXJlLCBhbmQgZGVmaW5lcyB0d28gbWFpbiB3b3JrIHBoYXNlcyBmb3Ig ZWFjaCByb3V0aW5nDQpwcm90b2NvbCBpbiBpdHMgcm9hZG1hcCAocGxlYXNlIHJlZmVyIHRvIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1rYXJwLWRlc2lnbi1ndWlk ZS8pLg0KSW4gcGhhc2UgSSwgdGhlIHdvcmsgaXMgdG8gZW5oYW5jZSB0aGUgcm91dGluZyBwcm90 b2NvbCdzIGN1cnJlbnQgYXV0aGVudGljYXRpb24NCm1lY2hhbmlzbSB3aXRob3V0IEtNUCAoS2V5 IE1hbmFnZW1lbnQgUHJvdG9jb2wpLCBhbmQgaW5jbHVkZXMgY2hhcmFjdGVyaXppbmcNClJQIChS b3V0aW5nIFByb3RvY29sKSBhbmQgZ2FwIGFuYWx5c2lzIGJldHdlZW4gY3VycmVudCBzZWN1cml0 eSBzdGF0ZSBhbmQNCnRoZSBvcHRpbWFsIHN0YXRlIG9mIFJQLiBBbmQgaW4gcGhhc2UgSUksIHRo ZSB3b3JrIGlzIHRvIGRldmVsb3AgYW4gYXV0b21hdGVkDQprZXlpbmcgZnJhbWV3b3JrLCBhbmQg aW5jbHVkZXMgS01QIGFuYWx5c2lzIGFuZCBnYXAgYW5hbHlzaXMgYmV0d2VlbiBjdXJyZW50DQpz ZWN1cml0eSBzdGF0ZSBhbmQgdGhlIG9wdGltYWwgc3RhdGUuPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSB3b3JrIHdlIGRvbmUgaW4gb3VyIGRyYWZ0IGlz IHRvDQphbmFseXplIHRoZSBjdXJyZW50IHNlY3VyaXR5IHN0YXRlIG9mIFJQKFJvdXRpbmcgUHJv dG9jb2wpLCBhbmQgc3BlY2lmaWNhbGx5LA0Kd2UgYW5hbHlzaXMgdGhlIFNBIChTZWN1cml0eSBB c3NvY2lhdGlvbikgb2Ygc2V2ZXJhbCBSUHMsIGkuZS4sPC9mb250Pjx0dD48Zm9udCBzaXplPTI+ DQpSSVB2MiwgT1NQRnYyLCBJU0lTLCBCRkQsIGFuZCBCR1A8L2ZvbnQ+PC90dD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+LA0KZXNwZWNpYWxseSBzb21lIGZpZWxkcyBpbmNsdWRpbmcg a2V5IGlkZW50aWZpZXIsIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtDQphbmQga2V5LCBsaWZldGlt ZSwgYW5kIHNlcXVlbmNlIG51bWJlci4gSGVyZSB3ZSBjYWxsIGZvciBhdHRlbnRpb24gdG8gdGhl DQpkaXZlcnNpdHkgb2YgU0FzLiBUaGlzIGlzc3VlIG1heSBwbGF5IHNvbWUgaW1wYWN0cyBvbiB0 aGUgZGVzaWduIG9mIGthcnANCmZyYW1ld29yayBvciBLTVAgcHJvdG9jb2wuIFRoaXMgZHJhZnQg bWF5IGJlIGFsc28gaGVscGZ1bCBmb3IgZXZhbHVhdGluZw0KdGhlIHZ1bG5lcmFiaWxpdGllcyBv ZiBjdXJyZW50IFJQJ3Mgc2VjdXJpdHkgbWVjaGFuaXNtcy4gPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIHdvcmsgY2FuIGJlIHJlZ2FyZGVkIGFz IGEgZ2FwIGFuYWx5c2lzDQppbiBwaGFzZSBJLiBXZSB0aGluayB0aGlzIGlzIHRoZSBmaXJzdCBz dGVwIGJlZm9yZSB3ZSBkbyB0aGUgcGhhc2UgSSBhbmQNCnBoYXNlIElJIHdvcms8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPg0KV2UgaG9wZSB0aGlzIGRyYWZ0IHdpbGwgYmUgaGVscGZ1bCB0byBmdXR1cmUg d29yayBpbiB0aGUgS0FSUCBXRywgYW5kIHdvdWxkDQpsaWtlIHRvIGhlYXIgY29tbWVudHMgZnJv bSB5b3UgYWxsLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KQmVzdCBSZWdhcmRzITxicj4NCldlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HbGVuIEtlbnQgJmx0O2dsZW4ua2VudEBnbWFp bC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMTAtMDctMTEgMDg6MjU8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+d2VpLnlpbnhpbmdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+b3BzZWMgd2cgbWFpbGluZyBsaXN0ICZsdDtvcHNlY0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBba2FycF0gcGxlYXNlIHJldmlldyBkcmFmdC13ZWkta2FycC1hbmFseXNp cy1ycC1zYS0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPjIwMTAvNy8xMCBHbGVuIEtlbnQgJmx0O2dsZW4ua2VudEBnbWFpbC5j b20mZ3Q7Ojxicj4NCiZndDsgSGkgV2VpLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYW0gbm90IHN1 cmUgaSB1bmRlcnN0YW5kIHRoZSBvYmplY3RpdmUgYW5kIHRoZSBtb3RpdmF0aW9uIGJlaGluZDxi cj4NCiZndDsgdGhpcyBkcmFmdC4gV291bGQgYmUgcmVhbGx5IGhlbHBmdWwgaWYgeW91IGNvdWxk IGVsYWJvcmF0ZSBvbiB0aGF0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEdsZW48YnI+DQomZ3Q7PGJy Pg0KJmd0OyAyMDEwLzcvMTAgJm5ic3A7Jmx0O3dlaS55aW54aW5nQHp0ZS5jb20uY24mZ3Q7Ojxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSGVsbG8sIEZvbGtzOjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgQSBuZXcgZHJhZnQgaXMgYXZhaWxpYWJsZTxicj4NCiZndDsmZ3Q7IChodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWkta2FycC1hbmFseXNpcy1ycC1zYS0wMC50 eHQpLA0KdGhlPGJyPg0KJmd0OyZndDsgYWJzdHJhY3QgaXMgYXMgZm9sbG93czo8YnI+DQomZ3Q7 Jmd0OyBUaGlzIGRvY3VtZW50IGFuYWx5emVzIHRoZSBzZWN1cml0eSBhc3NvY2lhdGlvbnMgdXNl ZCBieSBjdXJyZW50DQpyb3V0aW5nPGJyPg0KJmd0OyZndDsgcHJvdG9jb2xzLCBpbmNsdWRpbmcg UklQdjIsIE9TUEZ2MiwgSVNJUywgQkZELCBhbmQgQkdQLiAmbmJzcDtJdA0KYWxzbyBkaXNjdXNz ZXM8YnI+DQomZ3Q7Jmd0OyB0aGUgcG9zc2libGUgbWV0aG9kcyBmb3IgdGhlIGRpdmVyc2l0eSBp c3N1ZSBvZiByb3V0aW5nIHByb3RvY29sDQpzZWN1cml0eTxicj4NCiZndDsmZ3Q7IGFzc29jaWF0 aW9uIChTQSkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBQbGVhc2UgcmV2aWV3IGl0IGFu ZCBnaXZlIHVzIHNvbWUgY29tbWVudHMuIFlvdXIgY29tbWVudHMgYXJlDQpoaWdobHk8YnI+DQom Z3Q7Jmd0OyBhcHByZWNpYXRlZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlc3QgUmVn YXJkc6OhPGJyPg0KJmd0OyZndDsgV2VpPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4NCnRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KJmd0OyZndDsgVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbA0KYW5kIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hv bSB0aGV5DQphcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlDQpvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkg dmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UNCm9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci48YnI+DQomZ3Q7Jmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQpzeXN0ZW0uPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsmZ3Q7IGthcnAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsga2Fy cEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8va2FycDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KPGJy Pg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZu YnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5 Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5p emF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5i c3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3km bmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rp c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQm bmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5i c3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xl bHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJz cDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVj ZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNl Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5i c3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFz Jm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5i c3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9w cmU+ --=_alternative 002072024825775E_=-- From joelja@bogus.com Mon Jul 12 07:32:55 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E28D3A6892 for ; Mon, 12 Jul 2010 07:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 DWyT8pr-Oy6f for ; Mon, 12 Jul 2010 07:32:53 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 302463A681E for ; Mon, 12 Jul 2010 07:32:52 -0700 (PDT) Received: from joelja-mac.local (adsl-76-203-75-202.dsl.pltn13.sbcglobal.net [76.203.75.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o6CEWsJX024430 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 12 Jul 2010 14:32:55 GMT (envelope-from joelja@bogus.com) Message-ID: <4C3B2795.6060203@bogus.com> Date: Mon, 12 Jul 2010 07:32:53 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: opsec@ietf.org, jabley@hopcount.ca Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 12 Jul 2010 14:32:55 +0000 (UTC) Subject: [OPSEC] agenda ietms for ietf78 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, 12 Jul 2010 14:32:55 -0000 Currently the agenda is look sort of thin, I will post a strawman shortly however if you have topic that should be aired as part of the ietf78 opsec wg meeting I'd would greatly appreciate a note to that effect. If you will not be attending and have an item which should be brought to the attention of the wg, please coordinate with the working group chairs, Joe and myself to make sure that it get's on the agenda. thanks joel From joelja@bogus.com Thu Jul 15 21:04:11 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990ED3A677C for ; Thu, 15 Jul 2010 21:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 pLqXZ7hCYLuM for ; Thu, 15 Jul 2010 21:04:10 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 515D73A6405 for ; Thu, 15 Jul 2010 21:04:10 -0700 (PDT) Received: from joelja-mac.local (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o6G44HlD014147 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 16 Jul 2010 04:04:17 GMT (envelope-from joelja@bogus.com) Message-ID: <4C3FDA40.5080706@bogus.com> Date: Thu, 15 Jul 2010 21:04:16 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: opsec@ietf.org, Joe Abley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 16 Jul 2010 04:04:18 +0000 (UTC) Subject: [OPSEC] Preliminary Agenda for IETF78 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, 16 Jul 2010 04:04:11 -0000 - Agenda Bashing - 1m - Document Status - 5m - specific documents - draft-ietf-opsec-protect-control-plane - 15m - draft-ietf-opsec-ip-security-03 - 10m - post wg-last call - opsec outreach / liason activities - 10m - tentative - draft-ietf-opsec-igp-crypto-requirements (if there's anything to discuss beyond status) - karp activities From jtk@cymru.com Tue Jul 20 10:16:18 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 495E43A68EA for ; Tue, 20 Jul 2010 10:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zqmMHWUUELLl for ; Tue, 20 Jul 2010 10:16:17 -0700 (PDT) Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id 8817D3A687E for ; Tue, 20 Jul 2010 10:16:17 -0700 (PDT) Received: from t61p (vpn-21-36.svcs.iad01.cymru.com [192.168.21.36]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id C1147B016C; Tue, 20 Jul 2010 17:16:32 +0000 (GMT) Date: Tue, 20 Jul 2010 12:16:32 -0500 From: John Kristoff To: rodunn@cisco.com Message-ID: <20100720121632.3ad28a0f@t61p> In-Reply-To: <4C375989.7000300@cisco.com> References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> <4C375989.7000300@cisco.com> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.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, 20 Jul 2010 17:16:18 -0000 On Fri, 09 Jul 2010 13:16:57 -0400 Rodney Dunn wrote: > "Specifically, the generation of ICMP Unreachable messages by the > router control plane needs to be rate-limited, either implicitly RFC 1812 has this: 4.3.2.8 Rate Limiting A router which sends ICMP Source Quench messages MUST be able to limit the rate at which the messages can be generated. A router SHOULD also be able to limit the rate at which it sends other sorts of ICMP error messages (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem). The rate limit parameters SHOULD be settable as part of the configuration of the router. How the limits are applied (e.g., per router or per interface) is left to the implementor's discretion. I believe most routers rate limit ICMP messages already. John From danny@tcb.net Thu Jul 22 08:07:46 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 C09063A6BA2 for ; Thu, 22 Jul 2010 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.284 X-Spam-Level: X-Spam-Status: No, score=-101.284 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_20=-0.74, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GFwGIbkZQpy for ; Thu, 22 Jul 2010 08:07:45 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id F00D03A6A66 for ; Thu, 22 Jul 2010 08:07:42 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 3FAC12684EC; Thu, 22 Jul 2010 09:08:00 -0600 (MDT) Received: from [192.168.1.81] (97-118-245-110.hlrn.qwest.net [97.118.245.110]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for opsec@ietf.org; Thu, 22 Jul 2010 09:07:59 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.245.110; client-port=65380; syn-fingerprint=65535:56:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Danny McPherson In-Reply-To: Date: Thu, 22 Jul 2010 09:07:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <68D42BD2-008C-413C-9F7F-95675D4B1347@tcb.net> References: <4C2040EB.2040202@bogus.com> To: opsec@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [OPSEC] widely adopted communities presentation at nanog 49 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, 22 Jul 2010 15:07:46 -0000 On Jun 21, 2010, at 11:33 PM, Christopher Morrow wrote: > On Tue, Jun 22, 2010 at 12:49 AM, Joel Jaeggli = wrote: >> While I have some personal ambivialence to the idea of specifiying >> well-known communities, I noted this presentation with some interest = at >> nanog and since the subject has been discussed here before I would = drop >> a pointer to the presentation. >>=20 >> = http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BG= P_Communities_00_2.pdf >=20 > i vote, again, no 'well known communities' ... the guarantee that they > exist and will be used as intended isn't currently working with > no-export (as you stated at the mic I think). Having a contractually > obligated set of communities (even if it's different per provider) > with proscribed behaviours should be the target (which each customer > should pursue). My thoughts were mostly aligned with this. Here's a response I sent to=20= a related discussion on NANOG.. FWIW, from a codifying position I definitely get what Robert is trying = to do, I just share the concerns that Chris pointed out, coupled with the ones = below. -danny Begin forwarded message: > From: Danny McPherson > Date: July 20, 2010 9:34:40 AM MDT > To: "nanog@nanog.org >> nanog list" > Subject: Re: Standard for BGP community lists >=20 >=20 > On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote: >=20 >> On (2010-07-19 23:45 -0500), Brad Fleming wrote: >>=20 >> Hey, >>=20 >>> 9999:9999 for local rtbh >>> 9999:8888 for local + remote rtbh >>>=20 >>> I didn't have much reason for selecting 9999 other than it was easy >>> to identify visually. And obviously, I have safe-guards to not leak >>> those communities into other networks. >>=20 >> I would recommend against using other public ASNs for internal = signalling, >> ASN part should be considered property of given ASN. AS9999 might = want to >> use 9999 to signal particular source where route was learned and your >> customer might want to do TE with it. Now you must delete them on = ingress >> and rob your customers of this possibility. >=20 > IMO, any reasonable routing policy would reset all BGP communities on=20= > ingress (and MEDs for that matter), whether from a customer or peer,=20= > as transiting stuff that has varying semantic interpretations, unknown=20= > propagation scope, or relying on others to act on non-mandatory=20 > not-well-known communities that may not even be propagated in some=20 > BGP configurations as a matter of default behavior, is a simple recipe=20= > for nondeterministic behavior, more senseless path attribute tuples in=20= > the global routing system, resulting in less efficient BGP update = packing,=20 > and may even result in security issues.=20 >=20 > And customer ingress policy can always be crafted to accommodate the > upstream special handling policies for RFC1998+ functions, as well as > source and destination-based RTBH and other capabilities, across one > or more ISPs, even if they vary. =20 >=20 > There have been some spirited discussions on the specification of=20 > more well-known communities for functions related to this and other=20 > applications in various IETF working groups, from IDR and GROW to=20 > OPSEC and L3VPN, for those interested in having a gander... >=20 > -danny >=20 From rodunn@cisco.com Thu Jul 22 19:07:35 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617F63A68DF for ; Thu, 22 Jul 2010 19:07:35 -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 Ayv5xJ3KTeBN for ; Thu, 22 Jul 2010 19:07:34 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 429EB3A68B9 for ; Thu, 22 Jul 2010 19:07:34 -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 o6N27oJb020788; Thu, 22 Jul 2010 22:07:50 -0400 (EDT) Received: from rtp-rodunn-8711.cisco.com (rtp-rodunn-8711.cisco.com [10.116.190.130]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6N27lL3019761; Thu, 22 Jul 2010 22:07:47 -0400 (EDT) Message-ID: <4C48F972.9050203@cisco.com> Date: Thu, 22 Jul 2010 22:07:46 -0400 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: John Kristoff References: <20100704054506.8061E3A692C@core3.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CCFF10B77@INBANSXCHMBSA1.in.alcatel-lucent.com> <4C3350F4.1030109@cisco.com> <4C375989.7000300@cisco.com> <20100720121632.3ad28a0f@t61p> In-Reply-To: <20100720121632.3ad28a0f@t61p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 02:07:35 -0000 Thanks John. We listed that as a reference: The treatment of exception traffic in the forwarding plane, and the generation of specific messages by the router control plane also requires protection from a DoS attack. Specifically, the generation of ICMP Unreachable messages by the router control plane needs to be rate-limited, either implicitly within the router's architecture or explicitly through configuration. It's recommended to deploy explicit rate limiters where possible to improve troubleshooting and monitoring capability. For additional information of ICMP rate limiting see Section 4.3.2.8 of [RFC1812]. Rodney On 7/20/10 1:16 PM, John Kristoff wrote: > On Fri, 09 Jul 2010 13:16:57 -0400 > Rodney Dunn wrote: > >> "Specifically, the generation of ICMP Unreachable messages by the >> router control plane needs to be rate-limited, either implicitly > > RFC 1812 has this: > > 4.3.2.8 Rate Limiting > > A router which sends ICMP Source Quench messages MUST be able to > limit the rate at which the messages can be generated. A router > SHOULD also be able to limit the rate at which it sends other sorts > of ICMP error messages (Destination Unreachable, Redirect, Time > Exceeded, Parameter Problem). The rate limit parameters SHOULD be > settable as part of the configuration of the router. How the limits > are applied (e.g., per router or per interface) is left to the > implementor's discretion. > > I believe most routers rate limit ICMP messages already. > > John From joelja@bogus.com Sun Jul 25 21:55:32 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 E59413A6899 for ; Sun, 25 Jul 2010 21:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 Jh5qqlZX8p1g for ; Sun, 25 Jul 2010 21:55:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id DC3793A67A2 for ; Sun, 25 Jul 2010 21:55:31 -0700 (PDT) Received: from dhcp-76fa.meeting.ietf.org (dhcp-76fa.meeting.ietf.org [130.129.118.250]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o6Q4tloI009883 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 26 Jul 2010 04:55:49 GMT (envelope-from joelja@bogus.com) Message-ID: <4C4CA0FC.8020405@bogus.com> Date: Sun, 25 Jul 2010 22:39:24 +0200 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: opsec@ietf.org, Joe Abley References: <4C3FDA40.5080706@bogus.com> In-Reply-To: <4C3FDA40.5080706@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 Jul 2010 04:55:49 +0000 (UTC) Subject: Re: [OPSEC] Preliminary Agenda for IETF78 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, 26 Jul 2010 04:55:33 -0000 Agenda has been updated to include: draft-wei-karp-analysis-rp-sa-00.txt On 7/16/10 6:04 AM, Joel Jaeggli wrote: > > - Agenda Bashing - 1m > - Document Status - 5m > > - specific documents > > - draft-ietf-opsec-protect-control-plane - 15m > > - draft-ietf-opsec-ip-security-03 - 10m > - post wg-last call > > - opsec outreach / liason activities - 10m > > - tentative > > - draft-ietf-opsec-igp-crypto-requirements (if there's anything > to discuss beyond status) > > - karp activities > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From joelja@bogus.com Mon Jul 26 07:57:01 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 172A73A68AB for ; Mon, 26 Jul 2010 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 xKMD-W8RExfu for ; Mon, 26 Jul 2010 07:57:00 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 09F343A6922 for ; Mon, 26 Jul 2010 07:56:59 -0700 (PDT) Received: from dhcp-64fc.meeting.ietf.org (dhcp-64fc.meeting.ietf.org [130.129.100.252]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o6QEvIMd043989 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 26 Jul 2010 14:57:20 GMT (envelope-from joelja@bogus.com) Message-ID: <4C4DA24D.80707@bogus.com> Date: Mon, 26 Jul 2010 16:57:17 +0200 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 Jul 2010 14:57:20 +0000 (UTC) Subject: [OPSEC] FYI all three slides decks are up for the agenda. 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, 26 Jul 2010 14:57:01 -0000 the submitted decks have all been uploaded as of this morning but the agenda slide is now present as well. thanks joel From jabley@hopcount.ca Mon Jul 26 09:29: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 0E9CA3A6BE5 for ; Mon, 26 Jul 2010 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 sS3GgPU4+ikw for ; Mon, 26 Jul 2010 09:29:01 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id D1F773A694D for ; Mon, 26 Jul 2010 09:29:00 -0700 (PDT) Received: from [130.129.135.240] (helo=dhcp-87f0.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdQYK-000GIW-3d for opsec@ietf.org; Mon, 26 Jul 2010 16:29:21 +0000 From: Joe Abley Content-Type: multipart/mixed; boundary=Apple-Mail-9--940635301 Date: Mon, 26 Jul 2010 18:29:18 +0200 Message-Id: <324836B5-D277-4CC8-B138-AA1C225D2595@hopcount.ca> To: "opsec@ietf.org mailing list" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 130.129.135.240 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Subject: [OPSEC] draft minutes for opsec at IETF 78 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, 26 Jul 2010 16:29:02 -0000 --Apple-Mail-9--940635301 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi all, Per subject, please see attached. Joe --Apple-Mail-9--940635301 Content-Disposition: attachment; filename=minutes-opsec-ietf78.txt Content-Type: text/plain; name="minutes-opsec-ietf78.txt" Content-Transfer-Encoding: 7bit note-taker: Joe Abley jabber-monitor: Joe Abley meeting starts at Mon 26 Jul 2010 17:41:35 CEST Joel recounts note well. Joel presents Agenda. No changes were requested. Joel presents document status. Andrew Yourtchenko presents on draft-ietf-opsec-protect-control-plane. This is the second time this document has been presented. An overview of the motivations and document approach was provided. The status of the document is that -02 is expected to be published in mid-August, and that the authors anticipate being ready for last call at that time. Joel notes that document is progressing well, August wglc does not seem unreasonable. Notes that other vendor-specific examples would be welcome in addition to the current two. General problem space is not limited to routers, but is also applicable to other converged devices. No additional comments from the room. Yinxing Wei presents Analysis of Security Association For Current Routing Protocol. Chris Morrow wonders why there is a need for more key management protocols. Chris thinks that manual configuration is fine; he just wants a reliable way of updating a key smoothly, and of changing many keys because of a single event (e.g. employee leaves the company). The KMF approach seems overly complicated. Joel notes desire not to boil the ocean. Chris agrees that's a more succinct way of making his point. Joel suggests that in the ops area we are unconvinced that rolling out a key management protocol would solve a useful problem. Chris did like the survey of what different routing protocols provide. He is just decidedly unsure about the usefulness of a key management protocol. Joel presents Outreach Activities. On NANOG there has been discussion of a set of well-known BGP community string attributes. Consensus on the NANOG list seems to be that any document which aims to document lists of standard values is unlikely to gain relevance. However, it seems like there is some value in cataloguing the kinds of controls people provide using community string attributes. Fred Baker is interested in how we might set up an IANA registry. Joe described briefly the possible approaches, but noted that a registry would be more useful for a list of prescribed of attribute values, not for a catalogue of capabilities. Warran Kumari wonders whether this is a job for an IETF document, or whether something more ephemeral like a wiki might not be better. Joel wonders whether a common vocabulary might be really what we want, not something specifically tied to particular values. No obvious volunteers were evident in re-steering the existing document, but there is interest and Joel knows people outside this meeting who are interested in working on documents in this general area. Joel passed on a suggestion from Bob Natale that opsec might have an interest in sharing information with the TM Forum (formerly the OSI Network Management Forum). Joel noted that almost all of our documents are on track for last call before the next meeting, and hence a re-charter will be discussed on the mailing list between then. Also noted that scheduling meetings is difficult and that we should not meet arbitrarily. Opsawg chairs have expressed the opinion that the work in opsec finds a better home in opsec than it would in opsawg, and so there is enthusiasm there for this working group to remain alive. Sean mentioned that Tim has reviewed the revisions to -crypto-issues following his earlier DISCUSS, and he has some new comments that he will pass on. Meeting closed at Mon 26 Jul 2010 18:23:08 CEST. --Apple-Mail-9--940635301--