From opsec-bounces@ietf.org Tue Dec 18 23:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4qkc-0001kP-LX; Tue, 18 Dec 2007 23:41:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4n1q-0005FP-4Z for opsec@ietf.org; Tue, 18 Dec 2007 19:43:18 -0500 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4n1n-0003yp-GJ for opsec@ietf.org; Tue, 18 Dec 2007 19:43:18 -0500 Received: from [192.103.16.81] ([192.103.16.81]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id lBJ0hEtP044208 for ; Wed, 19 Dec 2007 00:43:14 GMT (envelope-from joelja@bogus.com) Message-ID: <47686913.3080509@bogus.com> Date: Tue, 18 Dec 2007 16:42:59 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: opsec@ietf.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/5174/Tue Dec 18 19:07:58 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Tue, 18 Dec 2007 23:41:45 -0500 Subject: [OPSEC] charter skeleton rev3 - your thoughts requested? X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Folks, I thought I would share our thoughts thus far on what a new charter might look like... feedback would be highly useful at this point. Moreover I think we need to be thinking about what work will be accepted under this charter, and are there any lose ends that need to be tied off or finished. Also I thought i would take advantage of the newly minted ietf mailing list. joel --- Goals: The opsec working group will focus on work which will address relevant issues facing the network operator community today. In particular an effort will be made to clarify the reasons behind current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the operations security working is intended to include the protection and secure operation of The Forwarding, Control and Management planes in internet networks. Documentation of accepted wisdom, revision of existing practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that most of the work product of the working group will fall into the category of current practices documents. Taxonomy or problem statement documents may provide a basis for current practices documents. Current Practices Document A single document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a common practices document. The work product of the working group is intended principally for the benefit of network operators rather than vendors. It should be noted that this represents a substantial break with the original charter. Non-Goals: The Operations security working group is not the place to do new protocol elements or functionality requirements documents. It is presumed that the appropriate place for vendor requirements is in the form of an RFP; a document which is necessarily informed by operational exegiences (and the documents that describe them) but is at the discretion of the operator creating such a request. New protocol development or requirements work should be addressed in a working group chartered in the appropriate area or as individual submissions. The opsec working group may take on documents related to the practices of using such work. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 19 12:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52Sx-0007ZV-Fq; Wed, 19 Dec 2007 12:12:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52Su-0007OS-Il for opsec@ietf.org; Wed, 19 Dec 2007 12:12:16 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167] helo=psmtp.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J52St-0007gQ-TX for opsec@ietf.org; Wed, 19 Dec 2007 12:12:16 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Dec 2007 09:10:59 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:11:43 -0800 Received: from [172.23.1.231] ([172.23.1.231] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:11:42 -0500 Message-ID: <476950CA.6030001@juniper.net> Date: Wed, 19 Dec 2007 12:11:38 -0500 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: opsec wg mailing list Subject: Re: [OPSEC] charter skeleton rev3 - your thoughts requested? References: <47686913.3080509@bogus.com> In-Reply-To: <47686913.3080509@bogus.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 17:11:42.0972 (UTC) FILETIME=[3A23EBC0:01C84262] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Comments inline.... Joel Jaeggli wrote: > Folks, > > I thought I would share our thoughts thus far on what a new charter > might look like... feedback would be highly useful at this point. > > Moreover I think we need to be thinking about what work will be accepted > under this charter, and are there any lose ends that need to be tied off > or finished. > > Also I thought i would take advantage of the newly minted ietf mailing list. > > joel > > --- > > Goals: > > The opsec working group will focus on work which will address relevant > issues facing the network operator community today. s/The opsec working group will focus on work which will address relevant issues facing the network operator community today / The OPSEC WG will document best current practices with regard to network security. / In particular an > effort will be made to clarify the reasons behind current operational > practice, address gaps in currently understood best practices for > forwarding, control plane, and management security and make clear the > liabilities inherent in security practices where they exist. > > Scope: > > The scope of the operations security working is intended to include the > protection and secure operation of The Forwarding, Control and > Management planes in internet networks. s/The Forwarding, Control and Management planes in internet networks/the forwarding, control and management planes./ > > Documentation of accepted wisdom, revision of existing practices > documents and proposals for new approaches to operational challenges are > in scope. s/accepted wisdom/best common practices/ > > Method: > > It is expected that most of the work product of the working group will > fall into the category of current practices documents. Taxonomy or > problem statement documents may provide a basis for current practices > documents. > > Current Practices Document > > A single document will be produced that attempts to capture > current practices related to secure operation. This will be > primarily based on operational experience. Each entry will > list: > > * threats addressed, > > * current practices for addressing the threat, > > * protocols, tools and technologies extant at the time of > writing that are used to address the threat, > > * the possibility that a solution does not exist within existing tools > or technologies. > > Taxonomy and Problem Statement Documents > > A document which attempts to describe the scope of particular > operational security challenge or problem space without necessarily > coming to a conclusion or proposing a solution. Such a document might be > a precursor to a common practices document. > > The work product of the working group is intended principally for the > benefit of network operators rather than vendors. It should be noted > that this represents a substantial break with the original charter. > > Non-Goals: > > The Operations security working group is not the place to do new > protocol elements or functionality requirements documents. > > It is presumed that the appropriate place for vendor requirements is in > the form of an RFP; a document which is necessarily informed by > operational exegiences (and the documents that describe them) but is at > the discretion of the operator creating such a request. > > New protocol development or requirements work should be addressed in a > working group chartered in the appropriate area or as individual > submissions. The opsec working group may take on documents related to > the practices of using such work. > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 21 06:18:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ftq-0007Yn-LN; Fri, 21 Dec 2007 06:18:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ftp-0007YP-Di for opsec@ietf.org; Fri, 21 Dec 2007 06:18:41 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5ftp-0006mE-1j for opsec@ietf.org; Fri, 21 Dec 2007 06:18:41 -0500 Received: from pc6 (1Cust209.tnt108.lnd4.gbr.da.uu.net [62.188.170.209]) by galaxy.systems.pipex.net (Postfix) with SMTP id BDF1BE000B16 for ; Fri, 21 Dec 2007 11:18:37 +0000 (GMT) Message-ID: <01e701c843ba$b70e39c0$0601a8c0@pc6> From: "Tom Petch" To: "opsec wg mailing list" References: <47686913.3080509@bogus.com> Subject: Re: [OPSEC] charter skeleton rev3 - your thoughts requested? Date: Fri, 21 Dec 2007 11:16:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch , opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org ----- Original Message ----- From: "Joel Jaeggli" To: Sent: Wednesday, December 19, 2007 1:42 AM Subject: [OPSEC] charter skeleton rev3 - your thoughts requested? > Folks, > > I thought I would share our thoughts thus far on what a new charter > might look like... feedback would be highly useful at this point. > > Moreover I think we need to be thinking about what work will be accepted > under this charter, and are there any lose ends that need to be tied off > or finished. > > Also I thought i would take advantage of the newly minted ietf mailing list. > > joel > > --- > > Goals: > > The opsec working group will focus on work which will address relevant > issues facing the network operator community today. In particular an > effort will be made to clarify the reasons behind current operational > practice, address gaps in currently understood best practices for > forwarding, control plane, and management security /forwarding, control plane, and management security/the security of the forwarding, control and management planes/ 'management security' sounds a bit like a bunch of heavies surrounding the CEO. Tom Petch _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 22 08:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J647g-00079F-L9; Sat, 22 Dec 2007 08:10:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J647f-000798-4d for opsec@ietf.org; Sat, 22 Dec 2007 08:10:35 -0500 Received: from hs-out-0708.google.com ([64.233.178.240] helo=hs-out-2122.google.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J647e-0008Sf-LW for opsec@ietf.org; Sat, 22 Dec 2007 08:10:35 -0500 Received: by hs-out-2122.google.com with SMTP id 54so558163hsz.5 for ; Sat, 22 Dec 2007 05:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=Qfwgzrffz3xeRVvBbvhzVQlPxRzQetnL3w4hKcgxdBE=; b=uu0wMTMVP+GqmSKdgyn+h1qqa6utOWbGFmFd1IScIVPWIBFXYVu/96u7G23KpOa7CzvlC3l2/fogkMVym6JT8jvVQbkMaNA4k1CTrWoHIn+6maAG0hBhyJwZSo7fRCLdQyjmUy3XaaE9GKHnMM551+5Oe9JfV+J1k+eQkdi9Iy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=tsOK1n9YT/0uXCt1f6+c8MAD2b/GwEBqAUy0zzgzrH/BLn5bgTQPVA8rB9UhEbQcYdIlcTnsZShpJYOthwRCuqWK+PugBQxXoRbFkzAqamQPoHUdoR18elYyUIj/xKDpBlFg/o91rOkyqp/RETDfXUTvb65B0UuBaJtGDKdBiKo= Received: by 10.151.85.20 with SMTP id n20mr735336ybl.79.1198329033046; Sat, 22 Dec 2007 05:10:33 -0800 (PST) Received: from ?192.168.1.2? ( [24.125.228.78]) by mx.google.com with ESMTPS id 38sm3424418wrl.14.2007.12.22.05.10.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 22 Dec 2007 05:10:31 -0800 (PST) Message-ID: <476D0CC5.2020207@gmail.com> Date: Sat, 22 Dec 2007 08:10:29 -0500 From: George Jones User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: opsec wg mailing list Subject: Re: [OPSEC] charter skeleton rev3 - your thoughts requested? References: <47686913.3080509@bogus.com> In-Reply-To: <47686913.3080509@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Joel Jaeggli wrote: > Goals: > > The opsec working group will focus on work which will address relevant > issues facing the network operator community today. I think this is good. Some thought should be given to defining "network operator community". Does that mean people who do transport ? ISPs ? Large Enterprise ? stub-sites ? SOHO ? Are "hosts" out of scope ? > In particular an > effort will be made to clarify the reasons behind current operational > practice, address gaps in currently understood best practices for > forwarding, control plane, and management security and make clear the > liabilities inherent in security practices where they exist. > > Scope: > See above. > The scope of the operations security working is intended to include the > protection and secure operation of The Forwarding, Control and > Management planes in internet networks. > > Documentation of accepted wisdom, revision of existing practices > documents and proposals for new approaches to operational challenges are > in scope. > > Method: > > It is expected that most of the work product of the working group will > fall into the category of current practices documents. Best Current Practice (http://www.ietf.org/rfc/rfc2026.txt) > Taxonomy or > problem statement documents may provide a basis for current practices > documents. > > Current Practices Document > > A single document will be produced that attempts to capture > current practices related to secure operation. This will be > primarily based on operational experience. Each entry will > list: > > * threats addressed, > > * current practices for addressing the threat, > > * protocols, tools and technologies extant at the time of > writing that are used to address the threat, > > * the possibility that a solution does not exist within existing tools > or technologies. > Good. > Taxonomy and Problem Statement Documents > > A document which attempts to describe the scope of particular > operational security challenge or problem space without necessarily > coming to a conclusion or proposing a solution. Such a document might be > a precursor to a common practices document. > > The work product of the working group is intended principally for the > benefit of network operators rather than vendors. It should be noted > that this represents a substantial break with the original charter. > Two comments here. The last sentence, while true, probably does not belong in the new charter. Second, if your target is operators, you'll need to get them involved. That, in my view, was the biggest problem OPSEC faced. They didn't see the benefit, didn't contribute, could not be pulled away from fighting the fires....you need to find a way to convince them that participation is worth the time. > Non-Goals: > > The Operations security working group is not the place to do new > protocol elements or functionality requirements documents. > Good. s/protocol elements/protocols/ s/functionality// > It is presumed that the appropriate place for vendor requirements is in > the form of an RFP; a document which is necessarily informed by > operational exegiences (and the documents that describe them) but is at > the discretion of the operator creating such a request. > > New protocol development or requirements work should be addressed in a > working group chartered in the appropriate area or as individual > submissions. The opsec working group may take on documents related to > the practices of using such work. > While this is true, I think the charter can do without it. ---George Jones _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 22 17:22:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6CjU-0002pq-O8; Sat, 22 Dec 2007 17:22:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J62KB-000114-37 for opsec@ietf.org; Sat, 22 Dec 2007 06:15:23 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J62KA-0005Gg-IC for opsec@ietf.org; Sat, 22 Dec 2007 06:15:22 -0500 Received: by an-out-0708.google.com with SMTP id d11so168469and.122 for ; Sat, 22 Dec 2007 03:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=Qfwgzrffz3xeRVvBbvhzVQlPxRzQetnL3w4hKcgxdBE=; b=l/P0grKGLvP5XRbZQ4f8RvXoWUzEqZ8F4M9HPlXF+GlbHxc/wpodZ5yaXEeG0XLLnL64IIx8Q54D6RdtUMlZJIyqeRfKFMVLuX7O3M+b88LkvIfygPSKXqFEWHtQCfnjnhH0KGqckeb9HYxXcdjp+PnigXDkLIFI94nU0W2H4bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Cyc8bBHn/808uLhhUuyaY26ZcWD861KHALDicTZQLgXD49ZdVQVGWlwkJKst4AcDgi7vVHAlRROveJCqTBgtu1yfTmXzfLViQWmJj3B/KxdW4r5s1/rMAeTil8ylHre+wrsUFTvq6ZJic5LOTpjc2DsbKMYnPY7CJ29Zt3X7Ld0= Received: by 10.100.123.4 with SMTP id v4mr4797012anc.14.1198322122171; Sat, 22 Dec 2007 03:15:22 -0800 (PST) Received: from ?192.168.1.2? ( [24.125.228.78]) by mx.google.com with ESMTPS id 11sm3306421wrl.15.2007.12.22.03.15.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 22 Dec 2007 03:15:21 -0800 (PST) Message-ID: <476CF1C7.7010708@gmail.com> Date: Sat, 22 Dec 2007 06:15:19 -0500 From: George Jones User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: opsec wg mailing list Subject: Re: [OPSEC] charter skeleton rev3 - your thoughts requested? References: <47686913.3080509@bogus.com> In-Reply-To: <47686913.3080509@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Sat, 22 Dec 2007 17:22:11 -0500 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Joel Jaeggli wrote: > Goals: > > The opsec working group will focus on work which will address relevant > issues facing the network operator community today. I think this is good. Some thought should be given to defining "network operator community". Does that mean people who do transport ? ISPs ? Large Enterprise ? stub-sites ? SOHO ? Are "hosts" out of scope ? > In particular an > effort will be made to clarify the reasons behind current operational > practice, address gaps in currently understood best practices for > forwarding, control plane, and management security and make clear the > liabilities inherent in security practices where they exist. > > Scope: > See above. > The scope of the operations security working is intended to include the > protection and secure operation of The Forwarding, Control and > Management planes in internet networks. > > Documentation of accepted wisdom, revision of existing practices > documents and proposals for new approaches to operational challenges are > in scope. > > Method: > > It is expected that most of the work product of the working group will > fall into the category of current practices documents. Best Current Practice (http://www.ietf.org/rfc/rfc2026.txt) > Taxonomy or > problem statement documents may provide a basis for current practices > documents. > > Current Practices Document > > A single document will be produced that attempts to capture > current practices related to secure operation. This will be > primarily based on operational experience. Each entry will > list: > > * threats addressed, > > * current practices for addressing the threat, > > * protocols, tools and technologies extant at the time of > writing that are used to address the threat, > > * the possibility that a solution does not exist within existing tools > or technologies. > Good. > Taxonomy and Problem Statement Documents > > A document which attempts to describe the scope of particular > operational security challenge or problem space without necessarily > coming to a conclusion or proposing a solution. Such a document might be > a precursor to a common practices document. > > The work product of the working group is intended principally for the > benefit of network operators rather than vendors. It should be noted > that this represents a substantial break with the original charter. > Two comments here. The last sentence, while true, probably does not belong in the new charter. Second, if your target is operators, you'll need to get them involved. That, in my view, was the biggest problem OPSEC faced. They didn't see the benefit, didn't contribute, could not be pulled away from fighting the fires....you need to find a way to convince them that participation is worth the time. > Non-Goals: > > The Operations security working group is not the place to do new > protocol elements or functionality requirements documents. > Good. s/protocol elements/protocols/ s/functionality// > It is presumed that the appropriate place for vendor requirements is in > the form of an RFP; a document which is necessarily informed by > operational exegiences (and the documents that describe them) but is at > the discretion of the operator creating such a request. > > New protocol development or requirements work should be addressed in a > working group chartered in the appropriate area or as individual > submissions. The opsec working group may take on documents related to > the practices of using such work. > While this is true, I think the charter can do without it. ---George Jones _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 26 02:17:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7QWM-0004WZ-Ie; Wed, 26 Dec 2007 02:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7QWK-0004Jg-VW for opsec@ietf.org; Wed, 26 Dec 2007 02:17:40 -0500 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7QWJ-00023n-VV for opsec@ietf.org; Wed, 26 Dec 2007 02:17:40 -0500 Received: from [192.168.11.143] (c-24-22-104-127.hsd1.or.comcast.net [24.22.104.127]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id lBQ7HbfU079302 for ; Wed, 26 Dec 2007 07:17:38 GMT (envelope-from joelja@bogus.com) Message-ID: <47720011.8010703@bogus.com> Date: Tue, 25 Dec 2007 23:17:37 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: opsec@ietf.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/5256/Wed Dec 26 05:07:54 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [OPSEC] charter skeleton rev4 - your thoughts requested... X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org This version incorporates comments from: Ron Bonica Tom Petch George Jones References to the previous charter have been eliminated. ---- Goals: The OPSEC WG will document best current practices with regard to network security. In particular an effort will be made to clarify the reasons behind current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management plane security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure operation of The Forwarding, Control and Management planes. Documentation of best common practices, revision of existing practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that most of the work product of the working group will fall into the category of current practices documents. Taxonomy or problem statement documents may provide a basis for best current practices documents. Best Current Practices Document A single document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a best common practices document. The work product of the working group is intended principally for the benefit of network operators rather than equipment vendors or protocol developers. Non-Goals: The Operations security working group is not the place to do new protocols or requirements documents. New protocol development or requirements work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to the practices of using such work. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 26 12:44:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7aJ2-0002Ip-AO; Wed, 26 Dec 2007 12:44:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7aJ0-0002HP-MG for opsec@ietf.org; Wed, 26 Dec 2007 12:44:34 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161] helo=psmtp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7aJ0-0004d1-3d for opsec@ietf.org; Wed, 26 Dec 2007 12:44:34 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Dec 2007 09:42:29 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 09:43:34 -0800 Received: from [172.23.1.44] ([172.23.1.44] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 12:43:33 -0500 Message-ID: <477292C0.1090504@juniper.net> Date: Wed, 26 Dec 2007 12:43:28 -0500 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: opsec wg mailing list Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... References: <47720011.8010703@bogus.com> In-Reply-To: <47720011.8010703@bogus.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2007 17:43:34.0051 (UTC) FILETIME=[D61FAF30:01C847E6] X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Joel, This looks very good. I have picked a few nits below, but they are all grammar issues. The one thing that we are lacking is a list of deliverables. I think that we have reached agreement on an ICMP filtering document. Can we think of any others? Ron Joel Jaeggli wrote: > This version incorporates comments from: > > Ron Bonica > Tom Petch > George Jones > > References to the previous charter have been eliminated. > > ---- > > Goals: > > The OPSEC WG will document best current practices with regard to network > security. In particular an effort will be made to clarify the reasons > behind current operational practice, address gaps in currently s/reasons behind/rationale supporting/ > understood best practices for forwarding, control plane, and management > plane security and make clear the liabilities inherent in security > practices where they exist. > > Scope: > > The scope of the OPSEC WG is intended to include the protection and > secure operation of The Forwarding, Control and Management planes. s/The Forwarding, Control and Management/the forwarding, control and management/ > > Documentation of best common practices, revision of existing practices > documents and proposals for new approaches to operational challenges are > in scope. > > Method: > > It is expected that most of the work product of the working group will s/most of// > fall into the category of current practices documents. Taxonomy or s/current practices/best current practice/ > problem statement documents may provide a basis for best current > practices documents. > > Best Current Practices Document > > A single document will be produced that attempts to capture s/A single/For each topic addressed, a single/ > current practices related to secure operation. This will be > primarily based on operational experience. Each entry will > list: > > * threats addressed, > > * current practices for addressing the threat, > > * protocols, tools and technologies extant at the time of > writing that are used to address the threat, > > * the possibility that a solution does not exist within existing tools > or technologies. > > Taxonomy and Problem Statement Documents > > A document which attempts to describe the scope of particular > operational security challenge or problem space without necessarily > coming to a conclusion or proposing a solution. Such a document might be > a precursor to a best common practices document. > > The work product of the working group is intended principally for the > benefit of network operators rather than equipment vendors or protocol > developers. > > Non-Goals: > > The Operations security working group is not the place to do new > protocols or requirements documents. > > New protocol development or requirements work should be addressed in a > working group chartered in the appropriate area or as individual > submissions. The OPSEC WG may take on documents related to > the practices of using such work. > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 26 13:23:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7auT-0000Zs-Oh; Wed, 26 Dec 2007 13:23:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7auS-0000Zn-67 for opsec@ietf.org; Wed, 26 Dec 2007 13:23:16 -0500 Received: from sudnp799.qwest.com ([155.70.32.99]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7auR-0001ot-H2 for opsec@ietf.org; Wed, 26 Dec 2007 13:23:16 -0500 Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id lBQINCl6010678 for ; Wed, 26 Dec 2007 11:23:14 -0700 (MST) Received: from ITDENE2KSM01.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id lBQIN6CU026566 for ; Wed, 26 Dec 2007 12:23:07 -0600 (CST) Received: from ITDENE2KM02.AD.QINTRA.COM ([10.1.4.66]) by ITDENE2KSM01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 11:23:06 -0700 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPSEC] charter skeleton rev4 - your thoughts requested... Date: Wed, 26 Dec 2007 11:23:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] charter skeleton rev4 - your thoughts requested... thread-index: AchHj32jvak07F0MTK6tbe6OUYVk/wAWeHZx Importance: normal References: <47720011.8010703@bogus.com> Priority: normal From: "Smith, Donald" To: "opsec wg mailing list" , X-OriginalArrivalTime: 26 Dec 2007 18:23:06.0980 (UTC) FILETIME=[5C7FEA40:01C847EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org We may want to include testing methods and processes. This would be more of a framework then an actual step by step testing = guidance. =20 For example: Recommending a specific ICMP rate limiting level without discussing how = to test the network elements that the rate limits would be applied to is = likely to lead to operations issues. In testing things like that I usually try to discover how many pps of a = specific packet type causes a certain level of cpu or other limited = resource exhaustion/consumption. =20 With out that type of testing how can anyone estimate much rate limiting = is required before a network element is protected well enough to = continue it's primary functions. =20 Most of us could agree "An attack that was consuming 50% of the cpu = would cause our routers to drop legitimate management and control = traffic and therefore any type of packet that at a specific rate of pps = causes >50% cpu consumption should be dropped." =20 An alternate approach would be to see pps of certain types of packets as = they exist in your network today and base your rate limiting on that = information. However I think that is much harder then finding the = "performance impacting level" of a device and rate limiting to some = acceptable performance level. =20 One issue with this is you may have to test to the I/O card levels, IOS = levels, etc... =20 It would be helpful if vendors would actually make reasonable = suggestions in these areas but from past experience I don't believe they = will. They are very reluctant to tell any "performance impacting levels" = for any specific type of packet/protocols. =20 It would be helpful if vendors at least documented their default rate = limits especially those that are hard coded and not configurable. =20 =20 donald.smith@qwest.com giac ________________________________ From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Wed 12/26/2007 12:17 AM To: opsec@ietf.org Subject: [OPSEC] charter skeleton rev4 - your thoughts requested... This version incorporates comments from: Ron Bonica Tom Petch George Jones References to the previous charter have been eliminated. ---- Goals: The OPSEC WG will document best current practices with regard to network security. In particular an effort will be made to clarify the reasons behind current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management plane security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure operation of The Forwarding, Control and Management planes. Documentation of best common practices, revision of existing practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that most of the work product of the working group will fall into the category of current practices documents. Taxonomy or problem statement documents may provide a basis for best current practices documents. Best Current Practices Document A single document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of =20 writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a best common practices document. The work product of the working group is intended principally for the benefit of network operators rather than equipment vendors or protocol developers. Non-Goals: The Operations security working group is not the place to do new protocols or requirements documents. New protocol development or requirements work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to the practices of using such work. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.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=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 27 08:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7t4L-0006b7-DR; Thu, 27 Dec 2007 08:46:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7t4K-0006b1-2A for opsec@ietf.org; Thu, 27 Dec 2007 08:46:40 -0500 Received: from aharp.ittns.northwestern.edu ([129.105.153.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7t4J-0000LA-QA for opsec@ietf.org; Thu, 27 Dec 2007 08:46:40 -0500 Received: from jtk (aharp [127.0.0.1]) by aharp.ittns.northwestern.edu (smtpd) with SMTP id 44F65136C82 for ; Thu, 27 Dec 2007 07:46:39 -0600 (CST) Date: Thu, 27 Dec 2007 07:46:37 -0600 From: John Kristoff To: opsec@ietf.org Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... In-Reply-To: References: <47720011.8010703@bogus.com> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20071227134639.44F65136C82@aharp.ittns.northwestern.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org On Wed, 26 Dec 2007 11:23:06 -0700 "Smith, Donald" wrote: > Recommending a specific ICMP rate limiting level without discussing how to test the network elements that the rate limits would be applied to is likely to lead to operations issues. > Even still there are likely going to be problems in some configurations. Just as a for instance, if you rate limit to 1 Mb/s at each edge, and also have the same limit somewhere upstream, any one edge can fill that upstream limit. Probably not what you want. Very tricky to codify hard and fast rules here. John _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 27 10:26:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ucB-0003jr-4Z; Thu, 27 Dec 2007 10:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7uc9-0003jl-He for opsec@ietf.org; Thu, 27 Dec 2007 10:25:41 -0500 Received: from smtp-bedford.mitre.org ([129.83.20.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7uc8-0002Er-CC for opsec@ietf.org; Thu, 27 Dec 2007 10:25:41 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id lBRFPemI011748 for ; Thu, 27 Dec 2007 10:25:40 -0500 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id lBRFPdt3011734 for ; Thu, 27 Dec 2007 10:25:39 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Dec 2007 10:25:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... Date: Thu, 27 Dec 2007 10:25:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] charter skeleton rev4 - your thoughts requested... Thread-Index: AchHj32jvak07F0MTK6tbe6OUYVk/wAWeHZxACzXGbc= From: "Jones, George" To: X-OriginalArrivalTime: 27 Dec 2007 15:25:39.0924 (UTC) FILETIME=[BCC5D940:01C8489C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075915450==" Errors-To: opsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0075915450== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8489C.BC291615" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8489C.BC291615 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3aWxsIHBvaW50IG91dCB0aGF0IHRoZSBiZW5jaG1hcmsgDQpNZXRob2RvbG9neSBXRyBleGlz dHMuDQoNCi0tLUdlb3JnZQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBT bWl0aCwgRG9uYWxkIDxEb25hbGQuU21pdGhAcXdlc3QuY29tPg0KVG86IG9wc2VjIHdnIG1haWxp bmcgbGlzdCA8b3BzZWNAaWV0Zi5vcmc+OyBvcHNlY0BpZXRmLm9yZw0KPG9wc2VjQGlldGYub3Jn Pg0KU2VudDogV2VkIERlYyAyNiAxMzoyMzowNiAyMDA3DQpTdWJqZWN0OiBSRTogW09QU0VDXSBj aGFydGVyIHNrZWxldG9uIHJldjQgLSB5b3VyIHRob3VnaHRzIHJlcXVlc3RlZC4uLg0KDQpXZSBt YXkgd2FudCB0byBpbmNsdWRlIHRlc3RpbmcgbWV0aG9kcyBhbmQgcHJvY2Vzc2VzLg0KVGhpcyB3 b3VsZCBiZSBtb3JlIG9mIGEgZnJhbWV3b3JrIHRoZW4gYW4gYWN0dWFsIHN0ZXAgYnkgc3RlcCB0 ZXN0aW5nDQpndWlkYW5jZS4NCiANCkZvciBleGFtcGxlOg0KUmVjb21tZW5kaW5nIGEgc3BlY2lm aWMgSUNNUCByYXRlIGxpbWl0aW5nIGxldmVsIHdpdGhvdXQgZGlzY3Vzc2luZyBob3cNCnRvIHRl c3QgdGhlIG5ldHdvcmsgZWxlbWVudHMgdGhhdCB0aGUgcmF0ZSBsaW1pdHMgd291bGQgYmUgYXBw bGllZCB0bw0KaXMgbGlrZWx5IHRvIGxlYWQgdG8gb3BlcmF0aW9ucyBpc3N1ZXMuDQpJbiB0ZXN0 aW5nIHRoaW5ncyBsaWtlIHRoYXQgSSB1c3VhbGx5IHRyeSB0byBkaXNjb3ZlciBob3cgbWFueSBw cHMgb2YgYQ0Kc3BlY2lmaWMgcGFja2V0IHR5cGUgY2F1c2VzIGEgY2VydGFpbiBsZXZlbCBvZiBj cHUgb3Igb3RoZXIgbGltaXRlZA0KcmVzb3VyY2UgZXhoYXVzdGlvbi9jb25zdW1wdGlvbi4NCiAN CldpdGggb3V0IHRoYXQgdHlwZSBvZiB0ZXN0aW5nIGhvdyBjYW4gYW55b25lIGVzdGltYXRlIG11 Y2ggcmF0ZQ0KbGltaXRpbmcgaXMgcmVxdWlyZWQgYmVmb3JlIGEgbmV0d29yayBlbGVtZW50IGlz IHByb3RlY3RlZCB3ZWxsIGVub3VnaA0KdG8gY29udGludWUgaXQncyBwcmltYXJ5IGZ1bmN0aW9u cy4NCiANCk1vc3Qgb2YgdXMgY291bGQgYWdyZWUgICJBbiBhdHRhY2sgdGhhdCB3YXMgY29uc3Vt aW5nIDUwJSBvZiB0aGUgY3B1DQp3b3VsZCBjYXVzZSBvdXIgcm91dGVycyB0byBkcm9wIGxlZ2l0 aW1hdGUgbWFuYWdlbWVudCBhbmQgY29udHJvbA0KdHJhZmZpYyBhbmQgdGhlcmVmb3JlIGFueSB0 eXBlIG9mIHBhY2tldCB0aGF0IGF0IGEgc3BlY2lmaWMgcmF0ZSBvZiBwcHMNCmNhdXNlcyA+NTAl IGNwdSBjb25zdW1wdGlvbiBzaG91bGQgYmUgZHJvcHBlZC4iDQogDQpBbiBhbHRlcm5hdGUgYXBw cm9hY2ggd291bGQgYmUgdG8gc2VlIHBwcyBvZiBjZXJ0YWluIHR5cGVzIG9mIHBhY2tldHMNCmFz IHRoZXkgZXhpc3QgaW4geW91ciBuZXR3b3JrIHRvZGF5IGFuZCBiYXNlIHlvdXIgcmF0ZSBsaW1p dGluZyBvbiB0aGF0DQppbmZvcm1hdGlvbi4gSG93ZXZlciBJIHRoaW5rIHRoYXQgaXMgbXVjaCBo YXJkZXIgdGhlbiBmaW5kaW5nIHRoZQ0KInBlcmZvcm1hbmNlIGltcGFjdGluZyBsZXZlbCIgb2Yg YSBkZXZpY2UgYW5kIHJhdGUgbGltaXRpbmcgdG8gc29tZQ0KYWNjZXB0YWJsZSBwZXJmb3JtYW5j ZSBsZXZlbC4NCiANCk9uZSBpc3N1ZSB3aXRoIHRoaXMgaXMgeW91IG1heSBoYXZlIHRvIHRlc3Qg dG8gdGhlIEkvTyBjYXJkIGxldmVscywgSU9TDQpsZXZlbHMsIGV0Yy4uLg0KIA0KSXQgd291bGQg YmUgaGVscGZ1bCBpZiB2ZW5kb3JzIHdvdWxkIGFjdHVhbGx5IG1ha2UgcmVhc29uYWJsZQ0Kc3Vn Z2VzdGlvbnMgaW4gdGhlc2UgYXJlYXMgYnV0IGZyb20gcGFzdCBleHBlcmllbmNlIEkgZG9uJ3Qg YmVsaWV2ZQ0KdGhleSB3aWxsLiBUaGV5IGFyZSB2ZXJ5IHJlbHVjdGFudCB0byB0ZWxsIGFueSAi cGVyZm9ybWFuY2UgaW1wYWN0aW5nDQpsZXZlbHMiIGZvciBhbnkgc3BlY2lmaWMgdHlwZSBvZiBw YWNrZXQvcHJvdG9jb2xzLg0KIA0KSXQgd291bGQgYmUgaGVscGZ1bCBpZiB2ZW5kb3JzIGF0IGxl YXN0IGRvY3VtZW50ZWQgdGhlaXIgZGVmYXVsdCByYXRlDQpsaW1pdHMgZXNwZWNpYWxseSB0aG9z ZSB0aGF0IGFyZSBoYXJkIGNvZGVkIGFuZCBub3QgY29uZmlndXJhYmxlLg0KIA0KIA0KZG9uYWxk LnNtaXRoQHF3ZXN0LmNvbSBnaWFjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkZyb206IEpvZWwgSmFlZ2dsaSBbbWFpbHRvOmpvZWxqYUBib2d1cy5jb21dDQpTZW50OiBX ZWQgMTIvMjYvMjAwNyAxMjoxNyBBTQ0KVG86IG9wc2VjQGlldGYub3JnDQpTdWJqZWN0OiBbT1BT RUNdIGNoYXJ0ZXIgc2tlbGV0b24gcmV2NCAtIHlvdXIgdGhvdWdodHMgcmVxdWVzdGVkLi4uDQoN Cg0KDQpUaGlzIHZlcnNpb24gaW5jb3Jwb3JhdGVzIGNvbW1lbnRzIGZyb206DQoNClJvbiBCb25p Y2ENClRvbSBQZXRjaA0KR2VvcmdlIEpvbmVzDQoNClJlZmVyZW5jZXMgdG8gdGhlIHByZXZpb3Vz IGNoYXJ0ZXIgaGF2ZSBiZWVuIGVsaW1pbmF0ZWQuDQoNCi0tLS0NCg0KR29hbHM6DQoNClRoZSBP UFNFQyBXRyB3aWxsIGRvY3VtZW50IGJlc3QgY3VycmVudCBwcmFjdGljZXMgd2l0aCByZWdhcmQg dG8NCm5ldHdvcmsNCnNlY3VyaXR5LiBJbiBwYXJ0aWN1bGFyIGFuIGVmZm9ydCB3aWxsIGJlIG1h ZGUgdG8gY2xhcmlmeSB0aGUgcmVhc29ucw0KYmVoaW5kIGN1cnJlbnQgb3BlcmF0aW9uYWwgcHJh Y3RpY2UsIGFkZHJlc3MgZ2FwcyBpbiBjdXJyZW50bHkNCnVuZGVyc3Rvb2QgYmVzdCBwcmFjdGlj ZXMgZm9yIGZvcndhcmRpbmcsIGNvbnRyb2wgcGxhbmUsIGFuZCBtYW5hZ2VtZW50DQpwbGFuZSBz ZWN1cml0eSBhbmQgbWFrZSBjbGVhciB0aGUgbGlhYmlsaXRpZXMgaW5oZXJlbnQgaW4gc2VjdXJp dHkNCnByYWN0aWNlcyB3aGVyZSB0aGV5IGV4aXN0Lg0KDQpTY29wZToNCg0KVGhlIHNjb3BlIG9m IHRoZSBPUFNFQyBXRyBpcyBpbnRlbmRlZCB0byBpbmNsdWRlIHRoZSBwcm90ZWN0aW9uIGFuZA0K c2VjdXJlIG9wZXJhdGlvbiBvZiBUaGUgRm9yd2FyZGluZywgQ29udHJvbCBhbmQgTWFuYWdlbWVu dCBwbGFuZXMuDQoNCkRvY3VtZW50YXRpb24gb2YgYmVzdCBjb21tb24gcHJhY3RpY2VzLCByZXZp c2lvbiBvZiBleGlzdGluZyBwcmFjdGljZXMNCmRvY3VtZW50cyBhbmQgcHJvcG9zYWxzIGZvciBu ZXcgYXBwcm9hY2hlcyB0byBvcGVyYXRpb25hbCBjaGFsbGVuZ2VzDQphcmUNCmluIHNjb3BlLg0K DQpNZXRob2Q6DQoNCkl0IGlzIGV4cGVjdGVkIHRoYXQgbW9zdCBvZiB0aGUgd29yayBwcm9kdWN0 IG9mIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwNCmZhbGwgaW50byB0aGUgY2F0ZWdvcnkgb2YgY3Vy cmVudCBwcmFjdGljZXMgZG9jdW1lbnRzLiBUYXhvbm9teSBvcg0KcHJvYmxlbSBzdGF0ZW1lbnQg ZG9jdW1lbnRzIG1heSBwcm92aWRlIGEgYmFzaXMgZm9yIGJlc3QgY3VycmVudA0KcHJhY3RpY2Vz IGRvY3VtZW50cy4NCg0KQmVzdCBDdXJyZW50IFByYWN0aWNlcyBEb2N1bWVudA0KDQpBIHNpbmds ZSBkb2N1bWVudCB3aWxsIGJlIHByb2R1Y2VkIHRoYXQgYXR0ZW1wdHMgdG8gY2FwdHVyZQ0KY3Vy cmVudCBwcmFjdGljZXMgcmVsYXRlZCB0byBzZWN1cmUgb3BlcmF0aW9uLiBUaGlzIHdpbGwgYmUN CnByaW1hcmlseSBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBlcmllbmNlLiBFYWNoIGVudHJ5IHdp bGwNCmxpc3Q6DQoNCiogdGhyZWF0cyBhZGRyZXNzZWQsDQoNCiogY3VycmVudCBwcmFjdGljZXMg Zm9yIGFkZHJlc3NpbmcgdGhlIHRocmVhdCwNCg0KKiBwcm90b2NvbHMsIHRvb2xzIGFuZCB0ZWNo bm9sb2dpZXMgZXh0YW50IGF0IHRoZSB0aW1lIG9mICAgICAgDQp3cml0aW5nIHRoYXQgYXJlIHVz ZWQgdG8gYWRkcmVzcyB0aGUgdGhyZWF0LA0KDQoqIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGEgc29s dXRpb24gZG9lcyBub3QgZXhpc3Qgd2l0aGluIGV4aXN0aW5nIHRvb2xzDQpvciB0ZWNobm9sb2dp ZXMuDQoNClRheG9ub215IGFuZCBQcm9ibGVtIFN0YXRlbWVudCBEb2N1bWVudHMNCg0KQSBkb2N1 bWVudCB3aGljaCBhdHRlbXB0cyB0byBkZXNjcmliZSB0aGUgc2NvcGUgb2YgcGFydGljdWxhcg0K b3BlcmF0aW9uYWwgc2VjdXJpdHkgY2hhbGxlbmdlIG9yIHByb2JsZW0gc3BhY2Ugd2l0aG91dCBu ZWNlc3NhcmlseQ0KY29taW5nIHRvIGEgY29uY2x1c2lvbiBvciBwcm9wb3NpbmcgYSBzb2x1dGlv bi4gU3VjaCBhIGRvY3VtZW50IG1pZ2h0DQpiZQ0KYSBwcmVjdXJzb3IgdG8gYSAgYmVzdCBjb21t b24gcHJhY3RpY2VzIGRvY3VtZW50Lg0KDQpUaGUgd29yayBwcm9kdWN0IG9mIHRoZSB3b3JraW5n IGdyb3VwIGlzIGludGVuZGVkIHByaW5jaXBhbGx5IGZvciB0aGUNCmJlbmVmaXQgb2YgbmV0d29y ayBvcGVyYXRvcnMgcmF0aGVyIHRoYW4gZXF1aXBtZW50IHZlbmRvcnMgb3IgcHJvdG9jb2wNCmRl dmVsb3BlcnMuDQoNCk5vbi1Hb2FsczoNCg0KVGhlIE9wZXJhdGlvbnMgc2VjdXJpdHkgd29ya2lu ZyBncm91cCBpcyBub3QgdGhlIHBsYWNlIHRvIGRvIG5ldw0KcHJvdG9jb2xzIG9yIHJlcXVpcmVt ZW50cyBkb2N1bWVudHMuDQoNCk5ldyBwcm90b2NvbCBkZXZlbG9wbWVudCBvciByZXF1aXJlbWVu dHMgd29yayBzaG91bGQgYmUgYWRkcmVzc2VkIGluIGENCndvcmtpbmcgZ3JvdXAgY2hhcnRlcmVk IGluIHRoZSBhcHByb3ByaWF0ZSBhcmVhIG9yIGFzIGluZGl2aWR1YWwNCnN1Ym1pc3Npb25zLiBU aGUgT1BTRUMgV0cgbWF5IHRha2Ugb24gZG9jdW1lbnRzIHJlbGF0ZWQgdG8NCnRoZSBwcmFjdGlj ZXMgb2YgdXNpbmcgc3VjaCB3b3JrLg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT1BTRUMgbWFpbGluZyBsaXN0DQpPUFNFQ0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCg0KDQoNClRo aXMgY29tbXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgUXdlc3QgYW5kIG1heSBjb250YWlu DQpjb25maWRlbnRpYWwgb3INCnByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXplZCB1 c2Ugb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzDQpzdHJpY3RseSANCnByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMNCmNvbW11bmljYXRpb24g DQppbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5 IGUtbWFpbCBhbmQNCmRlc3Ryb3kgDQphbGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFu ZCBhbnkgYXR0YWNobWVudHMuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPUFNFQyBtYWlsaW5nIGxpc3QNCk9QU0VDQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYw0K ------_=_NextPart_001_01C8489C.BC291615 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbT1BTRUNd IGNoYXJ0ZXIgc2tlbGV0b24gcmV2NCAtIHlvdXIgdGhvdWdodHMgcmVxdWVzdGVkLi4uPC9USVRM RT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1h dCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPkkgd2lsbCBwb2ludCBvdXQgdGhhdCB0aGUgYmVuY2ht YXJrPEJSPg0KTWV0aG9kb2xvZ3kgV0cgZXhpc3RzLjxCUj4NCjxCUj4NCi0tLUdlb3JnZTxCUj4N CjxCUj4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+DQpGcm9tOiBTbWl0aCwgRG9u YWxkICZsdDtEb25hbGQuU21pdGhAcXdlc3QuY29tJmd0OzxCUj4NClRvOiBvcHNlYyB3ZyBtYWls aW5nIGxpc3QgJmx0O29wc2VjQGlldGYub3JnJmd0Ozsgb3BzZWNAaWV0Zi5vcmcgJmx0O29wc2Vj QGlldGYub3JnJmd0OzxCUj4NClNlbnQ6IFdlZCBEZWMgMjYgMTM6MjM6MDYgMjAwNzxCUj4NClN1 YmplY3Q6IFJFOiBbT1BTRUNdIGNoYXJ0ZXIgc2tlbGV0b24gcmV2NCAtIHlvdXIgdGhvdWdodHMg cmVxdWVzdGVkLi4uPEJSPg0KPEJSPg0KV2UgbWF5IHdhbnQgdG8gaW5jbHVkZSB0ZXN0aW5nIG1l dGhvZHMgYW5kIHByb2Nlc3Nlcy48QlI+DQpUaGlzIHdvdWxkIGJlIG1vcmUgb2YgYSBmcmFtZXdv cmsgdGhlbiBhbiBhY3R1YWwgc3RlcCBieSBzdGVwIHRlc3RpbmcgZ3VpZGFuY2UuPEJSPg0KPEJS Pg0KRm9yIGV4YW1wbGU6PEJSPg0KUmVjb21tZW5kaW5nIGEgc3BlY2lmaWMgSUNNUCByYXRlIGxp bWl0aW5nIGxldmVsIHdpdGhvdXQgZGlzY3Vzc2luZyBob3cgdG8gdGVzdCB0aGUgbmV0d29yayBl bGVtZW50cyB0aGF0IHRoZSByYXRlIGxpbWl0cyB3b3VsZCBiZSBhcHBsaWVkIHRvIGlzIGxpa2Vs eSB0byBsZWFkIHRvIG9wZXJhdGlvbnMgaXNzdWVzLjxCUj4NCkluIHRlc3RpbmcgdGhpbmdzIGxp a2UgdGhhdCBJIHVzdWFsbHkgdHJ5IHRvIGRpc2NvdmVyIGhvdyBtYW55IHBwcyBvZiBhIHNwZWNp ZmljIHBhY2tldCB0eXBlIGNhdXNlcyBhIGNlcnRhaW4gbGV2ZWwgb2YgY3B1IG9yIG90aGVyIGxp bWl0ZWQgcmVzb3VyY2UgZXhoYXVzdGlvbi9jb25zdW1wdGlvbi48QlI+DQo8QlI+DQpXaXRoIG91 dCB0aGF0IHR5cGUgb2YgdGVzdGluZyBob3cgY2FuIGFueW9uZSBlc3RpbWF0ZSBtdWNoIHJhdGUg bGltaXRpbmcgaXMgcmVxdWlyZWQgYmVmb3JlIGEgbmV0d29yayBlbGVtZW50IGlzIHByb3RlY3Rl ZCB3ZWxsIGVub3VnaCB0byBjb250aW51ZSBpdCdzIHByaW1hcnkgZnVuY3Rpb25zLjxCUj4NCjxC Uj4NCk1vc3Qgb2YgdXMgY291bGQgYWdyZWUmbmJzcDsgJnF1b3Q7QW4gYXR0YWNrIHRoYXQgd2Fz IGNvbnN1bWluZyA1MCUgb2YgdGhlIGNwdSB3b3VsZCBjYXVzZSBvdXIgcm91dGVycyB0byBkcm9w IGxlZ2l0aW1hdGUgbWFuYWdlbWVudCBhbmQgY29udHJvbCB0cmFmZmljIGFuZCB0aGVyZWZvcmUg YW55IHR5cGUgb2YgcGFja2V0IHRoYXQgYXQgYSBzcGVjaWZpYyByYXRlIG9mIHBwcyBjYXVzZXMg Jmd0OzUwJSBjcHUgY29uc3VtcHRpb24gc2hvdWxkIGJlIGRyb3BwZWQuJnF1b3Q7PEJSPg0KPEJS Pg0KQW4gYWx0ZXJuYXRlIGFwcHJvYWNoIHdvdWxkIGJlIHRvIHNlZSBwcHMgb2YgY2VydGFpbiB0 eXBlcyBvZiBwYWNrZXRzIGFzIHRoZXkgZXhpc3QgaW4geW91ciBuZXR3b3JrIHRvZGF5IGFuZCBi YXNlIHlvdXIgcmF0ZSBsaW1pdGluZyBvbiB0aGF0IGluZm9ybWF0aW9uLiBIb3dldmVyIEkgdGhp bmsgdGhhdCBpcyBtdWNoIGhhcmRlciB0aGVuIGZpbmRpbmcgdGhlICZxdW90O3BlcmZvcm1hbmNl IGltcGFjdGluZyBsZXZlbCZxdW90OyBvZiBhIGRldmljZSBhbmQgcmF0ZSBsaW1pdGluZyB0byBz b21lIGFjY2VwdGFibGUgcGVyZm9ybWFuY2UgbGV2ZWwuPEJSPg0KPEJSPg0KT25lIGlzc3VlIHdp dGggdGhpcyBpcyB5b3UgbWF5IGhhdmUgdG8gdGVzdCB0byB0aGUgSS9PIGNhcmQgbGV2ZWxzLCBJ T1MgbGV2ZWxzLCBldGMuLi48QlI+DQo8QlI+DQpJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHZlbmRv cnMgd291bGQgYWN0dWFsbHkgbWFrZSByZWFzb25hYmxlIHN1Z2dlc3Rpb25zIGluIHRoZXNlIGFy ZWFzIGJ1dCBmcm9tIHBhc3QgZXhwZXJpZW5jZSBJIGRvbid0IGJlbGlldmUgdGhleSB3aWxsLiBU aGV5IGFyZSB2ZXJ5IHJlbHVjdGFudCB0byB0ZWxsIGFueSAmcXVvdDtwZXJmb3JtYW5jZSBpbXBh Y3RpbmcgbGV2ZWxzJnF1b3Q7IGZvciBhbnkgc3BlY2lmaWMgdHlwZSBvZiBwYWNrZXQvcHJvdG9j b2xzLjxCUj4NCjxCUj4NCkl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgdmVuZG9ycyBhdCBsZWFzdCBk b2N1bWVudGVkIHRoZWlyIGRlZmF1bHQgcmF0ZSBsaW1pdHMgZXNwZWNpYWxseSB0aG9zZSB0aGF0 IGFyZSBoYXJkIGNvZGVkIGFuZCBub3QgY29uZmlndXJhYmxlLjxCUj4NCjxCUj4NCjxCUj4NCmRv bmFsZC5zbWl0aEBxd2VzdC5jb20gZ2lhYzxCUj4NCjxCUj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPEJSPg0KPEJSPg0KRnJvbTogSm9lbCBKYWVnZ2xpIFs8QSBIUkVGPSJtYWls dG86am9lbGphQGJvZ3VzLmNvbSI+bWFpbHRvOmpvZWxqYUBib2d1cy5jb208L0E+XTxCUj4NClNl bnQ6IFdlZCAxMi8yNi8yMDA3IDEyOjE3IEFNPEJSPg0KVG86IG9wc2VjQGlldGYub3JnPEJSPg0K U3ViamVjdDogW09QU0VDXSBjaGFydGVyIHNrZWxldG9uIHJldjQgLSB5b3VyIHRob3VnaHRzIHJl cXVlc3RlZC4uLjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NClRoaXMgdmVyc2lvbiBpbmNvcnBvcmF0 ZXMgY29tbWVudHMgZnJvbTo8QlI+DQo8QlI+DQpSb24gQm9uaWNhPEJSPg0KVG9tIFBldGNoPEJS Pg0KR2VvcmdlIEpvbmVzPEJSPg0KPEJSPg0KUmVmZXJlbmNlcyB0byB0aGUgcHJldmlvdXMgY2hh cnRlciBoYXZlIGJlZW4gZWxpbWluYXRlZC48QlI+DQo8QlI+DQotLS0tPEJSPg0KPEJSPg0KR29h bHM6PEJSPg0KPEJSPg0KVGhlIE9QU0VDIFdHIHdpbGwgZG9jdW1lbnQgYmVzdCBjdXJyZW50IHBy YWN0aWNlcyB3aXRoIHJlZ2FyZCB0byBuZXR3b3JrPEJSPg0Kc2VjdXJpdHkuIEluIHBhcnRpY3Vs YXIgYW4gZWZmb3J0IHdpbGwgYmUgbWFkZSB0byBjbGFyaWZ5IHRoZSByZWFzb25zPEJSPg0KYmVo aW5kIGN1cnJlbnQgb3BlcmF0aW9uYWwgcHJhY3RpY2UsIGFkZHJlc3MgZ2FwcyBpbiBjdXJyZW50 bHk8QlI+DQp1bmRlcnN0b29kIGJlc3QgcHJhY3RpY2VzIGZvciBmb3J3YXJkaW5nLCBjb250cm9s IHBsYW5lLCBhbmQgbWFuYWdlbWVudDxCUj4NCnBsYW5lIHNlY3VyaXR5IGFuZCBtYWtlIGNsZWFy IHRoZSBsaWFiaWxpdGllcyBpbmhlcmVudCBpbiBzZWN1cml0eTxCUj4NCnByYWN0aWNlcyB3aGVy ZSB0aGV5IGV4aXN0LjxCUj4NCjxCUj4NClNjb3BlOjxCUj4NCjxCUj4NClRoZSBzY29wZSBvZiB0 aGUgT1BTRUMgV0cgaXMgaW50ZW5kZWQgdG8gaW5jbHVkZSB0aGUgcHJvdGVjdGlvbiBhbmQ8QlI+ DQpzZWN1cmUgb3BlcmF0aW9uIG9mIFRoZSBGb3J3YXJkaW5nLCBDb250cm9sIGFuZCBNYW5hZ2Vt ZW50IHBsYW5lcy48QlI+DQo8QlI+DQpEb2N1bWVudGF0aW9uIG9mIGJlc3QgY29tbW9uIHByYWN0 aWNlcywgcmV2aXNpb24gb2YgZXhpc3RpbmcgcHJhY3RpY2VzPEJSPg0KZG9jdW1lbnRzIGFuZCBw cm9wb3NhbHMgZm9yIG5ldyBhcHByb2FjaGVzIHRvIG9wZXJhdGlvbmFsIGNoYWxsZW5nZXMgYXJl PEJSPg0KaW4gc2NvcGUuPEJSPg0KPEJSPg0KTWV0aG9kOjxCUj4NCjxCUj4NCkl0IGlzIGV4cGVj dGVkIHRoYXQgbW9zdCBvZiB0aGUgd29yayBwcm9kdWN0IG9mIHRoZSB3b3JraW5nIGdyb3VwIHdp bGw8QlI+DQpmYWxsIGludG8gdGhlIGNhdGVnb3J5IG9mIGN1cnJlbnQgcHJhY3RpY2VzIGRvY3Vt ZW50cy4gVGF4b25vbXkgb3I8QlI+DQpwcm9ibGVtIHN0YXRlbWVudCBkb2N1bWVudHMgbWF5IHBy b3ZpZGUgYSBiYXNpcyBmb3IgYmVzdCBjdXJyZW50PEJSPg0KcHJhY3RpY2VzIGRvY3VtZW50cy48 QlI+DQo8QlI+DQpCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIERvY3VtZW50PEJSPg0KPEJSPg0KQSBz aW5nbGUgZG9jdW1lbnQgd2lsbCBiZSBwcm9kdWNlZCB0aGF0IGF0dGVtcHRzIHRvIGNhcHR1cmU8 QlI+DQpjdXJyZW50IHByYWN0aWNlcyByZWxhdGVkIHRvIHNlY3VyZSBvcGVyYXRpb24uIFRoaXMg d2lsbCBiZTxCUj4NCnByaW1hcmlseSBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBlcmllbmNlLiBF YWNoIGVudHJ5IHdpbGw8QlI+DQpsaXN0OjxCUj4NCjxCUj4NCiogdGhyZWF0cyBhZGRyZXNzZWQs PEJSPg0KPEJSPg0KKiBjdXJyZW50IHByYWN0aWNlcyBmb3IgYWRkcmVzc2luZyB0aGUgdGhyZWF0 LDxCUj4NCjxCUj4NCiogcHJvdG9jb2xzLCB0b29scyBhbmQgdGVjaG5vbG9naWVzIGV4dGFudCBh dCB0aGUgdGltZSBvZiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxCUj4NCndyaXRpbmcg dGhhdCBhcmUgdXNlZCB0byBhZGRyZXNzIHRoZSB0aHJlYXQsPEJSPg0KPEJSPg0KKiB0aGUgcG9z c2liaWxpdHkgdGhhdCBhIHNvbHV0aW9uIGRvZXMgbm90IGV4aXN0IHdpdGhpbiBleGlzdGluZyB0 b29sczxCUj4NCm9yIHRlY2hub2xvZ2llcy48QlI+DQo8QlI+DQpUYXhvbm9teSBhbmQgUHJvYmxl bSBTdGF0ZW1lbnQgRG9jdW1lbnRzPEJSPg0KPEJSPg0KQSBkb2N1bWVudCB3aGljaCBhdHRlbXB0 cyB0byBkZXNjcmliZSB0aGUgc2NvcGUgb2YgcGFydGljdWxhcjxCUj4NCm9wZXJhdGlvbmFsIHNl Y3VyaXR5IGNoYWxsZW5nZSBvciBwcm9ibGVtIHNwYWNlIHdpdGhvdXQgbmVjZXNzYXJpbHk8QlI+ DQpjb21pbmcgdG8gYSBjb25jbHVzaW9uIG9yIHByb3Bvc2luZyBhIHNvbHV0aW9uLiBTdWNoIGEg ZG9jdW1lbnQgbWlnaHQgYmU8QlI+DQphIHByZWN1cnNvciB0byBhJm5ic3A7IGJlc3QgY29tbW9u IHByYWN0aWNlcyBkb2N1bWVudC48QlI+DQo8QlI+DQpUaGUgd29yayBwcm9kdWN0IG9mIHRoZSB3 b3JraW5nIGdyb3VwIGlzIGludGVuZGVkIHByaW5jaXBhbGx5IGZvciB0aGU8QlI+DQpiZW5lZml0 IG9mIG5ldHdvcmsgb3BlcmF0b3JzIHJhdGhlciB0aGFuIGVxdWlwbWVudCB2ZW5kb3JzIG9yIHBy b3RvY29sPEJSPg0KZGV2ZWxvcGVycy48QlI+DQo8QlI+DQpOb24tR29hbHM6PEJSPg0KPEJSPg0K VGhlIE9wZXJhdGlvbnMgc2VjdXJpdHkgd29ya2luZyBncm91cCBpcyBub3QgdGhlIHBsYWNlIHRv IGRvIG5ldzxCUj4NCnByb3RvY29scyBvciByZXF1aXJlbWVudHMgZG9jdW1lbnRzLjxCUj4NCjxC Uj4NCk5ldyBwcm90b2NvbCBkZXZlbG9wbWVudCBvciByZXF1aXJlbWVudHMgd29yayBzaG91bGQg YmUgYWRkcmVzc2VkIGluIGE8QlI+DQp3b3JraW5nIGdyb3VwIGNoYXJ0ZXJlZCBpbiB0aGUgYXBw cm9wcmlhdGUgYXJlYSBvciBhcyBpbmRpdmlkdWFsPEJSPg0Kc3VibWlzc2lvbnMuIFRoZSBPUFNF QyBXRyBtYXkgdGFrZSBvbiBkb2N1bWVudHMgcmVsYXRlZCB0bzxCUj4NCnRoZSBwcmFjdGljZXMg b2YgdXNpbmcgc3VjaCB3b3JrLjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KT1BTRUMgbWFpbGlu ZyBsaXN0PEJSPg0KT1BTRUNAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYyI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb3BzZWM8L0E+PEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KVGhpcyBjb21tdW5p Y2F0aW9uIGlzIHRoZSBwcm9wZXJ0eSBvZiBRd2VzdCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yPEJSPg0KcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0 aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHk8QlI+DQpwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbjxC Uj4NCmluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVw bHkgZS1tYWlsIGFuZCBkZXN0cm95PEJSPg0KYWxsIGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlv biBhbmQgYW55IGF0dGFjaG1lbnRzLjxCUj4NCjxCUj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KT1BTRUMgbWFpbGluZyBsaXN0PEJSPg0KT1BT RUNAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vcHNlYyI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3Bz ZWM8L0E+PEJSPg0KPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C8489C.BC291615-- --===============0075915450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec --===============0075915450==-- From opsec-bounces@ietf.org Thu Dec 27 14:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7yO6-0005IJ-BV; Thu, 27 Dec 2007 14:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7yO5-0005ID-3R for opsec@ietf.org; Thu, 27 Dec 2007 14:27:25 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7yO4-0007eV-LA for opsec@ietf.org; Thu, 27 Dec 2007 14:27:25 -0500 Received: from [192.168.66.51] ([65.102.159.229]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id lBRJRLl0005269 for ; Thu, 27 Dec 2007 11:27:21 -0800 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <20071227134639.44F65136C82@aharp.ittns.northwestern.edu> References: <47720011.8010703@bogus.com> <20071227134639.44F65136C82@aharp.ittns.northwestern.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6606344C-4564-40D8-B55E-1F4544C35453@doubleshotsecurity.com> Content-Transfer-Encoding: 7bit From: Merike Kaeo Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... Date: Thu, 27 Dec 2007 11:32:36 -0800 To: opsec wg mailing list X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Agree with the hard to codify. But I'd be willing to explore more what makes sense for performance testing and could be reasonable to codify........performance limitations are always a pain since no vendor will ever want to disclose limitations..........note that in 1993/1994 I was responsible for performance testing for a major router vendor........the games I saw.......sigh. But as George pointed out, this sort of performance benchmarking work really does belong in the benchmark methodology wg. I participate in that wg......happy to help if needed. - merike On Dec 27, 2007, at 5:46 AM, John Kristoff wrote: > On Wed, 26 Dec 2007 11:23:06 -0700 > "Smith, Donald" wrote: > >> Recommending a specific ICMP rate limiting level without >> discussing how to test the network elements that the rate limits >> would be applied to is likely to lead to operations issues. >> > > Even still there are likely going to be problems in some > configurations. > Just as a for instance, if you rate limit to 1 Mb/s at each edge, and > also have the same limit somewhere upstream, any one edge can fill > that > upstream limit. Probably not what you want. Very tricky to codify > hard > and fast rules here. > > John > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 28 08:05:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8EuF-0006eP-Uj; Fri, 28 Dec 2007 08:05:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8EuD-0006e5-V5 for opsec@ietf.org; Fri, 28 Dec 2007 08:05:41 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8EuB-0003pc-Kg for opsec@ietf.org; Fri, 28 Dec 2007 08:05:41 -0500 Received: by nz-out-0506.google.com with SMTP id n1so652435nzf.4 for ; Fri, 28 Dec 2007 05:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=CwrADWjYLVmk8vckx/h+mhfUdXWcekAenwOSA2ZiAb0=; b=VjLVoowiE2/R7wVGbw9S7Rd5iGMFgNbC5KpkVhba2VTAvNQop6xiunB++4J6ODNXz0fsq/TF1RZf7iG9Z96K6ExS7tJ8O3GIzDs4/15pninFyrxCpn1BJt+NvYF2Cb18hYaM9L3vHgqloHVBoBifUPqENImUbIeD7WZ5Um5Rcxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dcdzJJZQyD0JGUjaTH/3VcmIDirVZE0V/7d7e6Kf0E1ktiuz9kF/pJqpPexSrH6RVQYbtrthYRZs3aHsIRAfy0HennTUfWs+lVC+bSOq2MzDxQ2j5weieuCqGoepextn8cHZ0p4QAxnSsU56k4wrIueqcYs2Oezw3x+l/XCUJZU= Received: by 10.142.212.19 with SMTP id k19mr2940064wfg.66.1198847138578; Fri, 28 Dec 2007 05:05:38 -0800 (PST) Received: from ?192.168.1.2? ( [24.125.228.78]) by mx.google.com with ESMTPS id 8sm11637339wra.28.2007.12.28.05.05.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Dec 2007 05:05:37 -0800 (PST) Message-ID: <4774F49F.6040202@gmail.com> Date: Fri, 28 Dec 2007 08:05:35 -0500 From: George Jones User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: opsec wg mailing list , Tina Bird Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... References: <47720011.8010703@bogus.com> <477292C0.1090504@juniper.net> In-Reply-To: <477292C0.1090504@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Ron Bonica wrote: > Joel, > > This looks very good. I have picked a few nits below, but they are all > grammar issues. > > The one thing that we are lacking is a list of deliverables. I think > that we have reached agreement on an ICMP filtering document. Can we > think of any others? > Talk to Tina Bird about logging. I think she's actively hacking her wiki aimed a the "What is being logged/what should be logged" question. Also see the skeleton that I just sent you about creating a list of vulnerabilities in common ports....think a very abbreviated IANA ports list with cross reference to to vulnerabilities lists (CVE?)...kind of a security hitchhikers guide to ports. ---George _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 28 09:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8GJi-0002Xd-I1; Fri, 28 Dec 2007 09:36:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8GJh-0002Vf-C0 for opsec@ietf.org; Fri, 28 Dec 2007 09:36:05 -0500 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8GJf-0005br-PA for opsec@ietf.org; Fri, 28 Dec 2007 09:36:05 -0500 Received: by dog.tcb.net (Postfix, from userid 0) id 78D1926848E; Fri, 28 Dec 2007 07:36:03 -0700 (MST) Received: from [192.168.1.7] (VDSL-151-118-144-88.DNVR.QWEST.NET [151.118.144.88]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for opsec@ietf.org; Fri, 28 Dec 2007 07:36:03 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.144.88; client-port=18500; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <47720011.8010703@bogus.com> References: <47720011.8010703@bogus.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... Date: Fri, 28 Dec 2007 07:35:47 -0700 To: opsec wg mailing list X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org On Dec 26, 2007, at 12:17 AM, Joel Jaeggli wrote: > > The OPSEC WG will document best current practices with regard to > network > security. In particular an effort will be made to clarify the reasons > behind current operational practice, address gaps in currently > understood best practices for forwarding, control plane, and > management > plane security and make clear the liabilities inherent in security > practices where they exist. What does that mean, "make clear the liabilities inherent in security practices where they exist"? Are you talking about gap analysis there or something else? > Scope: > > The scope of the OPSEC WG is intended to include the protection and > secure operation of The Forwarding, Control and Management planes. > > Documentation of best common practices, revision of existing practices s/existing practices/existing operational security practices/ > documents and proposals for new approaches to operational > challenges are > in scope. > > Method: > > It is expected that most of the work product of the working group will > fall into the category of current practices documents. Taxonomy or > problem statement documents may provide a basis for best current > practices documents. > > Best Current Practices Document > > A single document will be produced that attempts to capture > current practices related to secure operation. I'm a bit confused by the "a single document" bit here, what do you mean by this? A single document for each threat set, each 'plane', or something else? And either way, why would we unnecessarily scope to a single document? > This will be > primarily based on operational experience. Each entry will > list: > > * threats addressed, > > * current practices for addressing the threat, > > * protocols, tools and technologies extant at the time of > writing that are used to address the threat, Could 'extant' be augmented with envisioned here? Given the 'Scope' section above, 'proposals for new approaches' are explicitly within scope. > * the possibility that a solution does not exist within existing tools > or technologies. > > Taxonomy and Problem Statement Documents > > A document which attempts to describe the scope of particular > operational security challenge or problem space without necessarily > coming to a conclusion or proposing a solution. Such a document > might be > a precursor to a best common practices document. > > The work product of the working group is intended principally for the > benefit of network operators rather than equipment vendors or protocol > developers. I'm not sure the above sentence actually holds true. I believe that by compiling a list of functions or BCPs that seem to be common among WG participants, operators in particular, that 'equipment vendors' benefit from the output of that document by knowing where to focus, with referencable discussions and WG product. I suspect this text is perhaps aimed more at encouraging operators to participate, but it'd seem to me this should be implicit already. > Non-Goals: > > The Operations security working group is not the place to do new > protocols or requirements documents. > > New protocol development or requirements work should be addressed in a > working group chartered in the appropriate area or as individual > submissions. The OPSEC WG may take on documents related to > the practices of using such work. I think it's perfectly reasonable (desirable?) for OPSEC to provide requirements to other WGs, be it folks like BMWG or folks designing protocols. Perhaps the above text should allude to this. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 28 13:05:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8JZz-0004hm-Mb; Fri, 28 Dec 2007 13:05:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8JZx-0004hb-Tx for opsec@ietf.org; Fri, 28 Dec 2007 13:05:05 -0500 Received: from sudnp799.qwest.com ([155.70.32.99]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8JZx-0006vA-De for opsec@ietf.org; Fri, 28 Dec 2007 13:05:05 -0500 Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id lBSI54fH026731 for ; Fri, 28 Dec 2007 11:05:04 -0700 (MST) Received: from ITDENE2KSM01.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id lBSI4wNT004880 for ; Fri, 28 Dec 2007 12:04:59 -0600 (CST) Received: from ITDENE2KM02.AD.QINTRA.COM ([10.1.4.66]) by ITDENE2KSM01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 11:04:59 -0700 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPSEC] charter skeleton rev4 - your thoughts requested... Date: Fri, 28 Dec 2007 11:01:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] charter skeleton rev4 - your thoughts requested... thread-index: AchIvpFe5lu3a0CJQi2xpAj2JLM8SAAvRfd0 Importance: normal Priority: normal References: <47720011.8010703@bogus.com><20071227134639.44F65136C82@aharp.ittns.northwestern.edu> <6606344C-4564-40D8-B55E-1F4544C35453@doubleshotsecurity.com> From: "Smith, Donald" To: "opsec wg mailing list" , "opsec wg mailing list" X-OriginalArrivalTime: 28 Dec 2007 18:04:59.0065 (UTC) FILETIME=[28E0C290:01C8497C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org I agree the testing methodology probably belongs on the benchmarking = group wg. However in order to arrive at a non-production impacting level = of ratelimiting some mention of testing should be made here too. Ideally we would be able to point to a document that described the = testing methods and goals that is being done by the benchmarking WG. The closest document I see to that right now are the stress testing = documents. =20 =20 =20 donald.smith@qwest.com giac ________________________________ From: Merike Kaeo [mailto:merike@doubleshotsecurity.com] Sent: Thu 12/27/2007 12:32 PM To: opsec wg mailing list Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... Agree with the hard to codify. But I'd be willing to explore more=20 what makes sense for performance testing and could be reasonable to=20 codify........performance limitations are always a pain since no=20 vendor will ever want to disclose limitations..........note that in=20 1993/1994 I was responsible for performance testing for a major=20 router vendor........the games I saw.......sigh. But as George pointed out, this sort of performance benchmarking work=20 really does belong in the benchmark methodology wg. I participate=20 in that wg......happy to help if needed. - merike On Dec 27, 2007, at 5:46 AM, John Kristoff wrote: > On Wed, 26 Dec 2007 11:23:06 -0700 > "Smith, Donald" wrote: > >> Recommending a specific ICMP rate limiting level without=20 >> discussing how to test the network elements that the rate limits=20 >> would be applied to is likely to lead to operations issues. >> > > Even still there are likely going to be problems in some=20 > configurations. > Just as a for instance, if you rate limit to 1 Mb/s at each edge, and > also have the same limit somewhere upstream, any one edge can fill=20 > that > upstream limit. Probably not what you want. Very tricky to codify=20 > hard > and fast rules here. > > John > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.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=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 28 16:53:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8N8y-0000ms-LK; Fri, 28 Dec 2007 16:53:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8N8x-0000mm-W3 for opsec@ietf.org; Fri, 28 Dec 2007 16:53:27 -0500 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8N8x-0006fg-Ba for opsec@ietf.org; Fri, 28 Dec 2007 16:53:27 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2560948rvb.49 for ; Fri, 28 Dec 2007 13:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=nkj38HZ1SzHNJg+VNKK/Sn6aantU0E0jJoBvtzsJFak=; b=TiAKvtZPwA09Q5YR+XA4FABa2L3cqM3A9McSNWgbBDqrBOV2k7icWxGfC1hm5/rWsKeXh8j/NmED08H5xEGs6tMUkQ/+tWhmphpdFMLvN2/A0nltG/8D77Dm07CPUlo8t9MRZoL9orP7ZeM6wdBV7w0BNbzvSJPIq2n5UpzhjQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SurPz38z7nvxnIvQ78L1fKUOGzi3v9LEtG5XSEeR8EHiLN/LkXhYg+6T4+BDV0iQsgoTcVheojG93zLfMAc4xX2Dp0GXVVLqtMhFdIagL3bKmeb2YbsEXIBQ2CB3mffAOMsG4X8IxEIeZMXoxD5zmRjSkUN3RKZZGNb4rhk9OGc= Received: by 10.141.169.9 with SMTP id w9mr5040978rvo.179.1198878800185; Fri, 28 Dec 2007 13:53:20 -0800 (PST) Received: from ?192.168.1.2? ( [24.125.228.78]) by mx.google.com with ESMTPS id g9sm15326615wra.6.2007.12.28.13.53.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Dec 2007 13:53:19 -0800 (PST) Message-ID: <4775704A.3000103@gmail.com> Date: Fri, 28 Dec 2007 16:53:14 -0500 From: George Jones User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: opsec wg mailing list Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... References: <47720011.8010703@bogus.com><20071227134639.44F65136C82@aharp.ittns.northwestern.edu> <6606344C-4564-40D8-B55E-1F4544C35453@doubleshotsecurity.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org Smith, Donald wrote: > I agree the testing methodology probably belongs on the benchmarking group wg. However in order to arrive at a non-production impacting level of ratelimiting some mention of testing should be made here too. > Ideally we would be able to point to a document that described the testing methods and goals that is being done by the benchmarking WG. > The closest document I see to that right now are the stress testing documents. > RIght. I talked to Scott Poretsky about these a while back and gave some input. We should defiantly get their input on the charter and testing aspects of documents. ---George > > > > donald.smith@qwest.com giac > > ________________________________ > > From: Merike Kaeo [mailto:merike@doubleshotsecurity.com] > Sent: Thu 12/27/2007 12:32 PM > To: opsec wg mailing list > Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested... > > > > Agree with the hard to codify. But I'd be willing to explore more > what makes sense for performance testing and could be reasonable to > codify........performance limitations are always a pain since no > vendor will ever want to disclose limitations..........note that in > 1993/1994 I was responsible for performance testing for a major > router vendor........the games I saw.......sigh. > > But as George pointed out, this sort of performance benchmarking work > really does belong in the benchmark methodology wg. I participate > in that wg......happy to help if needed. > > - merike > > On Dec 27, 2007, at 5:46 AM, John Kristoff wrote: > > >> On Wed, 26 Dec 2007 11:23:06 -0700 >> "Smith, Donald" wrote: >> >> >>> Recommending a specific ICMP rate limiting level without >>> discussing how to test the network elements that the rate limits >>> would be applied to is likely to lead to operations issues. >>> >>> >> Even still there are likely going to be problems in some >> configurations. >> Just as a for instance, if you rate limit to 1 Mb/s at each edge, and >> also have the same limit somewhere upstream, any one edge can fill >> that >> upstream limit. Probably not what you want. Very tricky to codify >> hard >> and fast rules here. >> >> John >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www1.ietf.org/mailman/listinfo/opsec >> >> > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/opsec > > > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/opsec > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Dec 30 03:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8tLt-0006Ve-Df; Sun, 30 Dec 2007 03:16:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8tLr-0006VZ-Rw for opsec@ietf.org; Sun, 30 Dec 2007 03:16:55 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8tLr-0006YN-Hs for opsec@ietf.org; Sun, 30 Dec 2007 03:16:55 -0500 X-IronPort-AV: E=Sophos;i="4.24,222,1196658000"; d="scan'208";a="95123857" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Dec 2007 03:16:52 -0500 X-IronPort-AV: E=Sophos;i="4.24,222,1196658000"; d="scan'208";a="145268605" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Dec 2007 03:16:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPSEC] charter skeleton rev4 - your thoughts requested... Date: Sun, 30 Dec 2007 09:16:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] charter skeleton rev4 - your thoughts requested... Thread-Index: AchJXwqJYGchW5s1Rnikdy6FaNkM1gBXMEQg References: <47720011.8010703@bogus.com> From: "Romascanu, Dan (Dan)" To: "opsec wg mailing list" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: opsec wg mailing list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsec-bounces@ietf.org =20 =20 > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net]=20 > > > > The work product of the working group is intended=20 > principally for the=20 > > benefit of network operators rather than equipment vendors=20 > or protocol=20 > > developers. >=20 > I'm not sure the above sentence actually holds true. I=20 > believe that by compiling a list of functions or BCPs that=20 > seem to be common among WG participants, operators in=20 > particular, that 'equipment vendors' benefit from the output=20 > of that document by knowing where to focus, with referencable=20 > discussions and WG product. I suspect this text is perhaps=20 > aimed more at encouraging operators to participate, but it'd=20 > seem to me this should be implicit already. >=20 I agree with Danny here. While the principal input of the Working Group are operational experience and needs, the output should be I think directed both to provide guidance to the operators community as well as to Working Groups that develop protocols or the community of protocol developers at large, as well as to the implementers of these protocols, many of them working for 'equipment vendors'.=20 Dan _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/opsec