From loa@pi.nu Tue Aug 2 14:31:57 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B132F11E80CC; Tue, 2 Aug 2011 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UM-5mN7+c8J; Tue, 2 Aug 2011 14:31:56 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7F74C11E80C5; Tue, 2 Aug 2011 14:31:55 -0700 (PDT) Received: from [10.154.181.21] (unknown [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 26F5C514044; Tue, 2 Aug 2011 23:32:02 +0200 (CEST) Message-ID: <4E386CF0.5050700@pi.nu> Date: Tue, 02 Aug 2011 14:32:32 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, rtg-dir@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:31:57 -0000 Hello, I have been selected as the Routing Directorate reviewer for draft-ietf-pwe3-fat-pw-07. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pwe3-fat-pw-07 Reviewer: Loa Andersson Review Date: 2 Aug 2011 IETF LC End Date: 3 Aug 2011 Intended Status: Standards Track Summary: I have no major concerns about this document, howver I thing it would be good to reslove the mostly editorial comments below (especially on the IANA section) before publication. Comments: Unexpanded acronyms: OAM appears in the table of content and as header 7. It is not expanded in the document anywhere. Should be done at first occurance. page 6. The last paragraph of section 1 talks about TC bits (and EXP bits). We don't have TC bits - the correct name is TC field. First paragraph section three: This paragraph talks in genral about "load balanced paths" while the rest of the document is very specific about ECMP, it is the intention that this should work for any load balancing paradigm? Second paragraph section three: Normally a label is assigned by the down stream node, this scheme is doing upstream allocation. Don't see a problem under normal operation, but if the label "by accident" becomes top of stack this could have "interesting" effects. Sectyion 4 second paagraph: OLD The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. A PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. A PE that is using PW signalling and which does not receive a FL Sub- TLV from its peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. NEW The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. An ingress PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. An ingress PE that is using PW signalling and which does not receive a FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. The IANA section: In the IANA section we should use a TBD entry for the Flow label indicator; and maybe add 0x17 as suggest value in the text. The text in the IANA section needs to aligned with the rest of the text, or maybe even better have the rest of the text align with the IANA section; e.g. Flow Labe intdicator is not used anywhere else but in the iana section. To make it easier to find the references to the IANA registries should start with "Pseudowire Name Spaces (PWE3)" point to "Pseudowire Interface Parameters Sub-TLV type Registry" as a sub-registry, and ask for assigment of the next free value from the Experts review space (suggested value 0x17). On the other hand it looks like we have an early assigment (Flow Label shows up with the value 0x17). If this is the case after making the text changes suggest above this should be mentioned in the IANA section. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From adrian@olddog.co.uk Thu Aug 4 06:34:13 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF60C21F8AA8 for ; Thu, 4 Aug 2011 06:34:13 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnur0r6bSXZd for ; Thu, 4 Aug 2011 06:34:13 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 267F121F8A95 for ; Thu, 4 Aug 2011 06:34:13 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p74DY30f004291; Thu, 4 Aug 2011 14:34:03 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p74DY18C004260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 14:34:02 +0100 From: "Adrian Farrel" To: Date: Thu, 4 Aug 2011 14:34:02 +0100 Message-ID: <01e901cc52ab$2d5c2300$88146900$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxSqs9kX/ErwcRdSH2qq3hx4/rfEg== Content-Language: en-gb Cc: Dan Li , db3546@att.com Subject: [RTG-DIR] A draft to look at : draft-doria-genart-experience X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:34:14 -0000 Hi Routing Dir. Not asking for a review! You might be interested in this document. Cheers, Adrian > ID Tracker URL: http://datatracker.ietf.org/doc/draft-doria-genart-experience/ From loa@pi.nu Thu Aug 4 10:45:27 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A666921F8AE1; Thu, 4 Aug 2011 10:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj2fFaVsIE7k; Thu, 4 Aug 2011 10:45:27 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC921F8AD6; Thu, 4 Aug 2011 10:45:26 -0700 (PDT) Received: from [10.154.181.21] (unknown [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C3D79514044; Thu, 4 Aug 2011 19:45:37 +0200 (CEST) Message-ID: <4E3ADAE2.5060907@pi.nu> Date: Thu, 04 Aug 2011 10:46:10 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org References: <4E386CF0.5050700@pi.nu> In-Reply-To: <4E386CF0.5050700@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, pwe3@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:45:27 -0000 All, I have one more point on this - I should have captured it in the previous mail but had to think and discuss a bit about it! Doing ECMP hashing over the label stack as described is OK, but has one thing that needs to be taken care of. Introducing a reserved label - most prominently the GAL - into the label stack will change the outcome of the hash. Since we are ECMP-ing on the hash result, we will no longer to be able to guarantee that normal traffic and OAM packets will no longer be fate sharing - draft-ietf-pwe3-fat-pw should say explicitly that reserved labels should be excluded from ECMP hashing. /Loa On 2011-08-02 14:32, Loa Andersson wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for > draft-ietf-pwe3-fat-pw-07. > > The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-pwe3-fat-pw-07 > Reviewer: Loa Andersson > Review Date: 2 Aug 2011 > IETF LC End Date: 3 Aug 2011 > Intended Status: Standards Track > > Summary: > I have no major concerns about this document, howver I thing it > would be good to reslove the mostly editorial comments below > (especially on the IANA section) before publication. > > Comments: > > Unexpanded acronyms: > > OAM appears in the table of content and as header 7. It is not > expanded in the document anywhere. Should be done at first occurance. > > page 6. The last paragraph of section 1 talks about TC bits > (and EXP bits). We don't have TC bits - the correct name is TC field. > > First paragraph section three: > This paragraph talks in genral about "load balanced paths" while the > rest of the document is very specific about ECMP, it is the intention > that this should work for any load balancing paradigm? > > Second paragraph section three: > Normally a label is assigned by the down stream node, this scheme > is doing upstream allocation. Don't see a problem under normal > operation, but if the label "by accident" becomes top of stack > this could have "interesting" effects. > > Sectyion 4 second paagraph: > > OLD > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. A PE that is using PW signalling and that does > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > A PE that is using PW signalling and which does not receive a FL Sub- > TLV from its peer MUST NOT include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > NEW > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. An ingress PE that is using PW signalling > and that does not send a FL Sub-TLV MUST NOT include a flow label > in the PW packet. An ingress PE that is using PW signalling and > which does not receive a FL Sub-TLV from its egress peer MUST NOT > include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > The IANA section: > > In the IANA section we should use a TBD entry for the Flow label > indicator; and maybe add 0x17 as suggest value in the text. > > The text in the IANA section needs to aligned with the rest of > the text, or maybe even better have the rest of the text align > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > else but in the iana section. > > To make it easier to find the references to the IANA registries > should start with "Pseudowire Name Spaces (PWE3)" point to > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > sub-registry, and ask for assigment of the next free value from > the Experts review space (suggested value 0x17). > > On the other hand it looks like we have an early assigment > (Flow Label shows up with the value 0x17). If this is the case > after making the text changes suggest above this should be mentioned > in the IANA section. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From jdrake@juniper.net Thu Aug 4 11:18:23 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530EF21F88A5; Thu, 4 Aug 2011 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SMZmW6TbMuq; Thu, 4 Aug 2011 11:18:22 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C89C421F88A1; Thu, 4 Aug 2011 11:18:21 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTjric1AOxm8Dhb3Ut/uIHpXFLwD1ayaq@postini.com; Thu, 04 Aug 2011 11:18:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 4 Aug 2011 10:58:50 -0700 From: John E Drake To: Loa Andersson , "rtg-ads@tools.ietf.org" Date: Thu, 4 Aug 2011 10:58:47 -0700 Thread-Topic: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 Thread-Index: AcxSzlfOoejrgvVqTzS/vqt7j3CKxQAAZu6A Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCCEE@EMBX01-HQ.jnpr.net> References: <4E386CF0.5050700@pi.nu> <4E3ADAE2.5060907@pi.nu> In-Reply-To: <4E3ADAE2.5060907@pi.nu> 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: Kireeti Kompella , "rtg-dir@ietf.org" , "pwe3@ietf.org" , "draft-ietf-pwe3-fat.all@tools.ietf.org" Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:18:23 -0000 Loa, This statement will also be added to the next version of the entropy label = I-D. Thanks, John Sent from my iPhone > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Thursday, August 04, 2011 10:46 AM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; pwe3@ietf.org; draft-ietf-pwe3- > fat.all@tools.ietf.org > Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 >=20 > All, >=20 >=20 > I have one more point on this - I should have captured it in > the previous mail but had to think and discuss a bit about it! >=20 > Doing ECMP hashing over the label stack as described is OK, but > has one thing that needs to be taken care of. Introducing a > reserved label - most prominently the GAL - into the label > stack will change the outcome of the hash. Since we are ECMP-ing > on the hash result, we will no longer to be able to guarantee > that normal traffic and OAM packets will no longer be fate > sharing - draft-ietf-pwe3-fat-pw should say explicitly that > reserved labels should be excluded from ECMP hashing. >=20 > /Loa >=20 > On 2011-08-02 14:32, Loa Andersson wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for > > draft-ietf-pwe3-fat-pw-07. > > > > The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review > > is to provide assistance to the Routing ADs. For more information > > about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: draft-ietf-pwe3-fat-pw-07 > > Reviewer: Loa Andersson > > Review Date: 2 Aug 2011 > > IETF LC End Date: 3 Aug 2011 > > Intended Status: Standards Track > > > > Summary: > > I have no major concerns about this document, howver I thing it > > would be good to reslove the mostly editorial comments below > > (especially on the IANA section) before publication. > > > > Comments: > > > > Unexpanded acronyms: > > > > OAM appears in the table of content and as header 7. It is not > > expanded in the document anywhere. Should be done at first occurance. > > > > page 6. The last paragraph of section 1 talks about TC bits > > (and EXP bits). We don't have TC bits - the correct name is TC field. > > > > First paragraph section three: > > This paragraph talks in genral about "load balanced paths" while the > > rest of the document is very specific about ECMP, it is the intention > > that this should work for any load balancing paradigm? > > > > Second paragraph section three: > > Normally a label is assigned by the down stream node, this scheme > > is doing upstream allocation. Don't see a problem under normal > > operation, but if the label "by accident" becomes top of stack > > this could have "interesting" effects. > > > > Sectyion 4 second paagraph: > > > > OLD > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. A PE that is using PW signalling and that does > > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > > A PE that is using PW signalling and which does not receive a FL Sub- > > TLV from its peer MUST NOT include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > NEW > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. An ingress PE that is using PW signalling > > and that does not send a FL Sub-TLV MUST NOT include a flow label > > in the PW packet. An ingress PE that is using PW signalling and > > which does not receive a FL Sub-TLV from its egress peer MUST NOT > > include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > The IANA section: > > > > In the IANA section we should use a TBD entry for the Flow label > > indicator; and maybe add 0x17 as suggest value in the text. > > > > The text in the IANA section needs to aligned with the rest of > > the text, or maybe even better have the rest of the text align > > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > > else but in the iana section. > > > > To make it easier to find the references to the IANA registries > > should start with "Pseudowire Name Spaces (PWE3)" point to > > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > > sub-registry, and ask for assigment of the next free value from > > the Experts review space (suggested value 0x17). > > > > On the other hand it looks like we have an early assigment > > (Flow Label shows up with the value 0x17). If this is the case > > after making the text changes suggest above this should be mentioned > > in the IANA section. >=20 > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From Alexander.Vainshtein@ecitele.com Sat Aug 6 13:45:59 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3B21F863E for ; Sat, 6 Aug 2011 13:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ewjt+D0GucY for ; Sat, 6 Aug 2011 13:45:49 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 72DAE21F8639 for ; Sat, 6 Aug 2011 13:45:46 -0700 (PDT) X-AuditID: 93eaf2e7-b7b44ae000002b74-87-4e3da8043267 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id A1.77.11124.408AD3E4; Sat, 6 Aug 2011 23:45:56 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 6 Aug 2011 23:46:02 +0300 From: Alexander Vainshtein To: "'rtg-ads@tools.ietf.org'" Date: Sat, 6 Aug 2011 23:45:56 +0300 Thread-Topic: RTG-DIR Review: draft-ietf-opsawg-oam-overview-05.txt Thread-Index: AcxUedbkWiz51hHjSGiJW/+W82QZLA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76ECD4BBF2E2ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTmzsyuozk1rW57034skwiVKy4WrbRjRQX1owcWFf2oxtnr7tTu zLAzahtG/uphYg8jSiS1xEeagpj0sFArKisyJIrKMLMke6EuRULajJMmRPfXd8/3ne+cezmH xC2/zHGkIKooKHJ+xhxFFA8Ohx1EDbsh5WhtoquzoRi4BkrPEa7y+vcRK/C1lZU/sbXh7hHz JmxHPnBzoiipnIrsHqTwLLMpKORwfIixCx6WcTJ22c/xKIBElWU4WUaih0mPsv9z3JpMEO1I 5CWPIHpZZt3mjQ6Xa0maw8mkJ853pi6L2uITFDtyBDjBbw8gReG8yK5FdjfjvqejXZhcXWza VzQyiueD07eIAkCSkF4Mw51kAYjU4BzY9abRXACiSAt9E8CWcC1mXIoBLD3UDnSVmWZhU12P Wcex9FJ4u+3MRAZOlwJYcahwQkTQCbDsQgOh4xg6HebXtJqMhFXw2ovLhIGT4ZOu8xE6puiN 8Nv1ugkMtDZ+dNZjOsZpG3zZX4YZ7dGwsvUJbmAr/PhuzGTorfD14UagvwanJVh1/I/lbPjg XD9hyOfC9poXxAkQWzLNteRvRsm0DEOSBMtvDJsNvAhWVXzCJ/GjtnfY9Hg5iLgErIJfVjMD 3hRnMuIFFflRMi8FmoAxKQNXwWhZQgegScBEU3Ieu8Fi4nKUUKADzCUxxkodrtRCMzMlT8jH Kb5dwWw/UjoAJHEmllrJaxzl4UL7UVCapNZof3wSj5vBS9pMiuqu1JSU/18YG/We/7zeQnu1 EdyLkIyCkz7zSJKB1JlqrcTsIPKifVmCX/1LY2Sk3ka01sbCKr0NReYCiuA1+E6QSl4eGroL yPuD4bvAQoiSiOJsVJVuR+tSX7Y45aZvzcHx8fFBYNO+IYY6rauitZ2a8hvUSmFaqUC/Wy+l LcwUFZcPtr9aN9SdlrVt5ocVGUl5F5YpO3Nyz/ZEzpL2RvTs+FDX+yU1oVfte/P8W9GqGY1L +uinV5Y/upho6v089gUPDYy5bM15zbkXzx5bHd9W1F+0JzseL3R8LexusS7Y/TCLjd568EjM 9/SWWnfGenzs3qn4Z+LoNbbPXfH47cs7t+UD8hGGUHyccyEeVLjfUpt+ABAEAAA= Cc: "'rtg-dir@ietf.org'" , "'drafts-ietf-opsawg-oam-overview.all@tools.ietf.org'" Subject: [RTG-DIR] RTG-DIR Review: draft-ietf-opsawg-oam-overview-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 20:45:59 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76ECD4BBF2E2ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The= Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review. The purpose of the revie= w is to provide assistance to the Routing ADs. For more information about th= e Routing Directorate, please see http://www.ietf.org/iesg/directorate/routi= ng.html Although these comments are primarily for the use of the Routing ADs, it wou= ld be helpful if you could consider them along with any other IETF Last Call= comments that you receive, and strive to resolve them through discussion or= by updating the draft. Document: draft-ietf-opsawg-oam-overview-05.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 06-Aug-11 IETF LC End Date: 20-Jul-11 (?) Intended status: Informational Summary: I have significant concerns about this document and recommend that the Routi= ng ADs discuss these issues further with the authors. To some extent these concerns reflect my personal and potentially biased pos= ition with regard to OAM. So I would like the Routing ADs to take them with= a grain of salt. In the process of review I've maintained private discussions with one of the= draft authors (Nurit), and we've advanced in resolving some of the issues.= Unfortunately, due to conflicting schedules, this process has not been comp= leted. Comments: My concerns with the draft start from the question about its target audience= . I have assumes (possibly, incorrectly), that the purpose of this draft is= to provide guidance to OAM in IP, IP/MPLS and MPLS-TP networks to various "= beginners" groups (including people who have experience with OAM in SONET/SD= H, ATM and OTN networks), while "IETF gurus" would hardly need it anyway (= IETF Area Directors, WG chairs and reviewers for various Directorates are ex= cluded:)). Such guidance would be really useful because OAM-related issues a= re at the core of multiple discussions raging on some IETF mailing lists for= the last several years. IMHO and FWIW, in order to provide guidance to what I expected to be the ta= rget audience, the draft should: * Include a "Historical Background" session. A single sentence in Secti= on 1 ("OAM was originally used in the world of telephony, and has been adopt= ed in packet based networks") is hardly sufficient IMHO * Present a clear view of OAM functionality and its relationship to vario= us "planes" of networking (data plane, control plane, management plane). In= particular, the importance of fate-sharing of OAM and user traffic flows in= packet networks should be explained * Explicitly map the notions, terms and methods that have been adopted = from technologies owned by ITU-T and/or IEEE to IETF-owned technologies. = When such a mapping is not possible, it should be explicitly stated * Expose, rather than avoid, known points of contention regarding variou= s OAM-related issues, preferably without explicitly taking sides. The draft did not meet my expectations in this regard. This may be because m= y expectations have been exaggerated or even completely unrealistic, or be= cause the authors had in mind a different target audience and a different pu= rpose. At the very least, explicitly specifying these (the purpose and the t= arget audience) in the Introduction section would be helpful. Instead the draft looks to me like a long (but incomplete) annotated list of= references to IETF and non-IETF protocols and mechanisms that deal with cer= tain aspects of OAM in IP, IP/MPLS, MPLS-TP and Ethernet networks. The guid= ing principle behind selection of the referenced protocols and mechanisms is= not defined in the draft and from my point of view, is questionable, e.g.: * Why is the defunct ITU-T Y.1711 considered in detail, while ITU-T I.= 610 (which has been implemented by virtually all the vendors of ATM equipmen= t) is not even mentioned? * Why is IEEE 802.3ah included, while E-LMI (defined by MEF) is not? A= nd what are their analogs (if any) in IETF-owned technologies? * Why MPLS-TP client failure indications document(draft-ietf-mpls-tp-= csf-01.txt) is included but MPLS-TP fault management OAM one (draft-ietf-= mpls-tp-fault-05) is omitted? >From my point of view the draft is not easily readable - not in the least b= ecause some terms and concepts that have been "borrowed" from the reference= d documents have different meaning in these documents. E.g.,. in Section 4.= 1 the draft states that ICMP ping provides "connectivity verification for In= ternet Protocol". However, in Section 3.2.4 the draft says that "connectivit= y verification function allows an MP to check whether it is connected to a p= eer MP or not". Since MPs are not mentioned with regard to ICMP, it is not c= lear whether "connectivity verification" means the same thing in these two c= ases. The explanations that accompany some of these references sometimes focus on= unimportant details while in other cases are simply missing. To give a som= e examples: * In Sections 4.5.2 and 4.5.3 the authors remind the reader that OWA= MP uses TCP port 861 and TWAMP - port 862. At the same time, IPPM test plane= protocols are only mentioned by referencing the appropriate RFCs * In Section 3.2.3 the draft defines the term "Maintenance Entity" (= ME). (Inaccuracies of this definition will be discussed below). At the same= time an equally important (IMHO) term "Maintenance Entity Group" (MEG), a.k= .a. "Maintenance Association (MA), is only defined by reference * In Section 4.5.2 the draft mentions security aspects of IPPM proto= cols. However, these aspects are not even mentioned in Section 4.2. discussi= ng BFD. I would suggest a careful clean-up of explanatory texts in the draft with sp= ecial attention on homogeneity of detail. Major Issues: OAM and its relationship to network planes The following examples illustrate the problem IMO: 1. The concepts of data plane, control plane and management plane are n= ot explored in the draft: a. The term "data-plane" (with some modifications) is only found in Sec= tion 4.3 when discussing LSP-Ping ("data plane" is also found in the title o= f RFC 4379) b. The terms "control-plane" ( "control plane") are a bit more popular.= They can be found: i. In Sec= tion 4.3 (LSP-Ping again) ii. In Sect= ion 4.5 (IPPM protocols) where "control plane" and "test plane" protocols ar= e mentioned iii. In the s= ections dealing with MPLS-TP - but mainly to explain that control plane is n= either mandatory nor precluded in MPLS-TP c. The term "management plane" (with or without dash) simply does not= appear in the draft d. The term "test plane" appears in Section 4.5, but, as already mentio= ned above, specific test plane protocols are not discussed in the draft 2. I have failed to understand relationship between OAM functionality and n= etwork management as presented in the draft. To illustrate this point, pleas= e consider the following text fragments (conflicting statements are indicate= d by italics, and my comments are closed in double angle brackets <<...>>): a. (Section 1) Other aspects associated with the OAM acronym, such as= management, are outside the scope of this document <> b. (Section 4.6.4) The FDI function is used by an LSR to report a def= ect to affected client layers, allowing them to suppress alarms about this= defect << Are not alarms part of management? >> c. 3. (Section 4.7.2) When the ETH-CC function detects a defect,= it reports one of the following defect conditions: i. Loss o= f continuity (LOC): Occurs when at least when no CCM messages have been rece= ived from a peer MEP during a period of 3.5 times the configured transmissio= n period ii. ... (sn= ipped)... iii. Unexpect= ed period: Occurs when the transmission period field in the CCM does not mat= ch the expected transmission period value << Since transmission period fiel= d in ETH-CC is defined by management, this defect reports a management probl= em>> d. (Section 4.7.6) The Alarm Indication Signal indicates that a MEG s= hould suppress alarms about a defect condition at a lower MEG level, i.e., s= ince a defect has occurred in a lower hierarchy in the network, it should = not be reported by the current node <> e. (Section 4.7.9) The Y.1731 standard defines the frame format for Aut= omatic Protection Switching frames. The protection switching operations ar= e defined in other ITU-T standards. <> 3. OAM in connectionless vs. connection-oriented networks: a. (2a) above suggests that OAM is applicable only to connection-orient= ed networks (if you do not have connections, connection problems do not exis= t by definition) b. At the same time, the draft discusses ICMP Ping (Section 4.1) opera= ting in connectionless IP networks, and Ethernet OAM (Sections 4.7 and 4.8)= operating in connectionless Ethernet networks. My suggestion (FWIW) to the authors would be to define the scope of OAM expl= icitly and clearly - and then remove the sections dealing with protocols and= mechanisms that happen to be out of this scope. In particular, explaining t= he relationship of each specific defect to a specific networking planes woul= d be most helpful. The Mess of MEs, MPs, MEPs and MIPs Caveat: It may well be that the problem is not with the draft I am reviewing= but with the concept itself (or at least with the attempts to extend it to= IP. IP/MPLS and MPLS-TP networks). I may be also biased when it comes to t= his concept. However, if the problem is with the concept, I would expect a u= seful overview to expose it to the reader and not to hide it. Going back to the draft, consider the following statements: 1. (Section 3.2.2) A Maintenance Entity (ME) is a point-to-point rela= tionship between two Maintenance Points (MP). The connectivity between these= Maintenance Points is managed and monitored by the OAM protocol. A pair of= MPs engaged in an ME are connected by a Communication Link 2. (Section 3.2.3) A Maintenance Point (MP) is a functional entity that= is defined at a node in the network, and either initiates or reacts to OAM= messages. A Maintenance End Point (MEP) is one of the end points of an ME,= and can initiate OAM messages and respond to them. A Maintenance Intermedi= ate Point (MIP) is an intermediate point between two MEPs, that does not ini= tiate OAM frames, but is able to respond to OAM frames that are destined to= it, and to forward others. 3. (Section 3.2.3) The 802.1ag defines a finer distinction between Up= MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM= protocol... 4. (Section 4.1) ICMP provides a connectivity verification function= for the Internet Protocol... ICMP is also used in Traceroute for path disco= very. I suspect that, based on these fragments (all within two pages in the draft= ), an OAM beginner would not be able to answer the following questions: 1. Can a communication link exist without any MPs on it (the chicken an= d egg problem:)) 2. Suppose that I have defined a P2P bidirectional communication link w= ith two MEPs forming an ME. What would happen to this ME if I add a MIP be= tween the two MEPs? 3. What is the relationship (if any) between MEPs and interfaces? Or is= it just something specific to Ethernet bridges? 4. Does a MIP really forward OAM frames that are not destined to it? 5. Operation of ICMP Ping does not require creation of MPs. How does it= provide a connectivity verification function for IP? As a minimum, I would suggest to remove conflicting definitions, to fix typo= s (e.g., the definition of ME would be less problematic if it referred to a= pair of MEPs and not to a pair of MPs) and inaccurate statements (in IP, IP= /MPLS and MPLS-TP MIPs do NOT forward OAM packets that are not destined to t= hem - but they do that in Ethernet OAM). Minor Issues: Caveat: Each of the issues listed below, if you look at it separately, could= be considered as minor. But there seem to be too many of them for my taste. Connectivity Check vs. Continuity Check The draft mainly uses the term "Continuity Check". However, from time to tim= e I have seen the term "Connectivity Check" as well, e.g.: 1. (Section 4.12) A key element in some of the OAM standards that are a= nalyzed in this document is the continuity check. It is thus interesting to= present a more detailed comparison of the connectivity check mechanisms def= ined in OAM standards. 2. (Section 4.3) LSP Ping extends the basic ICMP Ping operation (of da= ta-plane connectivity and continuity check)... The second fragment seems to suggest that connectivity check and continuity= check are two different functions. I would suggest to clean up the text using the term "continuity check" consi= stently. Caveat: I have found a similar inconsistency in IEEE 802.1ag (but not in ITU= -T Y.1731). Continuity Check vs. Connectivity Verification In Section 3.2.4. the draft refers to RFC 5860 as the ultimate source of in= formation about the difference between Continuity Check and Connectivity Ver= ification. Looking up RFC 5860 (Section 2.2.3), I've learned that connectivi= ty verification is a function that allows an End Point to find out whether i= t is connected to a specific End Point(s) by means of an expected PW, LSP or= Section. At the same time, the draft says (in the same Section 3.2.4) that= "A connectivity verification function allows an MP to check whether it is c= onnected to a peer MP or not". The omitted words from RFC 5860 "by means o= f..." make such a definition meaningless IMO; and it is not clear to me if E= nd Points (of Section, LSP or PW) which, presumably, are MEPs, can be extend= ed to be MEPs or MIPs (the draft uses the term MPs). It is also not clear to me whether the draft considers LSP Ping (see Section= 4.3.) functionality "to verify data-plane vs. control-plane consistency for= a Forwarding Equivalence Class (FEC)" as related to Connectivity Verifica= tion. This is especially strange since the draft also states (in the same se= ction) that "LSP Ping extends the basic ICMP Ping operation" while Section= 4.1 states that "ICMP provides a connectivity verification function for the= Internet Protocol". Yet another problematic point is the statement (in Section 4.2.3) that "BFD= Echo provides a connectivity verification function", especially since draft= -ietf-mpls-tp-cc-cv-rdi-05 in Section 3.5 expands format of the BFD control= packets in order to provide CV function, while BFD Echo is not even mention= ed in this document. Last but not least, the draft does not explain whether there is any correlat= ion between the defects detected by the continuity check and those detected= by connectivity verification (Section 4.10.3.1 looks a logical place for t= his). Inaccurate Representation of IEEE 802.1ag In Section 3.2.3 of the draft I have found the following text: "The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP= is a bridge interface, that is monitored by an OAM protocol either in the d= irection facing the network, or in the direction facing the bridge. A Dow= n MP is an MP that receives OAM packets from, and transmits them to the d= irection of the network. An Up MP receives OAM packets from, and transmits t= hem to the direction of the bridging entity". In fact IEEE 802.1ag states (see Section 22.1.3 of that document ) that: "Al= l Up MEPs belonging to MAs that are attached to specific VIDs are placed bet= ween the Frame filtering entity (8.6.3) and the Port filtering entities (8.6= .1, 8.6.2, and 8.6.4). Separately for each VLAN, there can be from zero to e= ight Up MEPs, ordered by increasing MD Level, from Frame filtering towards P= ort filtering". To me that means that in 802.1ag MEPs are NOT bridge interfaces (since there= can be are multiple MEPs per VLAN and multiple VLANs per bridge interface). Defects, Faults and Failures In Section 3.2.5 the draft discusses the terms Defect, Fault and Failure. Ho= wever, these terms seem to apply to the "communication link" which presumabl= y is a data plane entity. At the same time, "Unexpected Period" and "Unexpected MEP" are mentioned as= defects detected by ETH-CC in Section 4.7.2 even if, to the best of my unde= rstanding, these conditions are side effects of mis-configuration i.e., a ma= nagement plane problem. VCCV: An OAM Mechanism or a Control Channel? In Section 4.4. the draft states that VCCV "provides end-to-end fault detect= ion and diagnostics for PWs". This seems to point that VCCV is an OAM mechan= ism/protocol. However, later in the same section is states that "The VCCV switching functi= on provides a control channel associated with each PW... and allows sending= OAM packets in-band with PW data". And on the next line it explains that "= VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, a= nd BFD" (which are all mentioned as OAM mechanisms providing continuity chec= k and/or connectivity verification in the draft). So it remains completely u= nclear whether VCCV is an OAM mechanism or just a channel for separating use= r data from OAM flows. MEs, MEGs and MEG levels The draft explicitly defines a Maintenance Entity (ME) in Section 3.2.2, bur= defers to MPLS-TP OAM Framework for the definition of the Maintenance Entit= y Group (MEG). The text defining ME in the draft differs from that in the MP= LS-T_ OAM Framework document (see http://datatracker.ietf.org/doc/draft-iet= f-mpls-tp-oam-framework/?include_text=3D1, Section 2.2). At the same time, i= t resembles the definition of ME in Section 3.1 of this document. MEG level is mentioned a couple of times in the draft, but the only explanat= ion given (in Section 4.7.2) is "The MEG level is a 3-bit number that define= s the level of hierarchy of the MEG"; and this seems to be the only text in= the draft that deals with MEG hierarchy. Differences between Approaches to Packet/Frame Loss Measurement I have not found any mention of the fundamental difference between two appro= aches to measuring packet loss - that of the IPPM WG (based on counting synt= hetic packets) and that of Y.1731 (based on counting the user packets), even= if both are mentioned in the draft. Nits: Unidirectional/Bidirectional OAM vs. One-way/Two-way OAM Both pairs of terms are used in the draft (One-way/Two-way - in Section 4.5.= 1, Unidirectional - in section 4.12, /Bidirectional - in Section 4.2.2). Ne= ither the terms nor their equivalence are explained in the draft. A Typo: In section 4.10.3.1: "Continuity Check and Connectivity Verification (CC-V) are OAM operations ge= nerally used in tandem, and compliment each other." - probably should be "co= mplement"? An Pleonasm: In Section 4.8.1: "There are a few differences between the two standards in terms of terminolo= gy" - I would suggest "There are a few differences in terminology between th= e two standards". Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76ECD4BBF2E2ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hello,=

 

I hav= e been selected as the Routing Directorate reviewer for this draft. The Rout= ing Directorate seeks to review all routing or routing-related drafts as the= y pass through IETF last call and IESG review. The purpose of the review is= to provide assistance to the Routing ADs. For more information about the Ro= uting Directorate, please see http://www.ietf.org/iesg/directorate/routi= ng.html

 <= /p>

Although these comments are primarily for the use of the= Routing ADs, it would be helpful if you could consider them along with any= other IETF Last Call comments that you receive, and strive to resolve them= through discussion or by updating the draft.

 

Document: draft-ietf-op= sawg-oam-overview-05.txt

Reviewer: Ale= xander (“Sasha”) Vainshtein    =

Review date: 06-Aug-11

IETF LC End Date: 20-Jul-11 (?)

Int= ended status: Informational

&nb= sp;

Summary:

 

I have significant= concerns about this document and recommend that the Routing ADs discuss the= se issues further with the authors.

 

To some extent these concerns refle= ct my personal and potentially biased position with regard to OAM.  So= I would like the Routing ADs to take them with a grain of salt.<= /span>

 

In the= process of review I’ve maintained private discussions with one of the= draft authors (Nurit), and we’ve advanced in resolving some of the is= sues. Unfortunately, due to conflicting schedules, this process has not been= completed.

 

Comments:

 

My concerns with the draft start fro= m the question about its target audience. I have assumes (possibly, incorrec= tly), that the purpose of this draft is to provide guidance to OAM in IP, IP= /MPLS and MPLS-TP networks to various “beginners” groups (includ= ing people who have experience with OAM in SONET/SDH, ATM and OTN networks),= while “IETF gurus” would hardly need  it anyway  (IET= F Area Directors, WG chairs and reviewers for various Directorates are exclu= dedJ). Such gui= dance would be really useful because OAM-related issues are at the core of m= ultiple discussions raging on some IETF mailing lists for the last several y= ears.

 

IMHO and FWIW,  in order to provide guidance to what I ex= pected to be the target audience, the draft should:

  • Include  a “Historical Background”  session. A s= ingle sentence in Section 1 (“OAM was originally used in the world of= telephony, and has been adopted in packet based networks”) is hardly= sufficient IMHO
  • Present a clear view of OAM functionality and it= s relationship to various “planes” of networking (data plane, co= ntrol plane, management plane). In particular, the importance of fate-sharin= g of OAM and user traffic flows in packet networks should be explained<= /o:p>
  • Explicitly map the notions,  terms= and methods that have been adopted  from technologies owned by ITU-T a= nd/or IEEE to  IETF-owned technologies.  When such a mapping is no= t possible, it should be explicitly stated
=
  • Expose, rather than avoid,  known points of contention regardi= ng various OAM-related issues, preferably without explicitly taking sides. <= o:p>

The draft did not meet my e= xpectations in this regard. This may be because my  expectations have b= een  exaggerated or even completely unrealistic, or because the authors= had in mind a different target audience and a different purpose. At the ver= y least, explicitly specifying these (the purpose and the target audience) i= n the Introduction section would be helpful.

 

Instead the draft looks= to me like a long (but incomplete) annotated list of references to IETF and= non-IETF protocols and mechanisms that deal with certain aspects of OAM in= IP, IP/MPLS, MPLS-TP and Ethernet networks.  The guiding principle beh= ind selection of the referenced protocols and mechanisms is not defined in t= he draft and from my point of view, is questionable, e.g.:=

 

·    =    Why is the defunct= ITU-T Y.1711 considered in detail, while ITU-T I.610 (which has been implem= ented by virtually all the vendors of ATM equipment) is not even mentioned?=

·       <= span style=3D'font-size:12.0pt'>Why is IEEE 802.3ah included, while E-LMI (d= efined by MEF) is not? And what are their analogs (if any) in IETF-owned tec= hnologies?

·       = ;Why MPLS-TP client failure indicati= ons  document(draft-ietf-mpls-tp-csf-01.txt) is   included bu= t MPLS-TP fault management OAM one  (draft-ietf-mpls-tp-fault-05) is om= itted?

 

From my point of view the dra= ft  is not easily readable - not in the least because some terms and co= ncepts that have been “borrowed” from  the referenced docum= ents have different meaning in these documents.  E.g.,. in Section 4.1= the draft states that ICMP ping provides “connectivity verification f= or Internet Protocol”. However, in Section 3.2.4 the draft says that &= #8220;connectivity verification function allows an MP to check whether it is= connected to a peer MP or not”. Since MPs are not mentioned with rega= rd to ICMP, it is not clear whether “connectivity verification”= means the same thing in these two cases.

&= nbsp;

The explanations that accompany some o= f these references sometimes focus on unimportant details  while in oth= er cases are simply missing. To give a some examples:

<= p class=3DMsoPlainText> 

= ·    = ;     In S= ections 4.5.2 and 4.5.3 the authors remind the reader that OWAMP uses TCP po= rt 861 and TWAMP – port 862. At the same time, IPPM test plane protoco= ls are only mentioned by referencing the appropriate RFCs<= /p>

·         = In Section 3.2.3 the draft defines the term= “Maintenance Entity” (ME). (Inaccuracies of this definition wil= l be discussed below). At the same time an equally important (IMHO) term = 220;Maintenance Entity Group” (MEG), a.k.a. “Maintenance Associa= tion (MA), is only defined by reference

·&n= bsp;        In Section 4.5.2 the draft mentions security aspects of IPP= M protocols. However, these aspects are not even mentioned in Section 4.2. d= iscussing BFD.

 =

I would suggest a careful clean-up of explanatory texts= in the draft with special attention on homogeneity of detail.

 

Majo= r Issues:

 <= /p>

OAM and its relationship  to network planes<= /o:p>

 

The following examples illustrate the problem IMO:

 

1.      <= span dir=3DLTR>The concepts of data plane, control plane and management plane= are not explored in the draft: 

a.      The term “data-plane” (with some modificat= ions) is only found in Section 4.3 when discussing LSP-Ping (“data pla= ne” is also found in the title of RFC 4379)

b.      The terms “control-plane” ( &= #8220;control plane”) are a bit more popular. They can be found:<= /o:p>

            =             &nbs= p;            &n= bsp;            =             i.=      = In Section 4.3 (LSP-Ping agai= n)

          &nb= sp;            &= nbsp;            = ;            &nb= sp;           ii.      In Section 4.5 (IPPM protocols)= where “control plane” and “test plane” protocols ar= e mentioned

         &= nbsp;            = ;            &nb= sp;            &= nbsp;          iii.      In the sections dealing with MPLS-T= P – but mainly to explain that control plane is neither mandatory nor= precluded in  MPLS-TP

c.       The term “management plane” (with or without d= ash) simply does not appear in the draft

d.      <= ![endif]>The term “test plane” appears in Section= 4.5, but, as already mentioned above,  specific test plane protocols a= re not discussed in the draft

2.  I have fai= led to understand relationship between OAM functionality and network managem= ent as presented in the draft. To illustrate this point, please consider the= following text fragments (conflicting statements are indicated by italic= s, and my comments are closed in double angle brackets <<&#= 8230;>>):

a.&n= bsp;     = &= nbsp;(Section 1) Other aspects associated with the OAM acronym, such as m= anagement, are outside the scope of this  document  <<Ma= nagement is out of scope>>

<= ![if !supportLists]>b.      (Section 4.6.4)   The FDI function is used by an L= SR to report a defect to affected client layers, allowing them to suppres= s alarms  about this defect << Are not alarms part of managem= ent? >>

c.&nbs= p;      3.      (Section 4.7.2) When the ETH-CC function= detects a defect, it reports one of the following defect conditions: <= /o:p>

            =             &nbs= p;            &n= bsp;            =             i.=      = Loss of continuity (LOC): Occ= urs when at least when no CCM messages have been received from a peer MEP du= ring a period of 3.5 times the configured transmission period 

      … (snipped)…

=  &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;      iii.      <= span dir=3DLTR>Unexpected period: Occurs when the transmission period fiel= d in the CCM does not match the expected transmission period value = << Since transmission period field in ETH-CC is defined by management= , this defect reports a management problem>>

d.      (Section 4.7.6)   The Alarm Ind= ication Signal indicates that a MEG should suppress alarms about a de= fect condition at a lower MEG level, i.e., since a defect has occurred in a= lower hierarchy in the network, it should   not be reported by th= e current node  <<Alarms’ suppression again…>>=

e.  <= /span>  (Section 4.7.9)   The= Y.1731 standard defines the frame format for Automatic Protection &= nbsp; Switching frames. The protection switching operations are defined= in  other ITU-T standards. <<Is APS part of OAM?>><= o:p>

3.   OAM in connectionless vs. connection-orie= nted networks:

a.&n= bsp;     = (= 2a) above suggests that OAM is applicable only to connection-oriented networ= ks (if you do not have connections, connection problems do not exist= by definition)

b.&n= bsp;     = A= t  the same time, the draft discusses ICMP Ping (Section 4.1) operating= in connectionless IP networks, and Ethernet OAM (Sections  4.7 and 4.8= ) operating in connectionless Ethernet networks.

 

My suggestion (FWIW= ) to the authors would be to define the scope of OAM explicitly and clearly= - and then remove the sections dealing with protocols and mechanisms that h= appen to be out of this scope. In particular, explaining the relationship of= each specific defect to a specific networking planes would be most helpful.=

 

The Mess  of  MEs, MPs, MEPs and MIPs

 

Cave= at: It may well be that the problem is not with the draft I am reviewing= but with the concept itself (or at least with the attempts to extend it to= IP. IP/MPLS and MPLS-TP networks).  I may be also biased when it comes= to this concept. However, if the problem is with the concept, I would expec= t a useful overview to expose it to the reader and not to hide it.

 

Goi= ng back to the draft, consider the following statements:

 

1.      (Section 3.2.2)   A Maintenance Entity (ME) is a point-t= o-point relationship between two Maintenance Points (MP). The connectivity b= etween these Maintenance Points is managed and monitored by the OAM protocol= .  A pair of MPs engaged in an ME are connected by a Communication Link=

2.  &nbs= p;   (Section 3.2.3)= A Maintenance Point (MP) is a functional entity that is defined at a node i= n the network, and either initiates or reacts to OAM messages. A Maintenance= End Point (MEP) is one of the end points of an ME, and  can initiate O= AM messages and respond to them. A Maintenance Intermediate Point (MIP) is a= n intermediate point between two MEPs, that does not initiate OAM frames, bu= t is able to respond to OAM  frames that are destined to it, and to for= ward others.

= 3. = ;     (Sec= tion 3.2.3)  The 802.1ag defines a finer distinction between Up MPs and= Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol= …

4. &n= bsp;     = ;= (Section 4.1)   ICMP provides a connectivity verification function= for the Internet Protocol… ICMP is also used in Traceroute for path d= iscovery.

 

=

I suspect that, based on  these fragments (all within t= wo pages in the draft), an OAM beginner would not be able to answer the foll= owing questions:

1.&= nbsp;     = Can a communication link exist without any MPs on it (the chicken and egg pr= oblemJ<= span style=3D'font-size:12.0pt;font-family:"Calibri","sans-serif"'>)<= o:p>

2.    &= nbsp; Suppose that I have defi= ned a P2P bidirectional communication link with two MEPs  forming an ME= .  What would happen to this ME if I add a MIP between the two MEPs?

3.   &n= bsp;  What is the relatio= nship (if any) between MEPs and interfaces? Or is it just something specific= to Ethernet bridges?

4.      Does a MIP really forward OAM frames that are not destined to i= t? 

5. &n= bsp;    Operati= on of ICMP Ping does not require creation of MPs. How does it provide a conn= ectivity verification function for IP?

 

As a minimum, I would suggest t= o remove conflicting definitions, to fix typos (e.g., the definition of ME w= ould be less problematic if it referred to a pair of MEPs and not to a pair= of MPs) and inaccurate statements (in IP, IP/MPLS and MPLS-TP MIPs do NOT f= orward OAM packets that are not destined to them – but they do that in= Ethernet OAM).

 

Minor Issues:

 

Caveat: Each of the is= sues listed below, if you look at it separately, could be considered as mino= r. But there seem to be too many of them for my taste.

=

 

Connectivity= Check vs. Continuity Check

 

The draft mainly uses the term “= Continuity Check”. However, from time to time I have seen the term = 220;Connectivity Check” as well, e.g.:

1.  &nbs= p;   (Section 4.12) A key element in some of the OAM standards that= are analyzed in this document is the continuity check. It is thus in= teresting to present a more detailed comparison of the connectivity check= mechanisms defined in OAM standards.

2.   &n= bsp;  (Section 4.3)  LSP Ping extends the basic ICMP Ping operation= (of data-plane connectivity and continuity check)…

 

The second fragment seems to suggest that connectivity check and continuit= y check are two different functions.

 

I would suggest to clean up the te= xt using the term “continuity check” consistently.

 

Cave= at: I have found a similar inconsistency in IEEE 802.1ag (but not in ITU-= T Y.1731).

 

Continuity Check vs. Connectivity Verification

 

In Section 3.2.4. the draft refers to  RFC 5860 as the ultimate source= of information about the difference between Continuity Check and Connectivi= ty Verification. Looking up RFC 5860 (Section 2.2.3), I’ve learned tha= t connectivity verification is a function that allows an End Point to find o= ut whether it is connected to a specific End Point(s) by means of an expe= cted PW, LSP or Section. At the same time, the draft says (in the same S= ection 3.2.4) that “A connectivity verification function allows an MP= to check whether it is connected to a peer MP or not”.  The omit= ted  words from RFC 5860 “by means of…” make such a d= efinition meaningless IMO; and it is not clear to me if End Points (of Secti= on, LSP or PW) which, presumably, are MEPs, can be extended to be MEPs or MI= Ps (the draft uses the term MPs).

 

It is also not clear to me whether t= he draft considers LSP Ping (see Section 4.3.) functionality “to verif= y data-plane vs. control-plane consistency for a Forwarding Equivalence Clas= s (FEC)”  as  related to Connectivity Verification. This is= especially strange since the draft also states (in the same section)  = that “LSP Ping extends the basic ICMP Ping operation”  whil= e Section 4.1 states that “ICMP provides a connectivity verification f= unction for the Internet   Protocol”.  

 

Yet anothe= r problematic point is the statement (in Section 4.2.3) that “BFD Echo= provides a connectivity verification function”, especially since draf= t-ietf-mpls-tp-cc-cv-rdi-05 in Section 3.5 expands format of the BFD control= packets in order to provide CV function, while BFD Echo is not even mention= ed in this document.

 

Last but not least, the draft does not explain wh= ether there is any correlation between the defects detected by the continuit= y check and those detected by connectivity verification (Section 4.10.3.1 lo= oks  a logical place for this).

 

Inaccurate Representation of I= EEE 802.1ag

 

In Section 3.2.3 of the draft I have found the followi= ng text:

 

=

“The 802.1ag defines a finer distinction between Up= MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM= protocol either in the direction facing the network, or in the direction&nb= sp;   facing the bridge. A Down MP is an MP that receives OAM pack= ets from,    and transmits them to the direction of the netwo= rk. An Up MP receives OAM packets from, and transmits them to the direction= of the bridging entity”.

 

In fact IEEE 802.1ag states (see= Section 22.1.3 of that document ) that: “All Up MEPs belonging to= MAs that are attached to specific VIDs are placed between the Frame filteri= ng entity (8.6.3) and the Port filtering entities (8.6.1, 8.6.2, and 8.6.4).= Separately for each VLAN, there can be from zero to eight Up MEPs, ordered= by increasing MD Level, from Frame filtering towards Port filteringR= 21;.

 

To me that means that in 802.1ag MEPs are NOT bridge interfaces= (since there can be are multiple MEPs per VLAN and multiple VLANs per bridg= e interface).

 =

Defects, Faults and Failures

 

In Section 3.= 2.5 the draft discusses the terms Defect, Fault and Failure. However, these= terms seem to apply to the “communication link” which presumabl= y is a data plane entity.

 = ;

At the same time, “Unexpected Period&#= 8221; and “Unexpected MEP” are mentioned as defects detected by= ETH-CC in Section 4.7.2 even if, to the best of my understanding, these con= ditions are side effects of mis-configuration i.e., a management plane probl= em.

 

VCCV: An OAM Mechanism or a Control Channel?

 

= In Secti= on 4.4. the draft states that VCCV “provides end-to-end fault detectio= n and diagnostics for PWs”. This seems to point that VCCV is an OAM me= chanism/protocol.

 

However, later in the same section is states that &#= 8220;The VCCV switching function provides a control channel associated with= each PW… and allows sending OAM packets in-band with PW data”.&= nbsp; And on the next line it explains that “VCCV currently supports t= he following OAM mechanisms: ICMP Ping, LSP Ping, and BFD” (which are= all mentioned as OAM mechanisms providing continuity check and/or connectiv= ity verification in the draft). So it remains completely unclear whether VCC= V is an OAM mechanism or just a channel for separating user data from OAM fl= ows.

 

MEs, MEGs and MEG levels

 

The draft explicitly define= s a Maintenance Entity (ME) in Section 3.2.2, bur defers to MPLS-TP OAM Fram= ework for the definition of the Maintenance Entity Group (MEG). The text def= ining ME in the draft differs from that in the MPLS-T_ OAM Framework documen= t  (see http://datatracker.ietf.or= g/doc/draft-ietf-mpls-tp-oam-framework/?include_text=3D1, Section 2.2).= At the same time, it resembles the definition of ME in Section 3.1 of this= document.

 

MEG level is mentioned a couple of times in the draft, but= the only explanation given (in Section 4.7.2) is “The MEG level is a= 3-bit number that defines the level of hierarchy of the MEG”; and thi= s seems to be the only text in the draft that deals with MEG hierarchy.

 

Differences between Approaches to Packet/Frame Loss Measurement=

 

I have not found any mention of the fundamental difference between two a= pproaches to measuring packet loss – that of the IPPM WG (based on cou= nting synthetic packets) and that of Y.1731 (based on counting the user pack= ets), even if both are mentioned in the draft.

 

Nits:

 

U= nidirectional/Bidirectional OAM vs. One-way/Two-way OAM

 

Both pairs= of terms are used in the draft (One-way/Two-way - in Section 4.5.1, Unidire= ctional – in section 4.12, /Bidirectional – in Section 4.2.2).&n= bsp; Neither  the terms nor their equivalence are explained in the draf= t.

 

A Typo:

 

In section 4.10.3.1:

 

“Continuity C= heck and Connectivity Verification (CC-V) are OAM operations generally used= in tandem, and compliment each other.” – probably should= be “complement”?

&= nbsp;

An Pleonasm:

=

 

In Section 4.8.= 1:

 

“There are a few differences between the two standards in = terms of terminology” – I would suggest “There= are a few differences in terminology between the two standards”.

 

Regards,

     Sas= ha

 

<= /div>

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76ECD4BBF2E2ILPTMAIL02eci_-- From rcallon@juniper.net Thu Aug 11 08:48:40 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4A21F8B6C for ; Thu, 11 Aug 2011 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnpBUxTuTUue for ; Thu, 11 Aug 2011 08:48:38 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id EBCBF21F8B6B for ; Thu, 11 Aug 2011 08:48:37 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTkP58QGy/1LYfPjbKA41BRYS0+4n4eYt@postini.com; Thu, 11 Aug 2011 08:49:13 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 11 Aug 2011 08:46:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 11 Aug 2011 11:46:55 -0400 From: Ross Callon To: "adrian@olddog.co.uk" , "stbryant@cisco.com" Date: Thu, 11 Aug 2011 11:46:52 -0400 Thread-Topic: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxYPeO+scq5n+URQ/KnpmonjfDQIg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2E1DE512EEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "rtg-dir@ietf.org" , "russw@riw.us" , Gregory Lebovitz Subject: [RTG-DIR] RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:48:40 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2E1DE512EEMBX01WFjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVu dHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3Ro ZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0 byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYta2FycC10aHJlYXRzLXJlcXMtMDMudHh0DQpSZXZp ZXdlcjogUm9zcyBDYWxsb24NClJldmlldyBEYXRlOiBBdWd1c3QgMTEsIDIwMTENCkludGVuZGVk IFN0YXR1czogSW5mb3JtYXRpb25hbA0KDQpTdW1tYXJ5Og0KDQpBcyBjdXJyZW50bHkgd3JpdHRl biBJIGhhdmUgc2lnbmlmaWNhbnQgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVj b21tZW5kIHRoYXQgdGhlIFJvdXRpbmcgQURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIg d2l0aCB0aGUgYXV0aG9ycy4NCg0KQ29tbWVudHM6DQoNClRoZSBkb2N1bWVudCBpcyB3ZWxsIHdy aXR0ZW4gYW5kIHZlcnkgcmVhZGFibGUuIEkgbGlrZWQgdGhlIHdheSB0aGF0IHRoZSBpbnRyb2R1 Y3Rpb24gcGxhY2VkIHRoaXMgZG9jdW1lbnQgaW4gdGhlIG92ZXJhbGwgY29udGV4dCBvZiBzZWN1 cmluZyB0aGUgcm91dGluZyBpbmZyYXN0cnVjdHVyZS4gVGhpcyBtYWtlcyBpdCBjbGVhciBob3cg dGhpcyByZWxhdGVzIHRvIG90aGVyIGVmZm9ydHMgKHN1Y2ggYXMgT1BTRUMsIFNJRFIpLg0KDQpI b3dldmVyLCB0aGVyZSBhcmUgdHdvIHJlcXVpcmVtZW50cyB3aGljaCBhcmUgbWlzc2luZyBmcm9t IHNlY3Rpb24gMywgdGhhdCBJTUhPIGFyZSBuZWNlc3NhcnkgZm9yIGFueSBzb2x1dGlvbiBkZXZl bG9wZWQgYnkgS0FSUCB0byBiZSB1c2VhYmxlLiBUaGVyZSBpcyBhbHNvIGEgcmVxdWlyZW1lbnQg dGhhdCBjb3VsZCB1c2UgYWRkaXRpb25hbCBleHBsYW5hdGlvbi4gSXQgaXMgcG9zc2libGUgdGhh dCB0aGVzZSByZXF1aXJlbWVudHMgbWlnaHQgYmUgc2F0aXNmaWVkIGJ5IHNvbHV0aW9ucyBldmVu IGlmIG5vdCBsaXN0ZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCwgYnV0IGl0IGlzIGZhciBi ZXR0ZXIgZm9ybSB0byBleHBsaWNpdGx5IGxpc3QgZXNzZW50aWFsIHJlcXVpcmVtZW50cy4NCg0K QXMgdGhlIGF1dGhvcnMgYXJlIHdlbGwgYXdhcmUsIHR3byBvZiB0aGUgYXV0aG9ycyBoYXZlIGNo YW5nZWQgZW1haWwgYWRkcmVzc2VzIGFuZCBJIHBlcnNvbmFsbHkgZG9u4oCZdCBrbm93IGhvdyBs b25nIHRoZWlyIG9sZCBhZGRyZXNzZXMgd2lsbCBzdGlsbCB3b3JrLiBUaGVpciBjb250YWN0IGlu Zm9ybWF0aW9uIHNob3VsZCBiZSB1cGRhdGVkIGluIHRoZSBkcmFmdC4NCg0KTWFqb3IgSXNzdWVz Og0KDQpJbiBzZWN0aW9uIDMsIHJlcXVpcmVtZW50cywgdGhlcmUgYXJlIHR3byBpbXBvcnRhbnQg cmVxdWlyZW1lbnRzIHRoYXQgYXBwZWFyIHRvIGJlIG1pc3NpbmcgKG9yIHBlcmhhcHMgb25seSBo aW50ZWQgaW4gb3RoZXIgcmVxdWlyZW1lbnRzKS4NCg0KQW55IHNlY3VyaXR5IHByb3RvY29sIHRo YXQgaXMgdXNlZCwgZm9yIGV4YW1wbGUgZm9yIGF1dG9tYXRlZCBrZXkgbWFuYWdlbWVudCwgTVVT VCBiZSBhYmxlIHRvIG9wZXJhdGUgYmV0d2VlbiBtdWx0aXBsZSBzeXN0ZW1zIG92ZXIgYSBCcm9h ZGNhc3QgbWVkaWEuIEZvciBleGFtcGxlLCBhbGwgb2YgSVMtSVMsIE9TUEYsIGFuZCBSSVAgaGF2 ZSB0aGUgYWJpbGl0eSB0byBvcGVyYXRlIGJldHdlZW4gbXVsdGlwbGUgcm91dGVycyBpbnRlcmNv bm5lY3RlZCB2aWEgYSBicm9hZGNhc3QgTEFOLCBhbmQgTERQIHVzZXMgbXVsdGljYXN0IGZvciBk aXNjb3Zlcnkgb3ZlciBicm9hZGNhc3QgTEFOcy4gVGhpcyBuZWVkcyB0byBiZSBzdXBwb3J0ZWQg Zm9yIGEgc2VjdXJpdHkgcHJvdG9jb2wgdG8gYmUgdXNlYWJsZSBieSB0aGVzZSByb3V0aW5nIHBy b3RvY29scy4NCg0KQW55IHNlY3VyaXR5IHByb3RvY29sIHVzZWQgdG8gc2VjdXJlIGEgcm91dGlu ZyBwcm90b2NvbCBNVVNUIE5PVCBhc3N1bWUgdGhhdCB0aGUgcm91dGluZyBwcm90b2NvbCBpcyBp dHNlbGYgb3BlcmF0aW5nIGJlZm9yZSB0aGUgc2VjdXJpdHkgcHJvdG9jb2wgY2FuIG9wZXJhdGUu IEZvciBleGFtcGxlLCB0aGlzIG1lYW5zIHRoYXQgYW55IHByb3RvY29sIHVzZWQgdG8gZ2VuZXJh dGUga2V5cyBmb3Igb3BlcmF0aW9uIG9mIElTLUlTIG9yIE9TUEYgTVVTVCBOT1QgYXNzdW1lIHRo YXQgaXQgaXMgcG9zc2libGUgdG8gc2VuZCBhbnkgcGFja2V0IGF0IGFsbCBiZXR3ZWVuIHR3byBz eXN0ZW1zIHVubGVzcyB0aG9zZSB0d28gc3lzdGVtcyBhcmUgZGlyZWN0bHkgY29ubmVjdGVkIGF0 IHRoZSBsaW5rIGxldmVsLg0KDQpUaGlzIGxhc3QgcG9pbnQgaGFzIGEgcmVsYXRpb25zaGlwIHdp dGggdGhlIHJlcXVpcmVtZW50IGN1cnJlbnRseSBsaXN0ZWQgYXMgbnVtYmVyIDI0LiBJdCBzYXlz IOKAnFRoZXJlZm9yZSwgcHJvcG9zZWQgc29sdXRpb25zIFNIT1VMRCBOT1QgcmVxdWlyZSBjb25u ZWN0aW9ucyB0byBleHRlcm5hbCBzeXN0ZW1z4oCm4oCdLiBIb3dldmVyLCBub3RlIHRoYXQgaWYg dGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGJlaW5nIHVzZWQgdG8gYXV0aGVudGljYXRlIE9TUEYg b3IgSVMtSVMsIGFuZCBpZiBPU1BGIG9yIElTLUlTIHdpbGwgbm90IGJyaW5nIHVwIGxpbmtzIHVu dGlsIHRoZXkgYXJlIGF1dGhlbnRpY2F0ZWQsIGFuZCBpZiB0aGUgcHJvcG9zZWQgc29sdXRpb24g cmVxdWlyZXMgc2VuZGluZyBhbnkgaW5mb3JtYXRpb24gdG8gb3IgZ2V0dGluZyBhbnkgcmVzcG9u c2UgZnJvbSBhIG5vdC1kaXJlY3RseS1hdHRhY2hlZCByZW1vdGUgc3lzdGVtLCB0aGVuIGl0IGlz buKAmXQgZ29pbmcgdG8gd29yay4gSW4gdGhpcyByZWdhcmQgSSB0aGluayB0aGF0IHRoZSDigJxT SE9VTEQgTk9U4oCdIGluIHJlcXVpcmVtZW50IDI0IGlzIG5vdCBzdHJvbmcgZW5vdWdoLCBhbmQg dGhlIHBvdGVudGlhbCBmb3IgZGVhZGxvY2sgc2hvdWxkIGJlIGV4cGxpY2l0bHkgbWVudGlvbmVk Lg0KDQpTZWN0aW9uIDMsIDl0aCBidWxsZXQgaXRlbSAoYWJvdXQgRE9TIGF0dGFja3MpOiBSb3V0 ZXJzIGFyZSBvY2Nhc2lvbmFsIGludGVuZGVkIHZpY3RpbXMgb2YgRERPUyBhdHRhY2tzLCB3aGlj aCBtYXkgYmUgYWltZWQgYXQgdGhlIHJvdXRlcuKAmXMgY29udHJvbCBwbGFuZS4gQXMgc3VjaCBp dCBpcyBub3JtYWwgZm9yIHJvdXRlcnMgdG8gbWFrZSB1c2Ugb2YgcGFja2V0IGZpbHRlcnMgdG8g cHJvdGVjdCB0aGUgY29udHJvbCBwbGFuZSwgZnJlcXVlbnRseSBpbXBsZW1lbnRlZCBpbiBzaWxp Y29uIGFuZCBvcGVyYXRpbmcgYXQgbGluZSByYXRlICh3aGljaCBtYXkgaW1wbHkgaW4gY29yZSBy b3V0ZXJzIHRoZSBhYmlsaXR5IHRvIGlkZW50aWZ5IGFuZCBkaXNjYXJkIGh1bmRyZWRzIG9mIGdp Z2FiaXRzIG9yIGV2ZW4gdGVyYWJpdHMgb2YgYXR0YWNrIGluZm9ybWF0aW9uIHdpdGhvdXQgaGF2 aW5nIGFueSBhZHZlcnNlIGVmZmVjdCBvbiBvdGhlciBhc3BlY3RzIG9mIHJvdXRlciBvcGVyYXRp b24g4oCTIG90aGVyIHRoYW4gdGhlIGxpbmsgYmFuZHdpZHRoIHRoYXQgdGhlIGF0dGFjayBjb25z dW1lcyBwcmlvciB0byBhcnJpdmluZyBhdCB0aGUgcm91dGVyKS4gV2UgYXJlbuKAmXQgcmVhbGlz dGljYWxseSBsaWtlbHkgdG8gYmUgY2hlY2tpbmcgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlv biBhbmQgZGlzY2FyZGluZyB1bndhbnRlZCB0cmFmZmljIGF0IHRlcmFiaXQgcmF0ZXMgaW4gcm91 dGVycywgd2hpY2ggaW1wbGllcyB0aGF0IHRoZSBleGlzdGluZyBwYWNrZXQgZmlsdGVyaW5nIG1l Y2hhbmlzbXMgbmVlZCB0byBiZSBtYWludGFpbmVkLCBhbmQgdGhhdCBLQVJQIGlzIHRhbGtpbmcg YWJvdXQgKmFkZGl0aW9uYWwqIHByb3RlY3Rpb24sIG5vdCBhIHJlcGxhY2VtZW50IGZvciBwYWNr ZXQgZmlsdGVycyB0byBwcm90ZWN0IGFnYWluc3QgRERPUy4gVGh1cyBpbiBkZWZpbmluZyBzZWN1 cml0eSBtZWNoYW5pc21zIHRoZXJlIHNob3VsZCBiZSBhIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBt ZWNoYW5pc21zIHRoYXQgZG9u4oCZdCBoaWRlIG5vciBlbmNyeXB0IHRoZSBpbmZvcm1hdGlvbiB0 aGF0IHRoZSByb3V0ZXIgaGFyZHdhcmUgaXMgYWJsZSB0byAgaW5zcGVjdCBhdCBmdWxsIGxpbmUg cmF0ZSBmb3IgRERPUyBwcm90ZWN0aW9uIChzdWNoIGFzIElQIGFkZHJlc3NlcywgYW5kIFRDUCBw b3J0cykuIEkgdGhpbmsgdGhhdCBhIGJpdCBtb3JlIHRleHQgYWxvbmcgdGhlIGxpbmVzIG1pZ2h0 IGJlIGFwcHJvcHJpYXRlIHRvIGJlIGFkZGVkIHRvIHRoaXMgYnVsbGV0IGl0ZW0uDQoNCk1pbm9y IElzc3VlczoNCg0KV2hhdCBpcyB0aGUgYXVkaWVuY2U/IFNlY3Rpb24gMS43IHNheXMgdGhhdCB0 aGlzIGluY2x1ZGVzIOKAnFJvdXRpbmcgQXJlYSB3b3JraW5nIGdyb3VwIGNoYWlycyBhbmQgcGFy dGljaXBhbnRz4oCdLiBTb21lIG9mIHRoZXNlIG1heSBvciBtYXkgbm90IGtub3cgbXVjaCBhYm91 dCBzZWN1cml0eS4gSXQgdGhlcmVmb3JlIG1pZ2h0IGJlIGEgZ29vZCBpZGVhIHRvIGRlZmluZSBh IGZldyBiYXNpYyBzZWN1cml0eSB0ZXJtcyBpbiBzZWN0aW9uIDEuMSwgaW4gcGFydGljdWxhciDi gJxub24tcmVwdWRpYXRpb27igJ0gaXMgbm90IGxpa2VseSB0byBiZSB1bml2ZXJzYWxseSB1bmRl cnN0b29kLiDigJxQcml2YWN54oCdLCDigJ1hdXRoZW50aWNhdGlvbuKAnSwgYW5kIOKAnG1lc3Nh Z2UgaW50ZWdyaXR54oCdIHNlZW0gbW9yZSBvYnZpb3VzLCBidXQgbWlnaHQgYmUgd29ydGggZGVm aW5pbmcgYWxzby4NCg0KSW4gc2VjdGlvbiAzLCByZXF1aXJlbWVudCAxNiwgSSB3b3VsZCBwdXQg dGhpcyBhcyDigJxNVVNUIE5PVOKAnSByYXRoZXIgdGhhbiDigJxTSE9VTEQgTk9U4oCdLiBUaGUg ZmFpbHVyZSB0byBwcmlvcml0aXplIEhFTExPIHByb2Nlc3NpbmcgaGFzIGF0IHNvbWUgcG9pbnRz IGluIHRoZSBwYXN0IGhhZCBjYXRhc3Ryb3BoaWMgaW1wbGljYXRpb25zIG9uIG5ldHdvcmsgb3Bl cmF0aW9uLiBBbnkgbWVjaGFuaXNtIHRoYXQgYnJlYWtzIHRoZSBwcmlvcml0aXphdGlvbiBvZiBI RUxMT3MgaXMgZXNzZW50aWFsbHkgdW51c2FibGUuDQoNCih2ZXJ5IG1pbm9yKSBJbiB0aGUgc2Vj b25kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDEuNCwgeW91IGNvdWxkIG1lbnRpb24gdGhhdCByb3V0 aW5nIHByb3RvY29scyBhcmUgZXNzZW50aWFsbHkgcmVhbCB0aW1lIGRpc3RyaWJ1dGVkIHN5c3Rl bXMsIGluIHRoYXQgdGhlcmUgYXJlIHJvdXRpbmcgcHJvdG9jb2wgZXZlbnRzIHRoYXQgcm91dGVy cyBtdXN0IHBlcmZvcm0gaW4gYSBzcGVjaWZpYyB0aW1lIGZyYW1lIGluIG9yZGVyIHRvIHByZXZl bnQgb3RoZXIgc3lzdGVtcyBmcm9tIHJlYWN0aW5nIGluIHVuZm9ydHVuYXRlIHdheXMuICBUaHVz IHRoZSBuZWVkIGZvciDigJxleHRlbnNpdmUgdHVuaW5nIG9mIHNvZnR3YXJlIGFuZCBoYXJkd2Fy ZSBlbGVtZW50c+KAnSBhcyB5b3Ugc3RhdGUuIEFzIG9uZSBleGFtcGxlICh3aGljaCB5b3UgcHJv YmFibHkgZG9u4oCZdCBuZWVkIHRvIGV4cGxpY2l0bHkgZGVzY3JpYmUsIGJ1dCBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIGF1dGhvcnMpIHRoZXJlIGhhdmUgYmVlbiB0aW1lcyBpbiB0aGUgcGFzdCB3 aGVyZSBkdWUgdG8gYmVpbmcgdmVyeSBidXN5IGR1ZSB0byBuZXR3b3JrIGV2ZW50cywgYSByb3V0 ZXIgaGFzIGZhaWxlZCB0byBzZW5kIG9yIHRvIHJlY2VpdmUgSEVMTE8gbWVzc2FnZXMgd2l0aGlu IHRoZSByZXF1aXJlZCB0aW1lIGZyYW1lLCBhbmQgYXMgYSByZXN1bHQgcm91dGVycyBoYXZlIGRl Y2xhcmVkIGxpbmtzIGRvd24uIFRoaXMgY2FuIHJlc3VsdCBpbiBhZGRpdGlvbmFsIHJvdXRpbmcg cHJvdG9jb2wgdHJhZmZpYyB3aGljaCBjYW4gZXhhY2VyYmF0ZSB3aGF0ZXZlciBldmVudCBjYXVz ZSBhIHJvdXRlciB0byBiZSBidXN5IGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KTml0czoNCg0KSW4g c2VjdGlvbiAxLjQsIHBlcnNvbmFsbHkgSSB3b3VsZCBwdXQg4oCcdmFzdGx5LSBpbXByb3ZlZC1v dmVyLWN1cnJlbnQtc2VjdXJpdHktYnV0LWFkbWl0dGVkbHktbm90LXlldC1iZXN0LXNlY3VyaXR5 LSBwb3NzaWJsZeKAnSBpbiBxdW90ZXMgcmF0aGVyIHRoYW4gd3JpdGluZyB0aGlzIGxvbmdpc2gg cGhyYXNlIHdpdGggZGFzaGVzLiBJZiBkb2luZyB0aGlzLCB0aGVuIHBlcmhhcHMg4oCcYmVzdC1z ZWN1cml0eS1wb3NzaWJsZeKAnSBjb3VsZCBhbHNvIGJlIGluIHF1b3Rlcy4gVGhlIHBvaW50IGlz IGVhc3kgdG8gdW5kZXJzdGFuZCBob3dldmVyIGFzIGlzIChhbmQgbWFrZXMgc2Vuc2UpLg0KDQpM YXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDEuNCwgYXJlIHdlIG1pc3NpbmcgdGhlIHdvcmQg4oCc YW5k4oCdIGJlZm9yZSDigJxUQ1Agc2Vzc2lvbiByZXNldHRpbmfigJ0/DQoNClNlY3Rpb24gMS41 LCB0aGlyZCBudW1iZXJlZCBidWxsZXQ6IFRoZSBmaXJzdCDigJxzZW50ZW5jZeKAnSBvZiB0aGlz IGlzIG5vdCBhY3R1YWxseSBhIHNlbnRlbmNlLiBUaGVyZSBpcyBhIHZlcmIgbWlzc2luZy4gRG8g eW91IG1lYW4g4oCcRW5zdXJlIHRoZSBkZXBsb3lhYmlsaXR5IG9mIHRoZSBpbXByb3ZlZCBzZWN1 cml0eSBzb2x1dGlvbnMgb24gY3VycmVudGx5IHJ1bm5pbmcgcm91dGluZyBpbmZyYXN0cnVjdHVy ZSBlcXVpcG1lbnQu4oCdPw0KDQpTZWN0aW9uIDEuNSwgZm91cnRoIG51bWJlcmVkIGJ1bGxldDog WW91IGhhdmUgd2FuZGVyZWQgYXdheSBmcm9tIGEgcGFyYWxsZWwgd3JpdGluZyBzdHlsZSBmb3Ig ZWFjaCBudW1iZXJlZCBidWxsZXQgaW4gdGhpcyBzZWN0aW9uLiBUaGUgZmlyc3QgdHdvIHN0YXJ0 IHdpdGggYSBzZW50ZW5jZS4gVGhlIHRoaXJkIHN0YXJ0cyB3aXRoIHNvbWV0aGluZyB0aGF0IGFw cGVhcnMgdG8gYmUgaW50ZW5kZWQgdG8gYmUgYSBzZW50ZW5jZSwgYnV0IGlzbuKAmXQgcXVpdGUu IFRoZSBmb3VydGggc3RhcnRzIHdpdGggYSBoZWFkaW5nIOKAnE9wZXJhdGlvbmFsIGRlcGxveWFi aWxpdHnigJ0uIEl0IHdvdWxkIHJlYWQgYmV0dGVyIHRvIG1haW50YWluIHRoZSBzYW1lIHN0eWxl IGluIGVhY2ggYnVsbGV0IChlaXRoZXIgc3RhcnQgdGhlIGZpcnN0IHRocmVlIHdpdGggYSBoZWFk aW5nLCBvciBkb27igJl0IHN0YXJ0IHRoZSBmb3VydGggd2l0aCBhIGhlYWRpbmcpLiBJIGxpa2Ug dGhlIGhlYWRpbmcgb24gdGhpcyBmb3VydGggYnVsbGV0LCBhbmQgd29uZGVyIHdoZXRoZXIgeW91 IHNob3VsZCBjb21lIHVwIHdpdGggb25lcyBmb3IgdGhlIGZpcnN0IHRocmVlIGJ1bGxldHMuIEFs dGVybmF0ZWx5IHRoZSBoZWFkaW5nIG9uIGJ1bGxldCBmb3VyIGNvdWxkIGJlIHR1cm5lZCBpbnRv IGEgdmVyeSBzaG9ydCBzZW50ZW5jZSwgc3VjaCBhcyDigJxFbnN1cmUgb3BlcmF0aW9uYWwgZGVw bG95YWJpbGl0eSDigJwuDQoNClNlY3Rpb24gMS43LCBmaXJzdCBidWxsZXQgaXRlbTogVG8gbWUg dGhlIHRlcm0g4oCcQ28tYWR2aXNvcnPigJ0gc2hvdWxkIGJlIGp1c3Qg4oCcQWR2aXNvcnPigJ0u DQoNClJlYWxseSBtaW5vciwgc2VjdGlvbiAzLCDigJxSb3VpbmcgUHJvdG9jb2zigJ0uIElzIOKA nHByaXZhY2V54oCdIHNwZWxsZWQgY3VycmVudGx5IGluIGl0ZW0gNyBvZiBzZWN0aW9uIDM/DQoN Cg0K --_000_DF7F294AF4153D498141CBEFADB17704C2E1DE512EEMBX01WFjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIy Ij4NCjxkaXY+SGVsbG8sIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSBoYXZlIGJl ZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGlu ZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFz dCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3Qu IFRoZSBwdXJwb3NlIG9mDQp0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0 aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2llc2cv ZGlyZWN0b3JhdGUvcm91dGluZy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0 b3JhdGUvcm91dGluZy5odG1sPC9hPiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFs dGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJv dXRpbmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVt IGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJl Y2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBi eSB1cGRhdGluZyB0aGUgZHJhZnQuDQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkRv Y3VtZW50OiBkcmFmdC1pZXRmLWthcnAtdGhyZWF0cy1yZXFzLTAzLnR4dDwvZGl2Pg0KPGRpdj5S ZXZpZXdlcjogUm9zcyBDYWxsb24gPC9kaXY+DQo8ZGl2PlJldmlldyBEYXRlOiBBdWd1c3QgMTEs IDIwMTEgPC9kaXY+DQo8ZGl2PkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbDwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+U3VtbWFyeTogPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5BcyBjdXJyZW50bHkgd3JpdHRlbiBJIGhhdmUgc2lnbmlmaWNhbnQgY29uY2VybnMg YWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRoYXQgdGhlIFJvdXRpbmcgQURzIGRp c2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PkNvbW1lbnRzOiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PlRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIHZlcnkgcmVhZGFibGUuIEkgbGlr ZWQgdGhlIHdheSB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24gcGxhY2VkIHRoaXMgZG9jdW1lbnQgaW4g dGhlIG92ZXJhbGwgY29udGV4dCBvZiBzZWN1cmluZyB0aGUgcm91dGluZyBpbmZyYXN0cnVjdHVy ZS4gVGhpcyBtYWtlcyBpdCBjbGVhciBob3cgdGhpcyByZWxhdGVzIHRvIG90aGVyIGVmZm9ydHMg KHN1Y2ggYXMgT1BTRUMsIFNJRFIpLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkhv d2V2ZXIsIHRoZXJlIGFyZSB0d28gcmVxdWlyZW1lbnRzIHdoaWNoIGFyZSBtaXNzaW5nIGZyb20g c2VjdGlvbiAzLCB0aGF0IElNSE8gYXJlIG5lY2Vzc2FyeSBmb3IgYW55IHNvbHV0aW9uIGRldmVs b3BlZCBieSBLQVJQIHRvIGJlIHVzZWFibGUuIFRoZXJlIGlzIGFsc28gYSByZXF1aXJlbWVudCB0 aGF0IGNvdWxkIHVzZSBhZGRpdGlvbmFsIGV4cGxhbmF0aW9uLiBJdCBpcyBwb3NzaWJsZSB0aGF0 IHRoZXNlIHJlcXVpcmVtZW50cyBtaWdodA0KYmUgc2F0aXNmaWVkIGJ5IHNvbHV0aW9ucyBldmVu IGlmIG5vdCBsaXN0ZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCwgYnV0IGl0IGlzIGZhciBi ZXR0ZXIgZm9ybSB0byBleHBsaWNpdGx5IGxpc3QgZXNzZW50aWFsIHJlcXVpcmVtZW50cy4gPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BcyB0aGUgYXV0aG9ycyBhcmUgd2VsbCBhd2Fy ZSwgdHdvIG9mIHRoZSBhdXRob3JzIGhhdmUgY2hhbmdlZCBlbWFpbCBhZGRyZXNzZXMgYW5kIEkg cGVyc29uYWxseSBkb27igJl0IGtub3cgaG93IGxvbmcgdGhlaXIgb2xkIGFkZHJlc3NlcyB3aWxs IHN0aWxsIHdvcmsuIFRoZWlyIGNvbnRhY3QgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHVwZGF0ZWQg aW4gdGhlIGRyYWZ0LiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1ham9yIElzc3Vl czogPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiBzZWN0aW9uIDMsIHJlcXVpcmVt ZW50cywgdGhlcmUgYXJlIHR3byBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIHRoYXQgYXBwZWFyIHRv IGJlIG1pc3NpbmcgKG9yIHBlcmhhcHMgb25seSBoaW50ZWQgaW4gb3RoZXIgcmVxdWlyZW1lbnRz KS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Bbnkgc2VjdXJpdHkgcHJvdG9jb2wg dGhhdCBpcyB1c2VkLCBmb3IgZXhhbXBsZSBmb3IgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50LCBN VVNUIGJlIGFibGUgdG8gb3BlcmF0ZSBiZXR3ZWVuIG11bHRpcGxlIHN5c3RlbXMgb3ZlciBhIEJy b2FkY2FzdCBtZWRpYS4gRm9yIGV4YW1wbGUsIGFsbCBvZiBJUy1JUywgT1NQRiwgYW5kIFJJUCBo YXZlIHRoZSBhYmlsaXR5IHRvIG9wZXJhdGUgYmV0d2VlbiBtdWx0aXBsZSByb3V0ZXJzIGludGVy Y29ubmVjdGVkDQp2aWEgYSBicm9hZGNhc3QgTEFOLCBhbmQgTERQIHVzZXMgbXVsdGljYXN0IGZv ciBkaXNjb3Zlcnkgb3ZlciBicm9hZGNhc3QgTEFOcy4gVGhpcyBuZWVkcyB0byBiZSBzdXBwb3J0 ZWQgZm9yIGEgc2VjdXJpdHkgcHJvdG9jb2wgdG8gYmUgdXNlYWJsZSBieSB0aGVzZSByb3V0aW5n IHByb3RvY29scy4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Bbnkgc2VjdXJpdHkg cHJvdG9jb2wgdXNlZCB0byBzZWN1cmUgYSByb3V0aW5nIHByb3RvY29sIE1VU1QgTk9UIGFzc3Vt ZSB0aGF0IHRoZSByb3V0aW5nIHByb3RvY29sIGlzIGl0c2VsZiBvcGVyYXRpbmcgYmVmb3JlIHRo ZSBzZWN1cml0eSBwcm90b2NvbCBjYW4gb3BlcmF0ZS4gRm9yIGV4YW1wbGUsIHRoaXMgbWVhbnMg dGhhdCBhbnkgcHJvdG9jb2wgdXNlZCB0byBnZW5lcmF0ZSBrZXlzIGZvciBvcGVyYXRpb24gb2Yg SVMtSVMgb3IgT1NQRg0KTVVTVCBOT1QgYXNzdW1lIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gc2Vu ZCBhbnkgcGFja2V0IGF0IGFsbCBiZXR3ZWVuIHR3byBzeXN0ZW1zIHVubGVzcyB0aG9zZSB0d28g c3lzdGVtcyBhcmUgZGlyZWN0bHkgY29ubmVjdGVkIGF0IHRoZSBsaW5rIGxldmVsLiA8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoaXMgbGFzdCBwb2ludCBoYXMgYSByZWxhdGlvbnNo aXAgd2l0aCB0aGUgcmVxdWlyZW1lbnQgY3VycmVudGx5IGxpc3RlZCBhcyBudW1iZXIgMjQuIEl0 IHNheXMg4oCcVGhlcmVmb3JlLCBwcm9wb3NlZCBzb2x1dGlvbnMgU0hPVUxEIE5PVCByZXF1aXJl IGNvbm5lY3Rpb25zIHRvIGV4dGVybmFsIHN5c3RlbXPigKbigJ0uIEhvd2V2ZXIsIG5vdGUgdGhh dCBpZiB0aGUgcHJvcG9zZWQgc29sdXRpb24gaXMgYmVpbmcgdXNlZCB0byBhdXRoZW50aWNhdGUN Ck9TUEYgb3IgSVMtSVMsIGFuZCBpZiBPU1BGIG9yIElTLUlTIHdpbGwgbm90IGJyaW5nIHVwIGxp bmtzIHVudGlsIHRoZXkgYXJlIGF1dGhlbnRpY2F0ZWQsIGFuZCBpZiB0aGUgcHJvcG9zZWQgc29s dXRpb24gcmVxdWlyZXMgc2VuZGluZyBhbnkgaW5mb3JtYXRpb24gdG8gb3IgZ2V0dGluZyBhbnkg cmVzcG9uc2UgZnJvbSBhIG5vdC1kaXJlY3RseS1hdHRhY2hlZCByZW1vdGUgc3lzdGVtLCB0aGVu IGl0IGlzbuKAmXQgZ29pbmcgdG8gd29yay4gSW4gdGhpcw0KcmVnYXJkIEkgdGhpbmsgdGhhdCB0 aGUg4oCcU0hPVUxEIE5PVOKAnSBpbiByZXF1aXJlbWVudCAyNCBpcyBub3Qgc3Ryb25nIGVub3Vn aCwgYW5kIHRoZSBwb3RlbnRpYWwgZm9yIGRlYWRsb2NrIHNob3VsZCBiZSBleHBsaWNpdGx5IG1l bnRpb25lZC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlNlY3Rpb24gMywgOTxmb250 IHNpemU9IjEiPjxzdXA+dGg8L3N1cD48L2ZvbnQ+IGJ1bGxldCBpdGVtIChhYm91dCBET1MgYXR0 YWNrcyk6IFJvdXRlcnMgYXJlIG9jY2FzaW9uYWwgaW50ZW5kZWQgdmljdGltcyBvZiBERE9TIGF0 dGFja3MsIHdoaWNoIG1heSBiZSBhaW1lZCBhdCB0aGUgcm91dGVy4oCZcyBjb250cm9sIHBsYW5l LiBBcyBzdWNoIGl0IGlzIG5vcm1hbCBmb3Igcm91dGVycyB0byBtYWtlIHVzZSBvZiBwYWNrZXQg ZmlsdGVycyB0bw0KcHJvdGVjdCB0aGUgY29udHJvbCBwbGFuZSwgZnJlcXVlbnRseSBpbXBsZW1l bnRlZCBpbiBzaWxpY29uIGFuZCBvcGVyYXRpbmcgYXQgbGluZSByYXRlICh3aGljaCBtYXkgaW1w bHkgaW4gY29yZSByb3V0ZXJzIHRoZSBhYmlsaXR5IHRvIGlkZW50aWZ5IGFuZCBkaXNjYXJkIGh1 bmRyZWRzIG9mIGdpZ2FiaXRzIG9yIGV2ZW4gdGVyYWJpdHMgb2YgYXR0YWNrIGluZm9ybWF0aW9u IHdpdGhvdXQgaGF2aW5nIGFueSBhZHZlcnNlIGVmZmVjdCBvbiBvdGhlcg0KYXNwZWN0cyBvZiBy b3V0ZXIgb3BlcmF0aW9uIOKAkyBvdGhlciB0aGFuIHRoZSBsaW5rIGJhbmR3aWR0aCB0aGF0IHRo ZSBhdHRhY2sgY29uc3VtZXMgcHJpb3IgdG8gYXJyaXZpbmcgYXQgdGhlIHJvdXRlcikuIFdlIGFy ZW7igJl0IHJlYWxpc3RpY2FsbHkgbGlrZWx5IHRvIGJlIGNoZWNraW5nIGNyeXB0b2dyYXBoaWMg YXV0aGVudGljYXRpb24gYW5kIGRpc2NhcmRpbmcgdW53YW50ZWQgdHJhZmZpYyBhdCB0ZXJhYml0 IHJhdGVzIGluIHJvdXRlcnMsIHdoaWNoDQppbXBsaWVzIHRoYXQgdGhlIGV4aXN0aW5nIHBhY2tl dCBmaWx0ZXJpbmcgbWVjaGFuaXNtcyBuZWVkIHRvIGJlIG1haW50YWluZWQsIGFuZCB0aGF0IEtB UlAgaXMgdGFsa2luZyBhYm91dCAqYWRkaXRpb25hbCogcHJvdGVjdGlvbiwgbm90IGEgcmVwbGFj ZW1lbnQgZm9yIHBhY2tldCBmaWx0ZXJzIHRvIHByb3RlY3QgYWdhaW5zdCBERE9TLiBUaHVzIGlu IGRlZmluaW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgdGhlcmUgc2hvdWxkIGJlIGEgc3Ryb25nDQpw cmVmZXJlbmNlIGZvciBtZWNoYW5pc21zIHRoYXQgZG9u4oCZdCBoaWRlIG5vciBlbmNyeXB0IHRo ZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSByb3V0ZXIgaGFyZHdhcmUgaXMgYWJsZSB0byZuYnNwOyBp bnNwZWN0IGF0IGZ1bGwgbGluZSByYXRlIGZvciBERE9TIHByb3RlY3Rpb24gKHN1Y2ggYXMgSVAg YWRkcmVzc2VzLCBhbmQgVENQIHBvcnRzKS4gSSB0aGluayB0aGF0IGEgYml0IG1vcmUgdGV4dCBh bG9uZyB0aGUgbGluZXMgbWlnaHQgYmUgYXBwcm9wcmlhdGUNCnRvIGJlIGFkZGVkIHRvIHRoaXMg YnVsbGV0IGl0ZW0uJm5ic3A7IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TWlub3Ig SXNzdWVzOiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldoYXQgaXMgdGhlIGF1ZGll bmNlPyBTZWN0aW9uIDEuNyBzYXlzIHRoYXQgdGhpcyBpbmNsdWRlcyDigJxSb3V0aW5nIEFyZWEg d29ya2luZyBncm91cCBjaGFpcnMgYW5kIHBhcnRpY2lwYW50c+KAnS4gU29tZSBvZiB0aGVzZSBt YXkgb3IgbWF5IG5vdCBrbm93IG11Y2ggYWJvdXQgc2VjdXJpdHkuIEl0IHRoZXJlZm9yZSBtaWdo dCBiZSBhIGdvb2QgaWRlYSB0byBkZWZpbmUgYSBmZXcgYmFzaWMgc2VjdXJpdHkgdGVybXMgaW4g c2VjdGlvbiAxLjEsDQppbiBwYXJ0aWN1bGFyIOKAnG5vbi1yZXB1ZGlhdGlvbuKAnSBpcyBub3Qg bGlrZWx5IHRvIGJlIHVuaXZlcnNhbGx5IHVuZGVyc3Rvb2QuIOKAnFByaXZhY3nigJ0sIOKAnWF1 dGhlbnRpY2F0aW9u4oCdLCBhbmQg4oCcbWVzc2FnZSBpbnRlZ3JpdHnigJ0gc2VlbSBtb3JlIG9i dmlvdXMsIGJ1dCBtaWdodCBiZSB3b3J0aCBkZWZpbmluZyBhbHNvLjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+SW4gc2VjdGlvbiAzLCByZXF1aXJlbWVudCAxNiwgSSB3b3VsZCBwdXQg dGhpcyBhcyDigJxNVVNUIE5PVOKAnSByYXRoZXIgdGhhbiDigJxTSE9VTEQgTk9U4oCdLiBUaGUg ZmFpbHVyZSB0byBwcmlvcml0aXplIEhFTExPIHByb2Nlc3NpbmcgaGFzIGF0IHNvbWUgcG9pbnRz IGluIHRoZSBwYXN0IGhhZCBjYXRhc3Ryb3BoaWMgaW1wbGljYXRpb25zIG9uIG5ldHdvcmsgb3Bl cmF0aW9uLiBBbnkgbWVjaGFuaXNtIHRoYXQgYnJlYWtzIHRoZSBwcmlvcml0aXphdGlvbg0Kb2Yg SEVMTE9zIGlzIGVzc2VudGlhbGx5IHVudXNhYmxlLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2Pih2ZXJ5IG1pbm9yKSBJbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDEu NCwgeW91IGNvdWxkIG1lbnRpb24gdGhhdCByb3V0aW5nIHByb3RvY29scyBhcmUgZXNzZW50aWFs bHkgcmVhbCB0aW1lIGRpc3RyaWJ1dGVkIHN5c3RlbXMsIGluIHRoYXQgdGhlcmUgYXJlIHJvdXRp bmcgcHJvdG9jb2wgZXZlbnRzIHRoYXQgcm91dGVycyBtdXN0IHBlcmZvcm0gaW4gYSBzcGVjaWZp YyB0aW1lIGZyYW1lIGluIG9yZGVyIHRvIHByZXZlbnQNCm90aGVyIHN5c3RlbXMgZnJvbSByZWFj dGluZyBpbiB1bmZvcnR1bmF0ZSB3YXlzLiZuYnNwOyBUaHVzIHRoZSBuZWVkIGZvciDigJxleHRl bnNpdmUgdHVuaW5nIG9mIHNvZnR3YXJlIGFuZCBoYXJkd2FyZSBlbGVtZW50c+KAnSBhcyB5b3Ug c3RhdGUuIEFzIG9uZSBleGFtcGxlICh3aGljaCB5b3UgcHJvYmFibHkgZG9u4oCZdCBuZWVkIHRv IGV4cGxpY2l0bHkgZGVzY3JpYmUsIGJ1dCBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIGF1dGhvcnMp IHRoZXJlIGhhdmUgYmVlbg0KdGltZXMgaW4gdGhlIHBhc3Qgd2hlcmUgZHVlIHRvIGJlaW5nIHZl cnkgYnVzeSBkdWUgdG8gbmV0d29yayBldmVudHMsIGEgcm91dGVyIGhhcyBmYWlsZWQgdG8gc2Vu ZCBvciB0byByZWNlaXZlIEhFTExPIG1lc3NhZ2VzIHdpdGhpbiB0aGUgcmVxdWlyZWQgdGltZSBm cmFtZSwgYW5kIGFzIGEgcmVzdWx0IHJvdXRlcnMgaGF2ZSBkZWNsYXJlZCBsaW5rcyBkb3duLiBU aGlzIGNhbiByZXN1bHQgaW4gYWRkaXRpb25hbCByb3V0aW5nIHByb3RvY29sIHRyYWZmaWMNCndo aWNoIGNhbiBleGFjZXJiYXRlIHdoYXRldmVyIGV2ZW50IGNhdXNlIGEgcm91dGVyIHRvIGJlIGJ1 c3kgaW4gdGhlIGZpcnN0IHBsYWNlLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk5p dHM6IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4gc2VjdGlvbiAxLjQsIHBlcnNv bmFsbHkgSSB3b3VsZCBwdXQg4oCcdmFzdGx5LSBpbXByb3ZlZC1vdmVyLWN1cnJlbnQtc2VjdXJp dHktYnV0LWFkbWl0dGVkbHktbm90LXlldC1iZXN0LXNlY3VyaXR5LSBwb3NzaWJsZeKAnSBpbiBx dW90ZXMgcmF0aGVyIHRoYW4gd3JpdGluZyB0aGlzIGxvbmdpc2ggcGhyYXNlIHdpdGggZGFzaGVz LiBJZiBkb2luZyB0aGlzLCB0aGVuIHBlcmhhcHMg4oCcYmVzdC1zZWN1cml0eS1wb3NzaWJsZeKA nSBjb3VsZCBhbHNvDQpiZSBpbiBxdW90ZXMuIFRoZSBwb2ludCBpcyBlYXN5IHRvIHVuZGVyc3Rh bmQgaG93ZXZlciBhcyBpcyAoYW5kIG1ha2VzIHNlbnNlKS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5MYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDEuNCwgYXJlIHdlIG1pc3Npbmcg dGhlIHdvcmQg4oCcYW5k4oCdIGJlZm9yZSDigJxUQ1Agc2Vzc2lvbiByZXNldHRpbmfigJ0/IDwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+U2VjdGlvbiAxLjUsIHRoaXJkIG51bWJlcmVk IGJ1bGxldDogVGhlIGZpcnN0IOKAnHNlbnRlbmNl4oCdIG9mIHRoaXMgaXMgbm90IGFjdHVhbGx5 IGEgc2VudGVuY2UuIFRoZXJlIGlzIGEgdmVyYiBtaXNzaW5nLiBEbyB5b3UgbWVhbiDigJxFbnN1 cmUgdGhlIGRlcGxveWFiaWxpdHkgb2YgdGhlIGltcHJvdmVkIHNlY3VyaXR5IHNvbHV0aW9ucyBv biBjdXJyZW50bHkgcnVubmluZyByb3V0aW5nIGluZnJhc3RydWN0dXJlIGVxdWlwbWVudC7igJ0/ IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+U2VjdGlvbiAxLjUsIGZvdXJ0aCBudW1i ZXJlZCBidWxsZXQ6IFlvdSBoYXZlIHdhbmRlcmVkIGF3YXkgZnJvbSBhIHBhcmFsbGVsIHdyaXRp bmcgc3R5bGUgZm9yIGVhY2ggbnVtYmVyZWQgYnVsbGV0IGluIHRoaXMgc2VjdGlvbi4gVGhlIGZp cnN0IHR3byBzdGFydCB3aXRoIGEgc2VudGVuY2UuIFRoZSB0aGlyZCBzdGFydHMgd2l0aCBzb21l dGhpbmcgdGhhdCBhcHBlYXJzIHRvIGJlIGludGVuZGVkIHRvIGJlIGEgc2VudGVuY2UsIGJ1dCBp c27igJl0DQpxdWl0ZS4gVGhlIGZvdXJ0aCBzdGFydHMgd2l0aCBhIGhlYWRpbmcg4oCcT3BlcmF0 aW9uYWwgZGVwbG95YWJpbGl0eeKAnS4gSXQgd291bGQgcmVhZCBiZXR0ZXIgdG8gbWFpbnRhaW4g dGhlIHNhbWUgc3R5bGUgaW4gZWFjaCBidWxsZXQgKGVpdGhlciBzdGFydCB0aGUgZmlyc3QgdGhy ZWUgd2l0aCBhIGhlYWRpbmcsIG9yIGRvbuKAmXQgc3RhcnQgdGhlIGZvdXJ0aCB3aXRoIGEgaGVh ZGluZykuIEkgbGlrZSB0aGUgaGVhZGluZyBvbiB0aGlzIGZvdXJ0aCBidWxsZXQsDQphbmQgd29u ZGVyIHdoZXRoZXIgeW91IHNob3VsZCBjb21lIHVwIHdpdGggb25lcyBmb3IgdGhlIGZpcnN0IHRo cmVlIGJ1bGxldHMuIEFsdGVybmF0ZWx5IHRoZSBoZWFkaW5nIG9uIGJ1bGxldCBmb3VyIGNvdWxk IGJlIHR1cm5lZCBpbnRvIGEgdmVyeSBzaG9ydCBzZW50ZW5jZSwgc3VjaCBhcyDigJxFbnN1cmUg b3BlcmF0aW9uYWwgZGVwbG95YWJpbGl0eSDigJwuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+U2VjdGlvbiAxLjcsIGZpcnN0IGJ1bGxldCBpdGVtOiBUbyBtZSB0aGUgdGVybSDigJxD by1hZHZpc29yc+KAnSBzaG91bGQgYmUganVzdCDigJxBZHZpc29yc+KAnS4gPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWFsbHkgbWlub3IsIHNlY3Rpb24gMywg4oCcUm91aW5nIFBy b3RvY29s4oCdLiBJcyDigJxwcml2YWNleeKAnSBzcGVsbGVkIGN1cnJlbnRseSBpbiBpdGVtIDcg b2Ygc2VjdGlvbiAzPzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DF7F294AF4153D498141CBEFADB17704C2E1DE512EEMBX01WFjnprn_-- From jdrake@juniper.net Thu Aug 11 14:37:24 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6608921F8736 for ; Thu, 11 Aug 2011 14:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.081 X-Spam-Level: X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8o1K18H5ZOp for ; Thu, 11 Aug 2011 14:37:23 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 15CA621F86F4 for ; Thu, 11 Aug 2011 14:37:23 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTkRLrcTbztF08rou4cJSdsLeAYvUZ/gV@postini.com; Thu, 11 Aug 2011 14:37:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 11 Aug 2011 14:36:23 -0700 From: John E Drake To: "rtg-ads@tools.ietf.org" Date: Thu, 11 Aug 2011 14:36:21 -0700 Thread-Topic: RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt Thread-Index: AcxYbrZgrOy15FlHTbWbuc2wvgtr+A== Message-ID: <5E893DB832F57341992548CDBB333163A0AC854B63@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-rsvp-te-no-php-oob-mapping.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 21:37:24 -0000 SGVsbG8sIA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3Mg dG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBw YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVz IG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92 aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSBodHRwOi8vd3d3LmlldGYu b3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1sIA0KDQpBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRy YWZ0LiANCg0KRG9jdW1lbnQ6ICBkcmFmdC1pZXRmLW1wbHMtcnN2cC10ZS1uby1waHAtb29iLW1h cHBpbmctMDgudHh0IA0KUmV2aWV3ZXI6IEpvaG4gRHJha2UgDQpSZXZpZXcgRGF0ZTogMTEtQXVn LTExIA0KSUVURiBMQyBFbmQgRGF0ZTogMTEtQXVnLTExIA0KSW50ZW5kZWQgU3RhdHVzOiBQcm9w b3NlZCBTdGFuZGFyZCANCg0KU3VtbWFyeTogDQoNCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5z IGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZv cmUgcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOiANCg0KVGhlIGRvY3VtZW50IGlzIHdlbGwtd3Jp dHRlbiBhbmQgdmVyeSByZWFkYWJsZSwgYW5kIGlzIG5pY2VseSBmb2N1c2VkIG9uIHNvbHZpbmcg YSBzcGVjaWZpYyBwcm9ibGVtIHRoYXQgaGFzIGV4aXN0ZWQgZm9yIHF1aXRlIA0Kc29tZSB0aW1l LiANCg0KTWFqb3IgSXNzdWVzOiANCg0KTm8gbWFqb3IgaXNzdWVzIGZvdW5kDQoNCk1pbm9yIElz c3VlczoNCiANClRoZXJlIGFyZSBzZXZlcmFsIGFwcGFyZW50bHkgbm9ybWF0aXZlIHJlZmVyZW5j ZXMgdG8ge0FUVFJJQlVURVMtQk5GXSB3aGljaCBJIGNvdWxkIG5vdCBmaW5kIGluIHRoZSBSZWZl cmVuY2VzIHNlY3Rpb24uDQoNCkl0IHByb3Bvc2VzIGFuIGFkanVuY3QgcHJvY2VkdXJlIHRvIGJl IHBlcmZvcm1lZCBieSB0aGUgaW5ncmVzcyBpbiBhZGRpdGlvbiB0byBpdHMgY2hlY2tpbmcgb2Yg dGhlIHNldHRpbmcgb2YgdGhlICdOb24tUEhQIGJlaGF2aW9yIGFja25vd2xlZGdlbWVudCBmbGFn JyBpbiB0aGUgRmxhZ3MgZmllbGQgb2YgdGhlIFJSTy4gIFRoaXMgcHJvY2VkdXJlIGlzIHRvIGNo ZWNrIHRoZSBSUk8gdG8gc2VlIHdoZXRoZXIgdGhlIGVncmVzcyBhbGxvY2F0ZWQgYSBub24tbnVs bCBsYWJlbCBmb3IgdGhlIExTUDsgIGl0IGlzIHVubmVjZXNzYXJ5IGFuZCBJIHdvdWxkIHN1Z2dl c3QgcmVtb3ZpbmcgaXQuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KDQo= From rcallon@juniper.net Fri Aug 12 11:03:28 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67C921F8754 for ; Fri, 12 Aug 2011 11:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7EU1yyfVcz8 for ; Fri, 12 Aug 2011 11:03:28 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id AB96E21F8751 for ; Fri, 12 Aug 2011 11:03:12 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTkVq+HgkUui3Quf6uik9xZFkuMBjOk8X@postini.com; Fri, 12 Aug 2011 11:03:51 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 12 Aug 2011 11:03:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 12 Aug 2011 14:03:16 -0400 From: Ross Callon To: "Bhatia, Manav (Manav)" , "adrian@olddog.co.uk" , "stbryant@cisco.com" Date: Fri, 12 Aug 2011 14:03:13 -0400 Thread-Topic: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxYPeO+scq5n+URQ/KnpmonjfDQIgAji+aQAA7UFAA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "rtg-dir@ietf.org" , "russw@riw.us" , Gregory Lebovitz , "gregory.ietf@gmail.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:03:28 -0000 I think that we are close. Looking at your proposed new text relating to DO= S attacks:=20 New mechanisms must resist DoS attacks described as in-scope in the threats section 2.1 above. Routers protect the control plane by implementing mechanisms to filter completely or rate limit traffic not required at the control plane level (i.e., unwanted traffic).=20 This is done by deep inspecting the packets and only accepting the legitimate ones. The new mechanisms shouldn't thus hide or encrypt the information carried in the control plane packets so that routers can inspect these packets at the line rate. To me "deep inspection" is something that looks deeper than just the IP and= transport layer headers, and that typically can't be done at full line rat= e on very fast interfaces. It would be lovely to do deep packet inspection = and cryptographic authentication checking at full line rate on all interfac= es on terabit routers, but this isn't likely to happen any time in the fore= seeable future. Thus service provider routers need to do full line rate fil= tering on as much as can be done at full line rate, and might or might not = also separately do deep inspection of packets that are headed for the contr= ol plane. We have certainly seen (as of several years ago, I assume that at= tacks have probably gotten worse) multi-gigabit attacks on the control plan= e of routers, which of course a gigabit Ethernet link to the control plane = can't carry. Thus I don't think that the sentence "This is done by deep inspecting the p= ackets and only accepting the legitimate ones." is quite right. I would be= inclined to just remove this sentence since the previous sentence captures= the point quite well. The next sentence already gets at the point that the= se filters should operate at full line rate. Typically (not universally in = all routers) what the large routers can filter on at line rate includes the= IP and transport (TCP or UDP) headers, and stuff below that (including inc= oming link), but does not include stuff above that in the stack. We might w= ant to mention this, so that the paragraph becomes:=20 New mechanisms must resist DoS attacks described as in-scope in the threats section 2.1 above. Routers protect the control plane by implementing mechanisms to filter completely or rate limit traffic not required at the control plane level (i.e., unwanted traffic).=20 Typically line rate packet filtering capabilities look at information=20 at or below the IP and transport (TCP or UDP) headers, but do not=20 include higher layer information. Therefore the new mechanisms shouldn't = =20 hide nor encrypt the information carried in the IP and transport layers in control plane packets. Are you proposing that this paragraph be added to the existing text in requ= irement number 9?=20 Also, this seems independent of the text relating to communicating with ext= ernal systems. I will respond to that in a different email (after first get= ting a snack).=20 thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russ= w@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, =20 Thanks for the detailed review! =20 > This last point has a relationship with the requirement currently=20 > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if=20 > the proposed solution is being used to authenticate OSPF or IS-IS,=20 > and if OSPF or IS-IS will not bring up links until they are=20 > authenticated, and if the proposed solution requires sending any=20 > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think=20 > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? =20 > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended=20 > victims of DDOS attacks, which may be aimed at the router's control=20 > plane. As such it is normal for routers to make use of packet=20 [clipped] > against DDOS. Thus in defining security mechanisms there should be a=20 > strong preference for mechanisms that don't hide nor encrypt the=20 > information that the router hardware is able to inspect at full=20 > line rate for DDOS protection (such as IP addresses, and TCP ports).=20 > I think that a bit more text along the lines might be appropriate=20 > to be added to this bullet item. =20 How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav =20 From rcallon@juniper.net Fri Aug 12 12:01:55 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4514E11E8099 for ; Fri, 12 Aug 2011 12:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5D7C6w4JYPX for ; Fri, 12 Aug 2011 12:01:54 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10E11E8090 for ; Fri, 12 Aug 2011 12:01:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTkV4wZGjSqqfAUpyUKNxGz5ImmMKdwAf@postini.com; Fri, 12 Aug 2011 12:02:32 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 12 Aug 2011 12:00:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 12 Aug 2011 15:00:55 -0400 From: Ross Callon To: "Bhatia, Manav (Manav)" Date: Fri, 12 Aug 2011 15:00:53 -0400 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxYPeO+scq5n+URQ/KnpmonjfDQIgAji+aQABTlI6A= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "gregory.ietf@gmail.com" , "stbryant@cisco.com" Subject: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:01:55 -0000 Regarding requirement number 24, changing "should not" to "must not" does h= elp a lot. However, it might be worth adding a bit of explanation. How abou= t: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. NEW 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that=20 is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a=20 circular dependency between the security mechanisms and routing (which itself is required to deliver IP packets to any external=20 systems which are not directly connected at the link layer). Therefore, proposed solutions MUST NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. Does this look okay to you?=20 Thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russ= w@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, =20 Thanks for the detailed review! =20 > This last point has a relationship with the requirement currently=20 > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if=20 > the proposed solution is being used to authenticate OSPF or IS-IS,=20 > and if OSPF or IS-IS will not bring up links until they are=20 > authenticated, and if the proposed solution requires sending any=20 > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think=20 > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? =20 > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended=20 > victims of DDOS attacks, which may be aimed at the router's control=20 > plane. As such it is normal for routers to make use of packet=20 [clipped] > against DDOS. Thus in defining security mechanisms there should be a=20 > strong preference for mechanisms that don't hide nor encrypt the=20 > information that the router hardware is able to inspect at full=20 > line rate for DDOS protection (such as IP addresses, and TCP ports).=20 > I think that a bit more text along the lines might be appropriate=20 > to be added to this bullet item. =20 How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav =20 From ycai@cisco.com Tue Aug 9 14:12:47 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A4A21F8CD7 for ; Tue, 9 Aug 2011 14:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOeAHiNtxOsh for ; Tue, 9 Aug 2011 14:12:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E8ED221F8C75 for ; Tue, 9 Aug 2011 14:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=14154; q=dns/txt; s=iport; t=1312924394; x=1314133994; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=5eYdtaE2YPXH1Z7OHx32VjCAkJrhRDTyioU9yckvbHM=; b=juIQP7PzNfP0PgN8IdoN0z+GmL0IAUMuQ4GYjL3/uuf8qAlnpWW3rXl+ VKKtljlgjD0ZsyQH+xd0l5kp2//WXpP1b4bucttVHFxirDJ+sP8eFob8z 08yHTIVxTBLZl7mAAdR4sxxN2MeksXK4jdnLcqrT9tfzUDAikKnMplQVy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4IAECiQU6rRDoI/2dsb2JhbABCpz0Cd4FAAQEBAQIBEgEnAgEvCggNAQgUgQkBAQQBEgkZh0sEnwsBnlGGRgSHXIsphRKHXYQc X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208";a="11487077" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 09 Aug 2011 21:12:49 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p79LCn9a006807; Tue, 9 Aug 2011 21:12:49 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 14:12:49 -0700 Received: from 128.107.161.230 ([128.107.161.230]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Aug 2011 21:12:48 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 09 Aug 2011 14:12:55 -0700 From: Yiqun Cai To: Thomas Heide Clausen , , , Message-ID: Thread-Topic: RtgDir review: draft-ietf-pim-mtid-08.txt Thread-Index: AcxW2RshvlFMJnqRC0OP2QQ+tQCIvQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Aug 2011 21:12:49.0179 (UTC) FILETIME=[17A9AEB0:01CC56D9] X-Mailman-Approved-At: Sun, 14 Aug 2011 19:21:49 -0700 Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:12:47 -0000 Thomas, Thank you very much for the review. Please see comments inline. On 6/28/11 9:47 AM, "Thomas Heide Clausen" wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. For more information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-pim-mtid-08.txt > Reviewer: Thomas Heide Clausen > Review Date: 2011-06-27 > IETF LC End Date: 2011-06-27 > Intended Status: Proposed Standard > > Summary: > > I have some minor concerns about this document that I think should be resolved > before publication. > > Comments: > > This is the first PIM document I have reviewed, so I went back and read some > of the previous > RFCs. It may mean that my review is not sufficiently in-depth. > > The document is relatively difficult to read. Specifically the introduction > reads more like a > problem statement (e.g. "if PIM was able to access .... it would be ...") than > it does a specification. > I would much prefer to have perhaps a very short motivational subsection to > the introduction, > then introduce that which this document actually introduces (and how). > Currently, that is difficult > to extract. This was actually described in the 4th paragraph in the "Introduction". "This document introduces a new type of PIM Join Attribute ...". As Marshall pointed out in another review comment, there are potentially quite a few use cases that can benefit from this functionality. We hoped to capture at least one of them. > > I feel that RFC2119 language is not used consistently, and that terminology in > general is > used somewhat inconsistently. Is "MT-ID" and "PIM MT-ID" the same or different > things, for example? > I would suggest that this is in part due to the absence of the by now > traditional "Terminology" section, > which (in my opinion) has as its primary role to ensure that spec-authors are > conscious and consistent > in their choice of words inside a spec. We will add a section to clarify that. > > I find that there are some internal inconsistencies in the document, i.e. > where it is stating different > things in different sections (e.g. that one MUST NOT include a MT-ID Join > Attribute with value 0 -- > yet that when performing a validity check, a Join packet with an MT-ID=0 is > still considered valid). Indeed. However it was done on practical purpose, 1. we want to specify a valid range 2. we also want to specify what an implementation should behave if another implementation includes a value that is outside of that range. What we learned from our experience is that if we don't specify how to handle error cases, we will consistently run into interop issues that can't be solved easily. > > One concern that I do have with the document is, that there are no references > to any kind of > previous work (typically, I would expect this to have been well studied in > academia) suggesting > the usefulness and justifying the validity of the proposed approach. Note: I > am not saying that > the approach isn't useful and valid - I am saying that I do not know, and > would feel comforted by > some supporting references to this effect. Actually, this is the first attempt to integrate multi-topology routing with multicast. > > Major Issues: > > o I have actually not found any single "major issues", however I feel that the > document is > hard to read and that the collection of the "minor issues" below would > constitute a single > "major issue". > > Minor Issues: > > o The RFC2119 language is typically seen in a terminology section; something > which > I feel that this document should have, if for no reason other than to help new > readers > to PIM family of documents. It could be as simple as importing (pointing to) > relevant > terminology from RFC5496/5384/4601 We will fix as suggested. > > o Also, the RFC2119 paragraph does not reflect the errata ("NOT RECOMMENDED" > is missing) Will fix. > > o Penultimate paragraph of section 2 "It might further need to perform the > function > of splitting and merging. But the detailed processing is beyond the scope of > the > document". It would be beneficial with elaboration of under which conditions > "splitting and merging" is required, as well as some guidance - for example, > in form > of a pointer to where these conditions are detailed. > > o Ultimate paragraph of section 2: "the MT-ID Join Attribute may be simply > referred to as MT-ID" > -- suggest "the MT-ID Join Attribute will be referred to as MT-ID > Ok > o This may be a matter of individual style, but I do not like empty section > introductions, > such as 3. > > o 3rd paragraph in 3.1, suggest removing "please" > > o Suggest that the figure in 3.1 be given a proper figure environment and > number, and > that references (especially later in the document) be given to that figure > number. > Ok. > o As a relatively newcomer to PIM, examples are appreciated. Alas, the example > in > section 3.1 actually didn't help my understanding much. Also, that example is > filled with details, whose importance I am not sure I capture: is the choice > of > "OSPF 1000" and "OSPF 2000" (etc.) important, or are they simply illustrative. > The text was added based on the comment from WG LC. Some people do like to see how MT-IDs are assigned numerically. > o First paragraph on page 5 states "The above example shows that the naming > spaces of > MT-ID are not required to be the same between PIM and IGPs". That appears > reasonable > -- however the last bullet point in section 3.2 on the same page goes on to > say that > "...the PIM MT-ID is RECOMMENDED to be assigned using the same value as the > IGP > topology identifier". Yes. The text describes two different cases and provides two different recommendations depending on how the topologies are built. > > Citing RFC2119: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > It appears to me that if this RFC2119 meaning is intended, then it would be > important > to (i) explain why and (ii) give guidance as to understand what the > implications are of > not following the recommendation. > > o Also, the document contains many uses of "must", "may" and "should" in > lowercase - I am > wondering if some (all?) of these should be capitalized to RFC2119 terms. I am > trying to > point out those I catch, but I would recommend that the authors review the > document to > ensure that they capitalize those where they mean RFC2119 terminology. > We will go through the document one more time and fix them if appropriate. > o On the same first paragraph on page 5, when I read " .... shows that ....", > then I actually > expect a bit more rigor - tainted by having spent too much time in academia, > perhaps, > but I read "...shows that ..." to entail (close to) a formal proof. Maybe > "....illustrates that..." > is a better choice of words? > Sure. > Same holds for the last bullet point on page 5. > > o Same paragraph, what exactly is meant by "...the prefix covering S...."? I > assume that > it has something to do with that routing state for S is not maintained by the > two routing > topologies? > In multicast jargons, S usually refers to a /32 host address (assuming IPv4). But the routing table usually contains only a prefix that covers or includes S, instead of S. > o Generally to section 3.1, it is somewhat unclear what this specification > does, vs. what > PIM already does, which caused me to chase off reading PIM RFCs. > > Reading through the specification, would it be correct to say that: > > - This I-D introduces a new name-space, the "PIM MT-ID" > - A given topology is provisioned with that "PIM MT-ID" by way of a > "MT-ID PIM Join Attribute", defined by this specification? > > If yes, then I would suggest calling that out explicitly. No it is not a new name-space. This document introduces a new type of Join Attribute which was introduced by RFC5384. > > o Section 3.2, second bullet-point talks about "...a value is not required to > be the same as > the MT-ID used by the unicast routing protocol ...." However the ultimate > paragraph in > section 2 defines MT-ID to be a "Join Attribute", which is a PIM-entity > (RFC5384). Do > you mean to say that this MT-ID should be used also in an unicast routing > protocol, or > is it a terminology issue? MT-ID is used by unicast routing protocols (such as OSPF and IS-IS). This document introduces its use to PIM via PIM Join Attribute. > > o Page 6, second bullet "This value must be unique and consistent within the > network domain...." > > - must or MUST? > - "network domain" is a wonderfully vague term. A quick google leads to the > first many results relating to either "LAN-style domain controllers" or DNS. > Suggest that his might be a good candidate term for replacement, or for > definition in a terminology section. It is probably better that we remove "domain". > > o Section 4.2.1, "...it may chose" - may or MAY? Also, can guideline be given > as to when > a PIM router would chose to, or not, encode the PIM MT-ID? Finally, "PIM > MT-ID", is that > the same as what the ultimate paragraph of section 2 calls "MT-ID". In this document, yes they are the same. > > o Section 4.2.1: missing colon before bullet points > > o Section 4.2.1 first bullet point: why MUST NOT? What are the consequences of > including a Join Attribute when the MT-ID=0? > Specifically, in 4.2.3, the ultimate bullet, the validation rules simply state > that if > the value is 0, then the Join Attribute "...is ignored" (there is a SHOULD or > MUST > needed here?) and that the rest of the message is processed as if that Join > Attribute was not included. In common practice (as with OSPF and IS-IS too), 0 is reserved for "default" topology. Including 0 will cause unnecessary interop issues that brings no additional gain. Thus we prevent the inclusion of it. > > o Section 4.2.1 2nd and 3rd bullet points, why "SHOULD NOT"? Can any guidance > be provided with respect to the consequences of ignoring such recommendation > (or, if there are no negative consequences, then the benefits of following > them)? > Because these packets do not require the receiving router to perform any RPF action. And when a router doesn't perform RPF action, MT-ID is not needed. > o Section 4.2.2 first bullet - prefer section references (if using xml2rfc > tags) > rather than "next section" or "in section Conflict Resolution". This is a > general comment, > but this seemed like a good point to mention this. > Ok > o Section 4.2.3, first bullet: as t his is about "Validating a PIM MT-ID Join > Attribute", I find it > curious that it suggests to check that there is at most 1 PIM MT-ID Join > Attribute included - > then goes on to say that it's OK if there are more, just ignore all but the > last. I would suggest > that either this is a validation check and so if more than 1 PIM MT-ID Join > Attribute then > the packet is malformed and should be discarded - or, that this be specified > somewhere > other than a section specifying how to determine if an attribute is valid or > not. That is exactly why we wanted to include this document how to handle error case. We can choose to discard, or ignore the attributes but continue with the next update. The second is more appropriate for PIM because "discarding" would require a rewinding of the operation already done on previous PDUs which is hard to do. > > o Same section & bullet: the title is "Validating a PIM MT-ID Join Attribute", > i.e. validating _a_ single > such. Yet, the bullet talks about having possibly multiple PIM MT-ID Join > Attributes encoded. > Encoded where? Should this section be retitled "Validating a Join Packet with > a PIM MT-ID > Join Attribute" instead? The paragraph does attempt to describe how to validate the particular type of Join Attribute that is PIM MT-ID. It doesn't specify how to validate Join Attributes or the Join message in general. > > o Section 5: Suggest that encoding, byte-order, ..., be called out (NBO, > unsigned integer, ....) for > newly defined fields. > Ok. > o Section 5: Suggest calling out that reserved bits SHOULD be cleared on > transmission and > MUST be ignored on reception. > Yes it s ithere. > o Section 5: Suggest citing the spec defining the format used (RFC5384?), > least it appears > odd to have an 8 bit "Length" field, and yet defining its value to always be > 2. > That would be RFC4601. > o Section 6, IANA considerations. > > - Suggest that "The IANA" be replaced by simply "IANA" > Ok. > - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option Type > ...." > Not yet but IANA will. > - I do not understand what the IANA action for the ultimate paragraph in 6.1 > is about? > The headings are wrong. We will fix them. > Respectfully Yours, > > Thomas Thanks again. -- Yiqun From manav.bhatia@alcatel-lucent.com Fri Aug 12 02:08:32 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBD721F86AE for ; Fri, 12 Aug 2011 02:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6I-n73Q7iai for ; Fri, 12 Aug 2011 02:08:32 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E76A921F86AB for ; Fri, 12 Aug 2011 02:08:31 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7C98vLn016050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2011 04:09:01 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7C98pPY022272 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Aug 2011 14:38:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 12 Aug 2011 14:38:51 +0530 From: "Bhatia, Manav (Manav)" To: Ross Callon , "adrian@olddog.co.uk" , "stbryant@cisco.com" Date: Fri, 12 Aug 2011 14:38:32 +0530 Thread-Topic: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxYPeO+scq5n+URQ/KnpmonjfDQIgAji+aQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> References: 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Sun, 14 Aug 2011 19:23:59 -0700 Cc: "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "rtg-dir@ietf.org" , "russw@riw.us" , Gregory Lebovitz , "gregory.ietf@gmail.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:08:32 -0000 Hi Ross, =20 Thanks for the detailed review! =20 > This last point has a relationship with the requirement currently=20 > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if=20 > the proposed solution is being used to authenticate OSPF or IS-IS,=20 > and if OSPF or IS-IS will not bring up links until they are=20 > authenticated, and if the proposed solution requires sending any=20 > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think=20 > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? =20 > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended=20 > victims of DDOS attacks, which may be aimed at the router's control=20 > plane. As such it is normal for routers to make use of packet=20 [clipped] > against DDOS. Thus in defining security mechanisms there should be a=20 > strong preference for mechanisms that don't hide nor encrypt the=20 > information that the router hardware is able to inspect at full=20 > line rate for DDOS protection (such as IP addresses, and TCP ports).=20 > I think that a bit more text along the lines might be appropriate=20 > to be added to this bullet item. =20 How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav =20 From manav.bhatia@alcatel-lucent.com Fri Aug 12 15:44:59 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD1E21F8802 for ; Fri, 12 Aug 2011 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5paixFrMceav for ; Fri, 12 Aug 2011 15:44:58 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2166121F882E for ; Fri, 12 Aug 2011 15:44:57 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7CMjR3d006481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2011 17:45:29 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7CMjPRb011049 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 13 Aug 2011 04:15:25 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 13 Aug 2011 04:15:25 +0530 From: "Bhatia, Manav (Manav)" To: Ross Callon , "adrian@olddog.co.uk" , "stbryant@cisco.com" Date: Sat, 13 Aug 2011 04:15:27 +0530 Thread-Topic: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxYPeO+scq5n+URQ/KnpmonjfDQIgAji+aQAA7UFAAADn4xQA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF8E2EE7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Sun, 14 Aug 2011 19:23:59 -0700 Cc: "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "rtg-dir@ietf.org" , "russw@riw.us" , Gregory Lebovitz , "gregory.ietf@gmail.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:44:59 -0000 Hi Ross, =20 > New mechanisms must resist DoS attacks described as in-scope in the > threats section 2.1 above. Routers protect the control plane by > implementing mechanisms to filter completely or rate limit traffic > not required at the control plane level (i.e., unwanted traffic).=20 > Typically line rate packet filtering capabilities look at=20 > information > at or below the IP and transport (TCP or UDP) headers, but do not=20 > include higher layer information. Therefore the new=20 > mechanisms shouldn't =20 > hide nor encrypt the information carried in the IP and=20 > transport layers > in control plane packets. >=20 > Are you proposing that this paragraph be added to the=20 > existing text in requirement number 9?=20 Yes, I am proposing replacing requirement 9 with the above text. Cheers, Manav >=20 >=20 > Also, this seems independent of the text relating to=20 > communicating with external systems. I will respond to that=20 > in a different email (after first getting a snack).=20 >=20 > thanks, Ross >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > Cc: rtg-dir@ietf.org;=20 > draft-ietf-karp-threats-reqs.all@tools.ietf.org;=20 > russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 >=20 > Hi Ross, > =20 > Thanks for the detailed review! > =20 > > This last point has a relationship with the requirement currently=20 > > listed as number 24. It says "Therefore, proposed solutions=20 > SHOULD NOT=20 > > require connections to external systems...". However, note=20 > that if the=20 > > proposed solution is being used to authenticate OSPF or=20 > IS-IS, and if=20 > > OSPF or IS-IS will not bring up links until they are authenticated,=20 > > and if the proposed solution requires sending any information to or=20 > > getting any response from a not-directly-attached remote=20 > system, then=20 > > it isn't going to work. In this regard I think that the=20 > "SHOULD NOT"=20 > > in requirement 24 is not strong enough, and the potential=20 > for deadlock=20 > > should be explicitly mentioned. >=20 > Would it work if we replace SHOULD NOT with a MUST NOT? > =20 > > Section 3, 9th bullet item (about DOS attacks): Routers are=20 > occasional=20 > > intended victims of DDOS attacks, which may be aimed at the=20 > router's=20 > > control plane. As such it is normal for routers to make use=20 > of packet >=20 > [clipped] >=20 > > against DDOS. Thus in defining security mechanisms there=20 > should be a=20 > > strong preference for mechanisms that don't hide nor encrypt the=20 > > information that the router hardware is able to inspect at=20 > full line=20 > > rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be=20 > appropriate to=20 > > be added to this bullet item. >=20 > How about something on these lines: >=20 > New mechanisms must resist DoS attacks described as in-scope=20 > in the threats section 2.1 above. Routers protect the control=20 > plane by implementing mechanisms to filter completely or rate=20 > limit traffic not required at the control plane level (i.e.,=20 > unwanted traffic). This is done by deep inspecting the=20 > packets and only accepting the legitimate ones. The new=20 > mechanisms shouldn't thus hide or encrypt the information=20 > carried in the control plane packets so that routers can=20 > inspect these packets at the line rate. >=20 > I have taken note of your other comments and those will get=20 > fixed in the next revision. >=20 > Cheers, Manav > =20 > = From manav.bhatia@alcatel-lucent.com Fri Aug 12 15:46:15 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148DE21F8891 for ; Fri, 12 Aug 2011 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBKdzN1DMK81 for ; Fri, 12 Aug 2011 15:46:14 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4BC21F888A for ; Fri, 12 Aug 2011 15:46:12 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7CMkgn9019518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2011 17:46:45 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7CMkgV2011125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 13 Aug 2011 04:16:42 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 13 Aug 2011 04:16:42 +0530 From: "Bhatia, Manav (Manav)" To: Ross Callon Date: Sat, 13 Aug 2011 04:16:44 +0530 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxYPeO+scq5n+URQ/KnpmonjfDQIgAji+aQABTlI6AACHh4gA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF8E2EE8@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Sun, 14 Aug 2011 19:23:59 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "gregory.ietf@gmail.com" , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:46:15 -0000 =20 >=20 > NEW >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that=20 > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a=20 > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external=20 > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. >=20 >=20 > Does this look okay to you?=20 Yes, it does. I will update the draft with this. Cheers, Manav=20 From gregory.ietf@gmail.com Sat Aug 13 00:09:52 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8B621F86F6 for ; Sat, 13 Aug 2011 00:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLDcQJ9zlpu9 for ; Sat, 13 Aug 2011 00:09:50 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id D781F21F8678 for ; Sat, 13 Aug 2011 00:09:49 -0700 (PDT) Received: by iye1 with SMTP id 1so3348757iye.27 for ; Sat, 13 Aug 2011 00:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a447BZdT2Y5UMGXErAeW8FZ+0kIMJhDZfvaTzmf0bvw=; b=gW3dOL4kqqyEFdceMyee57CjO6vKW8L1jIUdux/FLZACaihHp5X542FrB56LhWPNtK 3Vf96dtgqd3+4WbWmMUYs9HhFjldIVkfDuQioKnyKCubiMIHiB8T+cdteqQ4MMs8bfjl PFGMkJuACXffQ8cAJViGPK3OBhK0WDvqY4RTc= MIME-Version: 1.0 Received: by 10.142.195.6 with SMTP id s6mr806109wff.108.1313219428582; Sat, 13 Aug 2011 00:10:28 -0700 (PDT) Received: by 10.68.48.5 with HTTP; Sat, 13 Aug 2011 00:10:28 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 13 Aug 2011 00:10:28 -0700 Message-ID: From: Gregory Lebovitz To: Ross Callon Content-Type: multipart/alternative; boundary=000e0cd313828d878e04aa5db9c1 X-Mailman-Approved-At: Sun, 14 Aug 2011 19:24:46 -0700 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 07:09:52 -0000 --000e0cd313828d878e04aa5db9c1 Content-Type: text/plain; charset=ISO-8859-1 Hey all. Ross, the circular dependency issue is not really an issue. I remember you raising it early on in the KARP formation process, and me explaining the following, which was taken from the survey of about 7 operators I did before I wrote the original text (which later became the drafts to forming KARP): When operators bring up new routers, or bring up replaced/fixed routers, they do so by having a human local to the device rack it, connect it to a console server, and then send the coordinates to a NOC operator. Said NOC operator then starts to build up the config on the device. A few static routes, or a default route, is placed into the device first in order to test basic network connectivity and to setup up secure, inband management. At this point keys are often created for SSH use. Many other items are configured on the device that have to do with OAM, and all are tested, BEFORE dynamic routing is turned on. In other words, the device has to function well on the network as a healthy host before it becomes a forwarding agent. Once all this is clear and verified, then routing is turned on protocol by protocol and confirmed. The above process was ubiquitously followed by operators. NONE ever relied on routing protocols for management connectivity, not at least at the point of boot strapping. Any credentials or validating data that would need to be fetched in order to secure the routing protocol would be loaded or fetched BEFORE routing protocols were turned on, using default or static routes, just as all other config / data is fetched at device bring up. I recall when I explained this to you at the onset of all this work you said something to the effect of, "Oh, I get it. That makes me feel much better. So it's not really an issue then," and we moved on. Having said all that, I'm not opposed to your NEW proposal below. If everyone else agrees I would live with it. However, I will point out that a healthy use of "SHOULD NOT" would contain a clear explanation of the circumstance/condition under which it is acceptable to break the guidance, and reminder that aside from such circumstance/condition, the guidance ought be followed. I think both the OLD and NEW text already contained the explanation of when requiring connections to external systems is acceptable: to require post-initialization synchronization "in order to fully synchronize the security information." Thus, the SHOULD NOT was ok, because we stated the condition under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT" and then telling them when it's okay to break the condition really is the same as a "SHOULD NOT", no? Would the following address your concerns, and also have logic integrity: NEW II 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing protocols whereby the operation of the security mechanism would require a routing protocol -- which we are trying to secure -- to already be running in order to properly forward packets. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. The condition under which it is acceptable for the proposed solutions to require connections to external systems is for post initialization synchronization with external systems, in order to fully synchronize the security information. I think the above (1) makes your point about circular dependency, (2) makes it clear the only time when the SHOULD NOT would be disobeyed, (3) has logical integrity. Does it work for all you folks? Hope it helps, Gregory On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon wrote: > Regarding requirement number 24, changing "should not" to "must not" does > help a lot. However, it might be worth adding a bit of explanation. How > about: > > OLD > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. > > NEW > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. > > > Does this look okay to you? > > Thanks, Ross > > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; > russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 > > Hi Ross, > > Thanks for the detailed review! > > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note that if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. > > Would it work if we replace SHOULD NOT with a MUST NOT? > > > Section 3, 9th bullet item (about DOS attacks): Routers are occasional > intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet > > [clipped] > > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. > > How about something on these lines: > > New mechanisms must resist DoS attacks described as in-scope in the threats > section 2.1 above. Routers protect the control plane by implementing > mechanisms to filter completely or rate limit traffic not required at the > control plane level (i.e., unwanted traffic). This is done by deep > inspecting the packets and only accepting the legitimate ones. The new > mechanisms shouldn't thus hide or encrypt the information carried in the > control plane packets so that routers can inspect these packets at the line > rate. > > I have taken note of your other comments and those will get fixed in the > next revision. > > Cheers, Manav > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd313828d878e04aa5db9c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey all.

Ross, the circular dependency issue is not real= ly an issue. I remember you raising it early on in the KARP formation proce= ss, and me explaining the following, which was taken from the survey of abo= ut 7 operators I did before I wrote the original text (which later became t= he drafts to forming KARP):
=A0=A0
When operators bring up new routers, or bring up repl= aced/fixed routers, they do so by having a human local to the device rack i= t, connect it to a console server, and then send the coordinates to a NOC o= perator. Said NOC operator then starts to build up the config on the device= . A few static routes, or a default route, is placed into the device first = in order to test basic network connectivity and to setup up secure, inband = management. At this point keys are often created for SSH use. Many other it= ems are configured on the device that have to do with OAM, and all are test= ed, BEFORE dynamic routing is turned on. In other words, the device has to = function well on the network as a healthy host before it becomes a forwardi= ng agent. Once all this is clear and verified, then routing is turned on pr= otocol by protocol and confirmed.

The above process was ubiquitously followed by operator= s. NONE ever relied on routing protocols for management connectivity, not a= t least at the point of boot strapping. Any credentials or validating data = that would need to be fetched in order to secure the routing protocol would= be loaded or fetched BEFORE routing protocols were turned on, using defaul= t or static routes, just as all other config / data is fetched at device br= ing up.

I recall when I explained this to you at the onset of a= ll this work you said something to the effect of, "Oh, I get it. That = makes me feel much better. So it's not really an issue then," and = we moved on.

Having said all that, I'm not opposed to your NEW p= roposal below. If everyone else agrees I would live with it. However, I wil= l point out that a healthy use of "SHOULD NOT" would contain a cl= ear explanation of the circumstance/condition under which it is acceptable = to break the guidance, and reminder that aside from such circumstance/condi= tion, the guidance ought be followed. I think both the OLD and NEW text alr= eady contained the explanation of when requiring connections to external sy= stems is acceptable: =A0to require post-initialization synchronization &quo= t;in order to fully synchronize the security information." Thus, the S= HOULD NOT was ok, because we stated the condition under which it was reason= able to defy the SHOULD NOT. Saying "MUST NOT" and then telling t= hem when it's okay to break the condition really is the same as a "= ;SHOULD NOT", no? Would the following address your concerns, and also = have logic integrity:

NEW II

24. =A0The new authentication and secur= ity mechanisms should not rely
=A0 =A0 on systems external to the routin= g system (the equipment that
=A0 =A0 is performing forwarding). =A0In or= der to ensure the rapid
=A0 =A0 initialization and/or return to service of failed nodes it is
= =A0 =A0 important to reduce reliance on these external systems to the
= =A0 =A0 greatest extent possible. Also, it is necessary to avoid a
=A0 = =A0 circular dependency between the security mechanisms and routing
=A0=A0 =A0protocols=A0whereby the operation of the security mechanism would= =A0
=A0=A0 =A0require a routing protocol -- which we are trying t= o secure -- to already
=A0=A0 =A0be running in order to properly = forward packets.
=A0 =A0 Therefore, proposed solutions SHOULD NOT require connections to
= =A0 =A0 external systems, beyond those directly involved in peering
=A0 = =A0 relationships, in order to return to full service. =A0The condition und= er=A0
=A0=A0 =A0which it is acceptable for the proposed solutions to req= uire connections
=A0=A0 =A0to external systems is for post
=A0 =A0 initialization synchr= onization with external systems, in order to
=A0 =A0 fully synchronize t= he security information.=A0
=A0
I think the above (1) mak= es your point about circular dependency, (2) makes it clear the only time w= hen the SHOULD NOT would be disobeyed, (3) has logical integrity. Does it w= ork for all you folks?

Hope it helps,
Gregory


On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net<= /a>> wrote:
Regarding requirement number 24, changing &= quot;should not" to "must not" does help a lot. However, it = might be worth adding a bit of explanation. How about:

OLD

24. =A0The new authentication and security mechanisms should not rely
=A0 =A0 on systems external to the routing system (the equipment that is =A0 =A0 performing forwarding). =A0In order to ensure the rapid
=A0 =A0 initialization and/or return to service of failed nodes it is
=A0 =A0 important to reduce reliance on these external systems to the
=A0 =A0 greatest extent possible. =A0Therefore, proposed solutions SHOULD<= br> =A0 =A0 NOT require connections to external systems, beyond those
=A0 =A0 directly involved in peering relationships, in order to return
=A0 =A0 to full service. =A0It is however acceptable for the proposed
=A0 =A0 solutions to require post initialization synchronization with
=A0 =A0 external systems in order to fully synchronize the security
=A0 =A0 information.

NEW

24. =A0The new authentication and security mechanisms should not rely
=A0 =A0 on systems external to the routing system (the equipment that
=A0 =A0 is performing forwarding). =A0In order to ensure the rapid
=A0 =A0 initialization and/or return to service of failed nodes it is
=A0 =A0 important to reduce reliance on these external systems to the
=A0 =A0 greatest extent possible. Also, it is necessary to avoid a
=A0 =A0 circular dependency between the security mechanisms and routing =A0 =A0 (which itself is required to deliver IP packets to any external =A0 =A0 systems which are not directly connected at the link layer).
=A0 =A0 Therefore, proposed solutions MUST NOT require connections to
=A0 =A0 external systems, beyond those directly involved in peering
=A0 =A0 relationships, in order to return to full service. =A0It is
=A0 =A0 however acceptable for the proposed solutions to require post
=A0 =A0 initialization synchronization with external systems in order to =A0 =A0 fully synchronize the security information.


Does this look okay to you?

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk= ; stbryant@cisco.com
Cc: rtg-dir@ietf.org; draft-ietf-karp-threa= ts-reqs.all@tools.ietf.org; russw@riw.u= s; Gregory Lebovitz; gregory.= ietf@gmail.com
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

Thanks for the detailed review!

> This last point has a relationship with the requirement currently
> listed as number 24. It says "Therefore, proposed solutions SHOUL= D
> NOT require connections to external systems...". However, note th= at if
> the proposed solution is being used to authenticate OSPF or IS-IS,
> and if OSPF or IS-IS will not bring up links until they are
> authenticated, and if the proposed solution requires sending any
> information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think=
> that the "SHOULD NOT" in requirement 24 is not strong enough= , and
> the potential for deadlock should be explicitly mentioned.

Would it work if we replace SHOULD NOT with a MUST NOT?

> Section 3, 9th bullet item (about DOS attacks): Routers are occasional= intended
> victims of DDOS attacks, which may be aimed at the router's contro= l
> plane. As such it is normal for routers to make use of packet

[clipped]

> against DDOS. Thus in defining security mechanisms there should be a > strong preference for mechanisms that don't hide nor encrypt the > information that the router hardware is able to =A0inspect at full
> line rate for DDOS protection (such as IP addresses, and TCP ports). > I think that a bit more text along the lines might be appropriate
> to be added to this bullet item.

How about something on these lines:

New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). =A0This is done by deep inspecting = the packets and only accepting the legitimate ones. The new mechanisms shou= ldn't thus hide or encrypt the information carried in the control plane= packets so that routers can inspect these packets at the line rate.

I have taken note of your other comments and those will get fixed in the ne= xt revision.

Cheers, Manav




--
----
IETF= related email from
Gregory M. Lebovitz
Juniper Networks
--000e0cd313828d878e04aa5db9c1-- From gregory.ietf@gmail.com Sat Aug 13 01:03:48 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373021F8581 for ; Sat, 13 Aug 2011 01:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBt6dtAhNkT1 for ; Sat, 13 Aug 2011 01:03:47 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2D48F21F8582 for ; Sat, 13 Aug 2011 01:03:47 -0700 (PDT) Received: by iye1 with SMTP id 1so3419187iye.27 for ; Sat, 13 Aug 2011 01:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AXGdpVGN4N8opC4az6tb4veC4oXRp816wqxC1hJoQ/4=; b=g/XU4E5T1CfZDf8fM+iJpRiEewqyUx5sAJXgDXoxgOJ/I7k2mpgNRd/pchtJMcxZAH Q85vQHXuUfa/yu6LVDnI9uLyK3TMiX/1xYZObanx7LJSoQbNgXI+r6Hwo+2A/u77cvxv giVva27VqWJEafnmmKHY9GaEhlaYtXGrVS8IY= MIME-Version: 1.0 Received: by 10.142.153.9 with SMTP id a9mr12637wfe.279.1313222666151; Sat, 13 Aug 2011 01:04:26 -0700 (PDT) Received: by 10.68.48.5 with HTTP; Sat, 13 Aug 2011 01:04:26 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF8E2EE7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF8E2EE7@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 13 Aug 2011 01:04:26 -0700 Message-ID: From: Gregory Lebovitz To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=000e0cd2dd4886e8ce04aa5e7a73 X-Mailman-Approved-At: Sun, 14 Aug 2011 19:24:46 -0700 Cc: "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "rtg-dir@ietf.org" , "russw@riw.us" , Ross Callon , "adrian@olddog.co.uk" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 08:03:48 -0000 --000e0cd2dd4886e8ce04aa5e7a73 Content-Type: text/plain; charset=ISO-8859-1 The text works for me. One thing to consider, philosophically: I'm not sure we want to tell people that just because some tools exist today that do FOO we shouldn't solve a problem with BAR, because FOO and BAR may not work together. If BAR is genuinely wonderful and adds enormous value to the system, then maybe BAR ought to live, and FOO ought to morph. Practically applied to this paragraph, perhaps it is more helpful to say the following: "Therefore any new mechanism that would either hide or encrypt the information carried in the IP and transport layers in control plane packets would impair these existing filtering tools. Trade-offs must be described and weighed to ensure the value and acceptability of the new mechanism far surpasses that of the existing running tools that may be broken, and preference should be to avoid breaking the existing tools." Again, I can live with the below text; I'm not demanding my suggestion above. FWIW, Gregory On Fri, Aug 12, 2011 at 3:45 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi Ross, > > > New mechanisms must resist DoS attacks described as in-scope in the > > threats section 2.1 above. Routers protect the control plane by > > implementing mechanisms to filter completely or rate limit traffic > > not required at the control plane level (i.e., unwanted traffic). > > Typically line rate packet filtering capabilities look at > > information > > at or below the IP and transport (TCP or UDP) headers, but do not > > include higher layer information. Therefore the new > > mechanisms shouldn't > > hide nor encrypt the information carried in the IP and > > transport layers > > in control plane packets. > > > > Are you proposing that this paragraph be added to the > > existing text in requirement number 9? > > Yes, I am proposing replacing requirement 9 with the above text. > > Cheers, Manav > > > > > > > Also, this seems independent of the text relating to > > communicating with external systems. I will respond to that > > in a different email (after first getting a snack). > > > > thanks, Ross > > > > -----Original Message----- > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > Sent: Friday, August 12, 2011 5:09 AM > > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > > Cc: rtg-dir@ietf.org; > > draft-ietf-karp-threats-reqs.all@tools.ietf.org; > > russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 > > > > Hi Ross, > > > > Thanks for the detailed review! > > > > > This last point has a relationship with the requirement currently > > > listed as number 24. It says "Therefore, proposed solutions > > SHOULD NOT > > > require connections to external systems...". However, note > > that if the > > > proposed solution is being used to authenticate OSPF or > > IS-IS, and if > > > OSPF or IS-IS will not bring up links until they are authenticated, > > > and if the proposed solution requires sending any information to or > > > getting any response from a not-directly-attached remote > > system, then > > > it isn't going to work. In this regard I think that the > > "SHOULD NOT" > > > in requirement 24 is not strong enough, and the potential > > for deadlock > > > should be explicitly mentioned. > > > > Would it work if we replace SHOULD NOT with a MUST NOT? > > > > > Section 3, 9th bullet item (about DOS attacks): Routers are > > occasional > > > intended victims of DDOS attacks, which may be aimed at the > > router's > > > control plane. As such it is normal for routers to make use > > of packet > > > > [clipped] > > > > > against DDOS. Thus in defining security mechanisms there > > should be a > > > strong preference for mechanisms that don't hide nor encrypt the > > > information that the router hardware is able to inspect at > > full line > > > rate for DDOS protection (such as IP addresses, and TCP ports). > > > I think that a bit more text along the lines might be > > appropriate to > > > be added to this bullet item. > > > > How about something on these lines: > > > > New mechanisms must resist DoS attacks described as in-scope > > in the threats section 2.1 above. Routers protect the control > > plane by implementing mechanisms to filter completely or rate > > limit traffic not required at the control plane level (i.e., > > unwanted traffic). This is done by deep inspecting the > > packets and only accepting the legitimate ones. The new > > mechanisms shouldn't thus hide or encrypt the information > > carried in the control plane packets so that routers can > > inspect these packets at the line rate. > > > > I have taken note of your other comments and those will get > > fixed in the next revision. > > > > Cheers, Manav > > > > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd2dd4886e8ce04aa5e7a73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The text works for me.

One thing to consider, philosophi= cally: I'm not sure we want to tell people that just because some tools= exist today that do FOO we shouldn't solve a problem with BAR, because= FOO and BAR may not work together. If BAR is genuinely wonderful and adds = enormous value to the system, then maybe BAR ought to live, and FOO ought t= o morph. Practically applied to this paragraph, perhaps it is more helpful = to say the following:

"Therefore any new=A0mechanism that would either h= ide or=A0encrypt the information carried in the IP and=A0transport layers i= n control plane packets would impair these existing filtering tools. Trade-= offs must be described and weighed to ensure the value and acceptability of= the new mechanism far surpasses that of the existing running tools that ma= y be broken, and preference should be to avoid breaking the existing tools.= "

Again, I can live with the below text; I'm not dema= nding my suggestion above.

FWIW,
Gregory=

On Fri, Aug 12, 2011 at 3:45 PM, Bhatia,= Manav (Manav) <manav.bhatia@alcatel-lucent.com> wrote:
Hi Ross,

> =A0 New mechanisms must resist DoS attacks described as in-scope in th= e
> =A0 threats section 2.1 above. Routers protect the control plane by > =A0 implementing mechanisms to filter completely or rate limit traffic=
> =A0 not required at the control plane level (i.e., unwanted traffic).<= br> > =A0 Typically line rate packet filtering capabilities look at
> information
> =A0 at or below the IP and transport (TCP or UDP) headers, but do not<= br> > =A0 include higher layer information. Therefore the new
> mechanisms shouldn't
> =A0 hide nor encrypt the information carried in the IP and
> transport layers
> =A0 in control plane packets.
>
> Are you proposing that this paragraph be added to the
> existing text in requirement number 9?

Yes, I am proposing replacing requirement 9 with the above text.

Cheers, Manav

>
>
> Also, this seems independent of the text relating to
> communicating with external systems. I will respond to that
> in a different email (after first getting a snack).
>
> thanks, Ross
>
> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
> Sent: Friday, August 12, 2011 5:09 AM
> To: Ross Callon; adrian@olddog.= co.uk; stbryant@cisco.com
> Cc: rtg-dir@ietf.org;
> dra= ft-ietf-karp-threats-reqs.all@tools.ietf.org;
> russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
> Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03
>
> Hi Ross,
>
> Thanks for the detailed review!
>
> > This last point has a relationship with the requirement currently=
> > listed as number 24. It says "Therefore, proposed solutions<= br> > SHOULD NOT
> > require connections to external systems...". However, note > that if the
> > proposed solution is being used to authenticate OSPF or
> IS-IS, and if
> > OSPF or IS-IS will not bring up links until they are authenticate= d,
> > and if the proposed solution requires sending any information to = or
> > getting any response from a not-directly-attached remote
> system, then
> > it isn't going to work. In this regard I think that the
> "SHOULD NOT"
> > in requirement 24 is not strong enough, and the potential
> for deadlock
> > should be explicitly mentioned.
>
> Would it work if we replace SHOULD NOT with a MUST NOT?
>
> > Section 3, 9th bullet item (about DOS attacks): Routers are
> occasional
> > intended victims of DDOS attacks, which may be aimed at the
> router's
> > control plane. As such it is normal for routers to make use
> of packet
>
> [clipped]
>
> > against DDOS. Thus in defining security mechanisms there
> should be a
> > strong preference for mechanisms that don't hide nor encrypt = the
> > information that the router hardware is able to =A0inspect at
> full line
> > rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be
> appropriate to
> > be added to this bullet item.
>
> How about something on these lines:
>
> New mechanisms must resist DoS attacks described as in-scope
> in the threats section 2.1 above. Routers protect the control
> plane by implementing mechanisms to filter completely or rate
> limit traffic not required at the control plane level (i.e.,
> unwanted traffic). =A0This is done by deep inspecting the
> packets and only accepting the legitimate ones. The new
> mechanisms shouldn't thus hide or encrypt the information
> carried in the control plane packets so that routers can
> inspect these packets at the line rate.
>
> I have taken note of your other comments and those will get
> fixed in the next revision.
>
> Cheers, Manav
>
>



--=
----
IETF related email from
Gregory M. Lebovitz
Juniper Netw= orks
--000e0cd2dd4886e8ce04aa5e7a73-- From davari@broadcom.com Thu Aug 4 10:46:45 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE15921F8AD6; Thu, 4 Aug 2011 10:46: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omjqwJF95bdt; Thu, 4 Aug 2011 10:46:45 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67A21F8AB0; Thu, 4 Aug 2011 10:46:45 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 10:52:33 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 4 Aug 2011 10:46:53 -0700 From: "Shahram Davari" To: "Loa Andersson" , "rtg-ads@tools.ietf.org" Date: Thu, 4 Aug 2011 10:46:53 -0700 Thread-Topic: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 Thread-Index: AcxSzl8e1QBBTsjJST20o/t591BZbwAABiMg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F61D@SJEXCHCCR02.corp.ad.broadcom.com> References: <4E386CF0.5050700@pi.nu> <4E3ADAE2.5060907@pi.nu> In-Reply-To: <4E3ADAE2.5060907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622403EB3DK7742447-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 14 Aug 2011 19:26:20 -0700 Cc: "rtg-dir@ietf.org" , "pwe3@ietf.org" , "draft-ietf-pwe3-fat.all@tools.ietf.org" Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:46:46 -0000 I agree with Loa. Thx Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, August 04, 2011 10:46 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; pwe3@ietf.org; draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 All, I have one more point on this - I should have captured it in the previous mail but had to think and discuss a bit about it! Doing ECMP hashing over the label stack as described is OK, but has one thing that needs to be taken care of. Introducing a reserved label - most prominently the GAL - into the label stack will change the outcome of the hash. Since we are ECMP-ing on the hash result, we will no longer to be able to guarantee that normal traffic and OAM packets will no longer be fate sharing - draft-ietf-pwe3-fat-pw should say explicitly that reserved labels should be excluded from ECMP hashing. /Loa On 2011-08-02 14:32, Loa Andersson wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for > draft-ietf-pwe3-fat-pw-07. > > The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-pwe3-fat-pw-07 > Reviewer: Loa Andersson > Review Date: 2 Aug 2011 > IETF LC End Date: 3 Aug 2011 > Intended Status: Standards Track > > Summary: > I have no major concerns about this document, howver I thing it > would be good to reslove the mostly editorial comments below > (especially on the IANA section) before publication. > > Comments: > > Unexpanded acronyms: > > OAM appears in the table of content and as header 7. It is not > expanded in the document anywhere. Should be done at first occurance. > > page 6. The last paragraph of section 1 talks about TC bits > (and EXP bits). We don't have TC bits - the correct name is TC field. > > First paragraph section three: > This paragraph talks in genral about "load balanced paths" while the > rest of the document is very specific about ECMP, it is the intention > that this should work for any load balancing paradigm? > > Second paragraph section three: > Normally a label is assigned by the down stream node, this scheme > is doing upstream allocation. Don't see a problem under normal > operation, but if the label "by accident" becomes top of stack > this could have "interesting" effects. > > Sectyion 4 second paagraph: > > OLD > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. A PE that is using PW signalling and that does > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > A PE that is using PW signalling and which does not receive a FL Sub- > TLV from its peer MUST NOT include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > NEW > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. An ingress PE that is using PW signalling > and that does not send a FL Sub-TLV MUST NOT include a flow label > in the PW packet. An ingress PE that is using PW signalling and > which does not receive a FL Sub-TLV from its egress peer MUST NOT > include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > The IANA section: > > In the IANA section we should use a TBD entry for the Flow label > indicator; and maybe add 0x17 as suggest value in the text. > > The text in the IANA section needs to aligned with the rest of > the text, or maybe even better have the rest of the text align > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > else but in the iana section. > > To make it easier to find the references to the IANA registries > should start with "Pseudowire Name Spaces (PWE3)" point to > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > sub-registry, and ask for assigment of the next free value from > the Experts review space (suggested value 0x17). > > On the other hand it looks like we have an early assigment > (Flow Label shows up with the value 0x17). If this is the case > after making the text changes suggest above this should be mentioned > in the IANA section. --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From rcallon@juniper.net Mon Aug 15 06:18:08 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DEA21F8B9B for ; Mon, 15 Aug 2011 06:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STWJjrEwG2G7 for ; Mon, 15 Aug 2011 06:18:07 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 800E221F8B87 for ; Mon, 15 Aug 2011 06:18:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTkkcrQjzNM/tlXnHPwOtu562hXJDT37N@postini.com; Mon, 15 Aug 2011 06:18:52 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Aug 2011 06:18:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 15 Aug 2011 09:18:19 -0400 From: Ross Callon To: Gregory Lebovitz Date: Mon, 15 Aug 2011 09:18:07 -0400 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxZiBlA9g+3ZaMbSySX0bw+90SyyABxWtnQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.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: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2E20F5FB7EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:18:08 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2E20F5FB7EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would a security protocol, for example used for automated key management, o= perate over the out of band management plane, or would it operate over the = normal data plane, or between two systems directly attached at the link lay= er, or in some other way? Ross From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Saturday, August 13, 2011 3:10 AM To: Ross Callon Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Hey all. Ross, the circular dependency issue is not really an issue. I remember you = raising it early on in the KARP formation process, and me explaining the fo= llowing, which was taken from the survey of about 7 operators I did before = I wrote the original text (which later became the drafts to forming KARP): When operators bring up new routers, or bring up replaced/fixed routers, th= ey do so by having a human local to the device rack it, connect it to a con= sole server, and then send the coordinates to a NOC operator. Said NOC oper= ator then starts to build up the config on the device. A few static routes,= or a default route, is placed into the device first in order to test basic= network connectivity and to setup up secure, inband management. At this po= int keys are often created for SSH use. Many other items are configured on = the device that have to do with OAM, and all are tested, BEFORE dynamic rou= ting is turned on. In other words, the device has to function well on the n= etwork as a healthy host before it becomes a forwarding agent. Once all thi= s is clear and verified, then routing is turned on protocol by protocol and= confirmed. The above process was ubiquitously followed by operators. NONE ever relied = on routing protocols for management connectivity, not at least at the point= of boot strapping. Any credentials or validating data that would need to b= e fetched in order to secure the routing protocol would be loaded or fetche= d BEFORE routing protocols were turned on, using default or static routes, = just as all other config / data is fetched at device bring up. I recall when I explained this to you at the onset of all this work you sai= d something to the effect of, "Oh, I get it. That makes me feel much better= . So it's not really an issue then," and we moved on. Having said all that, I'm not opposed to your NEW proposal below. If everyo= ne else agrees I would live with it. However, I will point out that a healt= hy use of "SHOULD NOT" would contain a clear explanation of the circumstanc= e/condition under which it is acceptable to break the guidance, and reminde= r that aside from such circumstance/condition, the guidance ought be follow= ed. I think both the OLD and NEW text already contained the explanation of = when requiring connections to external systems is acceptable: to require p= ost-initialization synchronization "in order to fully synchronize the secur= ity information." Thus, the SHOULD NOT was ok, because we stated the condit= ion under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT"= and then telling them when it's okay to break the condition really is the = same as a "SHOULD NOT", no? Would the following address your concerns, and = also have logic integrity: NEW II 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing protocols whereby the operation of the security mechanism would require a routing protocol -- which we are trying to secure -- to alrea= dy be running in order to properly forward packets. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. The condition under which it is acceptable for the proposed solutions to require connection= s to external systems is for post initialization synchronization with external systems, in order to fully synchronize the security information. I think the above (1) makes your point about circular dependency, (2) makes= it clear the only time when the SHOULD NOT would be disobeyed, (3) has log= ical integrity. Does it work for all you folks? Hope it helps, Gregory On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: Regarding requirement number 24, changing "should not" to "must not" does h= elp a lot. However, it might be worth adding a bit of explanation. How abou= t: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. NEW 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing (which itself is required to deliver IP packets to any external systems which are not directly connected at the link layer). Therefore, proposed solutions MUST NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. Does this look okay to you? Thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@= cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs= .all@tools.ietf.org= ; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.c= om Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, Thanks for the detailed review! > This last point has a relationship with the requirement currently > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if > the proposed solution is being used to authenticate OSPF or IS-IS, > and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended > victims of DDOS attacks, which may be aimed at the router's control > plane. As such it is normal for routers to make use of packet [clipped] > against DDOS. Thus in defining security mechanisms there should be a > strong preference for mechanisms that don't hide nor encrypt the > information that the router hardware is able to inspect at full > line rate for DDOS protection (such as IP addresses, and TCP ports). > I think that a bit more text along the lines might be appropriate > to be added to this bullet item. How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --_000_DF7F294AF4153D498141CBEFADB17704C2E20F5FB7EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would a s= ecurity protocol, for example used for automated key management, operate ov= er the out of band management plane, or would it operate over the normal da= ta plane, or between two systems directly attached at the link layer, or in= some other way?

&nb= sp;

Ross

<= p class=3DMsoNormal> 

From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com]
Sent:= Saturday, August 13, 2011 3:10 AM
To: Ross Callon
Cc:<= /b> Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com
Subject: Re: reliance on external systems (req 24= ), RE: RtgDir review: draft-ietf-karp-threats-reqs-03

=

 

Hey al= l.

 

=

Ross, the circular dependency issue is not really an i= ssue. I remember you raising it early on in the KARP formation process, and= me explaining the following, which was taken from the survey of about 7 op= erators I did before I wrote the original text (which later became the draf= ts to forming KARP):

 &n= bsp;

When operators bring up = new routers, or bring up replaced/fixed routers, they do so by having a hum= an local to the device rack it, connect it to a console server, and then se= nd the coordinates to a NOC operator. Said NOC operator then starts to buil= d up the config on the device. A few static routes, or a default route, is = placed into the device first in order to test basic network connectivity an= d to setup up secure, inband management. At this point keys are often creat= ed for SSH use. Many other items are configured on the device that have to = do with OAM, and all are tested, BEFORE dynamic routing is turned on. In ot= her words, the device has to function well on the network as a healthy host= before it becomes a forwarding agent. Once all this is clear and verified,= then routing is turned on protocol by protocol and confirmed.

 

The above process was ubiquitously followed by operators. NONE= ever relied on routing protocols for management connectivity, not at least= at the point of boot strapping. Any credentials or validating data that wo= uld need to be fetched in order to secure the routing protocol would be loa= ded or fetched BEFORE routing protocols were turned on, using default or st= atic routes, just as all other config / data is fetched at device bring up.=

 

<= div>

I recall when I explained this to you at the onset= of all this work you said something to the effect of, "Oh, I get it. = That makes me feel much better. So it's not really an issue then," and= we moved on.

 

Having said all that, I'm not opposed= to your NEW proposal below. If everyone else agrees I would live with it. = However, I will point out that a healthy use of "SHOULD NOT" woul= d contain a clear explanation of the circumstance/condition under which it = is acceptable to break the guidance, and reminder that aside from such circ= umstance/condition, the guidance ought be followed. I think both the OLD an= d NEW text already contained the explanation of when requiring connections = to external systems is acceptable:  to require post-initialization syn= chronization "in order to fully synchronize the security information.&= quot; Thus, the SHOULD NOT was ok, because we stated the condition under wh= ich it was reasonable to defy the SHOULD NOT. Saying "MUST NOT" a= nd then telling them when it's okay to break the condition really is the sa= me as a "SHOULD NOT", no? Would the following address your concer= ns, and also have logic integrity:

 

NEW II


24.  The new authentication and se= curity mechanisms should not rely
    on systems external to t= he routing system (the equipment that
    is performing forwar= ding).  In order to ensure the rapid
    initialization a= nd/or return to service of failed nodes it is
    important to= reduce reliance on these external systems to the
    greatest= extent possible. Also, it is necessary to avoid a
    circula= r dependency between the security mechanisms and routing

    protocols whereby the operati= on of the security mechanism would 

    require a routing protocol -- which we are = trying to secure -- to already

    be running in order to properly forward packets.
&n= bsp;   Therefore, proposed solutions SHOULD NOT require connections to=
    external systems, beyond those directly involved in peeri= ng
    relationships, in order to return to full service. &nbs= p;The condition under 
    which it is acceptable fo= r the proposed solutions to require connections

    to external systems is for post<= /p>

    initialization synchronization w= ith external systems, in order to
    fully synchronize the se= curity information. 

 

I think the above (1) makes you= r point about circular dependency, (2) makes it clear the only time when th= e SHOULD NOT would be disobeyed, (3) has logical integrity. Does it work fo= r all you folks?

 <= /o:p>

Hope it helps,

Gregory

 

On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net> wrote:

Regarding requirement numb= er 24, changing "should not" to "must not" does help a = lot. However, it might be worth adding a bit of explanation. How about:
=
OLD

24.  The new authentication and security mechanisms sho= uld not rely
    on systems external to the routing system (th= e equipment that is
    performing forwarding).  In order= to ensure the rapid
    initialization and/or return to servi= ce of failed nodes it is
    important to reduce reliance on t= hese external systems to the
    greatest extent possible. &nb= sp;Therefore, proposed solutions SHOULD
    NOT require connec= tions to external systems, beyond those
    directly involved = in peering relationships, in order to return
    to full servi= ce.  It is however acceptable for the proposed
    soluti= ons to require post initialization synchronization with
    ex= ternal systems in order to fully synchronize the security
    = information.

NEW

24.  The new authentication and securit= y mechanisms should not rely
    on systems external to the ro= uting system (the equipment that
    is performing forwarding)= .  In order to ensure the rapid
    initialization and/or= return to service of failed nodes it is
    important to redu= ce reliance on these external systems to the
    greatest exte= nt possible. Also, it is necessary to avoid a
    circular dep= endency between the security mechanisms and routing
    (which= itself is required to deliver IP packets to any external
    = systems which are not directly connected at the link layer).
  &nbs= p; Therefore, proposed solutions MUST NOT require connections to
  =   external systems, beyond those directly involved in peering
 = ;   relationships, in order to return to full service.  It is
=     however acceptable for the proposed solutions to require post=
    initialization synchronization with external systems in o= rder to
    fully synchronize the security information.

Does this look okay to you?

Thanks, Ross

-----Original M= essage-----
From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Fr= iday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc: rtg-dir= @ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subject: RE: RtgDir revie= w: draft-ietf-karp-threats-reqs-03

Hi Ross,

Thanks for the de= tailed review!

> This last point has a relationship with the requ= irement currently
> listed as number 24. It says "Therefore, pro= posed solutions SHOULD
> NOT require connections to external systems.= ..". However, note that if
> the proposed solution is being used= to authenticate OSPF or IS-IS,
> and if OSPF or IS-IS will not bring= up links until they are
> authenticated, and if the proposed solutio= n requires sending any
> information to or getting any response from = a not-directly-attached
> remote system, then it isn't going to work.= In this regard I think
> that the "SHOULD NOT" in requirem= ent 24 is not strong enough, and
> the potential for deadlock should = be explicitly mentioned.

Would it work if we replace SHOULD NOT with= a MUST NOT?

> Section 3, 9th bullet item (about DOS attacks): Ro= uters are occasional intended
> victims of DDOS attacks, which may be= aimed at the router's control
> plane. As such it is normal for rout= ers to make use of packet

[clipped]

> against DDOS. Thus i= n defining security mechanisms there should be a
> strong preference = for mechanisms that don't hide nor encrypt the
> information that the= router hardware is able to  inspect at full
> line rate for DDO= S protection (such as IP addresses, and TCP ports).
> I think that a = bit more text along the lines might be appropriate
> to be added to t= his bullet item.

How about something on these lines:

New mech= anisms must resist DoS attacks described as in-scope in the threats section= 2.1 above. Routers protect the control plane by implementing mechanisms to= filter completely or rate limit traffic not required at the control plane = level (i.e., unwanted traffic).  This is done by deep inspecting the p= ackets and only accepting the legitimate ones. The new mechanisms shouldn't= thus hide or encrypt the information carried in the control plane packets = so that routers can inspect these packets at the line rate.

I have t= aken note of your other comments and those will get fixed in the next revis= ion.

Cheers, Manav



 

<= /div>

--
----
IETF related email from
Gregory= M. Lebovitz
Juniper Networks

= --_000_DF7F294AF4153D498141CBEFADB17704C2E20F5FB7EMBX01WFjnprn_-- From acee.lindem@ericsson.com Mon Aug 15 06:39:48 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA421F8B5F for ; Mon, 15 Aug 2011 06:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45KCC8c10jq2 for ; Mon, 15 Aug 2011 06:39:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15CB321F8BB1 for ; Mon, 15 Aug 2011 06:39:47 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7FDeOge030702; Mon, 15 Aug 2011 08:40:25 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.220]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 15 Aug 2011 09:40:20 -0400 From: Acee Lindem To: Ross Callon Date: Mon, 15 Aug 2011 09:40:18 -0400 Thread-Topic: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxbUOCE0ysG0iG/SrGWtJFEmRJsKQ== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5-100969498"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:39:48 -0000 --Apple-Mail-5-100969498 Content-Type: multipart/alternative; boundary=Apple-Mail-4-100969481 --Apple-Mail-4-100969481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii While I admit that I don't do a lot of customer router debugging these = days, my past experience has been that out-of-band OAM router access is = common but certainly not universal. However, "SHOULD NOT" is probably = strong enough wording to prefer KMPs not requiring connectivity to = external systems over those that do.=20 Thanks, Acee=20 On Aug 15, 2011, at 9:18 AM, Ross Callon wrote: > Would a security protocol, for example used for automated key = management, operate over the out of band management plane, or would it = operate over the normal data plane, or between two systems directly = attached at the link layer, or in some other way? > =20 > Ross > =20 > From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com]=20 > Sent: Saturday, August 13, 2011 3:10 AM > To: Ross Callon > Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; = draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory = Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > Subject: Re: reliance on external systems (req 24), RE: RtgDir review: = draft-ietf-karp-threats-reqs-03 > =20 > Hey all. > =20 > Ross, the circular dependency issue is not really an issue. I remember = you raising it early on in the KARP formation process, and me explaining = the following, which was taken from the survey of about 7 operators I = did before I wrote the original text (which later became the drafts to = forming KARP): > =20 > When operators bring up new routers, or bring up replaced/fixed = routers, they do so by having a human local to the device rack it, = connect it to a console server, and then send the coordinates to a NOC = operator. Said NOC operator then starts to build up the config on the = device. A few static routes, or a default route, is placed into the = device first in order to test basic network connectivity and to setup up = secure, inband management. At this point keys are often created for SSH = use. Many other items are configured on the device that have to do with = OAM, and all are tested, BEFORE dynamic routing is turned on. In other = words, the device has to function well on the network as a healthy host = before it becomes a forwarding agent. Once all this is clear and = verified, then routing is turned on protocol by protocol and confirmed. > =20 > The above process was ubiquitously followed by operators. NONE ever = relied on routing protocols for management connectivity, not at least at = the point of boot strapping. Any credentials or validating data that = would need to be fetched in order to secure the routing protocol would = be loaded or fetched BEFORE routing protocols were turned on, using = default or static routes, just as all other config / data is fetched at = device bring up. > =20 > I recall when I explained this to you at the onset of all this work = you said something to the effect of, "Oh, I get it. That makes me feel = much better. So it's not really an issue then," and we moved on. > =20 > Having said all that, I'm not opposed to your NEW proposal below. If = everyone else agrees I would live with it. However, I will point out = that a healthy use of "SHOULD NOT" would contain a clear explanation of = the circumstance/condition under which it is acceptable to break the = guidance, and reminder that aside from such circumstance/condition, the = guidance ought be followed. I think both the OLD and NEW text already = contained the explanation of when requiring connections to external = systems is acceptable: to require post-initialization synchronization = "in order to fully synchronize the security information." Thus, the = SHOULD NOT was ok, because we stated the condition under which it was = reasonable to defy the SHOULD NOT. Saying "MUST NOT" and then telling = them when it's okay to break the condition really is the same as a = "SHOULD NOT", no? Would the following address your concerns, and also = have logic integrity: > =20 > NEW II >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > protocols whereby the operation of the security mechanism would=20 > require a routing protocol -- which we are trying to secure -- to = already > be running in order to properly forward packets. > Therefore, proposed solutions SHOULD NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. The condition = under=20 > which it is acceptable for the proposed solutions to require = connections > to external systems is for post > initialization synchronization with external systems, in order to > fully synchronize the security information.=20 > =20 > I think the above (1) makes your point about circular dependency, (2) = makes it clear the only time when the SHOULD NOT would be disobeyed, (3) = has logical integrity. Does it work for all you folks? > =20 > Hope it helps, > Gregory > =20 >=20 > On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon = wrote: > Regarding requirement number 24, changing "should not" to "must not" = does help a lot. However, it might be worth adding a bit of explanation. = How about: >=20 > OLD >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. >=20 > NEW >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. >=20 >=20 > Does this look okay to you? >=20 > Thanks, Ross >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; = russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 >=20 > Hi Ross, >=20 > Thanks for the detailed review! >=20 > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note that = if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. >=20 > Would it work if we replace SHOULD NOT with a MUST NOT? >=20 > > Section 3, 9th bullet item (about DOS attacks): Routers are = occasional intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet >=20 > [clipped] >=20 > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. >=20 > How about something on these lines: >=20 > New mechanisms must resist DoS attacks described as in-scope in the = threats section 2.1 above. Routers protect the control plane by = implementing mechanisms to filter completely or rate limit traffic not = required at the control plane level (i.e., unwanted traffic). This is = done by deep inspecting the packets and only accepting the legitimate = ones. The new mechanisms shouldn't thus hide or encrypt the information = carried in the control plane packets so that routers can inspect these = packets at the line rate. >=20 > I have taken note of your other comments and those will get fixed in = the next revision. >=20 > Cheers, Manav >=20 >=20 >=20 > =20 > --=20 > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks --Apple-Mail-4-100969481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii While I admit that I don't do a lot of customer = router debugging these days, my past experience has been that = out-of-band OAM router access is common but certainly not universal. = However, "SHOULD NOT" is probably strong enough wording to prefer KMPs = not requiring connectivity to external systems over those that = do. 

Thanks,
Acee 


On Aug 15, 2011, at 9:18 AM, Ross Callon = wrote:

Would = a security protocol, for example used for automated key management, = operate over the out of band management plane, or would it operate over = the normal data plane, or between two systems directly attached at the = link layer, or in some other way?
From: Gregory Lebovitz = [mailto:gregory.ietf@gmail.com] 
Sent: Saturday, August 13, 2011 = 3:10 AM
To: Ross = Callon
Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org;  russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk;  Re: reliance on external = systems (req 24), RE: RtgDir review: = draft-ietf-karp-threats-reqs-03
When operators bring up = new routers, or bring up replaced/fixed routers, they do so by having a = human local to the device rack it, connect it to a console server, and = then send the coordinates to a NOC operator. Said NOC operator then = starts to build up the config on the device. A few static routes, or a = default route, is placed into the device first in order to test basic = network connectivity and to setup up secure, inband management. At this = point keys are often created for SSH use. Many other items are = configured on the device that have to do with OAM, and all are tested, = BEFORE dynamic routing is turned on. In other words, the device has to = function well on the network as a healthy host before it becomes a = forwarding agent. Once all this is clear and verified, then routing is = turned on protocol by protocol and = confirmed.
Having said all that, I'm not opposed to your NEW = proposal below. If everyone else agrees I would live with it. However, I = will point out that a healthy use of "SHOULD NOT" would contain a clear = explanation of the circumstance/condition under which it is acceptable = to break the guidance, and reminder that aside from such = circumstance/condition, the guidance ought be followed. I think both the = OLD and NEW text already contained the explanation of when requiring = connections to external systems is acceptable:  to require = post-initialization synchronization "in order to fully synchronize the = security information." Thus, the SHOULD NOT was ok, because we stated = the condition under which it was reasonable to defy the SHOULD NOT. = Saying "MUST NOT" and then telling them when it's okay to break the = condition really is the same as a "SHOULD NOT", no? Would the following = address your concerns, and also have logic = integrity:

 

On Fri, Aug 12, 2011 at = 12:00 PM, Ross Callon <Regarding requirement number 24, changing = "should not" to "must not" does help a lot. However, it might be worth = adding a bit of explanation. How about:

OLD

24.  The = new authentication and security mechanisms should not rely
  =   on systems external to the routing system (the equipment that = is
    performing forwarding).  In order to ensure the = rapid
    initialization and/or return to service of failed = nodes it is
    important to reduce reliance on these = external systems to the
    greatest extent possible. =  Therefore, proposed solutions SHOULD
    NOT require = connections to external systems, beyond those
    directly = involved in peering relationships, in order to return
    = to full service.  It is however acceptable for the = proposed
    solutions to require post initialization = synchronization with
    external systems in order to fully = synchronize the security
    = information.

NEW

24.  The new authentication and = security mechanisms should not rely
    on systems external = to the routing system (the equipment that
    is performing = forwarding).  In order to ensure the rapid
    = initialization and/or return to service of failed nodes it is
  =   important to reduce reliance on these external systems to = the
    greatest extent possible. Also, it is necessary to = avoid a
    circular dependency between the security = mechanisms and routing
    (which itself is required to = deliver IP packets to any external
    systems which are = not directly connected at the link layer).
    Therefore, = proposed solutions MUST NOT require connections to
    = external systems, beyond those directly involved in peering
  =   relationships, in order to return to full service.  It = is
    however acceptable for the proposed solutions to = require post
    initialization synchronization with = external systems in order to
    fully synchronize the = security information.


Does this look okay to = you?

Thanks, Ross

-----Original Message-----
From: = Bhatia, Manav (Manav) [mailto: adrian@olddog.co.uk; stbryant@cisco.com
Cc: rtg-dir@ietf.org;  russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subject: RE: = RtgDir review: draft-ietf-karp-threats-reqs-03

Hi = Ross,

Thanks for the detailed review!

> This last point = has a relationship with the requirement currently
> listed as = number 24. It says "Therefore, proposed solutions SHOULD
> NOT = require connections to external systems...". However, note that = if
> the proposed solution is being used to authenticate OSPF or = IS-IS,
> and if OSPF or IS-IS will not bring up links until they = are
> authenticated, and if the proposed solution requires sending = any
> information to or getting any response from a = not-directly-attached
> remote system, then it isn't going to = work. In this regard I think
> that the "SHOULD NOT" in = requirement 24 is not strong enough, and
> the potential for = deadlock should be explicitly mentioned.

Would it work if we = replace SHOULD NOT with a MUST NOT?

> Section 3, 9th bullet = item (about DOS attacks): Routers are occasional intended
> = victims of DDOS attacks, which may be aimed at the router's = control
> plane. As such it is normal for routers to make use of = packet

[clipped]

> against DDOS. Thus in defining = security mechanisms there should be a
> strong preference for = mechanisms that don't hide nor encrypt the
> information that the = router hardware is able to  inspect at full
> line rate for = DDOS protection (such as IP addresses, and TCP ports).
> I think = that a bit more text along the lines might be appropriate
> to be = added to this bullet item.

How about something on these = lines:

New mechanisms must resist DoS attacks described as = in-scope in the threats section 2.1 above. Routers protect the control = plane by implementing mechanisms to filter completely or rate limit = traffic not required at the control plane level (i.e., unwanted = traffic).  This is done by deep inspecting the packets and only = accepting the legitimate ones. The new mechanisms shouldn't thus hide or = encrypt the information carried in the control plane packets so that = routers can inspect these packets at the line rate.

I have taken = note of your other comments and those will get fixed in the next = revision.

Cheers, Manav



 
-- 
----
IETF related = email from
Gregory M. Lebovitz
Juniper = Networks

= --Apple-Mail-4-100969481-- --Apple-Mail-5-100969498 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgxNTEzNDAxOFowIwYJKoZI hvcNAQkEMRYEFCUUtUWhGzuHicsgyfksgTwbB31RMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIOly3KY745Tf0aetH2sZYDzbBz30bgziqK8ib20UukQ2rbqbTplbxLe20EnY+Z4 8CzBs+wFWwx1J3BbxUTyBRoUbEniuj3riMh30Uunk8l4QT/sMaTx+vHTKSqKeIcl+kh5OyFSrM7w DrH4t4gXkHfdioJtMBNwxZ8VuIQqTu/4AAAAAAAA --Apple-Mail-5-100969498-- From jmh@joelhalpern.com Mon Aug 15 08:16:20 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3F021F8BF7 for ; Mon, 15 Aug 2011 08:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25fq4gmWhUkC for ; Mon, 15 Aug 2011 08:16:19 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB821F8A69 for ; Mon, 15 Aug 2011 08:16:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 50B5632464C3; Mon, 15 Aug 2011 08:17:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.105] (pool-71-161-50-227.clppva.btas.verizon.net [71.161.50.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 411623246559; Mon, 15 Aug 2011 08:17:03 -0700 (PDT) Message-ID: <4E493882.3000602@joelhalpern.com> Date: Mon, 15 Aug 2011 11:17:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Ross Callon References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:16:20 -0000 That would depend upon the security protocol. Almost all of them assume at least reachability between the two parties (or n parties) involved. Given that the structure we are using allows for manual keying as well as automated key management, we can cope out by noting that bootstrapping devices could be done using manual keys, and that during normal operation, these could then use AKM for new keys. Also, some of what folks refer to as AKM uses preconfigured (even manually configured) base keys to bootstrap the peer AKM process. So that would not have dependence upon the rest of the network being configured and operational. Other folks use the term for other things. I will also note that we have an explicit decision by the WG that the AKM shall be a separate component, not a modification of the routing system itself. Unless we really want to re-open that can of worms, please think of that as a constraint. Yours, Joel On 8/15/2011 9:18 AM, Ross Callon wrote: > Would a security protocol, for example used for automated key > management, operate over the out of band management plane, or would it > operate over the normal data plane, or between two systems directly > attached at the link layer, or in some other way? > > Ross > > *From:*Gregory Lebovitz [mailto:gregory.ietf@gmail.com] > *Sent:* Saturday, August 13, 2011 3:10 AM > *To:* Ross Callon > *Cc:* Bhatia, Manav (Manav); rtg-dir@ietf.org; > draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory > Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > *Subject:* Re: reliance on external systems (req 24), RE: RtgDir review: > draft-ietf-karp-threats-reqs-03 > > Hey all. > > Ross, the circular dependency issue is not really an issue. I remember > you raising it early on in the KARP formation process, and me explaining > the following, which was taken from the survey of about 7 operators I > did before I wrote the original text (which later became the drafts to > forming KARP): > > When operators bring up new routers, or bring up replaced/fixed routers, > they do so by having a human local to the device rack it, connect it to > a console server, and then send the coordinates to a NOC operator. Said > NOC operator then starts to build up the config on the device. A few > static routes, or a default route, is placed into the device first in > order to test basic network connectivity and to setup up secure, inband > management. At this point keys are often created for SSH use. Many other > items are configured on the device that have to do with OAM, and all are > tested, BEFORE dynamic routing is turned on. In other words, the device > has to function well on the network as a healthy host before it becomes > a forwarding agent. Once all this is clear and verified, then routing is > turned on protocol by protocol and confirmed. > > The above process was ubiquitously followed by operators. NONE ever > relied on routing protocols for management connectivity, not at least at > the point of boot strapping. Any credentials or validating data that > would need to be fetched in order to secure the routing protocol would > be loaded or fetched BEFORE routing protocols were turned on, using > default or static routes, just as all other config / data is fetched at > device bring up. > > I recall when I explained this to you at the onset of all this work you > said something to the effect of, "Oh, I get it. That makes me feel much > better. So it's not really an issue then," and we moved on. > > Having said all that, I'm not opposed to your NEW proposal below. If > everyone else agrees I would live with it. However, I will point out > that a healthy use of "SHOULD NOT" would contain a clear explanation of > the circumstance/condition under which it is acceptable to break the > guidance, and reminder that aside from such circumstance/condition, the > guidance ought be followed. I think both the OLD and NEW text already > contained the explanation of when requiring connections to external > systems is acceptable: to require post-initialization synchronization > "in order to fully synchronize the security information." Thus, the > SHOULD NOT was ok, because we stated the condition under which it was > reasonable to defy the SHOULD NOT. Saying "MUST NOT" and then telling > them when it's okay to break the condition really is the same as a > "SHOULD NOT", no? Would the following address your concerns, and also > have logic integrity: > > NEW II > > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > > protocols whereby the operation of the security mechanism would > > require a routing protocol -- which we are trying to secure -- to already > > be running in order to properly forward packets. > Therefore, proposed solutions SHOULD NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. The condition under > which it is acceptable for the proposed solutions to require connections > > to external systems is for post > > initialization synchronization with external systems, in order to > fully synchronize the security information. > > I think the above (1) makes your point about circular dependency, (2) > makes it clear the only time when the SHOULD NOT would be disobeyed, (3) > has logical integrity. Does it work for all you folks? > > Hope it helps, > > Gregory > > On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: > > Regarding requirement number 24, changing "should not" to "must not" > does help a lot. However, it might be worth adding a bit of explanation. > How about: > > OLD > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. > > NEW > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. > > > Does this look okay to you? > > Thanks, Ross > > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com > ] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk ; > stbryant@cisco.com > Cc: rtg-dir@ietf.org ; > draft-ietf-karp-threats-reqs.all@tools.ietf.org > ; russw@riw.us > ; Gregory Lebovitz; gregory.ietf@gmail.com > > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 > > Hi Ross, > > Thanks for the detailed review! > > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note that if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. > > Would it work if we replace SHOULD NOT with a MUST NOT? > > > Section 3, 9th bullet item (about DOS attacks): Routers are > occasional intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet > > [clipped] > > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. > > How about something on these lines: > > New mechanisms must resist DoS attacks described as in-scope in the > threats section 2.1 above. Routers protect the control plane by > implementing mechanisms to filter completely or rate limit traffic not > required at the control plane level (i.e., unwanted traffic). This is > done by deep inspecting the packets and only accepting the legitimate > ones. The new mechanisms shouldn't thus hide or encrypt the information > carried in the control plane packets so that routers can inspect these > packets at the line rate. > > I have taken note of your other comments and those will get fixed in the > next revision. > > Cheers, Manav > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > From russw@riw.us Mon Aug 15 17:43:04 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E483D21F8C17 for ; Mon, 15 Aug 2011 17:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIRDcdbz5h67 for ; Mon, 15 Aug 2011 17:43:04 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2D75E21F8C16 for ; Mon, 15 Aug 2011 17:43:04 -0700 (PDT) Received: from m2b5636d0.tmodns.net ([208.54.86.43] helo=55.95.240.10.in-addr.arpa) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qt7kr-00063E-2t; Mon, 15 Aug 2011 20:43:41 -0400 Message-ID: <4E49BD33.2090006@riw.us> Date: Mon, 15 Aug 2011 20:43:31 -0400 From: Russ White User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Acee Lindem References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , Ross Callon , "adrian@olddog.co.uk" , Gregory Lebovitz , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 00:43:05 -0000 > While I admit that I don't do a lot of customer router debugging these > days, my past experience has been that out-of-band OAM router access is > common but certainly not universal. However, "SHOULD NOT" is probably > strong enough wording to prefer KMPs not requiring connectivity to > external systems over those that do. OOB OAM access is pretty rare, in my experience. the best solution would be one that works like a routing protocol --flooded to all interested parties, or hop by hop, so routing isn't needed. On the other hand, if you're going to deploy some form of automated key management, it doesn't seem particular horrible to say, "and you need to have out of band management. The alternative is to bring up routing in such a way that each device along the current edge authenticates and brings up routing, expanding the edge in the network by one hop in each time slice." Bringing an entire network up seems like it would happen rarely enough that this isn't too much of a restriction. :-) Russ From rcallon@juniper.net Mon Aug 15 19:33:44 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533121F8C85 for ; Mon, 15 Aug 2011 19:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vjHha0TPWz1 for ; Mon, 15 Aug 2011 19:33:38 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93D21F8BC3 for ; Mon, 15 Aug 2011 19:33:37 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTknXJ9Pkq8Hrx5UKKg9NEhgPXFvG4MKb@postini.com; Mon, 15 Aug 2011 19:34:24 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Aug 2011 19:32:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 15 Aug 2011 22:31:59 -0400 From: Ross Callon To: "Bhatia, Manav (Manav)" , Gregory Lebovitz Date: Mon, 15 Aug 2011 22:31:58 -0400 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxZiBlA9g+3ZaMbSySX0bw+90SyyABxWtnQAAGRoUAAFbz+cA== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF8E2F8F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF8E2F8F@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2E20F6A41EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , Ross Callon , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 02:33:44 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6A41EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But if the key management protocol was running over the out of band managem= ent network, then which version of OSPF would it be generating keys for? If= it were generating keys to be used for the version of OSPF running on its = production network, then there is a clear bootstrapping path either initial= ly or to recover from any bad state: first the OOB network comes up, then t= he keys are exchanged, then the regular network comes up. If it were gener= ating keys for the version that made the OOB network work, then what would = happen if it got out of sync? Didn't you sort of suggest below that if the key management protocol needs = to talk to some external device, then the external device needs to - like t= he initial method's used to bring up the router - either be local to the ro= uter, or run over a separate OOB network? It seems to make sense to add the= option of operating over a separate OOB network to the text that I was pro= posing. In the early days of the Arpanet, there was one "event" where the entire ne= twork crashed, and the operators had to first fix only the router's which w= ere adjacent to the network management station, then fix the ones which wer= e adjacent to the one's already fixed, and recurse in this way through the = network. I don't think that this is a method that we want to recommend as t= he normal method to recover from major events (it would seem to get progres= sively uglier as networks get bigger). Ross From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Monday, August 15, 2011 10:06 AM To: Ross Callon; Gregory Lebovitz Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russ= w@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 This imo can certainly happen. I used to know at least one big deployment i= n Europe that ran OSPF on its out-of-management plane - not sure if they st= ill do. If we define a new KMP that secures OSPF, then it could certainly r= un over the OOB ports. Cheers, Manav ________________________________ From: Ross Callon [mailto:rcallon@juniper.net] Sent: Monday, August 15, 2011 6:48 PM To: Gregory Lebovitz Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Would a security protocol, for example used for automated key management, o= perate over the out of band management plane, or would it operate over the = normal data plane, or between two systems directly attached at the link lay= er, or in some other way? Ross From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Saturday, August 13, 2011 3:10 AM To: Ross Callon Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Hey all. Ross, the circular dependency issue is not really an issue. I remember you = raising it early on in the KARP formation process, and me explaining the fo= llowing, which was taken from the survey of about 7 operators I did before = I wrote the original text (which later became the drafts to forming KARP): When operators bring up new routers, or bring up replaced/fixed routers, th= ey do so by having a human local to the device rack it, connect it to a con= sole server, and then send the coordinates to a NOC operator. Said NOC oper= ator then starts to build up the config on the device. A few static routes,= or a default route, is placed into the device first in order to test basic= network connectivity and to setup up secure, inband management. At this po= int keys are often created for SSH use. Many other items are configured on = the device that have to do with OAM, and all are tested, BEFORE dynamic rou= ting is turned on. In other words, the device has to function well on the n= etwork as a healthy host before it becomes a forwarding agent. Once all thi= s is clear and verified, then routing is turned on protocol by protocol and= confirmed. The above process was ubiquitously followed by operators. NONE ever relied = on routing protocols for management connectivity, not at least at the point= of boot strapping. Any credentials or validating data that would need to b= e fetched in order to secure the routing protocol would be loaded or fetche= d BEFORE routing protocols were turned on, using default or static routes, = just as all other config / data is fetched at device bring up. I recall when I explained this to you at the onset of all this work you sai= d something to the effect of, "Oh, I get it. That makes me feel much better= . So it's not really an issue then," and we moved on. Having said all that, I'm not opposed to your NEW proposal below. If everyo= ne else agrees I would live with it. However, I will point out that a healt= hy use of "SHOULD NOT" would contain a clear explanation of the circumstanc= e/condition under which it is acceptable to break the guidance, and reminde= r that aside from such circumstance/condition, the guidance ought be follow= ed. I think both the OLD and NEW text already contained the explanation of = when requiring connections to external systems is acceptable: to require p= ost-initialization synchronization "in order to fully synchronize the secur= ity information." Thus, the SHOULD NOT was ok, because we stated the condit= ion under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT"= and then telling them when it's okay to break the condition really is the = same as a "SHOULD NOT", no? Would the following address your concerns, and = also have logic integrity: NEW II 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing protocols whereby the operation of the security mechanism would require a routing protocol -- which we are trying to secure -- to alrea= dy be running in order to properly forward packets. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. The condition under which it is acceptable for the proposed solutions to require connection= s to external systems is for post initialization synchronization with external systems, in order to fully synchronize the security information. I think the above (1) makes your point about circular dependency, (2) makes= it clear the only time when the SHOULD NOT would be disobeyed, (3) has log= ical integrity. Does it work for all you folks? Hope it helps, Gregory On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: Regarding requirement number 24, changing "should not" to "must not" does h= elp a lot. However, it might be worth adding a bit of explanation. How abou= t: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. NEW 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing (which itself is required to deliver IP packets to any external systems which are not directly connected at the link layer). Therefore, proposed solutions MUST NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. Does this look okay to you? Thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@= cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs= .all@tools.ietf.org= ; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.c= om Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, Thanks for the detailed review! > This last point has a relationship with the requirement currently > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if > the proposed solution is being used to authenticate OSPF or IS-IS, > and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended > victims of DDOS attacks, which may be aimed at the router's control > plane. As such it is normal for routers to make use of packet [clipped] > against DDOS. Thus in defining security mechanisms there should be a > strong preference for mechanisms that don't hide nor encrypt the > information that the router hardware is able to inspect at full > line rate for DDOS protection (such as IP addresses, and TCP ports). > I think that a bit more text along the lines might be appropriate > to be added to this bullet item. How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6A41EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But if th= e key management protocol was running over the out of band management netwo= rk, then which version of OSPF would it be generating keys for? If it were = generating keys to be used for the version of OSPF running on its productio= n network, then there is a clear bootstrapping path either initially or to = recover from any bad state: first the OOB network comes up, then the keys a= re exchanged, then the regular network comes up.  If it were generatin= g keys for the version that made the OOB network work, then what would happ= en if it got out of sync?

 

Didn’t you s= ort of suggest below that if the key management protocol needs to talk to s= ome external device, then the external device needs to – like the ini= tial method’s used to bring up the router – either be local to = the router, or run over a separate OOB network? It seems to make sense to a= dd the option of operating over a separate OOB network to the text that I w= as proposing.

 =

In the early days of the Arpan= et, there was one “event” where the entire network crashed, and= the operators had to first fix only the router’s which were adjacent= to the network management station, then fix the ones which were adjacent t= o the one’s already fixed, and recurse in this way through the networ= k. I don’t think that this is a method that we want to recommend as t= he normal method to recover from major events (it would seem to get progres= sively uglier as networks get bigger).

 

Ross=

 <= /p>

From: Bhatia, Manav (Manav) [mailto:man= av.bhatia@alcatel-lucent.com]
Sent: Monday, August 15, 2011 10:0= 6 AM
To: Ross Callon; Gregory Lebovitz
Cc: rtg-dir@ietf= .org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregor= y Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com
Subject: RE: = reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-t= hreats-reqs-03

&= nbsp;

This imo can certainly happen. I used= to know at least one big deployment in Europe that ran OSPF on i= ts out-of-management plane - not sure if they still do. If we define a new = KMP that secures OSPF, then it could certainly run over the OOB ports.

 

Cheers, Manav

=  

From: Ross Callon [mailto:rcallon@junip= er.net]
Sent: Monday, August 15, 2011 6:48 PM
To: Greg= ory Lebovitz
Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-i= etf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; a= drian@olddog.co.uk; stbryant@cisco.com
Subject: RE: reliance on e= xternal systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-0= 3

Would a security protoco= l, for example used for automated key management, operate over the out of b= and management plane, or would it operate over the normal data plane, or be= tween two systems directly attached at the link layer, or in some other way= ?

 

Ross

 

From: G= regory Lebovitz [mailto:gregory.ietf@gmail.com]
Sent: Saturday, = August 13, 2011 3:10 AM
To: Ross Callon
Cc: Bhatia, Man= av (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.o= rg; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com=
Subject: Re: reliance on external systems (req 24), RE: RtgDir r= eview: draft-ietf-karp-threats-reqs-03

 

Hey all.<= /p>

 

Ross, the circular dependency issue is not really an issue. I rememb= er you raising it early on in the KARP formation process, and me explaining= the following, which was taken from the survey of about 7 operators I did = before I wrote the original text (which later became the drafts to forming = KARP):

  

When operators bring up new routers, o= r bring up replaced/fixed routers, they do so by having a human local to th= e device rack it, connect it to a console server, and then send the coordin= ates to a NOC operator. Said NOC operator then starts to build up the confi= g on the device. A few static routes, or a default route, is placed into th= e device first in order to test basic network connectivity and to setup up = secure, inband management. At this point keys are often created for SSH use= . Many other items are configured on the device that have to do with OAM, a= nd all are tested, BEFORE dynamic routing is turned on. In other words, the= device has to function well on the network as a healthy host before it bec= omes a forwarding agent. Once all this is clear and verified, then routing = is turned on protocol by protocol and confirmed.

<= p class=3DMsoNormal> 

Th= e above process was ubiquitously followed by operators. NONE ever relied on= routing protocols for management connectivity, not at least at the point o= f boot strapping. Any credentials or validating data that would need to be = fetched in order to secure the routing protocol would be loaded or fetched = BEFORE routing protocols were turned on, using default or static routes, ju= st as all other config / data is fetched at device bring up.

=

 

I recall when I explained this to you at the onset of all this wo= rk you said something to the effect of, "Oh, I get it. That makes me f= eel much better. So it's not really an issue then," and we moved on.

 

Having said all that, I'm not opposed to your NEW pr= oposal below. If everyone else agrees I would live with it. However, I will= point out that a healthy use of "SHOULD NOT" would contain a cle= ar explanation of the circumstance/condition under which it is acceptable t= o break the guidance, and reminder that aside from such circumstance/condit= ion, the guidance ought be followed. I think both the OLD and NEW text alre= ady contained the explanation of when requiring connections to external sys= tems is acceptable:  to require post-initialization synchronization &q= uot;in order to fully synchronize the security information." Thus, the= SHOULD NOT was ok, because we stated the condition under which it was reas= onable to defy the SHOULD NOT. Saying "MUST NOT" and then telling= them when it's okay to break the condition really is the same as a "S= HOULD NOT", no? Would the following address your concerns, and also ha= ve logic integrity:

&nbs= p;

NEW II


24.  The new authentication and security mechanis= ms should not rely
    on systems external to the routing syst= em (the equipment that
    is performing forwarding).  In= order to ensure the rapid
    initialization and/or return to= service of failed nodes it is
    important to reduce relianc= e on these external systems to the
    greatest extent possibl= e. Also, it is necessary to avoid a
    circular dependency be= tween the security mechanisms and routing

    protocols whereby the operation of the secur= ity mechanism would 

&nb= sp;   require a routing protocol -- which we are trying to secure= -- to already

   &= nbsp;be running in order to properly forward packets.
    Ther= efore, proposed solutions SHOULD NOT require connections to
   = ; external systems, beyond those directly involved in peering
  &nb= sp; relationships, in order to return to full service.  The condition = under 
    which it is acceptable for the proposed s= olutions to require connections

&nb= sp;   to external systems is for post

    initialization synchronization with external sys= tems, in order to
    fully synchronize the security informati= on. 

 

I think the above (1) makes your point about ci= rcular dependency, (2) makes it clear the only time when the SHOULD NOT wou= ld be disobeyed, (3) has logical integrity. Does it work for all you folks?=

 

<= div>

Hope it helps,

Gregory

 

On Fr= i, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net> wrote:

Regarding requirement number 24, changin= g "should not" to "must not" does help a lot. However, = it might be worth adding a bit of explanation. How about:

OLD
24.  The new authentication and security mechanisms should not rely    on systems external to the routing system (the equipment th= at is
    performing forwarding).  In order to ensure the= rapid
    initialization and/or return to service of failed n= odes it is
    important to reduce reliance on these external = systems to the
    greatest extent possible.  Therefore, = proposed solutions SHOULD
    NOT require connections to exter= nal systems, beyond those
    directly involved in peering rel= ationships, in order to return
    to full service.  It i= s however acceptable for the proposed
    solutions to require= post initialization synchronization with
    external systems= in order to fully synchronize the security
    information.
NEW

24.  The new authentication and security mechanisms s= hould not rely
    on systems external to the routing system (= the equipment that
    is performing forwarding).  In ord= er to ensure the rapid
    initialization and/or return to ser= vice of failed nodes it is
    important to reduce reliance on= these external systems to the
    greatest extent possible. A= lso, it is necessary to avoid a
    circular dependency betwee= n the security mechanisms and routing
    (which itself is req= uired to deliver IP packets to any external
    systems which = are not directly connected at the link layer).
    Therefore, = proposed solutions MUST NOT require connections to
    externa= l systems, beyond those directly involved in peering
    relat= ionships, in order to return to full service.  It is
    = however acceptable for the proposed solutions to require post
  &nb= sp; initialization synchronization with external systems in order to
&nb= sp;   fully synchronize the security information.


Does this= look okay to you?

Thanks, Ross

-----Original Message-----From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Friday, August 1= 2, 2011 5:09 AM
To: Ross Callon; = adrian@olddog.co.uk; stbryant@cis= co.com
Cc: rtg-dir@ietf.org;= draft-i= etf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subject: RE: RtgDir review: draft-ietf-= karp-threats-reqs-03

Hi Ross,

Thanks for the detailed review!=

> This last point has a relationship with the requirement curren= tly
> listed as number 24. It says "Therefore, proposed solution= s SHOULD
> NOT require connections to external systems...". Howe= ver, note that if
> the proposed solution is being used to authentica= te OSPF or IS-IS,
> and if OSPF or IS-IS will not bring up links unti= l they are
> authenticated, and if the proposed solution requires sen= ding any
> information to or getting any response from a not-directly= -attached
> remote system, then it isn't going to work. In this regar= d I think
> that the "SHOULD NOT" in requirement 24 is not = strong enough, and
> the potential for deadlock should be explicitly = mentioned.

Would it work if we replace SHOULD NOT with a MUST NOT?
> Section 3, 9th bullet item (about DOS attacks): Routers are occa= sional intended
> victims of DDOS attacks, which may be aimed at the = router's control
> plane. As such it is normal for routers to make us= e of packet

[clipped]

> against DDOS. Thus in defining sec= urity mechanisms there should be a
> strong preference for mechanisms= that don't hide nor encrypt the
> information that the router hardwa= re is able to  inspect at full
> line rate for DDOS protection (= such as IP addresses, and TCP ports).
> I think that a bit more text = along the lines might be appropriate
> to be added to this bullet ite= m.

How about something on these lines:

New mechanisms must re= sist DoS attacks described as in-scope in the threats section 2.1 above. Ro= uters protect the control plane by implementing mechanisms to filter comple= tely or rate limit traffic not required at the control plane level (i.e., u= nwanted traffic).  This is done by deep inspecting the packets and onl= y accepting the legitimate ones. The new mechanisms shouldn't thus hide or = encrypt the information carried in the control plane packets so that router= s can inspect these packets at the line rate.

I have taken note of y= our other comments and those will get fixed in the next revision.

Ch= eers, Manav



 

--
----
IETF related email from
Gregory M. Lebovitz<= br>Juniper Networks

= --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6A41EMBX01WFjnprn_-- From manav.bhatia@alcatel-lucent.com Mon Aug 15 07:05:59 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A9121F8B80 for ; Mon, 15 Aug 2011 07:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPWFi2MAcZng for ; Mon, 15 Aug 2011 07:05:58 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F09B921F8B7E for ; Mon, 15 Aug 2011 07:05:57 -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 p7FE6ZGP014629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Aug 2011 09:06:37 -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 p7FE6Vhc016889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Aug 2011 19:36:32 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 15 Aug 2011 19:36:31 +0530 From: "Bhatia, Manav (Manav)" To: Ross Callon , Gregory Lebovitz Date: Mon, 15 Aug 2011 19:36:29 +0530 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxZiBlA9g+3ZaMbSySX0bw+90SyyABxWtnQAAGRoUA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF8E2F8F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.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: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFF8E2F8FINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Mailman-Approved-At: Mon, 15 Aug 2011 21:39:35 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:05:59 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFF8E2F8FINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This imo can certainly happen. I used to know at least one big deployment i= n Europe that ran OSPF on its out-of-management plane - not sure if they st= ill do. If we define a new KMP that secures OSPF, then it could certainly r= un over the OOB ports. Cheers, Manav ________________________________ From: Ross Callon [mailto:rcallon@juniper.net] Sent: Monday, August 15, 2011 6:48 PM To: Gregory Lebovitz Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Would a security protocol, for example used for automated key management, o= perate over the out of band management plane, or would it operate over the = normal data plane, or between two systems directly attached at the link lay= er, or in some other way? Ross From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Saturday, August 13, 2011 3:10 AM To: Ross Callon Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Hey all. Ross, the circular dependency issue is not really an issue. I remember you = raising it early on in the KARP formation process, and me explaining the fo= llowing, which was taken from the survey of about 7 operators I did before = I wrote the original text (which later became the drafts to forming KARP): When operators bring up new routers, or bring up replaced/fixed routers, th= ey do so by having a human local to the device rack it, connect it to a con= sole server, and then send the coordinates to a NOC operator. Said NOC oper= ator then starts to build up the config on the device. A few static routes,= or a default route, is placed into the device first in order to test basic= network connectivity and to setup up secure, inband management. At this po= int keys are often created for SSH use. Many other items are configured on = the device that have to do with OAM, and all are tested, BEFORE dynamic rou= ting is turned on. In other words, the device has to function well on the n= etwork as a healthy host before it becomes a forwarding agent. Once all thi= s is clear and verified, then routing is turned on protocol by protocol and= confirmed. The above process was ubiquitously followed by operators. NONE ever relied = on routing protocols for management connectivity, not at least at the point= of boot strapping. Any credentials or validating data that would need to b= e fetched in order to secure the routing protocol would be loaded or fetche= d BEFORE routing protocols were turned on, using default or static routes, = just as all other config / data is fetched at device bring up. I recall when I explained this to you at the onset of all this work you sai= d something to the effect of, "Oh, I get it. That makes me feel much better= . So it's not really an issue then," and we moved on. Having said all that, I'm not opposed to your NEW proposal below. If everyo= ne else agrees I would live with it. However, I will point out that a healt= hy use of "SHOULD NOT" would contain a clear explanation of the circumstanc= e/condition under which it is acceptable to break the guidance, and reminde= r that aside from such circumstance/condition, the guidance ought be follow= ed. I think both the OLD and NEW text already contained the explanation of = when requiring connections to external systems is acceptable: to require p= ost-initialization synchronization "in order to fully synchronize the secur= ity information." Thus, the SHOULD NOT was ok, because we stated the condit= ion under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT"= and then telling them when it's okay to break the condition really is the = same as a "SHOULD NOT", no? Would the following address your concerns, and = also have logic integrity: NEW II 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing protocols whereby the operation of the security mechanism would require a routing protocol -- which we are trying to secure -- to alrea= dy be running in order to properly forward packets. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. The condition under which it is acceptable for the proposed solutions to require connection= s to external systems is for post initialization synchronization with external systems, in order to fully synchronize the security information. I think the above (1) makes your point about circular dependency, (2) makes= it clear the only time when the SHOULD NOT would be disobeyed, (3) has log= ical integrity. Does it work for all you folks? Hope it helps, Gregory On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: Regarding requirement number 24, changing "should not" to "must not" does h= elp a lot. However, it might be worth adding a bit of explanation. How abou= t: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. NEW 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing (which itself is required to deliver IP packets to any external systems which are not directly connected at the link layer). Therefore, proposed solutions MUST NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. Does this look okay to you? Thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@= cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs= .all@tools.ietf.org= ; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.c= om Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, Thanks for the detailed review! > This last point has a relationship with the requirement currently > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if > the proposed solution is being used to authenticate OSPF or IS-IS, > and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended > victims of DDOS attacks, which may be aimed at the router's control > plane. As such it is normal for routers to make use of packet [clipped] > against DDOS. Thus in defining security mechanisms there should be a > strong preference for mechanisms that don't hide nor encrypt the > information that the router hardware is able to inspect at full > line rate for DDOS protection (such as IP addresses, and TCP ports). > I think that a bit more text along the lines might be appropriate > to be added to this bullet item. How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --_000_7C362EEF9C7896468B36C9B79200D8350CFF8E2F8FINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This imo can certainly happen. I used to know = ;at least=20 one big deployment in Europe that ran OSPF on its out-of-management pl= ane -=20 not sure if they still do. If we define a new KMP that secures OSPF, then i= t=20 could certainly run over the OOB ports.
 
Cheers, Manav

From: Ross Callon [mailto:rcallon@jun= iper.net]=20
Sent: Monday, August 15, 2011 6:48 PM
To: Gregory=20 Lebovitz
Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org;=20 draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory=20 Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com
Subject: RE:= =20 reliance on external systems (req 24), RE: RtgDir review:=20 draft-ietf-karp-threats-reqs-03

Would=20 a security protocol, for example used for automated key management, opera= te=20 over the out of band management plane, or would it operate over the norma= l=20 data plane, or between two systems directly attached at the link layer, o= r in=20 some other way?

 

Ross

 

From: Gregory Le= bovitz=20 [mailto:gregory.ietf@gmail.com]
Sent: Saturday, August 13, 201= 1=20 3:10 AM
To: Ross Callon
Cc: Bhatia, Manav (Manav);=20 rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org;=20 russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk;=20 stbryant@cisco.com
Subject: Re: reliance on external systems (r= eq=20 24), RE: RtgDir review:=20 draft-ietf-karp-threats-reqs-03

 

Hey all.

 

Ross, the circular dependency issue is not really an= issue.=20 I remember you raising it early on in the KARP formation process, and me= =20 explaining the following, which was taken from the survey of about 7 oper= ators=20 I did before I wrote the original text (which later became the drafts to= =20 forming KARP):

  

When operators bring up new routers, or bring up=20 replaced/fixed routers, they do so by having a human local to the device = rack=20 it, connect it to a console server, and then send the coordinates to a NO= C=20 operator. Said NOC operator then starts to build up the config on the dev= ice.=20 A few static routes, or a default route, is placed into the device first = in=20 order to test basic network connectivity and to setup up secure, inband=20 management. At this point keys are often created for SSH use. Many other = items=20 are configured on the device that have to do with OAM, and all are tested= ,=20 BEFORE dynamic routing is turned on. In other words, the device has to=20 function well on the network as a healthy host before it becomes a forwar= ding=20 agent. Once all this is clear and verified, then routing is turned on pro= tocol=20 by protocol and confirmed.

 

The above process was ubiquitously followed by opera= tors.=20 NONE ever relied on routing protocols for management connectivity, not at= =20 least at the point of boot strapping. Any credentials or validating data = that=20 would need to be fetched in order to secure the routing protocol would be= =20 loaded or fetched BEFORE routing protocols were turned on, using default = or=20 static routes, just as all other config / data is fetched at device bring= =20 up.

 

I recall when I explained this to you at the onset o= f all=20 this work you said something to the effect of, "Oh, I get it. That makes = me=20 feel much better. So it's not really an issue then," and we moved=20 on.

 

Having said all that, I'm not opposed to your NEW pr= oposal=20 below. If everyone else agrees I would live with it. However, I will poin= t out=20 that a healthy use of "SHOULD NOT" would contain a clear explanation of t= he=20 circumstance/condition under which it is acceptable to break the guidance= , and=20 reminder that aside from such circumstance/condition, the guidance ought = be=20 followed. I think both the OLD and NEW text already contained the explana= tion=20 of when requiring connections to external systems is acceptable:  to= =20 require post-initialization synchronization "in order to fully synchroniz= e the=20 security information." Thus, the SHOULD NOT was ok, because we stated the= =20 condition under which it was reasonable to defy the SHOULD NOT. Saying "M= UST=20 NOT" and then telling them when it's okay to break the condition really i= s the=20 same as a "SHOULD NOT", no? Would the following address your concerns, an= d=20 also have logic integrity:

 

NEW II


24.  The new authentication and security=20 mechanisms should not rely
    on systems external to the ro= uting=20 system (the equipment that
    is performing forwarding).=20  In order to ensure the rapid
    initialization and/or= =20 return to service of failed nodes it is
    important to red= uce=20 reliance on these external systems to the
    greatest exten= t=20 possible. Also, it is necessary to avoid a
    circular=20 dependency between the security mechanisms and routing

    protocols whereby the operat= ion of=20 the security mechanism would 

    require a routing protocol -- whi= ch we=20 are trying to secure -- to already

    be running in order to properly f= orward=20 packets.
    Therefore, proposed solutions SHOULD NOT requir= e=20 connections to
    external systems, beyond those directly=20 involved in peering
    relationships, in order to return to= full=20 service.  The condition under 
    which it i= s=20 acceptable for the proposed solutions to require connections

    to external systems is for=20 post

    initialization synchronization with ex= ternal=20 systems, in order to
    fully synchronize the security=20 information. 

 

I think the above (1) makes your point about circula= r=20 dependency, (2) makes it clear the only time when the SHOULD NOT would be= =20 disobeyed, (3) has logical integrity. Does it work for all you=20 folks?

 

Hope it helps,

Gregory

 

On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net>=20 wrote:

Regarding requirement = number=20 24, changing "should not" to "must not" does help a lot. However, it migh= t be=20 worth adding a bit of explanation. How about:

OLD

24.  = ;The=20 new authentication and security mechanisms should not rely
  &nbs= p; on=20 systems external to the routing system (the equipment that is
  &= nbsp;=20 performing forwarding).  In order to ensure the rapid
  &nbs= p;=20 initialization and/or return to service of failed nodes it is
  &= nbsp;=20 important to reduce reliance on these external systems to the
  &= nbsp;=20 greatest extent possible.  Therefore, proposed solutions SHOULD
&= nbsp;=20   NOT require connections to external systems, beyond those
 = ;=20   directly involved in peering relationships, in order to=20 return
    to full service.  It is however acceptable f= or=20 the proposed
    solutions to require post initialization=20 synchronization with
    external systems in order to fully= =20 synchronize the security
    information.

NEW

= 24.=20  The new authentication and security mechanisms should not rely
&= nbsp;=20   on systems external to the routing system (the equipment that
&= nbsp;=20   is performing forwarding).  In order to ensure the rapid
&= nbsp;=20   initialization and/or return to service of failed nodes it is
&= nbsp;=20   important to reduce reliance on these external systems to the
&= nbsp;=20   greatest extent possible. Also, it is necessary to avoid a
&nbs= p;=20   circular dependency between the security mechanisms and=20 routing
    (which itself is required to deliver IP packets = to=20 any external
    systems which are not directly connected at= the=20 link layer).
    Therefore, proposed solutions MUST NOT requ= ire=20 connections to
    external systems, beyond those directly=20 involved in peering
    relationships, in order to return to= full=20 service.  It is
    however acceptable for the proposed= =20 solutions to require post
    initialization synchronization= with=20 external systems in order to
    fully synchronize the secur= ity=20 information.


Does this look okay to you?

Thanks,=20 Ross

-----Original Message-----
From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-luce= nt.com]
Sent:=20 Friday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc: rtg-dir@ietf.org; draft-iet= f-karp-threats-reqs.all@tools.ietf.org;=20 russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subj= ect:=20 RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi=20 Ross,

Thanks for the detailed review!

> This last point = has a=20 relationship with the requirement currently
> listed as number 24. = It=20 says "Therefore, proposed solutions SHOULD
> NOT require connection= s to=20 external systems...". However, note that if
> the proposed solution= is=20 being used to authenticate OSPF or IS-IS,
> and if OSPF or IS-IS wi= ll=20 not bring up links until they are
> authenticated, and if the propo= sed=20 solution requires sending any
> information to or getting any respo= nse=20 from a not-directly-attached
> remote system, then it isn't going t= o=20 work. In this regard I think
> that the "SHOULD NOT" in requirement= 24=20 is not strong enough, and
> the potential for deadlock should be=20 explicitly mentioned.

Would it work if we replace SHOULD NOT with = a=20 MUST NOT?

> Section 3, 9th bullet item (about DOS attacks): Rou= ters=20 are occasional intended
> victims of DDOS attacks, which may be aim= ed at=20 the router's control
> plane. As such it is normal for routers to m= ake=20 use of packet

[clipped]

> against DDOS. Thus in defining= =20 security mechanisms there should be a
> strong preference for mecha= nisms=20 that don't hide nor encrypt the
> information that the router hardw= are=20 is able to  inspect at full
> line rate for DDOS protection (s= uch=20 as IP addresses, and TCP ports).
> I think that a bit more text alo= ng=20 the lines might be appropriate
> to be added to this bullet=20 item.

How about something on these lines:

New mechanisms mu= st=20 resist DoS attacks described as in-scope in the threats section 2.1 above= .=20 Routers protect the control plane by implementing mechanisms to filter=20 completely or rate limit traffic not required at the control plane level= =20 (i.e., unwanted traffic).  This is done by deep inspecting the packe= ts=20 and only accepting the legitimate ones. The new mechanisms shouldn't thus= hide=20 or encrypt the information carried in the control plane packets so that=20 routers can inspect these packets at the line rate.

I have taken n= ote=20 of your other comments and those will get fixed in the next=20 revision.

Cheers, Manav



 

--
----
IETF related email from
Gregory M.= =20 Lebovitz
Juniper=20 Networks

--_000_7C362EEF9C7896468B36C9B79200D8350CFF8E2F8FINBANSXCHMBSA_-- From akatlas@juniper.net Mon Aug 15 10:09:30 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858AE21F8C78 for ; Mon, 15 Aug 2011 10:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZJ6ZfYhlvNJ for ; Mon, 15 Aug 2011 10:09:30 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 99DDB21F8C75 for ; Mon, 15 Aug 2011 10:09:29 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTklS8jnENvRsc1gkIZeDM03eUhMJ7HAr@postini.com; Mon, 15 Aug 2011 10:10:16 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Aug 2011 10:07:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 15 Aug 2011 13:07:19 -0400 From: Alia Atlas To: "rtg-ads@tools.ietf.org" Date: Mon, 15 Aug 2011 13:07:18 -0400 Thread-Topic: RtgDir review: draft-ietf-ospf-auth-trailer-ospfv3-05.txt Thread-Index: AcxbbcmvSJ+anaYxRPmXAy+HjCWq6Q== Message-ID: 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-Mailman-Approved-At: Mon, 15 Aug 2011 21:39:35 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-ospf-auth-trailer-ospfv3-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:09:30 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ospf-auth-trailer-ospfv3-05.txt Reviewer: Alia Atlas Review Date: August 15, 2011 IETF LC End Date: August 16, 2011 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should = be considered prior to publication. Comments: I found this draft to be very well written and carefully addresses details = and transitions. The technology is a straightforward extension of work don= e for OSPFv2 to apply to OSPFv3 with the added benefit of protecting agains= t replay attacks. Major Issues: Minor Issues: Nits: 1) In Sec 4.1, for Cryptographic Sequence Number, additional description in= dicating behavior when the value wraps would be useful. If that is never e= xpected, that is also useful to state. The phrase "strictly increasing" is= not sufficiently clear to me. 2) In Sec 1, 3rd paragraph, last sentence /s/platforms or it/platforms or with it/ 3) In Sec 3, 3rd paragraph under Security Association Identifier (SA ID), f= irst sentence /s/The sender based on/The sender, based on/ /s/OSPFV3/OSPFv3/ 4) Last paragraph on p. 13: " If the cryptographic sequence number in the AT is less than or equal to the last sequence number received from the neighbor, the OSPFv3 packet MUST be dropped." Perhaps change received to "successfully received" just to clarify that onl= y packets which have passed the authentication check will have their sequence number used to upd= ate the last sequence number. 5) Sec 8.1: Shouldn't OSPFv3 [RFC5340] be a normative reference rather tha= n informative. From acee.lindem@ericsson.com Wed Aug 17 08:16:44 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2072421F8B52 for ; Wed, 17 Aug 2011 08:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QqcBc+U1FMR for ; Wed, 17 Aug 2011 08:16:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2121321F8B51 for ; Wed, 17 Aug 2011 08:16:43 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7HFHPJH004557; Wed, 17 Aug 2011 10:17:27 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.220]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 17 Aug 2011 11:17:23 -0400 From: Acee Lindem To: Alia Atlas Date: Wed, 17 Aug 2011 11:17:21 -0400 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ospf-auth-trailer-ospfv3-05.txt Thread-Index: Acxc8MOXJ+ZYf13WScO2qOkiOTB9uw== Message-ID: <1B091506-A261-4AA1-863E-E95DAC610076@ericsson.com> References: 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: "rtg-dir@ietf.org" , "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ospf-auth-trailer-ospfv3-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:16:44 -0000 Hi Alia, Thanks much for the thorough review. We have some comments from Sam as well= . We will incorporate your updates once we decide what to do with his comme= nts which are mostly based on the presumption of a global crypto table infr= astructure (which was only recently made a KARP WG document). See inline.=20 On Aug 15, 2011, at 1:07 PM, Alia Atlas wrote: > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://www.ietf.org/iesg/directorate/routing.html >=20 > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft. >=20 > Document: draft-ietf-ospf-auth-trailer-ospfv3-05.txt > Reviewer: Alia Atlas > Review Date: August 15, 2011 > IETF LC End Date: August 16, 2011 > Intended Status: Standards Track >=20 > Summary: >=20 > This document is basically ready for publication, but has nits that shoul= d be considered prior to publication. >=20 > Comments: >=20 > I found this draft to be very well written and carefully addresses detail= s and transitions. The technology is a straightforward extension of work d= one for OSPFv2 to apply to OSPFv3 with the added benefit of protecting agai= nst replay attacks. >=20 > Major Issues: >=20 > Minor Issues: >=20 > Nits: >=20 > 1) In Sec 4.1, for Cryptographic Sequence Number, additional description = indicating behavior when the value wraps would be useful. =20 We will add this. I admit that the behavior is implied based on the discuss= ion of the upper word in the sequence number.=20 > If that is never expected, that is also useful to state. The phrase "str= ictly increasing" is not sufficiently clear to me. This is as opposed to the current requirement that the sequence number is m= onotonically increasing. Would adding, ",i.e., greater than the previously = received sequence number," suffice? The term "strictly increasing" is used = in this Wiki: http://en.wikipedia.org/wiki/Monotonic_function >=20 > 2) In Sec 1, 3rd paragraph, last sentence > /s/platforms or it/platforms or with it/ Will update.=20 >=20 > 3) In Sec 3, 3rd paragraph under Security Association Identifier (SA ID),= first sentence > /s/The sender based on/The sender, based on/ > /s/OSPFV3/OSPFv3/ Good catch.=20 >=20 > 4) Last paragraph on p. 13: > " If the cryptographic sequence number in the AT is less than or equal > to the last sequence number received from the neighbor, the OSPFv3 > packet MUST be dropped." > Perhaps change received to "successfully received" just to clarify that o= nly packets which have > passed the authentication check will have their sequence number used to u= pdate the last sequence number. Good point.=20 >=20 > 5) Sec 8.1: Shouldn't OSPFv3 [RFC5340] be a normative reference rather t= han informative. I agree.=20 Thanks, Acee=20 >=20 >=20 From zali@cisco.com Wed Aug 17 09:40:48 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF47921F8BA6 for ; Wed, 17 Aug 2011 09:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIfWlEihKQof for ; Wed, 17 Aug 2011 09:40:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB1721F8AD8 for ; Wed, 17 Aug 2011 09:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=38607; q=dns/txt; s=iport; t=1313599298; x=1314808898; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=I68IRUdAE8QPcVqpAzyvEnrJFpz4cc5NutbtqTP+nXs=; b=ReG8L2K0cS9id69VSWMxQrac00JNNtrOrM0hNe22H7xLUsFdZGnd178j aT+ZD2goR77sLP8YCDdWYtyyc19EpCIKaSN29Yp1Yza+PQ4tMboYZynX2 9pii5RaQRs7iIYOFukTcAWBKOqW/w+ai09NCEqVVWJL6mmN4cWDAhJx5L A=; X-Files: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt : 24792 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAAANDtS06tJV2a/2dsb2JhbAA4CoRIlE+OYXd3gTkHAQEBAQIBEgEHAgcNNwYFBwUHBAIBCBEDAQEBCwYXAQICAgEBRAkIAQEEARIIARmHTgSWdAGNMZFpgyeCETFfBIdgkEiLfg X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="txt'?scan'208";a="14013401" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 17 Aug 2011 16:41:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7HGfbGY030734; Wed, 17 Aug 2011 16:41:37 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 11:41:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC5CFC.88376F51" Date: Wed, 17 Aug 2011 11:41:36 -0500 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B05AEA1A0@XMB-RCD-103.cisco.com> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AC854B63@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt Thread-Index: AcxYbrZgrOy15FlHTbWbuc2wvgtr+AEjIT3g References: <5E893DB832F57341992548CDBB333163A0AC854B63@EMBX01-HQ.jnpr.net> From: "Zafar Ali (zali)" To: "John E Drake" , X-OriginalArrivalTime: 17 Aug 2011 16:41:37.0720 (UTC) FILETIME=[886C1380:01CC5CFC] X-Mailman-Approved-At: Wed, 17 Aug 2011 09:43:25 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-rsvp-te-no-php-oob-mapping.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 16:40:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5CFC.88376F51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSm9objogDQoNClRoYW5rcyBmb3IgeW91ciBraW5kIHJldmlldy4gUGxlYXNlIHNlZSBteSBy ZXNwb25zZSBpbi1saW5lLiANCg0KVGhhbmtzDQoNClJlZ2FyZHMgLi4uIFphZmFyIA0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9obiBFIERyYWtlIFttYWlsdG86 amRyYWtlQGp1bmlwZXIubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDU6 MzYgUE0NCj4gVG86IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IHJ0Zy1kaXJAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtbXBscy1yc3ZwLXRlLW5vLXBocC1vb2ItDQo+IG1hcHBpbmcuYWxsQHRv b2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1y c3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0NCj4gMDgudHh0DQo+IA0KPiBIZWxsbywNCj4gDQo+ IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0Lg0KPiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZp ZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+IGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZA0KPiBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUNCj4gYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IHRoZSBSb3V0aW5nDQo+IERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCj4gDQo+IEFsdGhvdWdo IHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcg QURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFs b25nIHdpdGggYW55IG90aGVyIElFVEYNCj4gTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJl Y2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gNCj4gZGlzY3Vzc2lvbiBv ciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDogIGRyYWZ0LWlldGYtbXBs cy1yc3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0wOC50eHQNCj4gUmV2aWV3ZXI6IEpvaG4gRHJh a2UNCj4gUmV2aWV3IERhdGU6IDExLUF1Zy0xMQ0KPiBJRVRGIExDIEVuZCBEYXRlOiAxMS1BdWct MTENCj4gSW50ZW5kZWQgU3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gU3VtbWFyeToN Cj4gDQo+IEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhh dCBJIHRoaW5rIHNob3VsZCBiZQ0KPiByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+IA0K PiBDb21tZW50czoNCj4gDQo+IFRoZSBkb2N1bWVudCBpcyB3ZWxsLXdyaXR0ZW4gYW5kIHZlcnkg cmVhZGFibGUsIGFuZCBpcyBuaWNlbHkgZm9jdXNlZCBvbg0KPiBzb2x2aW5nIGEgc3BlY2lmaWMg cHJvYmxlbSB0aGF0IGhhcyBleGlzdGVkIGZvciBxdWl0ZQ0KPiBzb21lIHRpbWUuDQo+IA0KPiBN YWpvciBJc3N1ZXM6DQo+IA0KPiBObyBtYWpvciBpc3N1ZXMgZm91bmQNCj4gDQo+IE1pbm9yIElz c3VlczoNCj4gDQo+IFRoZXJlIGFyZSBzZXZlcmFsIGFwcGFyZW50bHkgbm9ybWF0aXZlIHJlZmVy ZW5jZXMgdG8ge0FUVFJJQlVURVMtQk5GXQ0KPiB3aGljaCBJIGNvdWxkIG5vdCBmaW5kIGluIHRo ZSBSZWZlcmVuY2VzIHNlY3Rpb24uDQo+IA0KDQpTb3JyeSwgdGhpcyB3YXMgbWlzc2luZyBieSBt aXN0YWtlLiBBZHJpYW4gYWxzbyBwb2ludGVkIHRoaXMgb3V0IGluIGhpcyBBRCByZXZpZXcuIElu IHRoZSBlbmNsb3NlZCB2ZXJzaW9uLCB0aGUgcmVmZXJlbmNlIGFzIGJlZW4gYWRkZWQgKGFzIG5v cm1hdGl2ZSkuIA0KDQo+IEl0IHByb3Bvc2VzIGFuIGFkanVuY3QgcHJvY2VkdXJlIHRvIGJlIHBl cmZvcm1lZCBieSB0aGUgaW5ncmVzcyBpbg0KPiBhZGRpdGlvbiB0byBpdHMgY2hlY2tpbmcgb2Yg dGhlIHNldHRpbmcgb2YgdGhlICdOb24tUEhQIGJlaGF2aW9yDQo+IGFja25vd2xlZGdlbWVudCBm bGFnJyBpbiB0aGUgRmxhZ3MgZmllbGQgb2YgdGhlIFJSTy4gIFRoaXMgcHJvY2VkdXJlIGlzDQo+ IHRvIGNoZWNrIHRoZSBSUk8gdG8gc2VlIHdoZXRoZXIgdGhlIGVncmVzcyBhbGxvY2F0ZWQgYSBu b24tbnVsbCBsYWJlbA0KPiBmb3IgdGhlIExTUDsgIGl0IGlzIHVubmVjZXNzYXJ5IGFuZCBJIHdv dWxkIHN1Z2dlc3QgcmVtb3ZpbmcgaXQuDQo+IA0KDQpBcyBjdXJyZW50IFJGQ3MgYWxsb3cgaW5n cmVzcyB0byBsb29rIGF0IHRoZSBsYWJlbCByZWNvcmRpbmcgaW4gUlJPLCB3ZSB0aG91Z2h0IGl0 IHdpbGwgYmUgdXNlZnVsIHRvIGFsbG93IGl0LiBUaGlzIGNvdmVycyB1cyBmb3IgdGhlIGNhc2Ug d2hlcmUgZWdyZXNzIGRvZXMgbm90IGltcGxlbWVudCB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9uIGJ1 dCBiYXNlZCBvbiBzb21lIGxvY2FsIHBvbGljeSBzdGlsbCBhbGxvY2F0ZXMgYSBub24tTnVsbCBs YWJlbC4gV2UgZmVlbCBpdCBpcyB1c2VmdWwgYW5kIGhlbmNlIHdhcyBwYXJ0IG9mIHRoZSB0ZXh0 LiANCg0KQXQgdGhlIHZlcnkgbGVhc3QsIHdlIG5lZWQgdG8gdGFsayBhYm91dCBsYWJlbCByZWNv cmRpbmcgaW4gUlJPIHRvIGJlIGNvbXBsZXRlLiBEaXNhbGxvd2luZyBpbmdyZXNzIG5vdCB0byBp bmZlciBhbnl0aGluZyBmcm9tIGxhYmVsIHJlY29yZGluZyBpcyBhbHNvIG9kZC4gDQoNCkluIHRo ZSBsaWdodCBvZiB0aGUgYWJvdmUsIHdlIHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUgUlJPIGxhYmVs IHJlY29yZGluZyB0ZXh0LiBIb3BlIHlvdSBhcmUgb2sgd2l0aCB0aGF0LiANCg0KVGhhbmtzDQoN ClJlZ2FyZHMuLi4gWmFmYXIgICANCg0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+IA0KDQo= ------_=_NextPart_001_01CC5CFC.88376F51 Content-Type: text/plain; name="draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt Content-Disposition: attachment; filename="draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt" DQoKCgoKCgogICAgDQogICAgDQogICBNUExTIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFouIEFsaSANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBTd2FsbG93IA0KICAg SW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5 c3RlbXMsIEluYy4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUi4gQWdnYXJ3YWwgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtzIA0KICAgSW50 ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZCBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0 IDE3LCAyMDExIA0KICAgRXhwaXJlczogRmVicnVhcnkgMTYsIDIwMTIgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICBOb24gUGVudWx0aW1hdGUgSG9wIFBvcHBpbmcgQmVo YXZpb3IgYW5kIG91dC1vZi1iYW5kIG1hcHBpbmcgZm9yIA0KICAgICAgICAgICAgICAgICAgICAg ICAgIFJTVlAtVEUgTGFiZWwgU3dpdGNoZWQgUGF0aHMgDQogICAgICAgICAgICAgICBkcmFmdC1p ZXRmLW1wbHMtcnN2cC10ZS1uby1waHAtb29iLW1hcHBpbmctMDkudHh0IA0KCg0KCiAgIFN0YXR1 cyBvZiB0aGlzIE1lbW8gDQoKDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQg QkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQogICBEcmFm dHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBGZWJydWFyeSAxNiwgMjAxMi4NCg0KICAg ICAgIA0KICAgQ29weXJpZ2h0IE5vdGljZSANCiAgICAgICANCgogICBDb3B5cmlnaHQgKGMpIDIw MTEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9u IG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cw0KICAgY2Fy ZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0 aCByZXNwZWN0DQogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3Rl ZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mDQogICB0aGUgVHJ1c3QgTGVn YWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNCiAgIGRl c2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4gICAgDQogICAgDQogICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMDEyICAgICAgICAgICAg ICAgW1BhZ2UgMV0gDQogICAgDA0KCgoKCgoKICAgSW50ZXJuZXQtRHJhZnQgICAgIGRyYWZ0LWll dGYtbXBscy1yc3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0wOS50eHQgDQogICAgICAgDQoKICAg VGhpcyBkb2N1bWVudCBtYXkgY29udGFpbiBtYXRlcmlhbCBmcm9tIElFVEYgRG9jdW1lbnRzIG9y IElFVEYNCiAgIENvbnRyaWJ1dGlvbnMgcHVibGlzaGVkIG9yIG1hZGUgcHVibGljbHkgYXZhaWxh YmxlIGJlZm9yZSBOb3ZlbWJlcg0KICAgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNvbnRyb2xs aW5nIHRoZSBjb3B5cmlnaHQgaW4gc29tZSBvZiB0aGlzDQogICBtYXRlcmlhbCBtYXkgbm90IGhh dmUgZ3JhbnRlZCB0aGUgSUVURiBUcnVzdCB0aGUgcmlnaHQgdG8gYWxsb3cNCiAgIG1vZGlmaWNh dGlvbnMgb2Ygc3VjaCBtYXRlcmlhbCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNz Lg0KICAgV2l0aG91dCBvYnRhaW5pbmcgYW4gYWRlcXVhdGUgbGljZW5zZSBmcm9tIHRoZSBwZXJz b24ocykgY29udHJvbGxpbmcNCiAgIHRoZSBjb3B5cmlnaHQgaW4gc3VjaCBtYXRlcmlhbHMsIHRo aXMgZG9jdW1lbnQgbWF5IG5vdCBiZSBtb2RpZmllZA0KICAgb3V0c2lkZSB0aGUgSUVURiBTdGFu ZGFyZHMgUHJvY2VzcywgYW5kIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5DQogICBub3QgYmUg Y3JlYXRlZCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCBleGNlcHQgdG8gZm9y bWF0DQogICBpdCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZDIG9yIHRvIHRyYW5zbGF0ZSBpdCBp bnRvIGxhbmd1YWdlcyBvdGhlcg0KICAgdGhhbiBFbmdsaXNoLiANCgogICAgICAgDQogICBBYnN0 cmFjdCANCgogICAgICBUaGVyZSBhcmUgbWFueSBkZXBsb3ltZW50IHNjZW5hcmlvcyB3aGljaCBy ZXF1aXJlIEVncmVzcyBMYWJlbCANCiAgICAgIFN3aXRjaGluZyBSb3V0ZXIgKExTUikgdG8gcmVj ZWl2ZSBiaW5kaW5nIG9mIHRoZSBSZXNvdXJjZSANCiAgICAgIFJlc2VyVmF0aW9uIFByb3RvY29s IFRyYWZmaWMgRW5naW5lZXJlZCAoUlNWUC1URSkgTGFiZWwgU3dpdGNoZWQgDQogICAgICBQYXRo IChMU1ApIHRvIGFuIGFwcGxpY2F0aW9uLCBhbmQgcGF5bG9hZCBpZGVudGlmaWNhdGlvbiwgdXNp bmcgDQogICAgICBzb21lICJvdXQtb2YtYmFuZCIgKE9PQikgbWVjaGFuaXNtLiBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgDQogICAgICBwcm90b2NvbCBtZWNoYW5pc21zIHRvIGFkZHJlc3MgdGhpcyBy ZXF1aXJlbWVudC4gVGhlIHByb2NlZHVyZXMgDQogICAgICBkZXNjcmliZWQgaW4gdGhpcyBkb2N1 bWVudCBhcmUgZXF1YWxseSBhcHBsaWNhYmxlIGZvciBwb2ludC10by0NCiAgICAgIHBvaW50IChQ MlApIGFuZCBwb2ludC10by1tdWx0aXBvaW50IChQMk1QKSBMU1BzLiANCiAgICAgICANCiAgIENv bnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCANCgogICAgICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIA0KICAgICAgTk9U IiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCANCiAg ICAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMg ZGVzY3JpYmVkIGluIA0KICAgICAgUkZDIDIxMTkgW1JGQzIxMTldLiANCgogICBUYWJsZSBvZiBD b250ZW50cyANCgogICAgICAgDQogICAgICBDb3B5cmlnaHQgTm90aWNlIC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xIA0KICAgICAgMS4gSW50cm9kdWN0aW9u IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgICAg IDIuIFJTVlAtVEUgc2lnbmFsaW5nIGV4dGVuc2lvbnMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjQgDQogICAgICAgICAyLjEuIFNpZ25hbGluZyBub24tUEhQIGJlaGF2aW9yIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAgICAgICAgMi4yLiBTaWduYWxpbmcgT09CIE1h cHBpbmcgSW5kaWNhdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgICAgICAgIDIuMy4g UmVsYXRpb25zaGlwIGJldHdlZW4gT09CIGFuZCBub24tUEhQIGZsYWdzIC4uLi4uLi4uLi4uLjcg DQogICAgICAgICAyLjQuIEVncmVzcyBQcm9jZWR1cmUgZm9yIGxhYmVsIGJpbmRpbmcgLi4uLi4u Li4uLi4uLi4uLi4uLi43IA0KICAgICAgMy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgICAgIDQuIElBTkEgQ29uc2lkZXJh dGlvbnMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAg ICA0LjEuIEF0dHJpYnV0ZSBGbGFncyBmb3IgTFNQX0FUVFJJQlVURVMgb2JqZWN0IC4uLi4uLi4u Li4uLi44IA0KICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMDEyICAgICAgICAg ICAgICAgICAgW1BhZ2UgMl0gDQogICAgICAgDA0KCgoKCgoKICAgSW50ZXJuZXQtRHJhZnQgICAg IGRyYWZ0LWlldGYtbXBscy1yc3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0wOS50eHQgDQogICAg ICAgDQoKICAgICAgICAgNC4yLiBOZXcgUlNWUCBlcnJvciBzdWItY29kZSAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uOSANCiAgICAgIDUuIEFja25vd2xlZGdtZW50cyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkgDQogICAgICA2LiBSZWZlcmVuY2Vz IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAg ICAgICAgNi4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uOSANCiAgICAgICAgIDYuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTAgDQogICAgICAgDQogICAxLiBJbnRyb2R1Y3Rpb24g DQoKICAgICAgV2hlbiBSZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbCBUcmFmZmljIEVuZ2lu ZWVyZWQgKFJTVlAtVEUpIA0KICAgICAgaXMgdXNlZCBmb3IgYXBwbGljYXRpb25zIGxpa2UgTXVs dGljYXN0IFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIA0KICAgICAgKE1WUE4pIFtNVlBOXSBhbmQg VmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNlIChWUExTKSBbUkZDNDc2MV0sIA0KICAgICAgYW4g RWdyZXNzIExhYmVsIFN3aXRjaGluZyBSb3V0ZXIgKExTUikgcmVjZWl2ZXMgdGhlIGJpbmRpbmcg b2YgDQogICAgICB0aGUgUlNWUC1URSBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIHRvIGFuIGFw cGxpY2F0aW9uLCBhbmQgDQogICAgICBwYXlsb2FkIGlkZW50aWZpY2F0aW9uLCB1c2luZyBhbiAi b3V0LW9mLWJhbmQiIChPT0IpIG1lY2hhbmlzbSANCiAgICAgIChlLmcuLCB1c2luZyBCb3JkZXIg R2F0ZXdheSBQcm90b2NvbCAoQkdQKSkuIEluIHN1Y2ggY2FzZXMsIHRoZSANCiAgICAgIEVncmVz cyBMU1IgY2Fubm90IG1ha2UgY29ycmVjdCBmb3J3YXJkaW5nIGRlY2lzaW9uIHVudGlsIHN1Y2gg T09CIA0KICAgICAgbWFwcGluZyBpbmZvcm1hdGlvbiBpcyByZWNlaXZlZC4gRnVydGhlcm1vcmUs IGluIG9yZGVyIHRvIGFwcGx5IA0KICAgICAgdGhlIGJpbmRpbmcgaW5mb3JtYXRpb24sIHRoZSBF Z3Jlc3MgTFNSIG5lZWRzIHRvIGlkZW50aWZ5IHRoZSANCiAgICAgIGluY29taW5nIExTUCBvbiB3 aGljaCB0cmFmZmljIGlzIGNvbWluZy4gVGhlcmVmb3JlLCBub24gDQogICAgICBQZW51bHRpbWF0 ZSBIb3AgUG9wcGluZyAobm9uLVBIUCkgYmVoYXZpb3IgaXMgcmVxdWlyZWQgdG8gYXBwbHkgDQog ICAgICBPT0IgbWFwcGluZy4gIA0KICAgIA0KICAgICAgVGhlcmUgYXJlIG90aGVyIGFwcGxpY2F0 aW9ucyB0aGF0IHJlcXVpcmUgbm9uLVBIUCBiZWhhdmlvci4gV2hlbiANCiAgICAgIFJTVlAtVEUg UDJNUCBMU1BzIGFyZSB1c2VkIHRvIGNhcnJ5IElQIG11bHRpY2FzdCB0cmFmZmljIG5vbi1QSFAg DQogICAgICBiZWhhdmlvciBlbmFibGVzIGEgbGVhZiBMU1IgdG8gaWRlbnRpZnkgdGhlIFAyTVAg VEUgTFNQLCBvbiB3aGljaCANCiAgICAgIHRyYWZmaWMgaXMgcmVjZWl2ZWQuIEhlbmNlIHRoZSBl Z3Jlc3MgTFNSIGNhbiBkZXRlcm1pbmUgd2hldGhlciANCiAgICAgIHRyYWZmaWMgaXMgcmVjZWl2 ZWQgb24gdGhlIGV4cGVjdGVkIFAyTVAgTFNQIGFuZCBkaXNjYXJkIHRyYWZmaWMgDQogICAgICB0 aGF0IGlzIG5vdCByZWNlaXZlZCBvbiB0aGUgZXhwZWN0ZWQgUDJNUCBMU1AuIE5vbi1QSFAgYmVo YXZpb3IgDQogICAgICBpcyBhbHNvIHJlcXVpcmVkIHRvIGRldGVybWluZSB0aGUgY29udGV4dCBv ZiB1cHN0cmVhbSBhc3NpZ25lZCANCiAgICAgIGxhYmVscyB3aGVuIHRoZSBjb250ZXh0IGlzIGEg TVBMUyBMU1AuIE5vbi1QSFAgYmVoYXZpb3IgbWF5IGFsc28gDQogICAgICBiZSByZXF1aXJlZCBm b3IgTVBMUy1UUCBMU1BzIFtSRkM1OTIxXS4gDQogICAgICAgDQogICAgICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgdHdvIG5ldyBmbGFncyBpbiB0aGUgQXR0cmlidXRlcyBGbGFncyBUTFYgDQogICAg ICBvZiB0aGUgTFNQX0FUVFJJQlVURVMgb2JqZWN0IGRlZmluZWQgaW4gW1JGQzU0MjBdOiBvbmUg ZmxhZyBmb3IgDQogICAgICBjb21tdW5pY2F0aW9uIG9mIG5vbi1QSFAgYmVoYXZpb3IsIGFuZCBv bmUgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IA0KICAgICAgdGhlIGJpbmRpbmcgb2YgdGhlIExTUCB0 byBhbiBhcHBsaWNhdGlvbiBhbmQgcGF5bG9hZCBpZGVudGlmaWVyIA0KICAgICAgKHBheWxvYWQt SWQpIG5lZWRzIHRvIGJlIGxlYXJuZWQgdmlhIGFuIG91dC1vZi1iYW5kIG1hcHBpbmcgDQogICAg ICBtZWNoYW5pc20uIEFzIHRoZXJlIGlzIG9uZS10by1vbmUgY29ycmVzcG9uZGVuY2UgYmV0d2Vl biBiaXRzIGluIA0KICAgICAgdGhlIEF0dHJpYnV0ZSBGbGFncyBUTFYgYW5kIHRoZSBSUk8gQXR0 cmlidXRlcyBzdWJvYmplY3QsIA0KICAgICAgY29ycmVzcG9uZGluZyBmbGFncyB0byBiZSBjYXJy aWVkIGluIFJSTyBBdHRyaWJ1dGVzIHN1Ym9iamVjdCBhcmUgDQogICAgICBhbHNvIGRlZmluZWQu ICANCiAgICAgICANCiAgICAgIFRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3Vt ZW50IGFyZSBlcXVhbGx5IGFwcGxpY2FibGUgDQogICAgICBmb3IgUDJQIGFuZCBQMk1QIExTUHMu IFNwZWNpZmljYXRpb24gb2YgdGhlIE9PQiBjb21tdW5pY2F0aW9uIA0KICAgICAgbWVjaGFuaXNt KHMpIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIA0KCgogICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMTIgICAgICAgICAgICAgICAgICBbUGFnZSAzXSAN CiAgICAgICAMDQoKCgoKCgogICBJbnRlcm5ldC1EcmFmdCAgICAgZHJhZnQtaWV0Zi1tcGxzLXJz dnAtdGUtbm8tcGhwLW9vYi1tYXBwaW5nLTA5LnR4dCANCiAgICAgICANCgogICAyLiBSU1ZQLVRF IHNpZ25hbGluZyBleHRlbnNpb25zIA0KCiAgICAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhl IHNpZ25hbGluZyBleHRlbnNpb25zIHJlcXVpcmVkIHRvIA0KICAgICAgYWRkcmVzcyB0aGUgYWJv dmUtbWVudGlvbmVkIHJlcXVpcmVtZW50cy4gIA0KCiAgIDIuMS4gU2lnbmFsaW5nIG5vbi1QSFAg YmVoYXZpb3IgDQoKICAgICAgSW4gb3JkZXIgdG8gcmVxdWVzdCBub24tUEhQIGJlaGF2aW9yIGZv ciBhbiBSU1ZQLVRFIExTUCwgdGhpcyANCiAgICAgIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgZmxh ZyBpbiB0aGUgQXR0cmlidXRlcyBGbGFncyBUTFYgb2YgdGhlIA0KICAgICAgTFNQX0FUVFJJQlVU RVMgb2JqZWN0IGRlZmluZWQgaW4gW1JGQzU0MjBdOiANCiAgICAgICANCgogICAgICBCaXQgTnVt YmVyICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKTogbm9uLVBIUCBiZWhhdmlvciByZXF1ZXN0ZWQg DQogICAgICBmbGFnLiAgDQoKICAgICAgSW4gb3JkZXIgdG8gaW5kaWNhdGUgdG8gdGhlIEluZ3Jl c3MgTFNSIHRoYXQgdGhlIEVncmVzcyBMU1IgDQogICAgICByZWNvZ25pemVzIHRoZSAibm9uLVBI UCBiZWhhdmlvciByZXF1ZXN0ZWQgZmxhZyIsIHRoZSBmb2xsb3dpbmcgDQogICAgICBuZXcgYml0 IGlzIGRlZmluZWQgaW4gdGhlIEZsYWdzIGZpZWxkIG9mIHRoZSBSZWNvcmQgUm91dGUgb2JqZWN0 IA0KICAgICAgKFJSTykgQXR0cmlidXRlcyBzdWJvYmplY3Q6ICANCiAgICAgICANCiAgICAgIEJp dCBOdW1iZXIgKHNhbWUgYXMgYml0IG51bWJlciBhc3NpZ25lZCBmb3Igbm9uLVBIUCBiZWhhdmlv ciANCiAgICAgIHJlcXVlc3RlZCBmbGFnKTogTm9uLVBIUCBiZWhhdmlvciBhY2tub3dsZWRnZW1l bnQgZmxhZy4gDQoKICAgICAgQW4gSW5ncmVzcyBMU1Igc2V0cyB0aGUgIm5vbi1QSFAgYmVoYXZp b3IgcmVxdWVzdGVkIGZsYWciIHRvIA0KICAgICAgc2lnbmFsIHRoZSBlZ3Jlc3MgTFNScyBTSE9V TEQgYXNzaWduIG5vbi1OVUxMIGxhYmVsIGZvciB0aGUgTFNQIA0KICAgICAgYmVpbmcgc2lnbmFs ZWQuICBUaGlzIGZsYWcgTVVTVCBOT1QgYmUgbW9kaWZpZWQgYnkgYW55IG90aGVyIExTUnMgDQog ICAgICBpbiB0aGUgbmV0d29yay4gTFNScyBvdGhlciB0aGFuIHRoZSBFZ3Jlc3MgTFNScyBTSE9V TEQgaWdub3JlIA0KICAgICAgdGhpcyBmbGFnLiAgDQogICAgICAgDQogICAgICBJZiBhbiBlZ3Jl c3MgTFNSIHJlY2VpdmluZyB0aGUgUGF0aCBtZXNzYWdlLCBzdXBwb3J0cyB0aGUgDQogICAgICBM U1BfQVRUUklCVVRFUyBvYmplY3QgYW5kIHRoZSBBdHRyaWJ1dGVzIEZsYWdzIFRMViwgYW5kIGFs c28gDQogICAgICByZWNvZ25pemVzIHRoZSAibm9uLVBIUCBiZWhhdmlvciByZXF1ZXN0ZWQgZmxh ZyIsIGl0IE1VU1QgDQogICAgICBhbGxvY2F0ZSBhIG5vbi1OVUxMIGxvY2FsIGxhYmVsLiBUaGUg ZWdyZXNzIExTUiBNVVNUIGFsc28gc2V0IHRoZSANCiAgICAgICJOb24tUEhQIGJlaGF2aW9yIGFj a25vd2xlZGdlbWVudCBmbGFnIiBpbiB0aGUgRmxhZ3MgZmllbGQgb2YgdGhlIA0KICAgICAgUlJP IEF0dHJpYnV0ZSBzdWJvYmplY3QuICANCiAgICAgICANCiAgICAgIElmIHRoZSBlZ3Jlc3MgTFNS ICANCgogICAgICAtIHN1cHBvcnRzIHRoZSBMU1BfQVRUUklCVVRFUyBvYmplY3QgYnV0IGRvZXMg bm90IHJlY29nbml6ZSB0aGUgDQogICAgICAgICBBdHRyaWJ1dGVzIEZsYWdzIFRMVjsgb3IgIA0K CiAgICAgIC0gc3VwcG9ydHMgdGhlIExTUF9BVFRSSUJVVEVTIG9iamVjdCBhbmQgcmVjb2duaXpl IHRoZSBBdHRyaWJ1dGVzIA0KICAgICAgICAgRmxhZ3MgVExWLCBidXQgZG9lcyBub3QgcmVjb2du aXplICJub24tUEhQIGJlaGF2aW9yIHJlcXVlc3RlZCANCiAgICAgICAgIGZsYWciOyAgDQoKCgog ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMTIgICAgICAgICAgICAgICAgICBb UGFnZSA0XSANCiAgICAgICAMDQoKCgoKCgogICBJbnRlcm5ldC1EcmFmdCAgICAgZHJhZnQtaWV0 Zi1tcGxzLXJzdnAtdGUtbm8tcGhwLW9vYi1tYXBwaW5nLTA5LnR4dCANCiAgICAgICANCgogICAg ICB0aGVuIGl0IHNpbGVudGx5IGlnbm9yZXMgdGhpcyByZXF1ZXN0IGFjY29yZGluZyB0byB0aGUg cHJvY2Vzc2luZyANCiAgICAgIHJ1bGVzIG9mIFtSRkM1NDIwXS4gIA0KICAgICAgICAgIA0KCiAg ICAgIEFuIGluZ3Jlc3MgTFNSIHJlcXVlc3Rpbmcgbm9uLVBIUCBiZWhhdmlvciBTSE9VTEQgZXhh bWluZSAiTm9uLQ0KICAgICAgUEhQIGJlaGF2aW9yIGFja25vd2xlZGdlbWVudCBmbGFnIiBpbiB0 aGUgRmxhZ3MgZmllbGQgb2YgdGhlIFJSTyANCiAgICAgIEF0dHJpYnV0ZSBzdWJvYmplY3QgYW5k IE1BWSBzZW5kIGEgUGF0aCBUZWFyIHRvIHRoZSBFZ3Jlc3Mgd2hpY2ggDQogICAgICBoYXMgbm90 IHNldCB0aGUgIk5vbi1QSFAgYmVoYXZpb3IgYWNrbm93bGVkZ2VtZW50IGZsYWciLiBBbiANCiAg ICAgIGluZ3Jlc3MgTFNSIHJlcXVlc3Rpbmcgbm9uLVBIUCBiZWhhdmlvciBNQVkgYWxzbyBleGFt aW5lIHRoZSANCiAgICAgIGxhYmVsIHZhbHVlIGNvcnJlc3BvbmRpbmcgdG8gdGhlIEVncmVzcyBM U1IocykgaW4gdGhlIFJSTywgYW5kIA0KICAgICAgTUFZIHNlbmQgYSBQYXRoIFRlYXIgdG8gdGhl IEVncmVzcyB3aGljaCBhc3NpZ25zIGEgTnVsbCBsYWJlbCANCiAgICAgIHZhbHVlLiAgDQoKICAg ICAgV2hlbiBzaWduYWxpbmcgYSBQMk1QIExTUCwgYSBzb3VyY2Ugbm9kZSBtYXkgd2lzaCB0byBz b2xpY2l0IA0KICAgICAgaW5kaXZpZHVhbCByZXNwb25zZSB0byAibm9uLVBIUCBiZWhhdmlvciBy ZXF1ZXN0ZWQgZmxhZyIgZnJvbSB0aGUgDQogICAgICBsZWFmIG5vZGVzLiBHaXZlbiB0aGUgY29u c3RyYWludHMgb24gaG93IHRoZSBMU1BfQVRUUklCVVRFUyBtYXkgDQogICAgICBiZSBjYXJyaWVk IGluIFBhdGggYW5kIFJlc3YgTWVzc2FnZXMgYWNjb3JkaW5nIHRvIFJGQzU0MjAsIGluIA0KICAg ICAgdGhpcyBzaXR1YXRpb24gYSBzb3VyY2Ugbm9kZSBNVVNUIHVzZSBhIHNlcGFyYXRlIFBhdGgg bWVzc2FnZSBmb3IgDQogICAgICBlYWNoIGxlYWYgaW4gbmV0d29ya3Mgd2hlcmUgW0FUVFJJQlVU RS1CTkZdIGlzIG5vdCBzdXBwb3J0ZWQuICBJbiANCiAgICAgIG5ldHdvcmtzIHdpdGggW0FUVFJJ QlVURS1CTkZdIGRlcGxveWVkIGVpdGhlciBzZXBhcmF0ZSBQYXRoIA0KICAgICAgbWVzc2FnZSBm b3IgZWFjaCBsZWFmIG9yIG11bHRpcGxlIGxlYWZzIHBlciBQYXRoIG1lc3NhZ2UgTUFZIGJlIA0K ICAgICAgdXNlZCBieSBhIHNvdXJjZSBub2RlLiANCiAgICAgICANCiAgICAgICANCiAgIDIuMi4g U2lnbmFsaW5nIE9PQiBNYXBwaW5nIEluZGljYXRpb24gDQoKICAgICAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGEgc2luZ2xlIGZsYWcgdG8gaW5kaWNhdGUgdGhhdCB0aGUgbm9ybWFsIA0KICAgICAg YmluZGluZyBtZWNoYW5pc20gb2YgYW4gUlNWUCBzZXNzaW9uIGlzIG92ZXJyaWRkZW4uICBUaGUg YWN0dWFsIA0KICAgICAgb3V0LW9mLWJhbmQgbWFwcGluZ3MgYXJlIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4gIFRoZSAgICAgIA0KICAgICAgZmxhZyBpcyBjYXJyaWVkIGluIHRo ZSBBdHRyaWJ1dGVzIEZsYWdzIFRMViBvZiB0aGUgTFNQX0FUVFJJQlVURVMgDQogICAgICBvYmpl Y3QgZGVmaW5lZCBpbiBbUkZDNTQyMF0gYW5kIGlzIGRlZmluZWQgYXMgZm9sbG93czogIA0KICAg ICAgIA0KCiAgICAgIEJpdCBOdW1iZXIgKHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEpOiBPT0IgbWFw cGluZyBpbmRpY2F0aW9uIGZsYWcuICANCgogICAgICBJbiBvcmRlciB0byBpbmRpY2F0ZSB0byB0 aGUgSW5ncmVzcyBMU1IgdGhhdCB0aGUgRWdyZXNzIExTUiANCiAgICAgIHJlY29nbml6ZXMgdGhl ICJPT0IgbWFwcGluZyBpbmRpY2F0aW9uIGZsYWciLCB0aGUgZm9sbG93aW5nIG5ldyANCiAgICAg IGJpdCBpcyBkZWZpbmVkIGluIHRoZSBGbGFncyBmaWVsZCBvZiB0aGUgUmVjb3JkIFJvdXRlIG9i amVjdCANCiAgICAgIChSUk8pIEF0dHJpYnV0ZXMgc3Vib2JqZWN0OiAgDQogICAgICAgDQogICAg ICBCaXQgTnVtYmVyIChzYW1lIGFzIGJpdCBudW1iZXIgYXNzaWduZWQgZm9yIE9PQiBtYXBwaW5n IA0KICAgICAgaW5kaWNhdGlvbiBmbGFnKTogT09CIG1hcHBpbmcgYWNrbm93bGVkZ2VtZW50IGZs YWcuICANCgogICAgICAgDQoKICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMDEy ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQogICAgICAgDA0KCgoKCgoKICAgSW50ZXJuZXQt RHJhZnQgICAgIGRyYWZ0LWlldGYtbXBscy1yc3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0wOS50 eHQgDQogICAgICAgDQoKICAgICAgQW4gSW5ncmVzcyBMU1Igc2V0cyB0aGUgT09CIG1hcHBpbmcg aW5kaWNhdGlvbiBmbGFnIHRvIHNpZ25hbCB0aGUgDQogICAgICBFZ3Jlc3MgTFNSIHRoYXQgYmlu ZGluZyBvZiBSU1ZQLVRFIExTUCB0byBhbiBhcHBsaWNhdGlvbiBhbmQgDQogICAgICBwYXlsb2Fk IGlkZW50aWZpY2F0aW9uIGlzIGJlaW5nIHNpZ25hbGVkIG91dC1vZi1iYW5kLiBUaGlzIGZsYWcg DQogICAgICBNVVNUIE5PVCBiZSBtb2RpZmllZCBieSBhbnkgb3RoZXIgTFNScyBpbiB0aGUgbmV0 d29yay4gTFNScyBvdGhlciANCiAgICAgIHRoYW4gdGhlIEVncmVzcyBMU1JzIFNIT1VMRCBpZ25v cmUgdGhpcyBmbGFnLiAgDQogICAgICAgDQogICAgICBXaGVuIGFuIEVncmVzcyBMU1Igd2hpY2gg c3VwcG9ydHMgdGhlICJPT0IgbWFwcGluZyBpbmRpY2F0aW9uIA0KICAgICAgZmxhZyIsIHJlY2Vp dmVzIGEgUGF0aCBtZXNzYWdlIHdpdGggdGhhdCBmbGFnIHNldCwgdGhlIEVncmVzcyBMU1IgDQog ICAgICBNVVNUIHNldCB0aGUgIk9PQiBtYXBwaW5nIGFja25vd2xlZGdlbWVudCBmbGFnIiBpbiB0 aGUgRmxhZ3MgDQogICAgICBmaWVsZCBvZiB0aGUgUlJPIEF0dHJpYnV0ZSBzdWJvYmplY3QuIFRo ZSByZXN0IG9mIHRoZSBSU1ZQIA0KICAgICAgc2lnbmFsaW5nIHByb2NlZWRzIGFzIG5vcm1hbC4g IEhvd2V2ZXIsIHRoZSBMU1IgTVVTVCBoYXZlIA0KICAgICAgcmVjZWl2ZWQgdGhlIE9PQiBtYXBw aW5nIGJlZm9yZSBhY2NlcHRpbmcgdHJhZmZpYyBvbiB0aGUgTFNQLiAgDQogICAgICBUaGlzIGlt cGxpZXMgdGhhdCB0aGUgRWdyZXNzIExTUiBNVVNUIE5PVCBzZXR1cCBmb3J3YXJkaW5nIHN0YXRl IA0KICAgICAgZm9yIHRoZSBMU1AgYmVmb3JlIGl0IHJlY2VpdmVzIHRoZSBPT0IgbWFwcGluZy4g IA0KICAgICAgIA0KICAgICAgTm90ZSB0aGF0IHRoZSBwYXlsb2FkIGluZm9ybWF0aW9uIFNIT1VM RCBiZSBzdXBwbGllZCBieSB0aGUgT09CIA0KICAgICAgbWFwcGluZy4gSWYgdGhlIGVncmVzcyBM U1IgcmVjZWl2ZXMgdGhlIHBheWxvYWQgaW5mb3JtYXRpb24gZnJvbSANCiAgICAgIE9PQiBtYXBw aW5nIHRoZW4gdGhlIExTUiBNVVNUIGlnbm9yZSBMM1BJRCBpbiB0aGUgTGFiZWwgUmVxdWVzdCAN CiAgICAgIE9iamVjdCBbUkZDMzIwOV0uIA0KICAgIA0KICAgIA0KICAgICAgSWYgdGhlIGVncmVz cyBMU1IgIA0KCiAgICAgIC0gc3VwcG9ydHMgdGhlIExTUF9BVFRSSUJVVEVTIG9iamVjdCBidXQg ZG9lcyBub3QgcmVjb2duaXplIHRoZSANCiAgICAgICAgIEF0dHJpYnV0ZXMgRmxhZ3MgVExWOyBv ciAgDQoKICAgICAgLSBzdXBwb3J0cyB0aGUgTFNQX0FUVFJJQlVURVMgb2JqZWN0IGFuZCByZWNv Z25pemVzIHRoZSANCiAgICAgICAgIEF0dHJpYnV0ZXMgRmxhZ3MgVExWLCBidXQgZG9lcyBub3Qg cmVjb2duaXplIHRoZSAiT09CIG1hcHBpbmcgDQogICAgICAgICBpbmRpY2F0aW9uIGZsYWciOyAN CgogICAgICB0aGVuIGl0IHNpbGVudGx5IGlnbm9yZXMgdGhpcyByZXF1ZXN0IGFjY29yZGluZyB0 byB0aGUgcHJvY2Vzc2luZyANCiAgICAgIHJ1bGVzIG9mIFtSRkM1NDIwXS4gIA0KICAgICAgIA0K CiAgICAgIEFuIGluZ3Jlc3MgTFNSIHJlcXVlc3RpbmcgT09CIG1hcHBpbmcgU0hPVUxEIGV4YW1p bmUgIk9PQiBtYXBwaW5nIA0KICAgICAgYWNrbm93bGVkZ2VtZW50IGZsYWciIGluIHRoZSBGbGFn cyBmaWVsZCBvZiB0aGUgUlJPIEF0dHJpYnV0ZSANCiAgICAgIHN1Ym9iamVjdCBhbmQgTUFZIHNl bmQgYSBQYXRoIFRlYXIgdG8gdGhlIEVncmVzcyB3aGljaCBoYXMgbm90IA0KICAgICAgc2V0IHRo ZSAiT09CIG1hcHBpbmcgYWNrbm93bGVkZ2VtZW50IGZsYWciLiAgDQoKICAgICAgV2hlbiBzaWdu YWxpbmcgYSBQMk1QIExTUCwgYSBzb3VyY2Ugbm9kZSBtYXkgd2lzaCB0byBzb2xpY2l0IA0KICAg ICAgaW5kaXZpZHVhbCByZXNwb25zZSB0byAiT09CIG1hcHBpbmcgaW5kaWNhdGlvbiBmbGFnIiBm cm9tIHRoZSANCiAgICAgIGxlYWYgbm9kZXMuIEdpdmVuIHRoZSBjb25zdHJhaW50cyBvbiBob3cg dGhlIExTUF9BVFRSSUJVVEVTIG1heSANCiAgICAgIGJlIGNhcnJpZWQgaW4gUGF0aCBhbmQgUmVz diBNZXNzYWdlcyBhY2NvcmRpbmcgdG8gUkZDNTQyMCwgaW4gDQogICAgICB0aGlzIHNpdHVhdGlv biBhIHNvdXJjZSBub2RlIE1VU1QgdXNlIGEgc2VwYXJhdGUgUGF0aCBtZXNzYWdlIGZvciANCiAg ICAgIGVhY2ggbGVhZiBpbiBuZXR3b3JrcyB3aGVyZSBbQVRUUklCVVRFLUJORl0gaXMgbm90IHN1 cHBvcnRlZC4gIEluIA0KICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMDEyICAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQogICAgICAgDA0KCgoKCgoKICAgSW50ZXJuZXQtRHJh ZnQgICAgIGRyYWZ0LWlldGYtbXBscy1yc3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0wOS50eHQg DQogICAgICAgDQoKICAgICAgbmV0d29ya3Mgd2l0aCBbQVRUUklCVVRFLUJORl0gZGVwbG95ZWQg ZWl0aGVyIHNlcGFyYXRlIFBhdGggDQogICAgICBtZXNzYWdlIGZvciBlYWNoIGxlYWYgb3IgbXVs dGlwbGUgbGVhZnMgcGVyIFBhdGggbWVzc2FnZSBNQVkgYmUgDQogICAgICB1c2VkIGJ5IGEgc291 cmNlIG5vZGUuIA0KICAgICAgIA0KICAgICAgSW4gZGVwbG95aW5nIGFwcGxpY2F0aW9ucyB3aGVy ZSBFZ3Jlc3MgTFNSIHJlY2VpdmVzIHRoZSBiaW5kaW5nIA0KICAgICAgb2YgdGhlIFJTVlAtVEUg TFNQIHRvIGFuIGFwcGxpY2F0aW9uLCBhbmQgcGF5bG9hZCBpZGVudGlmaWNhdGlvbiwgDQogICAg ICB1c2luZyBPT0IgbWVjaGFuaXNtLCBpdCBpcyBpbXBvcnRhbnQgdG8gcmVjb2duaXplIHRoYXQg T09CIA0KICAgICAgbWFwcGluZyBpcyBzZW50IGFzeW5jaHJvbm91c2x5IHcuci50LiBzaWduYWxp bmcgb2YgUlNWUC1URSBMU1AuICANCiAgICAgIEVncmVzcyBMU1Igb25seSBpbnN0YWxscyBmb3J3 YXJkaW5nIHN0YXRlIGZvciB0aGUgTFNQIGFmdGVyIGl0IA0KICAgICAgcmVjZWl2ZXMgdGhlIE9P QiBtYXBwaW5nLiBJbiBkZXBsb3lpbmcgYXBwbGljYXRpb25zIHVzaW5nIE9PQiANCiAgICAgIG1l Y2hhbmlzbSwgSW5ncmVzcyBMU1IgbWF5IG5lZWQgdG8ga25vdyB3aGVuIEVncmVzcyBpcyBwcm9w ZXJseSANCiAgICAgIHNldHVwIGZvciBmb3J3YXJkaW5nIChpLmUuLCBoYXMgcmVjZWl2ZWQgT09C IG1hcHBpbmcpLiBIb3cgDQogICAgICBJbmdyZXNzIExTUiBkZXRlcm1pbmVzIHRoYXQgTFNSIGlz IHByb3Blcmx5IHNldHVwIGZvciBmb3J3YXJkaW5nIA0KICAgICAgYXQgdGhlIEVncmVzcyBMU1Ig aXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiANCiAgICAgIE5vbmV0aGVsZXNz LCBpZiBPT0IgbWFwcGluZyBpcyBub3QgcmVjZWl2ZWQgYnkgdGhlIEVncmVzcyBMU1IgDQogICAg ICB3aXRoaW4gYSByZWFzb25hYmxlIHRpbWUsIGEgcHJvY2VkdXJlIGRlZmluZWQgaW4gc2VjdGlv biAyLjQgdG8gDQogICAgICB0ZWFyIGRvd24gdGhlIExTUCBpcyBmb2xsb3dlZC4gICANCiAgICAg ICANCgogICAyLjMuIFJlbGF0aW9uc2hpcCBiZXR3ZWVuIE9PQiBhbmQgbm9uLVBIUCBmbGFncyAN CgogICAgICAiTm9uLVBIUCBiZWhhdmlvciBkZXNpcmVkIiBhbmQgIk9PQiBtYXBwaW5nIGluZGlj YXRpb24iIGZsYWdzIGNhbiANCiAgICAgIGFwcGVhciBhbmQgYmUgcHJvY2Vzc2VkIGluZGVwZW5k ZW50bHkgb2YgZWFjaCBvdGhlci4gSG93ZXZlciwgYXMgDQogICAgICBtZW50aW9uZWQgZWFybGll ciwgaW4gdGhlIGNvbnRleHQgb2YgYXBwbGljYXRpb25zIGRpc2N1c3NlZCBpbiANCiAgICAgIHRo aXMgZG9jdW1lbnQsIE9PQiBtYXBwaW5nIHJlcXVpcmVzIG5vbi1QSFAgYmVoYXZpb3IuIEFuIElu Z3Jlc3MgDQogICAgICBMU1IgcmVxdWVzdGluZyBPT0IgbWFwcGluZyBNQVkgYWxzbyBzZXQgIm5v bi1QSFAgYmVoYXZpb3IgDQogICAgICByZXF1ZXN0ZWQgZmxhZyIgaW4gdGhlIExTUF9BVFRSSUJV VEVTIG9iamVjdCBpbiB0aGUgUGF0aCBtZXNzYWdlLiAgDQoKICAgMi40LiBFZ3Jlc3MgUHJvY2Vk dXJlIGZvciBsYWJlbCBiaW5kaW5nIA0KCiAgICAgIFJTVlAtVEUgc2lnbmFsaW5nIGNvbXBsZXRp b24gYW5kIHRoZSBPT0IgbWFwcGluZyBpbmZvcm1hdGlvbiANCiAgICAgIHJlY2VwdGlvbiBoYXBw ZW4gYXN5bmNocm9ub3VzbHkgYXQgdGhlIEVncmVzcy4gQXMgbWVudGlvbmVkIGluIA0KICAgICAg U2VjdGlvbiAyLjIsIEVncmVzcyB3YWl0cyBmb3IgdGhlIE9PQiBtYXBwaW5nIGJlZm9yZSBhY2Nl cHRpbmcgDQogICAgICB0cmFmZmljIG9uIHRoZSBMU1AuIE5vbmV0aGVsZXNzLCBNUExTIE9BTSBt ZWNoYW5pc21zLCBlLmcuLCBMU1AgDQogICAgICBQaW5nIGFuZCBUcmFjZSByb3V0ZSBhcyBkZWZp bmVkIGluIFtSRkM0Mzc5XSwgW1AyTVAtT0FNXSwgYXJlIA0KICAgICAgZXhwZWN0ZWQgdG8gd29y ayBpbmRlcGVuZGVudCBvZiBPT0IgbWFwcGluZyBsZWFybmluZyBwcm9jZXNzLiAgDQogICAgICAg IA0KICAgICAgSW4gb3JkZXIgdG8gYXZvaWQgdW5uZWNlc3NhcnkgdXNlIG9mIHRoZSByZXNvdXJj ZXMgYW5kIHBvc3NpYmxlIA0KICAgICAgYmxhY2staG9saW5nIG9mIHRyYWZmaWMsIGFuIEVncmVz cyBMU1IgTUFZIHNlbmQgYSBQYXRoIEVycm9yIA0KICAgICAgbWVzc2FnZSBpZiB0aGUgT09CIG1h cHBpbmcgaW5mb3JtYXRpb24gaXMgbm90IHJlY2VpdmVkIHdpdGhpbiBhIA0KICAgICAgcmVhc29u YWJsZSB0aW1lLiBUaGlzIFBhdGggRXJyb3IgbWVzc2FnZSB3aWxsIGluY2x1ZGUgdGhlIGVycm9y IA0KICAgICAgY29kZS9zdWItY29kZSAiTm90aWZ5IEVycm9yLyBubyBPT0IgbWFwcGluZyByZWNl aXZlZCIgZm9yIGFsbCANCiAgICAgIGFmZmVjdGVkIExTUHMuIElmIG5vdGlmeSByZXF1ZXN0IHdh cyBpbmNsdWRlZCB3aGVuIHRoZSBMU1Agd2FzIA0KICAgICAgaW5pdGlhbGx5IHNldHVwLCBOb3Rp ZnkgbWVzc2FnZSAoYXMgZGVmaW5lZCBpbiBbUkZDMzQ3M10pIE1BWSANCiAgICAgIGFsc28gYmUg dXNlZCBmb3IgZGVsaXZlcnkgb2YgdGhpcyBpbmZvcm1hdGlvbiB0byB0aGUgSW5ncmVzcyBMU1Iu IA0KICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMDEyICAgICAgICAgICAgICAg ICAgW1BhZ2UgN10gDQogICAgICAgDA0KCgoKCgoKICAgSW50ZXJuZXQtRHJhZnQgICAgIGRyYWZ0 LWlldGYtbXBscy1yc3ZwLXRlLW5vLXBocC1vb2ItbWFwcGluZy0wOS50eHQgDQogICAgICAgDQoK ICAgICAgQW4gRWdyZXNzIExTUiBNQVkgaW1wbGVtZW50IGEgY2xlYW51cCB0aW1lciBmb3IgdGhp cyBwdXJwb3NlLiBUaGUgDQogICAgICB0aW1lLW91dCB2YWx1ZSBpcyBhIGxvY2FsIGRlY2lzaW9u IGF0IHRoZSBFZ3Jlc3MsIHdpdGggYSANCiAgICAgIFJFQ09NTUVOREVEIGRlZmF1bHQgdmFsdWUg b2YgNjAgc2Vjb25kcy4gIA0KCiAgIDMuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIA0KCiAgICAg IEFkZGl0aW9uIG9mICJub24tUEhQIGJlaGF2aW9yIiBhZGRzIGEgdmFyaWFibGUgb2YgYXR0YWNr cyBvbiB0aGUgDQogICAgICBsYWJlbCBhc3NpZ25lZCBieSB0aGUgRWdyZXNzIG5vZGUuIEFzIGNo YW5nZSBpbiB0aGUgdmFsdWUgb2YgdGhlIA0KICAgICAgZWdyZXNzIGxhYmVsIHJlcG9ydGVkIGlu IHRoZSBSUk8gY2FuIGNhdXNlIHRoZSBMU1AgdG8gYmUgdG9ybiANCiAgICAgIGRvd24sIGFkZGl0 aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHByb3RlY3RpbmcgbGFiZWwgDQogICAg ICBhc3NpZ25lZCBieSB0aGUgRWdyZXNzIG5vZGUgYXJlIHJlcXVpcmVkLiBTZWN1cml0eSBtZWNo YW5pc21zIGFzIA0KICAgICAgaWRlbnRpZmllZCBpbiBbUkZDNTkyMF0sIFtSRkMyMjA1XSwgW1JG QzMyMDldLCBbUkZDMzQ3M10sIA0KICAgICAgW1JGQzU0MjBdIGFuZCBbUkZDNDg3NV0gY2FuIGJl IHVzZWQgZm9yIHRoaXMgcHVycG9zZS4gVGhpcyANCiAgICAgIGRvY3VtZW50IGRvZXMgbm90IGlu dHJvZHVjZSBhbnkgYWRkaXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgYWJvdmUgDQogICAgICB0aG9z ZSBpZGVudGlmaWVkIGluIFtSRkM1OTIwXSwgW1JGQzIyMDVdLCBbUkZDMzIwOV0sIFtSRkMzNDcz XSwgDQogICAgICBbUkZDNTQyMF0gYW5kIFtSRkM0ODc1XS4gIA0KICAgIA0KICAgIA0KICAgNC4g SUFOQSBDb25zaWRlcmF0aW9ucyANCgogICA0LjEuIEF0dHJpYnV0ZSBGbGFncyBmb3IgTFNQX0FU VFJJQlVURVMgb2JqZWN0IA0KCiAgICAgIFRoZSBmb2xsb3dpbmcgbmV3IGZsYWdzIGFyZSBkZWZp bmVkIGZvciB0aGUgQXR0cmlidXRlcyBGbGFncyBUTFYgDQogICAgICBpbiB0aGUgTFNQX0FUVFJJ QlVURVMgb2JqZWN0LiAgVGhlIG51bWVyaWMgdmFsdWVzIGFyZSB0byBiZSANCiAgICAgIGFzc2ln bmVkIGJ5IElBTkEuIA0KCiAgICAgIG8gIE5vbi1QSFAgYmVoYXZpb3IgZmxhZzogIA0KCiAgICAg IFRoaXMgZmxhZ3MgaXMgdXNlZCBpbiB0aGUgQXR0cmlidXRlcyBGbGFncyBUTFYgaW4gYSBQYXRo IG1lc3NhZ2UuIA0KICAgICAgVGhlIGZsYWdzIGhhdmUgY29ycmVzcG9uZGluZyBuZXcgZmxhZyB0 byBiZSB1c2VkIGluIHRoZSBSUk8gDQogICAgICBBdHRyaWJ1dGVzIHN1Ym9iamVjdC4gQXMgcGVy IFtSRkM1NDIwXSwgdGhlIGJpdCBudW1iZXJpbmcgaW4gdGhlIA0KICAgICAgQXR0cmlidXRlIEZs YWdzIFRMViBhbmQgdGhlIFJSTyBBdHRyaWJ1dGVzIHN1Ym9iamVjdCBpcyANCiAgICAgIGlkZW50 aWNhbC4gVGhhdCBpcywgdGhlIHNhbWUgYXR0cmlidXRlIGlzIGluZGljYXRlZCBieSB0aGUgc2Ft ZSANCiAgICAgIGJpdCBpbiBib3RoIHBsYWNlcy4gVGhpcyBmbGFnIGlzIG5vdCBhbGxvd2VkIGlu IHRoZSBBdHRyaWJ1dGVzIA0KICAgICAgRmxhZ3MgVExWIGluIGEgUmVzdiBtZXNzYWdlLiBTcGVj aWZpY2FsbHksIEF0dHJpYnV0ZXMgb2YgdGhpcyANCiAgICAgIGZsYWcgYXJlIGFzIGZvbGxvd3M6 ICANCgogICAgICAgICAgICAtIEJpdCBOdW1iZXI6IFRvIGJlIGFzc2lnbmVkIGJ5IElBTkEuIA0K CiAgICAgICAgICAgIC0gQXR0cmlidXRlIGZsYWcgY2FycmllZCBpbiBQYXRoIG1lc3NhZ2U6IFll cyANCgogICAgICAgICAgICAtIEF0dHJpYnV0ZSBmbGFnIGNhcnJpZWQgaW4gUmVzdiBtZXNzYWdl OiBObyANCgogICAgICAgICAgICAtIEF0dHJpYnV0ZSBmbGFnIGNhcnJpZWQgaW4gUlJPIG1lc3Nh Z2U6IFllcyANCgogICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMTIgICAgICAg ICAgICAgICAgICBbUGFnZSA4XSANCiAgICAgICAMDQoKCgoKCgogICBJbnRlcm5ldC1EcmFmdCAg ICAgZHJhZnQtaWV0Zi1tcGxzLXJzdnAtdGUtbm8tcGhwLW9vYi1tYXBwaW5nLTA5LnR4dCANCiAg ICAgICANCgogICAgDQoKICAgICAgbyAgT09CIG1hcHBpbmcgZmxhZzogICANCgogICAgICBUaGlz IGZsYWdzIGlzIHVzZWQgaW4gdGhlIEF0dHJpYnV0ZXMgRmxhZ3MgVExWIGluIGEgUGF0aCBtZXNz YWdlLiANCiAgICAgIFRoZSBmbGFncyBoYXZlIGNvcnJlc3BvbmRpbmcgbmV3IGZsYWcgdG8gYmUg dXNlZCBpbiB0aGUgUlJPIA0KICAgICAgQXR0cmlidXRlcyBzdWJvYmplY3QuIEFzIHBlciBbUkZD NTQyMF0sIHRoZSBiaXQgbnVtYmVyaW5nIGluIHRoZSANCiAgICAgIEF0dHJpYnV0ZSBGbGFncyBU TFYgYW5kIHRoZSBSUk8gQXR0cmlidXRlcyBzdWJvYmplY3QgaXMgDQogICAgICBpZGVudGljYWwu IFRoYXQgaXMsIHRoZSBzYW1lIGF0dHJpYnV0ZSBpcyBpbmRpY2F0ZWQgYnkgdGhlIHNhbWUgDQog ICAgICBiaXQgaW4gYm90aCBwbGFjZXMuIFRoaXMgZmxhZyBpcyBub3QgYWxsb3dlZCBpbiB0aGUg QXR0cmlidXRlcyANCiAgICAgIEZsYWdzIFRMViBpbiBhIFJlc3YgbWVzc2FnZS4gU3BlY2lmaWNh bGx5LCBBdHRyaWJ1dGVzIG9mIHRoaXMgDQogICAgICBmbGFnIGFyZSBhcyBmb2xsb3dzOiAgDQoK ICAgICAgICAgICAgLSBCaXQgTnVtYmVyOiBUbyBiZSBhc3NpZ25lZCBieSBJQU5BLiANCgogICAg ICAgICAgICAtIEF0dHJpYnV0ZSBmbGFnIGNhcnJpZWQgaW4gUGF0aCBtZXNzYWdlOiBZZXMgDQoK ICAgICAgICAgICAgLSBBdHRyaWJ1dGUgZmxhZyBjYXJyaWVkIGluIFJlc3YgbWVzc2FnZTogTm8g DQoKICAgICAgICAgICAgLSBBdHRyaWJ1dGUgZmxhZyBjYXJyaWVkIGluIFJSTyBtZXNzYWdlOiBZ ZXMgIA0KCiAgIDQuMi4gTmV3IFJTVlAgZXJyb3Igc3ViLWNvZGUgIA0KCiAgICAgIEZvciBFcnJv ciBDb2RlID0gMjUgIk5vdGlmeSBFcnJvciIgKHNlZSBbUkZDMzIwOV0pIHRoZSBmb2xsb3dpbmcg DQogICAgICBzdWItY29kZSBpcyBkZWZpbmVkLiANCiAgICAgICANCiAgICAgICAgICAgIFN1Yi1j b2RlICAgICAgICAgICAgICAgICAgICBWYWx1ZSANCiAgICAgICAgICAgIC0tLS0tLS0tICAgICAg ICAgICAgICAgICAgICAtLS0tLSANCiAgICAgICANCiAgICAgICAgICAgIE5vIE9PQiBtYXBwaW5n IHJlY2VpdmVkICAgICB0byBiZSBhc3NpZ25lZCBieSBJQU5BLiAgDQogICAgICAgDQoKICAgNS4g QWNrbm93bGVkZ21lbnRzIA0KCiAgICAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsg WWFrb3YgUmVraHRlciBmb3IgaGlzIHN1Z2dlc3Rpb25zIA0KICAgICAgb24gdGhlIGRyYWZ0LiAg IA0KCiAgICANCiAgIDYuIFJlZmVyZW5jZXMgDQoKICAgNi4xLiBOb3JtYXRpdmUgUmVmZXJlbmNl cyANCgogICAgICBbUkZDMjExOV0gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBS RkNzIHRvIEluZGljYXRlICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LiANCgoKCiAgICAgICAg ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAxMiAgICAgICAgICAgICAgICAgIFtQYWdlIDld IA0KICAgICAgIAwNCgoKCgoKCiAgIEludGVybmV0LURyYWZ0ICAgICBkcmFmdC1pZXRmLW1wbHMt cnN2cC10ZS1uby1waHAtb29iLW1hcHBpbmctMDkudHh0IA0KICAgICAgIA0KCiAgICAgIFtSRkM1 NDIwXSBBLiBGYXJyZWwsIEQuIFBhcGFkaW1pdHJpb3UsIEouIFAuIFZhc3NldXIgYW5kIEEuIA0K ICAgICAgICAgICAgICAgIEF5eWFuZ2FyLCAiRW5jb2Rpbmcgb2YgQXR0cmlidXRlcyBmb3IgTXVs dGlwcm90b2NvbCANCiAgICAgICAgICAgICAgICBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIExhYmVs IFN3aXRjaGVkIFBhdGggKExTUCkgDQogICAgICAgICAgICAgICAgRXN0YWJsaXNobWVudCBVc2lu ZyBSU1ZQLVRFIiwgUkZDIDU0MjAsIEZlYnJ1YXJ5IDIwMDYuIA0KCiAgICAgIFtSRkMzMjA5XSBE LiBBd2R1Y2hlLCBMLiBCZXJnZXIsIEQuIEdhbiwgVC4gTGksIFYuIFNyaW5pdmFzYW4sIA0KICAg ICAgICAgICAgICAgIGFuZCBHLiBTd2FsbG93LCAiUlNWUC1URTogRXh0ZW5zaW9ucyB0byBSU1ZQ IGZvciBMU1AgDQogICAgICAgICAgICAgICAgVHVubmVscyIsIFJGQyAzMjA5LCBEZWNlbWJlciAy MDAxLiANCgogICAgICBbUkZDNDg3NV0gUi4gQWdnYXJ3YWwsIEQuIFBhcGFkaW1pdHJpb3UsIFMu IFlhc3VrYXdhLCBldCBhbCwgDQogICAgICAgICAgICAgICAgIkV4dGVuc2lvbnMgdG8gUlNWUC1U RSBmb3IgUG9pbnQtdG8tTXVsdGlwb2ludCBURSANCiAgICAgICAgICAgICAgICBMU1BzIiwgUkZD IDQ4NzUuIA0KCiAgICAgIFtSRkMzNDczXSBCZXJnZXIsIEwuLCBFZC4sICJHZW5lcmFsaXplZCBN dWx0aS1Qcm90b2NvbCBMYWJlbCANCiAgICAgICAgICAgICAgICBTd2l0Y2hpbmcgKEdNUExTKSBT aWduYWxpbmcgUmVzb3VyY2UgUmVzZXJWYXRpb24gDQogICAgICAgICAgICAgICAgUHJvdG9jb2wt VHJhZmZpYyBFbmdpbmVlcmluZyAoUlNWUC1URSkgRXh0ZW5zaW9ucyIsIFJGQyANCiAgICAgICAg ICAgICAgICAzNDczLCBKYW51YXJ5IDIwMDMuLiANCgogICAgICBbUkZDMjIwNV0gUi4gQnJhZGVu LCBFZC4sICJSZXNvdXJjZSBSZVNlclZhdGlvbiBQcm90b2NvbCAoUlNWUCkgLQ0KICAgICAgICAg ICAgICAgIC0gVmVyc2lvbiAxIEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlvbiIsIFJGQyAyMjA1LCAN CiAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMTk5Ny4gICANCgogICAgICBbQVRUUklCVVRFLUJO Rl0gQmVyZ2VyLCBMLiBhbmQgU3dhbGxvdywgRy4sICJMU1AgQXR0cmlidXRlcyBSZWxhdGVkDQog ICAgICAgICAgICAgICAgUm91dGluZyBCYWNrdXMtTmF1ciBGb3JtIiwgZHJhZnQtaWV0Zi1jY2Ft cC1hdHRyaWJ1dGUtDQogICAgICAgICAgICAgICAgYm5mLCB3b3JrIGluIHByb2dyZXNzLg0KDQog ICAgDQogICA2LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQoKICAgICAgW01WUE5dIEUuIFJv c2VuLCBSLiBBZ2dhcndhbCBldCBhbCwgIk11bHRpY2FzdCBpbiBNUExTL0JHUCBJUCANCiAgICAg ICAgICAgICAgICBWUE5zIiwgZHJhZnQtaWV0Zi1sM3Zwbi0yNTQ3YmlzLW1jYXN0LTEwLnR4dCwg d29yayBpbiANCiAgICAgICAgICAgICAgICBwcm9ncmVzcy4gIA0KCiAgICAgIFtSRkM0NzYxXSBL b21wZWxsYSwgSy4sIEVkLiwgYW5kIFkuIFJla2h0ZXIsIEVkLiwgIlZpcnR1YWwgDQogICAgICAg ICAgICAgICAgUHJpdmF0ZSBMQU4gU2VydmljZSAoVlBMUykgVXNpbmcgQkdQIGZvciBBdXRvLURp c2NvdmVyeSANCiAgICAgICAgICAgICAgICBhbmQgU2lnbmFsaW5nIiwgUkZDIDQ3NjEsIEphbnVh cnkgMjAwNy4gICANCgogICAgICBbUkZDNTkyMV0gTS4gQm9jY2ksIFMuIEJyeWFudCwgZXQgYWws ICJBIEZyYW1ld29yayBmb3IgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICBNUExTIGlu IFRyYW5zcG9ydCBOZXR3b3JrcyIsIFJGQyA1OTIxLCBKYW51YXJ5IDIwMDcuIA0KCiAgICAgIFtS RkM1OTIwXSBMLiBGYW5nLCBFZC4sICJTZWN1cml0eSBGcmFtZXdvcmsgZm9yIE1QTFMgYW5kIEdN UExTIA0KICAgICAgICAgICAgICAgIE5ldHdvcmtzIiwgUkZDIDU5MjAsIEp1bHkgMjAxMC4NCgoK ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMDEyICAgICAgICAgICAgICAgICAg W1BhZ2UgMTBdIA0KICAgICAgIAwNCgoKCgoKCiAgIEludGVybmV0LURyYWZ0ICAgICBkcmFmdC1p ZXRmLW1wbHMtcnN2cC10ZS1uby1waHAtb29iLW1hcHBpbmctMDkudHh0IA0KICAgICAgIA0KCiAg ICAgIFtSRkM0Mzc5XSBLLiBLb21wZWxsYSwgYW5kIEcuIFN3YWxsb3csICJEZXRlY3RpbmcgTXVs dGktUHJvdG9jb2wgDQogICAgICAgICAgICAgICAgTGFiZWwgU3dpdGNoZWQgKE1QTFMpIERhdGEg UGxhbmUgRmFpbHVyZXMiLCBSRkMgNDM3OSwgDQogICAgICAgICAgICAgICAgRmVicnVhcnkgMjAw Ni4NCiAgICAgIFtQMk1QLU9BTV0gUy4gU2F4ZW5hLCBFZC4sIEcuIFN3YWxsb3csIFouIEFsaSwg QS4gRmFycmVsLCBTLiANCiAgICAgICAgICAgICAgICBZYXN1a2F3YSwgVC4gTmFkZWF1LCAiRGV0 ZWN0aW5nIERhdGEgUGxhbmUgRmFpbHVyZXMgaW4gDQogICAgICAgICAgICAgICAgUG9pbnQtdG8t TXVsdGlwb2ludCBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyANCiAgICAgICAgICAgICAg ICAoTVBMUykgLSBFeHRlbnNpb25zIHRvIExTUCBQaW5nIiwgZHJhZnQtaWV0Zi1tcGxzLXAybXAt DQogICAgICAgICAgICAgICAgbHNwLXBpbmctMTcudHh0LCB3b3JrIGluIHByb2dyZXNzLiANCgoN CiAgIEF1dGhvcidzIEFkZHJlc3NlcyANCgogICAgICAgDQogICAgICBaYWZhciBBbGkgDQogICAg ICBDaXNjbyBTeXN0ZW1zLCBJbmMuIA0KICAgICAgRW1haWw6IHphbGlAY2lzY28uY29tIA0KICAg ICAgIA0KICAgICAgR2VvcmdlIFN3YWxsb3cgDQogICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMuIA0K ICAgICAgRW1haWw6IHN3YWxsb3dAY2lzY28uY29tIA0KICAgICAgIA0KICAgICAgUmFodWwgQWdn YXJ3YWwgDQogICAgICBKdW5pcGVyIE5ldHdvcmtzIA0KICAgICAgcmFodWxAanVuaXBlci5uZXQg DQogICAgDQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgMjAxMiAgICAgICAgICAgICAgICAgIFtQYWdlIDExXSANCiAgICAgICAM ------_=_NextPart_001_01CC5CFC.88376F51-- From jdrake@juniper.net Wed Aug 17 11:53:31 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B151F0C3F for ; Wed, 17 Aug 2011 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwJWBmuZhgOs for ; Wed, 17 Aug 2011 11:53:31 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0B61F0C39 for ; Wed, 17 Aug 2011 11:53:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTkwOW34I/6N8smPG8eO86oIKh3E/wcZ6@postini.com; Wed, 17 Aug 2011 11:54:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 17 Aug 2011 11:53:35 -0700 From: John E Drake To: "Zafar Ali (zali)" , "rtg-ads@tools.ietf.org" Date: Wed, 17 Aug 2011 11:53:33 -0700 Thread-Topic: RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt Thread-Index: AcxYbrZgrOy15FlHTbWbuc2wvgtr+AEjIT3gAAS3tSA= Message-ID: <5E893DB832F57341992548CDBB333163A0ACC2FD0D@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0AC854B63@EMBX01-HQ.jnpr.net> <7CC717E2F49DAA4A827DA3FEA237111B05AEA1A0@XMB-RCD-103.cisco.com> In-Reply-To: <7CC717E2F49DAA4A827DA3FEA237111B05AEA1A0@XMB-RCD-103.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-rsvp-te-no-php-oob-mapping.all@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 18:53:31 -0000 WmFmYXIsDQoNClNuaXBwZWQsIGNvbW1lbnRzIGlubGluZS4NCg0KVGhhbmtzLA0KDQpKb2huDQoN ClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiANCj4gPiBJdCBwcm9wb3NlcyBhbiBhZGp1bmN0IHBy b2NlZHVyZSB0byBiZSBwZXJmb3JtZWQgYnkgdGhlIGluZ3Jlc3MgaW4NCj4gPiBhZGRpdGlvbiB0 byBpdHMgY2hlY2tpbmcgb2YgdGhlIHNldHRpbmcgb2YgdGhlICdOb24tUEhQIGJlaGF2aW9yDQo+ ID4gYWNrbm93bGVkZ2VtZW50IGZsYWcnIGluIHRoZSBGbGFncyBmaWVsZCBvZiB0aGUgUlJPLiAg VGhpcyBwcm9jZWR1cmUNCj4gPiBpcyB0byBjaGVjayB0aGUgUlJPIHRvIHNlZSB3aGV0aGVyIHRo ZSBlZ3Jlc3MgYWxsb2NhdGVkIGEgbm9uLW51bGwNCj4gPiBsYWJlbCBmb3IgdGhlIExTUDsgIGl0 IGlzIHVubmVjZXNzYXJ5IGFuZCBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcNCj4gaXQuDQo+ID4N Cj4gDQo+IEFzIGN1cnJlbnQgUkZDcyBhbGxvdyBpbmdyZXNzIHRvIGxvb2sgYXQgdGhlIGxhYmVs IHJlY29yZGluZyBpbiBSUk8sIHdlDQo+IHRob3VnaHQgaXQgd2lsbCBiZSB1c2VmdWwgdG8gYWxs b3cgaXQuIFRoaXMgY292ZXJzIHVzIGZvciB0aGUgY2FzZQ0KPiB3aGVyZSBlZ3Jlc3MgZG9lcyBu b3QgaW1wbGVtZW50IHRoZSBwcm9wb3NlZCBleHRlbnNpb24gYnV0IGJhc2VkIG9uDQo+IHNvbWUg bG9jYWwgcG9saWN5IHN0aWxsIGFsbG9jYXRlcyBhIG5vbi1OdWxsIGxhYmVsLiBXZSBmZWVsIGl0 IGlzDQo+IHVzZWZ1bCBhbmQgaGVuY2Ugd2FzIHBhcnQgb2YgdGhlIHRleHQuDQoNCkpEOiAgV2hh dCB3b3VsZCB0aGUgaW5ncmVzcyBkbyBkaWZmZXJlbnRseSBpbiB0aGlzIGNhc2U/ICBJIHRob3Vn aHQgaXQgd2FzIHRvIGNoZWNrIGZvciB0aGUgY2FzZSBvZiBhbiBlZ3Jlc3Mgbm9kZSB0aGF0IGlu ZGljYXRlZCBzdXBwb3J0IGJ1dCBhbGxvY2F0ZWQgYSBOdWxsIGxhYmVsLCBhbmQgaXQgc2VlbWVk IG9mIG1hcmdpbmFsIHV0aWxpdHkuDQoNCj4gDQo+IEF0IHRoZSB2ZXJ5IGxlYXN0LCB3ZSBuZWVk IHRvIHRhbGsgYWJvdXQgbGFiZWwgcmVjb3JkaW5nIGluIFJSTyB0byBiZQ0KPiBjb21wbGV0ZS4g RGlzYWxsb3dpbmcgaW5ncmVzcyBub3QgdG8gaW5mZXIgYW55dGhpbmcgZnJvbSBsYWJlbA0KPiBy ZWNvcmRpbmcgaXMgYWxzbyBvZGQuDQo+IA0KPiBJbiB0aGUgbGlnaHQgb2YgdGhlIGFib3ZlLCB3 ZSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIFJSTyBsYWJlbA0KPiByZWNvcmRpbmcgdGV4dC4gSG9w ZSB5b3UgYXJlIG9rIHdpdGggdGhhdC4NCg0KSkQ6ICBJdCdzIGZpbmUgdG8ga2VlcCBpdC4NCg0K PiANCj4gVGhhbmtzDQo+IA0KPiBSZWdhcmRzLi4uIFphZmFyDQo+IA0KPiA+IFNlbnQgZnJvbSBt eSBpUGhvbmUNCj4gPg0KDQo= From akatlas@gmail.com Wed Aug 17 17:47:45 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C71E11E8095 for ; Wed, 17 Aug 2011 17:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTnMNyx0EQ17 for ; Wed, 17 Aug 2011 17:47:44 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC9721F8AED for ; Wed, 17 Aug 2011 17:47:44 -0700 (PDT) Received: by ywm21 with SMTP id 21so1217798ywm.31 for ; Wed, 17 Aug 2011 17:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OEtxQbZsYtl6jiDH11Uv7Q1mc9uRHaYpMuIWHTPzMMw=; b=STlhtUlugdW14vDr6MJv7vr55hs273wg/RiNDegPHsj9+jHwQaMbq5OMAmnQ/WZ360 JJkZ9qusI8DW8JjZC+JUO6A6dMDa0Vi7CImjJ1jHM6Kkr5tBYRtyA5lAznlMYuheCZZZ kM43NQYmCnVcFQTAKEZ0G7PkhujWRS6m662Jc= MIME-Version: 1.0 Received: by 10.142.140.18 with SMTP id n18mr67917wfd.61.1313628516033; Wed, 17 Aug 2011 17:48:36 -0700 (PDT) Received: by 10.68.42.130 with HTTP; Wed, 17 Aug 2011 17:48:36 -0700 (PDT) In-Reply-To: <1B091506-A261-4AA1-863E-E95DAC610076@ericsson.com> References: <1B091506-A261-4AA1-863E-E95DAC610076@ericsson.com> Date: Wed, 17 Aug 2011 20:48:36 -0400 Message-ID: From: Alia Atlas To: Acee Lindem Content-Type: multipart/alternative; boundary=000e0cd1857210a54a04aabcf9a8 Cc: "rtg-dir@ietf.org" , Alia Atlas , "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ospf-auth-trailer-ospfv3-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 00:47:45 -0000 --000e0cd1857210a54a04aabcf9a8 Content-Type: text/plain; charset=ISO-8859-1 Hi Acee, On Wed, Aug 17, 2011 at 11:17 AM, Acee Lindem wrote: > Hi Alia, > > Thanks much for the thorough review. We have some comments from Sam as > well. We will incorporate your updates once we decide what to do with his > comments which are mostly based on the presumption of a global crypto table > infrastructure (which was only recently made a KARP WG document). See > inline. > Sam's comments are based on a wider experience of key management and handling. Certainly, I don't think that OSPFv3 should have worse key management than OSPFv2 does. > On Aug 15, 2011, at 1:07 PM, Alia Atlas wrote: > > > 1) In Sec 4.1, for Cryptographic Sequence Number, additional description > indicating behavior when the value wraps would be useful. > > We will add this. I admit that the behavior is implied based on the > discussion of the upper word in the sequence number. > > > If that is never expected, that is also useful to state. The phrase > "strictly increasing" is not sufficiently clear to me. > > This is as opposed to the current requirement that the sequence number is > monotonically increasing. Would adding, ",i.e., greater than the previously > received sequence number," suffice? The term "strictly increasing" is used > in this Wiki: http://en.wikipedia.org/wiki/Monotonic_function > Strictly increasing is fine and clear until one gets to the question of what happens when the number needs to wrap. That's my only concern. Alia --000e0cd1857210a54a04aabcf9a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Acee,

On Wed, Aug 17, 2011 at 11:17 AM= , Acee Lindem <acee.lindem@ericsson.com> wrote:
Hi Alia,

Thanks much for the thorough review. We have some comments from Sam as well= . We will incorporate your updates once we decide what to do with his comme= nts which are mostly based on the presumption of a global crypto table infr= astructure (which was only recently made a KARP WG document). See inline.

Sam's comments are based = on a wider experience of key management and handling.=A0 Certainly, I don&#= 39;t think that OSPFv3 should have worse key management than OSPFv2 does. =A0
On Aug 15, 2011, at 1:07 PM, Alia Atlas wrote:

> 1) In Sec 4.1, for Cryptographic Sequence Number, additional descripti= on indicating behavior when the value wraps would be useful.

We will add this. I admit that the behavior is implied based on the d= iscussion of the upper word in the sequence number.

> If that is never expected, that is also useful to state. =A0The phrase= "strictly increasing" is not sufficiently clear to me.

This is as opposed to the current requirement that the sequence numbe= r is monotonically increasing. Would adding, ",i.e., greater than the = previously received sequence number," suffice? The term "strictly= increasing" is used in this Wiki: http://en.wikipedia.org/wiki/Mon= otonic_function

Strictly increasing is fine and clear until one gets = to the question of what happens when the number needs to wrap.=A0 That'= s my only concern.

Alia
--000e0cd1857210a54a04aabcf9a8-- From zali@cisco.com Wed Aug 17 20:26:48 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84C65E8002 for ; Wed, 17 Aug 2011 20:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfFvpeZ1fKTF for ; Wed, 17 Aug 2011 20:26:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5985E8003 for ; Wed, 17 Aug 2011 20:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=2936; q=dns/txt; s=iport; t=1313638061; x=1314847661; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hzvHF906EYLd8pnyK8YLBaAc7ArDeKIfYxiR4JeziX0=; b=H0IxCXNthrWWNDuKmWZx8y+Secz5SqlJydxEtJhwfzTkaDnyPchvL8WF XCl1CEJOQqnpqo0JKWlzdhrOFTRQbQHTQJV/4SY3nQmJ0Tx7Ab1rhBppW MPQaYpUqEN1mOHGMIzgQ+MjEP0v6Wvvfbfg2VovyaP5/jueBEGHpQjgBS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAEKGTE6tJXG//2dsb2JhbABBhEmUUI5hd3eBQAEBAQEDEgEQDQRFDAQCAQgRBAEBAwIGBhcBAgICAQFECQgBAQQBEggan1gBjTGRUYEshAwxXwSHYJBIi34 X-IronPort-AV: E=Sophos;i="4.68,242,1312156800"; d="scan'208";a="14186519" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 18 Aug 2011 03:27:26 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7I3RQLb029495; Thu, 18 Aug 2011 03:27:26 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 22:27:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 17 Aug 2011 22:27:24 -0500 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B05AEA40C@XMB-RCD-103.cisco.com> In-Reply-To: <5E893DB832F57341992548CDBB333163A0ACC2FD0D@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt Thread-Index: AcxYbrZgrOy15FlHTbWbuc2wvgtr+AEjIT3gAAS3tSAAEevAwA== References: <5E893DB832F57341992548CDBB333163A0AC854B63@EMBX01-HQ.jnpr.net> <7CC717E2F49DAA4A827DA3FEA237111B05AEA1A0@XMB-RCD-103.cisco.com> <5E893DB832F57341992548CDBB333163A0ACC2FD0D@EMBX01-HQ.jnpr.net> From: "Zafar Ali (zali)" To: "John E Drake" , X-OriginalArrivalTime: 18 Aug 2011 03:27:26.0298 (UTC) FILETIME=[C05FDBA0:01CC5D56] X-Mailman-Approved-At: Wed, 17 Aug 2011 23:47:53 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-rsvp-te-no-php-oob-mapping.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 03:26:48 -0000 SGkgSm9obi0gDQoNCklmIHRoZSBsYWJlbCByZWNvcmRpbmcgaW5kaWNhdGVzIHRoYXQgdGhlIG5v ZGUgaGFzIG5vdCBhbGxvY2F0ZWQgYSBOdWxsIGxhYmVsLCB0aGUgSW5ncmVzcyBub2RlIHdpbGwg dGVhciB0aGUgc2V0dXAgKHNvIG5vdCBhIGRpZmZlcmVudCBhY3Rpb24pLiBJIGFncmVlIHRoYXQg aXQncyBtYXJnaW5hbCBhZGRpdGlvbiBidXQgZ29vZCB0byBoYXZlIGl0IHRoZXJlIGZvciBjb21w bGV0ZW5lc3MuIA0KDQpUaGFua3MgZm9yIGFncmVlaW5nIHRvIGtlZXAgdGhlIHRleHQuIA0KDQpU aGFua3MNCg0KUmVnYXJkcyAuLi4gWmFmYXIgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSm9obiBFIERyYWtlIFttYWlsdG86amRyYWtlQGp1bmlwZXIubmV0XQ0KPiBT ZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNywgMjAxMSAyOjU0IFBNDQo+IFRvOiBaYWZhciBBbGkg KHphbGkpOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQo+IENjOiBydGctZGlyQGlldGYub3JnOyBk cmFmdC1pZXRmLW1wbHMtcnN2cC10ZS1uby1waHAtb29iLQ0KPiBtYXBwaW5nLmFsbEB0b29scy5p ZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxzLXJz dnAtdGUtbm8tcGhwLW9vYi1tYXBwaW5nLQ0KPiAwOC50eHQNCj4gDQo+IFphZmFyLA0KPiANCj4g U25pcHBlZCwgY29tbWVudHMgaW5saW5lLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gSm9obg0KPiAN Cj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gPg0KPiA+ID4gSXQgcHJvcG9zZXMgYW4gYWRq dW5jdCBwcm9jZWR1cmUgdG8gYmUgcGVyZm9ybWVkIGJ5IHRoZSBpbmdyZXNzIGluDQo+ID4gPiBh ZGRpdGlvbiB0byBpdHMgY2hlY2tpbmcgb2YgdGhlIHNldHRpbmcgb2YgdGhlICdOb24tUEhQIGJl aGF2aW9yDQo+ID4gPiBhY2tub3dsZWRnZW1lbnQgZmxhZycgaW4gdGhlIEZsYWdzIGZpZWxkIG9m IHRoZSBSUk8uICBUaGlzIHByb2NlZHVyZQ0KPiA+ID4gaXMgdG8gY2hlY2sgdGhlIFJSTyB0byBz ZWUgd2hldGhlciB0aGUgZWdyZXNzIGFsbG9jYXRlZCBhIG5vbi1udWxsDQo+ID4gPiBsYWJlbCBm b3IgdGhlIExTUDsgIGl0IGlzIHVubmVjZXNzYXJ5IGFuZCBJIHdvdWxkIHN1Z2dlc3QgcmVtb3Zp bmcNCj4gPiBpdC4NCj4gPiA+DQo+ID4NCj4gPiBBcyBjdXJyZW50IFJGQ3MgYWxsb3cgaW5ncmVz cyB0byBsb29rIGF0IHRoZSBsYWJlbCByZWNvcmRpbmcgaW4gUlJPLA0KPiB3ZQ0KPiA+IHRob3Vn aHQgaXQgd2lsbCBiZSB1c2VmdWwgdG8gYWxsb3cgaXQuIFRoaXMgY292ZXJzIHVzIGZvciB0aGUg Y2FzZQ0KPiA+IHdoZXJlIGVncmVzcyBkb2VzIG5vdCBpbXBsZW1lbnQgdGhlIHByb3Bvc2VkIGV4 dGVuc2lvbiBidXQgYmFzZWQgb24NCj4gPiBzb21lIGxvY2FsIHBvbGljeSBzdGlsbCBhbGxvY2F0 ZXMgYSBub24tTnVsbCBsYWJlbC4gV2UgZmVlbCBpdCBpcw0KPiA+IHVzZWZ1bCBhbmQgaGVuY2Ug d2FzIHBhcnQgb2YgdGhlIHRleHQuDQo+IA0KPiBKRDogIFdoYXQgd291bGQgdGhlIGluZ3Jlc3Mg ZG8gZGlmZmVyZW50bHkgaW4gdGhpcyBjYXNlPyAgSSB0aG91Z2h0IGl0DQo+IHdhcyB0byBjaGVj ayBmb3IgdGhlIGNhc2Ugb2YgYW4gZWdyZXNzIG5vZGUgdGhhdCBpbmRpY2F0ZWQgc3VwcG9ydCBi dXQNCj4gYWxsb2NhdGVkIGEgTnVsbCBsYWJlbCwgYW5kIGl0IHNlZW1lZCBvZiBtYXJnaW5hbCB1 dGlsaXR5Lg0KPiANCj4gPg0KPiA+IEF0IHRoZSB2ZXJ5IGxlYXN0LCB3ZSBuZWVkIHRvIHRhbGsg YWJvdXQgbGFiZWwgcmVjb3JkaW5nIGluIFJSTyB0byBiZQ0KPiA+IGNvbXBsZXRlLiBEaXNhbGxv d2luZyBpbmdyZXNzIG5vdCB0byBpbmZlciBhbnl0aGluZyBmcm9tIGxhYmVsDQo+ID4gcmVjb3Jk aW5nIGlzIGFsc28gb2RkLg0KPiA+DQo+ID4gSW4gdGhlIGxpZ2h0IG9mIHRoZSBhYm92ZSwgd2Ug d291bGQgbGlrZSB0byBrZWVwIHRoZSBSUk8gbGFiZWwNCj4gPiByZWNvcmRpbmcgdGV4dC4gSG9w ZSB5b3UgYXJlIG9rIHdpdGggdGhhdC4NCj4gDQo+IEpEOiAgSXQncyBmaW5lIHRvIGtlZXAgaXQu DQo+IA0KPiA+DQo+ID4gVGhhbmtzDQo+ID4NCj4gPiBSZWdhcmRzLi4uIFphZmFyDQo+ID4NCj4g PiA+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gPiA+DQoNCg== From gregory.ietf@gmail.com Wed Aug 17 23:18:46 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF0521F87E2 for ; Wed, 17 Aug 2011 23:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDbUxYbtiEyX for ; Wed, 17 Aug 2011 23:18:44 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id DD72421F87D6 for ; Wed, 17 Aug 2011 23:18:43 -0700 (PDT) Received: by pzk33 with SMTP id 33so3977333pzk.18 for ; Wed, 17 Aug 2011 23:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WdDoHg+hZLfszb+SNZb1XCYE56Xz18AoGvqQfvPr4gE=; b=l+2WOZemNy6fyNlUz7yTKd5zzJq+Bd/90/PKfywsTEmOsYF+spMHmoHiQuuTjwJrd7 LqiO7COTIPmsLcp8cWodRZTklKxmUoA2HuW5llzsDGo2fzHzDJkCtncuZf7PNOCGu/sO GDFAh/Y5CG79QiHL40hu7b2/7xASi8g3SZDqE= MIME-Version: 1.0 Received: by 10.142.153.9 with SMTP id a9mr206678wfe.279.1313648370060; Wed, 17 Aug 2011 23:19:30 -0700 (PDT) Received: by 10.68.48.5 with HTTP; Wed, 17 Aug 2011 23:19:30 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF8E2F8F@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 17 Aug 2011 23:19:30 -0700 Message-ID: From: Gregory Lebovitz To: Ross Callon Content-Type: multipart/alternative; boundary=000e0cd2dd48750c9404aac19802 X-Mailman-Approved-At: Wed, 17 Aug 2011 23:48:06 -0700 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 06:18:46 -0000 --000e0cd2dd48750c9404aac19802 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable inline... On Mon, Aug 15, 2011 at 7:31 PM, Ross Callon wrote: > But if the key management protocol was running over the out of band > management network, then which version of OSPF would it be generating key= s > for? If it were generating keys to be used for the version of OSPF runnin= g > on its production network, then there is a clear bootstrapping path eithe= r > initially or to recover from any bad state: first the OOB network comes u= p, > then the keys are exchanged, then the regular network comes up. If it we= re > generating keys for the version that made the OOB network work, then what > would happen if it got out of sync? > GML> There are two issues here wrt the AKM operation: (1) How the credentials and bootstrapping crypto inputs get on the device, and (2) how peers find each other. GML> For (1) the answer is the same as for how the device will receive inputs in order to be securely managed: the crypto inputs (e.g. for a public key pair used for a self-signed cert, or in an SSH negotiation, or PSK, or whatever) are either generated locally on the device via a console connection at initial device bring up, or manually typed in (could be cut-n-paste) via config lines, or via an uploaded config file. Once these initial config elements are created/entered, then the AKM can be run successfully. GML> for (2) it will completely depend upon the particular routing protocol and the solution we come up with for that routing protocol. However, since the AKM is NOT DESIGNED INTO THE ROUTING PROTOCOL ITSELF, there can be config associated with the AKM's operation which tells the device how to reach a particular routing peer(s). Sometimes this might be "send the message out this interface" sometimes it may be "send it to this IP address= , or that host name"... it will just depend on the specifics and characteristics of the routing protocol being worked on. GML> Does that make sense? GML> Gregory > **** > > ** ** > > Didn=92t you sort of suggest below that if the key management protocol ne= eds > to talk to some external device, then the external device needs to =96 li= ke > the initial method=92s used to bring up the router =96 either be local to= the > router, or run over a separate OOB network? It seems to make sense to add > the option of operating over a separate OOB network to the text that I wa= s > proposing. **** > > ** ** > > In the early days of the Arpanet, there was one =93event=94 where the ent= ire > network crashed, and the operators had to first fix only the router=92s w= hich > were adjacent to the network management station, then fix the ones which > were adjacent to the one=92s already fixed, and recurse in this way throu= gh > the network. I don=92t think that this is a method that we want to recomm= end > as the normal method to recover from major events (it would seem to get > progressively uglier as networks get bigger). **** > > ** ** > > Ross**** > > ** ** > > *From:* Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > *Sent:* Monday, August 15, 2011 10:06 AM > *To:* Ross Callon; Gregory Lebovitz > *Cc:* rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; > russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > > *Subject:* RE: reliance on external systems (req 24), RE: RtgDir review: > draft-ietf-karp-threats-reqs-03**** > > ** ** > > This imo can certainly happen. I used to know at least one big deployment > in Europe that ran OSPF on its out-of-management plane - not sure if they > still do. If we define a new KMP that secures OSPF, then it could certain= ly > run over the OOB ports.**** > > **** > > Cheers, Manav**** > > ** ** > ------------------------------ > > *From:* Ross Callon [mailto:rcallon@juniper.net] > *Sent:* Monday, August 15, 2011 6:48 PM > *To:* Gregory Lebovitz > *Cc:* Bhatia, Manav (Manav); rtg-dir@ietf.org; > draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory > Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > *Subject:* RE: reliance on external systems (req 24), RE: RtgDir review: > draft-ietf-karp-threats-reqs-03**** > > Would a security protocol, for example used for automated key management, > operate over the out of band management plane, or would it operate over t= he > normal data plane, or between two systems directly attached at the link > layer, or in some other way? **** > > ** ** > > Ross**** > > ** ** > > *From:* Gregory Lebovitz [mailto:gregory.ietf@gmail.com] > *Sent:* Saturday, August 13, 2011 3:10 AM > *To:* Ross Callon > *Cc:* Bhatia, Manav (Manav); rtg-dir@ietf.org; > draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory > Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > *Subject:* Re: reliance on external systems (req 24), RE: RtgDir review: > draft-ietf-karp-threats-reqs-03**** > > ** ** > > Hey all.**** > > ** ** > > Ross, the circular dependency issue is not really an issue. I remember yo= u > raising it early on in the KARP formation process, and me explaining the > following, which was taken from the survey of about 7 operators I did bef= ore > I wrote the original text (which later became the drafts to forming KARP)= : > **** > > **** > > When operators bring up new routers, or bring up replaced/fixed routers, > they do so by having a human local to the device rack it, connect it to a > console server, and then send the coordinates to a NOC operator. Said NOC > operator then starts to build up the config on the device. A few static > routes, or a default route, is placed into the device first in order to t= est > basic network connectivity and to setup up secure, inband management. At > this point keys are often created for SSH use. Many other items are > configured on the device that have to do with OAM, and all are tested, > BEFORE dynamic routing is turned on. In other words, the device has to > function well on the network as a healthy host before it becomes a > forwarding agent. Once all this is clear and verified, then routing is > turned on protocol by protocol and confirmed.**** > > ** ** > > The above process was ubiquitously followed by operators. NONE ever relie= d > on routing protocols for management connectivity, not at least at the poi= nt > of boot strapping. Any credentials or validating data that would need to = be > fetched in order to secure the routing protocol would be loaded or fetche= d > BEFORE routing protocols were turned on, using default or static routes, > just as all other config / data is fetched at device bring up.**** > > ** ** > > I recall when I explained this to you at the onset of all this work you > said something to the effect of, "Oh, I get it. That makes me feel much > better. So it's not really an issue then," and we moved on.**** > > ** ** > > Having said all that, I'm not opposed to your NEW proposal below. If > everyone else agrees I would live with it. However, I will point out that= a > healthy use of "SHOULD NOT" would contain a clear explanation of the > circumstance/condition under which it is acceptable to break the guidance= , > and reminder that aside from such circumstance/condition, the guidance ou= ght > be followed. I think both the OLD and NEW text already contained the > explanation of when requiring connections to external systems is acceptab= le: > to require post-initialization synchronization "in order to fully > synchronize the security information." Thus, the SHOULD NOT was ok, becau= se > we stated the condition under which it was reasonable to defy the SHOULD > NOT. Saying "MUST NOT" and then telling them when it's okay to break the > condition really is the same as a "SHOULD NOT", no? Would the following > address your concerns, and also have logic integrity:**** > > ** ** > > NEW II**** > > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing**** > > protocols whereby the operation of the security mechanism would **** > > require a routing protocol -- which we are trying to secure -- to > already**** > > be running in order to properly forward packets. > Therefore, proposed solutions SHOULD NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. The condition > under > which it is acceptable for the proposed solutions to require > connections**** > > to external systems is for post**** > > initialization synchronization with external systems, in order to > fully synchronize the security information. **** > > **** > > I think the above (1) makes your point about circular dependency, (2) mak= es > it clear the only time when the SHOULD NOT would be disobeyed, (3) has > logical integrity. Does it work for all you folks?**** > > ** ** > > Hope it helps,**** > > Gregory**** > > ** ** > > On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon wrote= : > **** > > Regarding requirement number 24, changing "should not" to "must not" does > help a lot. However, it might be worth adding a bit of explanation. How > about: > > OLD > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. > > NEW > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. > > > Does this look okay to you? > > Thanks, Ross > > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; > russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 > > Hi Ross, > > Thanks for the detailed review! > > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note that if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. > > Would it work if we replace SHOULD NOT with a MUST NOT? > > > Section 3, 9th bullet item (about DOS attacks): Routers are occasional > intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet > > [clipped] > > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. > > How about something on these lines: > > New mechanisms must resist DoS attacks described as in-scope in the threa= ts > section 2.1 above. Routers protect the control plane by implementing > mechanisms to filter completely or rate limit traffic not required at the > control plane level (i.e., unwanted traffic). This is done by deep > inspecting the packets and only accepting the legitimate ones. The new > mechanisms shouldn't thus hide or encrypt the information carried in the > control plane packets so that routers can inspect these packets at the li= ne > rate. > > I have taken note of your other comments and those will get fixed in the > next revision. > > Cheers, Manav**** > > > > **** > > ** ** > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks**** > > --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd2dd48750c9404aac19802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable inline...

On Mon, Aug 15, 2011 at 7:31 PM= , Ross Callon <= rcallon@juniper.net> wrote:

But if the key managemen= t protocol was running over the out of band management network, then which = version of OSPF would it be generating keys for? If it were generating keys= to be used for the version of OSPF running on its production network, then= there is a clear bootstrapping path either initially or to recover from an= y bad state: first the OOB network comes up, then the keys are exchanged, t= hen the regular network comes up. =A0If it were generating keys for the ver= sion that made the OOB network work, then what would happen if it got out o= f sync?


GML> There are two issues h= ere wrt the AKM operation: (1) How the credentials and bootstrapping crypto= inputs get on the device, and (2) how peers find each other.=A0

GML> For (1) the answer is the same as for how the device= will receive inputs in order to be securely managed: =A0the crypto inputs = (e.g. for a public key pair used for a self-signed cert, or in an SSH negot= iation, or PSK, or whatever) are either generated locally on the device via= a console connection at initial device bring up, or manually typed in (cou= ld be cut-n-paste) via config lines, or via an uploaded config file. Once t= hese initial config elements are created/entered, then the AKM can be run s= uccessfully.

GML> for (2) it will completely depend upon the part= icular routing protocol and the solution we come up with for that routing p= rotocol. However, since the AKM is NOT DESIGNED INTO THE ROUTING PROTOCOL I= TSELF, there can be config associated with the AKM's operation which te= lls the device how to reach a particular routing peer(s). Sometimes this mi= ght be "send the message out this interface" sometimes it may be = "send it to this IP address, or that host name"... it will just d= epend on the specifics and characteristics of the routing protocol being wo= rked on.=A0

GML> Does that make sense?

= GML> Gregory=A0
=A0

=

=A0

Didn=92t you sort of suggest be= low that if the key management protocol needs to talk to some external devi= ce, then the external device needs to =96 like the initial method=92s used = to bring up the router =96 either be local to the router, or run over a sep= arate OOB network? It seems to make sense to add the option of operating ov= er a separate OOB network to the text that I was proposing. <= /span>

=A0

In the early days of the Arpanet, there was one =93event= =94 where the entire network crashed, and the operators had to first fix on= ly the router=92s which were adjacent to the network management station, th= en fix the ones which were adjacent to the one=92s already fixed, and recur= se in this way through the network. I don=92t think that this is a method t= hat we want to recommend as the normal method to recover from major events = (it would seem to get progressively uglier as networks get bigger). =

=A0

Ross

=A0

Fr= om: Bhatia, Manav (Manav) [mail= to:man= av.bhatia@alcatel-lucent.com]
Sent: Monday, August 15, 2011 10:06 AM
To: Ross Callon; Gr= egory Lebovitz
Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@to= ols.ietf.org; russw@r= iw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com


Subject: RE: reliance on exter= nal systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03=

=A0

This imo can certainly happen. I used t= o know=A0at least one=A0big deployment in Europe that ran OSPF on its out-o= f-management plane - not sure if they still do. If we define a new KMP that= secures OSPF, then it could certainly run over the OOB ports.

=A0

Cheers, Manav

<= blockquote style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0i= n 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bot= tom:5.0pt">

=A0

= From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Monday, August 15, 2011 6:48 PM
To: Gregory Lebovitz=
Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-re= qs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com
Subject: RE: reliance on external systems (req 24), RE: RtgDir revie= w: draft-ietf-karp-threats-reqs-03

Would a security prot= ocol, for example used for automated key management, operate over the out o= f band management plane, or would it operate over the normal data plane, or= between two systems directly attached at the link layer, or in some other = way?

=A0

Ross

=A0

From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com= ]
Sent: Saturday, August 13, 2011 3:10 AM
To: Ross CallonCc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.= all@tools.ietf.org; r= ussw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com
Subject: Re: reliance on external systems (req 24), RE: RtgDir revie= w: draft-ietf-karp-threats-reqs-03

=A0

Hey all.<= u>

=A0

Ross, the circular dependency issue is not really an issue. I remem= ber you raising it early on in the KARP formation process, and me explainin= g the following, which was taken from the survey of about 7 operators I did= before I wrote the original text (which later became the drafts to forming= KARP):

=A0=A0

When operators bring up new routers, or bring up replaced/= fixed routers, they do so by having a human local to the device rack it, co= nnect it to a console server, and then send the coordinates to a NOC operat= or. Said NOC operator then starts to build up the config on the device. A f= ew static routes, or a default route, is placed into the device first in or= der to test basic network connectivity and to setup up secure, inband manag= ement. At this point keys are often created for SSH use. Many other items a= re configured on the device that have to do with OAM, and all are tested, B= EFORE dynamic routing is turned on. In other words, the device has to funct= ion well on the network as a healthy host before it becomes a forwarding ag= ent. Once all this is clear and verified, then routing is turned on protoco= l by protocol and confirmed.

=A0

The above process was ubiquitously followed by operators. NO= NE ever relied on routing protocols for management connectivity, not at lea= st at the point of boot strapping. Any credentials or validating data that = would need to be fetched in order to secure the routing protocol would be l= oaded or fetched BEFORE routing protocols were turned on, using default or = static routes, just as all other config / data is fetched at device bring u= p.

=A0

I recall when I explained this to you at the onset of all th= is work you said something to the effect of, "Oh, I get it. That makes= me feel much better. So it's not really an issue then," and we mo= ved on.

=A0

Having said all that, I'm not opposed to your NEW propos= al below. If everyone else agrees I would live with it. However, I will poi= nt out that a healthy use of "SHOULD NOT" would contain a clear e= xplanation of the circumstance/condition under which it is acceptable to br= eak the guidance, and reminder that aside from such circumstance/condition,= the guidance ought be followed. I think both the OLD and NEW text already = contained the explanation of when requiring connections to external systems= is acceptable: =A0to require post-initialization synchronization "in = order to fully synchronize the security information." Thus, the SHOULD= NOT was ok, because we stated the condition under which it was reasonable = to defy the SHOULD NOT. Saying "MUST NOT" and then telling them w= hen it's okay to break the condition really is the same as a "SHOU= LD NOT", no? Would the following address your concerns, and also have = logic integrity:

=A0

NEW II


24.= =A0The new authentication and security mechanisms should not rely
=A0 = =A0 on systems external to the routing system (the equipment that
=A0 =A0 is performing forwarding). =A0In order to ensure the rapid
=A0 = =A0 initialization and/or return to service of failed nodes it is
=A0 = =A0 important to reduce reliance on these external systems to the
=A0 = =A0 greatest extent possible. Also, it is necessary to avoid a
=A0 =A0 circular dependency between the security mechanisms and routing<= /u>

=A0=A0 =A0protocols=A0whereby the= operation of the security mechanism would=A0

<= p class=3D"MsoNormal"> =A0=A0 =A0require a routing protocol -- which we are trying to secure -- to= already

=A0=A0 =A0be ru= nning in order to properly forward packets.
=A0 =A0 Therefore, proposed = solutions SHOULD NOT require connections to
=A0 =A0 external systems, beyond those directly involved in peering
=A0 = =A0 relationships, in order to return to full service. =A0The condition und= er=A0
=A0=A0 =A0which it is acceptable for the proposed solutions to req= uire connections

=A0=A0 =A0to external systems is for post

=A0 =A0 initialization synchronizat= ion with external systems, in order to
=A0 =A0 fully synchronize the sec= urity information.=A0

=A0

I think the above (1) makes your point about circular dependency, (= 2) makes it clear the only time when the SHOULD NOT would be disobeyed, (3)= has logical integrity. Does it work for all you folks?

=A0

Hope it helps,

Gregory

=A0

On Fri, Aug 12, 2011 at 12= :00 PM, Ross Callon <rcallon@juniper.net> wrote:

Regarding requirement number 24, changing "should not" to "m= ust not" does help a lot. However, it might be worth adding a bit of e= xplanation. How about:

OLD

24. =A0The new authentication and = security mechanisms should not rely
=A0 =A0 on systems external to the routing system (the equipment that is=A0 =A0 performing forwarding). =A0In order to ensure the rapid
=A0 =A0= initialization and/or return to service of failed nodes it is
=A0 =A0 i= mportant to reduce reliance on these external systems to the
=A0 =A0 greatest extent possible. =A0Therefore, proposed solutions SHOULD=A0 =A0 NOT require connections to external systems, beyond those
=A0 = =A0 directly involved in peering relationships, in order to return
=A0 = =A0 to full service. =A0It is however acceptable for the proposed
=A0 =A0 solutions to require post initialization synchronization with
= =A0 =A0 external systems in order to fully synchronize the security
=A0 = =A0 information.

NEW

24. =A0The new authentication and securi= ty mechanisms should not rely
=A0 =A0 on systems external to the routing system (the equipment that
= =A0 =A0 is performing forwarding). =A0In order to ensure the rapid
=A0 = =A0 initialization and/or return to service of failed nodes it is
=A0 = =A0 important to reduce reliance on these external systems to the
=A0 =A0 greatest extent possible. Also, it is necessary to avoid a
=A0 = =A0 circular dependency between the security mechanisms and routing
=A0 = =A0 (which itself is required to deliver IP packets to any external
=A0 = =A0 systems which are not directly connected at the link layer).
=A0 =A0 Therefore, proposed solutions MUST NOT require connections to
= =A0 =A0 external systems, beyond those directly involved in peering
=A0 = =A0 relationships, in order to return to full service. =A0It is
=A0 =A0 = however acceptable for the proposed solutions to require post
=A0 =A0 initialization synchronization with external systems in order to=A0 =A0 fully synchronize the security information.


Does this l= ook okay to you?

Thanks, Ross

-----Original Message-----
F= rom: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc:= rtg-dir@ietf.org= ; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz;= gregory.ietf@g= mail.com
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,=

Thanks for the detailed review!

> This last point has a r= elationship with the requirement currently
> listed as number 24. It = says "Therefore, proposed solutions SHOULD
> NOT require connections to external systems...". However, note th= at if
> the proposed solution is being used to authenticate OSPF or I= S-IS,
> and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any
&g= t; information to or getting any response from a not-directly-attached
&= gt; remote system, then it isn't going to work. In this regard I think<= br> > that the "SHOULD NOT" in requirement 24 is not strong enough= , and
> the potential for deadlock should be explicitly mentioned.
Would it work if we replace SHOULD NOT with a MUST NOT?

> Se= ction 3, 9th bullet item (about DOS attacks): Routers are occasional intend= ed
> victims of DDOS attacks, which may be aimed at the router's contro= l
> plane. As such it is normal for routers to make use of packet
=
[clipped]

> against DDOS. Thus in defining security mechanism= s there should be a
> strong preference for mechanisms that don't hide nor encrypt the> information that the router hardware is able to =A0inspect at full> line rate for DDOS protection (such as IP addresses, and TCP ports).=
> I think that a bit more text along the lines might be appropriate
&= gt; to be added to this bullet item.

How about something on these li= nes:

New mechanisms must resist DoS attacks described as in-scope in= the threats section 2.1 above. Routers protect the control plane by implem= enting mechanisms to filter completely or rate limit traffic not required a= t the control plane level (i.e., unwanted traffic). =A0This is done by deep= inspecting the packets and only accepting the legitimate ones. The new mec= hanisms shouldn't thus hide or encrypt the information carried in the c= ontrol plane packets so that routers can inspect these packets at the line = rate.

I have taken note of your other comments and those will get fixed in th= e next revision.

Cheers, Manav



=A0

--
----
IETF relat= ed email from
Gregory M. Lebovitz
Juniper Networks

<= /div>



--
----
IETF related email from=
Gregory M. Lebovitz
Juniper Networks
--000e0cd2dd48750c9404aac19802-- From bew@cisco.com Thu Aug 18 10:04:07 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BD721F8B42 for ; Thu, 18 Aug 2011 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o41a7zxyCPr for ; Thu, 18 Aug 2011 10:04:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0124021F8B33 for ; Thu, 18 Aug 2011 10:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=22959; q=dns/txt; s=iport; t=1313687100; x=1314896700; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=cyiEytOCBCch9ZB0LpgtebC1jEfSefvQI+oTo1oUH2I=; b=ZoB2PXJWcAuQu3/IrKzm1yXOUmdG7HAQQqT2wK26Eea3RgQTOy6qK3F4 XPeKhh+8693mD9F+5FQYn8ObpCvNdL9ZLmXaXGYgYGR4dKAZG7n9SSgbQ K55mBv2sUuKCyu9YxP91rqG+RhHIsWV0EDA0znq/6CWrGLA0OabWHL2Fy A=; X-IronPort-AV: E=Sophos;i="4.68,246,1312156800"; d="scan'208,217";a="14397492" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 18 Aug 2011 17:04:59 +0000 Received: from stealth-10-32-244-212.cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7IH4wt6014479; Thu, 18 Aug 2011 17:04:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-66-372449151 From: Brian Weis In-Reply-To: Date: Thu, 18 Aug 2011 10:04:58 -0700 Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Gregory Lebovitz X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 18 Aug 2011 10:15:55 -0700 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "russw@riw.us" , "adrian@olddog.co.uk" , Ross Callon , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:04:07 -0000 --Apple-Mail-66-372449151 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I prefer the SHOULD NOT wording. Recall that multicast routing protocols = (e.g., PIM) are independent from unicast routing, and as such security = system mechanism for multicast routing protocols can rely on systems = external to the routing system without worrying about a circular = dependancy. Thanks, Brian On Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote: > Hey all. >=20 > Ross, the circular dependency issue is not really an issue. I remember = you raising it early on in the KARP formation process, and me explaining = the following, which was taken from the survey of about 7 operators I = did before I wrote the original text (which later became the drafts to = forming KARP): > =20 > When operators bring up new routers, or bring up replaced/fixed = routers, they do so by having a human local to the device rack it, = connect it to a console server, and then send the coordinates to a NOC = operator. Said NOC operator then starts to build up the config on the = device. A few static routes, or a default route, is placed into the = device first in order to test basic network connectivity and to setup up = secure, inband management. At this point keys are often created for SSH = use. Many other items are configured on the device that have to do with = OAM, and all are tested, BEFORE dynamic routing is turned on. In other = words, the device has to function well on the network as a healthy host = before it becomes a forwarding agent. Once all this is clear and = verified, then routing is turned on protocol by protocol and confirmed. >=20 > The above process was ubiquitously followed by operators. NONE ever = relied on routing protocols for management connectivity, not at least at = the point of boot strapping. Any credentials or validating data that = would need to be fetched in order to secure the routing protocol would = be loaded or fetched BEFORE routing protocols were turned on, using = default or static routes, just as all other config / data is fetched at = device bring up. >=20 > I recall when I explained this to you at the onset of all this work = you said something to the effect of, "Oh, I get it. That makes me feel = much better. So it's not really an issue then," and we moved on. >=20 > Having said all that, I'm not opposed to your NEW proposal below. If = everyone else agrees I would live with it. However, I will point out = that a healthy use of "SHOULD NOT" would contain a clear explanation of = the circumstance/condition under which it is acceptable to break the = guidance, and reminder that aside from such circumstance/condition, the = guidance ought be followed. I think both the OLD and NEW text already = contained the explanation of when requiring connections to external = systems is acceptable: to require post-initialization synchronization = "in order to fully synchronize the security information." Thus, the = SHOULD NOT was ok, because we stated the condition under which it was = reasonable to defy the SHOULD NOT. Saying "MUST NOT" and then telling = them when it's okay to break the condition really is the same as a = "SHOULD NOT", no? Would the following address your concerns, and also = have logic integrity: >=20 > NEW II >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > protocols whereby the operation of the security mechanism would=20 > require a routing protocol -- which we are trying to secure -- to = already > be running in order to properly forward packets. > Therefore, proposed solutions SHOULD NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. The condition = under=20 > which it is acceptable for the proposed solutions to require = connections > to external systems is for post > initialization synchronization with external systems, in order to > fully synchronize the security information.=20 > =20 > I think the above (1) makes your point about circular dependency, (2) = makes it clear the only time when the SHOULD NOT would be disobeyed, (3) = has logical integrity. Does it work for all you folks? >=20 > Hope it helps, > Gregory >=20 >=20 > On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon = wrote: > Regarding requirement number 24, changing "should not" to "must not" = does help a lot. However, it might be worth adding a bit of explanation. = How about: >=20 > OLD >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. >=20 > NEW >=20 > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. >=20 >=20 > Does this look okay to you? >=20 > Thanks, Ross >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; = russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 >=20 > Hi Ross, >=20 > Thanks for the detailed review! >=20 > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note that = if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. >=20 > Would it work if we replace SHOULD NOT with a MUST NOT? >=20 > > Section 3, 9th bullet item (about DOS attacks): Routers are = occasional intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet >=20 > [clipped] >=20 > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. >=20 > How about something on these lines: >=20 > New mechanisms must resist DoS attacks described as in-scope in the = threats section 2.1 above. Routers protect the control plane by = implementing mechanisms to filter completely or rate limit traffic not = required at the control plane level (i.e., unwanted traffic). This is = done by deep inspecting the packets and only accepting the legitimate = ones. The new mechanisms shouldn't thus hide or encrypt the information = carried in the control plane packets so that routers can inspect these = packets at the line rate. >=20 > I have taken note of your other comments and those will get fixed in = the next revision. >=20 > Cheers, Manav >=20 >=20 >=20 >=20 > --=20 > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail-66-372449151 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hey all.

Ross, = the circular dependency issue is not really an issue. I remember you = raising it early on in the KARP formation process, and me explaining the = following, which was taken from the survey of about 7 operators I did = before I wrote the original text (which later became the drafts to = forming KARP):
  
When operators bring up new routers, or = bring up replaced/fixed routers, they do so by having a human local to = the device rack it, connect it to a console server, and then send the = coordinates to a NOC operator. Said NOC operator then starts to build up = the config on the device. A few static routes, or a default route, is = placed into the device first in order to test basic network connectivity = and to setup up secure, inband management. At this point keys are often = created for SSH use. Many other items are configured on the device that = have to do with OAM, and all are tested, BEFORE dynamic routing is = turned on. In other words, the device has to function well on the = network as a healthy host before it becomes a forwarding agent. Once all = this is clear and verified, then routing is turned on protocol by = protocol and confirmed.

The above process was ubiquitously followed by = operators. NONE ever relied on routing protocols for management = connectivity, not at least at the point of boot strapping. Any = credentials or validating data that would need to be fetched in order to = secure the routing protocol would be loaded or fetched BEFORE routing = protocols were turned on, using default or static routes, just as all = other config / data is fetched at device bring up.

I recall when I explained this to you at the onset = of all this work you said something to the effect of, "Oh, I get it. = That makes me feel much better. So it's not really an issue then," and = we moved on.

Having said all that, I'm not opposed to your NEW = proposal below. If everyone else agrees I would live with it. However, I = will point out that a healthy use of "SHOULD NOT" would contain a clear = explanation of the circumstance/condition under which it is acceptable = to break the guidance, and reminder that aside from such = circumstance/condition, the guidance ought be followed. I think both the = OLD and NEW text already contained the explanation of when requiring = connections to external systems is acceptable:  to require = post-initialization synchronization "in order to fully synchronize the = security information." Thus, the SHOULD NOT was ok, because we stated = the condition under which it was reasonable to defy the SHOULD NOT. = Saying "MUST NOT" and then telling them when it's okay to break the = condition really is the same as a "SHOULD NOT", no? Would the following = address your concerns, and also have logic integrity:

NEW II

24.  The new authentication and = security mechanisms should not rely
    on systems external = to the routing system (the equipment that
    is performing = forwarding).  In order to ensure the rapid
    initialization and/or return to service of failed nodes it = is
    important to reduce reliance on these external = systems to the
    greatest extent possible. Also, it is = necessary to avoid a
    circular dependency between the = security mechanisms and routing
    protocols whereby the operation of the security = mechanism would 
    require a routing = protocol -- which we are trying to secure -- to = already
    be running in order to properly = forward packets.
    Therefore, proposed solutions SHOULD NOT require = connections to
    external systems, beyond those directly = involved in peering
    relationships, in order to return = to full service.  The condition under 
   =  which it is acceptable for the proposed solutions to require = connections
    to external systems is for post
    = initialization synchronization with external systems, in order = to
    fully synchronize the security = information. 
 
I think the above (1) makes = your point about circular dependency, (2) makes it clear the only time = when the SHOULD NOT would be disobeyed, (3) has logical integrity. Does = it work for all you folks?

Hope it = helps,
Gregory


On = Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net> = wrote:
Regarding requirement number 24, changing "should not" to "must = not" does help a lot. However, it might be worth adding a bit of = explanation. How about:

OLD

24.  The new authentication and security mechanisms should not = rely
    on systems external to the routing system (the equipment = that is
    performing forwarding).  In order to ensure the = rapid
    initialization and/or return to service of failed nodes = it is
    important to reduce reliance on these external systems to = the
    greatest extent possible.  Therefore, proposed = solutions SHOULD
    NOT require connections to external systems, beyond = those
    directly involved in peering relationships, in order to = return
    to full service.  It is however acceptable for the = proposed
    solutions to require post initialization synchronization = with
    external systems in order to fully synchronize the = security
    information.

NEW

24.  The new authentication and security mechanisms should not = rely
    on systems external to the routing system (the equipment = that
    is performing forwarding).  In order to ensure the = rapid
    initialization and/or return to service of failed nodes = it is
    important to reduce reliance on these external systems to = the
    greatest extent possible. Also, it is necessary to avoid = a
    circular dependency between the security mechanisms and = routing
    (which itself is required to deliver IP packets to any = external
    systems which are not directly connected at the link = layer).
    Therefore, proposed solutions MUST NOT require = connections to
    external systems, beyond those directly involved in = peering
    relationships, in order to return to full service. =  It is
    however acceptable for the proposed solutions to require = post
    initialization synchronization with external systems in = order to
    fully synchronize the security information.


Does this look okay to you?

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucen= t.com]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc: rtg-dir@ietf.org; draft-ietf= -karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

Thanks for the detailed review!

> This last point has a relationship with the requirement = currently
> listed as number 24. It says "Therefore, proposed solutions = SHOULD
> NOT require connections to external systems...". However, note that = if
> the proposed solution is being used to authenticate OSPF or = IS-IS,
> and if OSPF or IS-IS will not bring up links until they are
> authenticated, and if the proposed solution requires sending = any
> information to or getting any response from a = not-directly-attached
> remote system, then it isn't going to work. In this regard I = think
> that the "SHOULD NOT" in requirement 24 is not strong enough, = and
> the potential for deadlock should be explicitly mentioned.

Would it work if we replace SHOULD NOT with a MUST NOT?

> Section 3, 9th bullet item (about DOS attacks): Routers are = occasional intended
> victims of DDOS attacks, which may be aimed at the router's = control
> plane. As such it is normal for routers to make use of packet

[clipped]

> against DDOS. Thus in defining security mechanisms there should be = a
> strong preference for mechanisms that don't hide nor encrypt = the
> information that the router hardware is able to  inspect at = full
> line rate for DDOS protection (such as IP addresses, and TCP = ports).
> I think that a bit more text along the lines might be = appropriate
> to be added to this bullet item.

How about something on these lines:

New mechanisms must resist DoS attacks described as in-scope in the = threats section 2.1 above. Routers protect the control plane by = implementing mechanisms to filter completely or rate limit traffic not = required at the control plane level (i.e., unwanted traffic).  This = is done by deep inspecting the packets and only accepting the legitimate = ones. The new mechanisms shouldn't thus hide or encrypt the information = carried in the control plane packets so that routers can inspect these = packets at the line rate.

I have taken note of your other comments and those will get fixed in the = next revision.

Cheers, Manav




-- =
----
IETF related email from
Gregory M. Lebovitz
Juniper = Networks

bew@cisco.com





= --Apple-Mail-66-372449151-- From rcallon@juniper.net Thu Aug 18 11:30:50 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7C11E80A7 for ; Thu, 18 Aug 2011 11:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RJFg-w8nH6H for ; Thu, 18 Aug 2011 11:30:43 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 710F811E8093 for ; Thu, 18 Aug 2011 11:30:42 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTk1af0WTqxAO9BbTt5HeXiBUv0i5w3U4@postini.com; Thu, 18 Aug 2011 11:31:38 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 18 Aug 2011 11:15:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 18 Aug 2011 14:15:37 -0400 From: Ross Callon To: Brian Weis , Gregory Lebovitz Date: Thu, 18 Aug 2011 14:15:35 -0400 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxdyPlQnYLuKWPZTQGDNkzfH+exoAABqWoQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.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: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C348A35D6CEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:30:50 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C348A35D6CEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am coming to the conclusion that we want some combination of a SHOULD NOT= , as well as a note that if the security protocols that are used to secure = routing depends upon connecting to systems that are not direct neighbors of= the routers, then there MUST be one or more options to ensure against circ= ular dependencies. Thus three examples of a way to ensure against circular dependencies might = be (i) using a separate network so that the security protocols run out of b= and from the normal routing protocols, (ii) using unicast routing to allow = exchange of security protocols in order to pass information needed to boots= trap multicast routing; (iii) Using routing internal to a routing domain (t= he IGP, either OSPF or IS-IS) to allow communication within that domain, in= order to pass information used to operate BGP. The current ("old") text is: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. We might for example add to this an additional new paragraph: NEW (add to the above): If authentication and security mechanisms rely on systems external to t= he routing system, then there MUST be one or more options available to avoid circu= lar dependencies. For example, it is not acceptable to have the operation o= f OSPF within a routing domain depend upon correct operation of a security pro= tocol, have correct operation of the security protocol depend upon the ability= to exchange IP packets between remote systems, and have the ability to exc= hange IP packets between remote systems depend upon correct operation of the = same instance of OSPF within the same routing domain. However, it is okay to= have operation of multicast routing and/or interdomain routing depend upon o= peration of a security protocol, which depends upon exchange of IP packets betwe= en remote systems, which depends upon the correct operation of OSPF for un= icast routing. Similarly it would be okay to have the operation of OSPF depen= d upon a security protocol, which in turn uses an out of band network to excha= nge information with remote systems. Ross From: Brian Weis [mailto:bew@cisco.com] Sent: Thursday, August 18, 2011 1:05 PM To: Gregory Lebovitz Cc: Ross Callon; Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-t= hreats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@oldd= og.co.uk; stbryant@cisco.com Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 All, I prefer the SHOULD NOT wording. Recall that multicast routing protocols (e= .g., PIM) are independent from unicast routing, and as such security system= mechanism for multicast routing protocols can rely on systems external to = the routing system without worrying about a circular dependancy. Thanks, Brian On Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote: Hey all. Ross, the circular dependency issue is not really an issue. I remember you = raising it early on in the KARP formation process, and me explaining the fo= llowing, which was taken from the survey of about 7 operators I did before = I wrote the original text (which later became the drafts to forming KARP): When operators bring up new routers, or bring up replaced/fixed routers, th= ey do so by having a human local to the device rack it, connect it to a con= sole server, and then send the coordinates to a NOC operator. Said NOC oper= ator then starts to build up the config on the device. A few static routes,= or a default route, is placed into the device first in order to test basic= network connectivity and to setup up secure, inband management. At this po= int keys are often created for SSH use. Many other items are configured on = the device that have to do with OAM, and all are tested, BEFORE dynamic rou= ting is turned on. In other words, the device has to function well on the n= etwork as a healthy host before it becomes a forwarding agent. Once all thi= s is clear and verified, then routing is turned on protocol by protocol and= confirmed. The above process was ubiquitously followed by operators. NONE ever relied = on routing protocols for management connectivity, not at least at the point= of boot strapping. Any credentials or validating data that would need to b= e fetched in order to secure the routing protocol would be loaded or fetche= d BEFORE routing protocols were turned on, using default or static routes, = just as all other config / data is fetched at device bring up. I recall when I explained this to you at the onset of all this work you sai= d something to the effect of, "Oh, I get it. That makes me feel much better= . So it's not really an issue then," and we moved on. Having said all that, I'm not opposed to your NEW proposal below. If everyo= ne else agrees I would live with it. However, I will point out that a healt= hy use of "SHOULD NOT" would contain a clear explanation of the circumstanc= e/condition under which it is acceptable to break the guidance, and reminde= r that aside from such circumstance/condition, the guidance ought be follow= ed. I think both the OLD and NEW text already contained the explanation of = when requiring connections to external systems is acceptable: to require p= ost-initialization synchronization "in order to fully synchronize the secur= ity information." Thus, the SHOULD NOT was ok, because we stated the condit= ion under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT"= and then telling them when it's okay to break the condition really is the = same as a "SHOULD NOT", no? Would the following address your concerns, and = also have logic integrity: NEW II 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing protocols whereby the operation of the security mechanism would require a routing protocol -- which we are trying to secure -- to alrea= dy be running in order to properly forward packets. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. The condition under which it is acceptable for the proposed solutions to require connection= s to external systems is for post initialization synchronization with external systems, in order to fully synchronize the security information. I think the above (1) makes your point about circular dependency, (2) makes= it clear the only time when the SHOULD NOT would be disobeyed, (3) has log= ical integrity. Does it work for all you folks? Hope it helps, Gregory On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: Regarding requirement number 24, changing "should not" to "must not" does h= elp a lot. However, it might be worth adding a bit of explanation. How abou= t: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. NEW 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing (which itself is required to deliver IP packets to any external systems which are not directly connected at the link layer). Therefore, proposed solutions MUST NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. Does this look okay to you? Thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@= cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs= .all@tools.ietf.org= ; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.c= om Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, Thanks for the detailed review! > This last point has a relationship with the requirement currently > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if > the proposed solution is being used to authenticate OSPF or IS-IS, > and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended > victims of DDOS attacks, which may be aimed at the router's control > plane. As such it is normal for routers to make use of packet [clipped] > against DDOS. Thus in defining security mechanisms there should be a > strong preference for mechanisms that don't hide nor encrypt the > information that the router hardware is able to inspect at full > line rate for DDOS protection (such as IP addresses, and TCP ports). > I think that a bit more text along the lines might be appropriate > to be added to this bullet item. How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks -- Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --_000_DF7F294AF4153D498141CBEFADB17704C348A35D6CEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am coming to the conclusion that we want some combination of a= SHOULD NOT, as well as a note that if the security protocols that are used= to secure routing depends upon connecting to systems that are not direct n= eighbors of the routers, then there MUST be one or more options to ensure a= gainst circular dependencies.

 

Thus three exa= mples of a way to ensure against circular dependencies might be (i) using a= separate network so that the security protocols run out of band from the n= ormal routing protocols, (ii) using unicast routing to allow exchange of se= curity protocols in order to pass information needed to bootstrap multicast= routing; (iii) Using routing internal to a routing domain (the IGP, either= OSPF or IS-IS) to allow communication within that domain, in order to pass= information used to operate BGP.

 

The curren= t (“old”) text is:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

OLD

 

24.  The new authentication and security mechanis= ms should not rely

 &= nbsp;  on systems external to the routing system (the equipment that i= s

    perfo= rming forwarding).  In order to ensure the rapid

=

    initialization and/or return= to service of failed nodes it is

    important to reduce reliance on these external s= ystems to the

  =   greatest extent possible.  Therefore, proposed solutions SHOULD=

    NOT re= quire connections to external systems, beyond those

    directly involved in peering r= elationships, in order to return

=     to full service.  It is however acceptable f= or the proposed

 &nbs= p;  solutions to require post initialization synchronization with=

    external sy= stems in order to fully synchronize the security

    information.

 

We might for example add to this an additional new paragraph:

 

=

NEW (add to the above):

<= p class=3DMsoNormal> 

    If authentication and security mechanisms rely o= n systems external to the routing

    system, then there MUST be one or more options a= vailable to avoid circular

    dependencies. For example, it is not acceptable t= o have the operation of OSPF

    within a routing domain depend upon correct operation= of a security protocol,

&= nbsp;   have correct operation of the security protocol depend up= on the ability to

 &= nbsp;  exchange IP packets between remote systems, and have the a= bility to exchange

 &= nbsp;  IP packets between remote systems depend upon correct operation= of the same

  &= nbsp; instance of OSPF within the same routing domain. However, it is okay = to have

   = ; operation of multicast routing and/or interdomain routing depend upo= n operation

   &= nbsp;of a security protocol, which depends upon exchange of IP packets betw= een

   &nb= sp;remote systems, which depends upon the correct operation of OSPF for uni= cast

   &n= bsp;routing. Similarly it would be okay to have the operation of OSPF depen= d upon

   =  a security protocol, which in turn uses an out of band network to exc= hange

    i= nformation with remote systems.

=  

Ross

 

=

From: Brian Weis [mailto:bew@cisco.com]
= Sent: Thursday, August 18, 2011 1:05 PM
To: Gregory Lebovitz<= br>Cc: Ross Callon; Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-i= etf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; a= drian@olddog.co.uk; stbryant@cisco.com
Subject: Re: reliance on e= xternal systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-0= 3

 

All,

&n= bsp;

I prefer the SHOULD NOT wordi= ng. Recall that multicast routing protocols (e.g., PIM) are independent fro= m unicast routing, and as such security system mechanism for multicast rout= ing protocols can rely on systems external to the routing system witho= ut worrying about a circular dependancy.

 

Thanks,

Brian

 

O= n Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote:

Hey all.

 

Ross, the circular dependency issue is not re= ally an issue. I remember you raising it early on in the KARP formation pro= cess, and me explaining the following, which was taken from the survey of a= bout 7 operators I did before I wrote the original text (which later became= the drafts to forming KARP):

  

When operators = bring up new routers, or bring up replaced/fixed routers, they do so by hav= ing a human local to the device rack it, connect it to a console server, an= d then send the coordinates to a NOC operator. Said NOC operator then start= s to build up the config on the device. A few static routes, or a default r= oute, is placed into the device first in order to test basic network connec= tivity and to setup up secure, inband management. At this point keys are of= ten created for SSH use. Many other items are configured on the device that= have to do with OAM, and all are tested, BEFORE dynamic routing is turned = on. In other words, the device has to function well on the network as a hea= lthy host before it becomes a forwarding agent. Once all this is clear and = verified, then routing is turned on protocol by protocol and confirmed.

 

=

The above process was ubiquitously followed by operato= rs. NONE ever relied on routing protocols for management connectivity, not = at least at the point of boot strapping. Any credentials or validating data= that would need to be fetched in order to secure the routing protocol woul= d be loaded or fetched BEFORE routing protocols were turned on, using defau= lt or static routes, just as all other config / data is fetched at device b= ring up.

 

I recall when I explained this to you at t= he onset of all this work you said something to the effect of, "Oh, I = get it. That makes me feel much better. So it's not really an issue then,&q= uot; and we moved on.

&n= bsp;

Having said all that, I'm not= opposed to your NEW proposal below. If everyone else agrees I would live w= ith it. However, I will point out that a healthy use of "SHOULD NOT&qu= ot; would contain a clear explanation of the circumstance/condition under w= hich it is acceptable to break the guidance, and reminder that aside from s= uch circumstance/condition, the guidance ought be followed. I think both th= e OLD and NEW text already contained the explanation of when requiring conn= ections to external systems is acceptable:  to require post-initializa= tion synchronization "in order to fully synchronize the security infor= mation." Thus, the SHOULD NOT was ok, because we stated the condition = under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT= " and then telling them when it's okay to break the condition really i= s the same as a "SHOULD NOT", no? Would the following address you= r concerns, and also have logic integrity:

 

NEW II


24.  The new authenticatio= n and security mechanisms should not rely
    on systems exter= nal to the routing system (the equipment that
    is performin= g forwarding).  In order to ensure the rapid
    initiali= zation and/or return to service of failed nodes it is
    impo= rtant to reduce reliance on these external systems to the
    = greatest extent possible. Also, it is necessary to avoid a
   = circular dependency between the security mechanisms and routing=

    protocols whereby the= operation of the security mechanism would 

<= p class=3DMsoNormal>    require a routing protocol -- which = we are trying to secure -- to already

    be running in order to properly forward packets= .
    Therefore, proposed solutions SHOULD NOT require connect= ions to
    external systems, beyond those directly involved i= n peering
    relationships, in order to return to full servic= e.  The condition under 
    which it is accept= able for the proposed solutions to require connections

<= p class=3DMsoNormal>    to external systems is for post=

    initialization synchroniz= ation with external systems, in order to
    fully synchronize= the security information. 

&n= bsp;

I think the above (1) ma= kes your point about circular dependency, (2) makes it clear the only time = when the SHOULD NOT would be disobeyed, (3) has logical integrity. Does it = work for all you folks?

=  

Hope it helps,

Gregory

 

On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net> wrote:

<= o:p>

Regarding= requirement number 24, changing "should not" to "must not&q= uot; does help a lot. However, it might be worth adding a bit of explanatio= n. How about:

OLD

24.  The new authentication and securi= ty mechanisms should not rely
    on systems external to the r= outing system (the equipment that is
    performing forwarding= ).  In order to ensure the rapid
    initialization and/o= r return to service of failed nodes it is
    important to red= uce reliance on these external systems to the
    greatest ext= ent possible.  Therefore, proposed solutions SHOULD
    N= OT require connections to external systems, beyond those
    d= irectly involved in peering relationships, in order to return
  &nb= sp; to full service.  It is however acceptable for the proposed
&nb= sp;   solutions to require post initialization synchronization with    external systems in order to fully synchronize the security<= br>    information.

NEW

24.  The new authentic= ation and security mechanisms should not rely
    on systems e= xternal to the routing system (the equipment that
    is perfo= rming forwarding).  In order to ensure the rapid
    init= ialization and/or return to service of failed nodes it is
    = important to reduce reliance on these external systems to the
  &nb= sp; greatest extent possible. Also, it is necessary to avoid a
  &n= bsp; circular dependency between the security mechanisms and routing
&nb= sp;   (which itself is required to deliver IP packets to any external<= br>    systems which are not directly connected at the link layer= ).
    Therefore, proposed solutions MUST NOT require connecti= ons to
    external systems, beyond those directly involved in= peering
    relationships, in order to return to full service= .  It is
    however acceptable for the proposed solution= s to require post
    initialization synchronization with exte= rnal systems in order to
    fully synchronize the security in= formation.


Does this look okay to you?

Thanks, Ross
-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com= ]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subject= : RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,
Thanks for the detailed review!

> This last point has a relation= ship with the requirement currently
> listed as number 24. It says &q= uot;Therefore, proposed solutions SHOULD
> NOT require connections to= external systems...". However, note that if
> the proposed solu= tion is being used to authenticate OSPF or IS-IS,
> and if OSPF or IS= -IS will not bring up links until they are
> authenticated, and if th= e proposed solution requires sending any
> information to or getting = any response from a not-directly-attached
> remote system, then it is= n't going to work. In this regard I think
> that the "SHOULD NOT= " in requirement 24 is not strong enough, and
> the potential fo= r deadlock should be explicitly mentioned.

Would it work if we repla= ce SHOULD NOT with a MUST NOT?

> Section 3, 9th bullet item (abou= t DOS attacks): Routers are occasional intended
> victims of DDOS att= acks, which may be aimed at the router's control
> plane. As such it = is normal for routers to make use of packet

[clipped]

> ag= ainst DDOS. Thus in defining security mechanisms there should be a
> = strong preference for mechanisms that don't hide nor encrypt the
> in= formation that the router hardware is able to  inspect at full
>= line rate for DDOS protection (such as IP addresses, and TCP ports).
&g= t; I think that a bit more text along the lines might be appropriate
>= ; to be added to this bullet item.

How about something on these line= s:

New mechanisms must resist DoS attacks described as in-scope in t= he threats section 2.1 above. Routers protect the control plane by implemen= ting mechanisms to filter completely or rate limit traffic not required at = the control plane level (i.e., unwanted traffic).  This is done by dee= p inspecting the packets and only accepting the legitimate ones. The new me= chanisms shouldn't thus hide or encrypt the information carried in the cont= rol plane packets so that routers can inspect these packets at the line rat= e.

I have taken note of your other comments and those will get fixed= in the next revision.

Cheers, Manav



 

--
----
IETF related ema= il from
Gregory M. Lebovitz
Juniper Networks

 

=


-- 
Brian Weis
Security Standards and Technology, SRT= G, Cisco Systems
Telephone: +1 408= 526 4796
Email: bew@cisco.com

 

 

 

 

= --_000_DF7F294AF4153D498141CBEFADB17704C348A35D6CEMBX01WFjnprn_-- From russw@riw.us Sun Aug 21 12:11:45 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A1E21F86B6 for ; Sun, 21 Aug 2011 12:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=2.028, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5PeGWdU7Cft for ; Sun, 21 Aug 2011 12:11:43 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD121F86AB for ; Sun, 21 Aug 2011 12:11:41 -0700 (PDT) Received: from cpe-066-057-007-246.nc.res.rr.com ([66.57.7.246] helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QvDRi-0007UE-FV; Sun, 21 Aug 2011 15:12:34 -0400 Message-ID: <4E51589E.1050808@riw.us> Date: Sun, 21 Aug 2011 15:12:30 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Gregory Lebovitz References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "rtg-dir@ietf.org" , Brian Weis , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , Ross Callon , "adrian@olddog.co.uk" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:11:46 -0000 > Ok by me. We are using a SHOULD NOT, and explaining why it's a SHOULD > NOT by describing a case or two where it is needed. This, IMHO, is the > right way to use as SHOULD NOT. Thanks for the good team work. I'm fine with this, as well. :-) Russ From rcallon@juniper.net Sun Aug 21 17:39:37 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39D21F8745 for ; Sun, 21 Aug 2011 17:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeV7JV722LHH for ; Sun, 21 Aug 2011 17:39:29 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9721F8751 for ; Sun, 21 Aug 2011 17:39:27 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTlGldVKDt874dGNoV9X/V+HOGL9P0iwd@postini.com; Sun, 21 Aug 2011 17:40:32 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 21 Aug 2011 17:39:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 21 Aug 2011 20:39:32 -0400 From: Ross Callon To: Gregory Lebovitz Date: Sun, 21 Aug 2011 20:39:31 -0400 Thread-Topic: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Thread-Index: AcxdbsxQMF/m8wN0QiqxvsyPPPTldgCv315A Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF8E2F8F@INBANSXCHMBSA1.in.alcatel-lucent.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: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C349142784EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , Ross Callon , "adrian@olddog.co.uk" , "russw@riw.us" , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 00:39:37 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C349142784EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg; I think that the first issue we need to deal with is what text to put into = the requirements document. It is not obvious to me how to reduce your disc= ussion of possible solutions into text for the requirements. thanks, Ross From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Thursday, August 18, 2011 2:20 AM To: Ross Callon Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.a= ll@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stb= ryant@cisco.com Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 inline... On Mon, Aug 15, 2011 at 7:31 PM, Ross Callon > wrote: But if the key management protocol was running over the out of band managem= ent network, then which version of OSPF would it be generating keys for? If= it were generating keys to be used for the version of OSPF running on its = production network, then there is a clear bootstrapping path either initial= ly or to recover from any bad state: first the OOB network comes up, then t= he keys are exchanged, then the regular network comes up. If it were gener= ating keys for the version that made the OOB network work, then what would = happen if it got out of sync? GML> There are two issues here wrt the AKM operation: (1) How the credentia= ls and bootstrapping crypto inputs get on the device, and (2) how peers fin= d each other. GML> For (1) the answer is the same as for how the device will receive inpu= ts in order to be securely managed: the crypto inputs (e.g. for a public k= ey pair used for a self-signed cert, or in an SSH negotiation, or PSK, or w= hatever) are either generated locally on the device via a console connectio= n at initial device bring up, or manually typed in (could be cut-n-paste) v= ia config lines, or via an uploaded config file. Once these initial config = elements are created/entered, then the AKM can be run successfully. GML> for (2) it will completely depend upon the particular routing protocol= and the solution we come up with for that routing protocol. However, since= the AKM is NOT DESIGNED INTO THE ROUTING PROTOCOL ITSELF, there can be con= fig associated with the AKM's operation which tells the device how to reach= a particular routing peer(s). Sometimes this might be "send the message ou= t this interface" sometimes it may be "send it to this IP address, or that = host name"... it will just depend on the specifics and characteristics of t= he routing protocol being worked on. GML> Does that make sense? GML> Gregory Didn't you sort of suggest below that if the key management protocol needs = to talk to some external device, then the external device needs to - like t= he initial method's used to bring up the router - either be local to the ro= uter, or run over a separate OOB network? It seems to make sense to add the= option of operating over a separate OOB network to the text that I was pro= posing. In the early days of the Arpanet, there was one "event" where the entire ne= twork crashed, and the operators had to first fix only the router's which w= ere adjacent to the network management station, then fix the ones which wer= e adjacent to the one's already fixed, and recurse in this way through the = network. I don't think that this is a method that we want to recommend as t= he normal method to recover from major events (it would seem to get progres= sively uglier as networks get bigger). Ross From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Monday, August 15, 2011 10:06 AM To: Ross Callon; Gregory Lebovitz Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs= .all@tools.ietf.org= ; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk<= mailto:adrian@olddog.co.uk>; stbryant@cisco.com Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 This imo can certainly happen. I used to know at least one big deployment i= n Europe that ran OSPF on its out-of-management plane - not sure if they st= ill do. If we define a new KMP that secures OSPF, then it could certainly r= un over the OOB ports. Cheers, Manav ________________________________ From: Ross Callon [mailto:rcallon@juniper.net] Sent: Monday, August 15, 2011 6:48 PM To: Gregory Lebovitz Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft= -ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovit= z; adrian@olddog.co.uk; stbryant@cisco.com Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Would a security protocol, for example used for automated key management, o= perate over the out of band management plane, or would it operate over the = normal data plane, or between two systems directly attached at the link lay= er, or in some other way? Ross From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Saturday, August 13, 2011 3:10 AM To: Ross Callon Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft= -ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovit= z; adrian@olddog.co.uk; stbryant@cisco.com Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draf= t-ietf-karp-threats-reqs-03 Hey all. Ross, the circular dependency issue is not really an issue. I remember you = raising it early on in the KARP formation process, and me explaining the fo= llowing, which was taken from the survey of about 7 operators I did before = I wrote the original text (which later became the drafts to forming KARP): When operators bring up new routers, or bring up replaced/fixed routers, th= ey do so by having a human local to the device rack it, connect it to a con= sole server, and then send the coordinates to a NOC operator. Said NOC oper= ator then starts to build up the config on the device. A few static routes,= or a default route, is placed into the device first in order to test basic= network connectivity and to setup up secure, inband management. At this po= int keys are often created for SSH use. Many other items are configured on = the device that have to do with OAM, and all are tested, BEFORE dynamic rou= ting is turned on. In other words, the device has to function well on the n= etwork as a healthy host before it becomes a forwarding agent. Once all thi= s is clear and verified, then routing is turned on protocol by protocol and= confirmed. The above process was ubiquitously followed by operators. NONE ever relied = on routing protocols for management connectivity, not at least at the point= of boot strapping. Any credentials or validating data that would need to b= e fetched in order to secure the routing protocol would be loaded or fetche= d BEFORE routing protocols were turned on, using default or static routes, = just as all other config / data is fetched at device bring up. I recall when I explained this to you at the onset of all this work you sai= d something to the effect of, "Oh, I get it. That makes me feel much better= . So it's not really an issue then," and we moved on. Having said all that, I'm not opposed to your NEW proposal below. If everyo= ne else agrees I would live with it. However, I will point out that a healt= hy use of "SHOULD NOT" would contain a clear explanation of the circumstanc= e/condition under which it is acceptable to break the guidance, and reminde= r that aside from such circumstance/condition, the guidance ought be follow= ed. I think both the OLD and NEW text already contained the explanation of = when requiring connections to external systems is acceptable: to require p= ost-initialization synchronization "in order to fully synchronize the secur= ity information." Thus, the SHOULD NOT was ok, because we stated the condit= ion under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT"= and then telling them when it's okay to break the condition really is the = same as a "SHOULD NOT", no? Would the following address your concerns, and = also have logic integrity: NEW II 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing protocols whereby the operation of the security mechanism would require a routing protocol -- which we are trying to secure -- to alrea= dy be running in order to properly forward packets. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. The condition under which it is acceptable for the proposed solutions to require connection= s to external systems is for post initialization synchronization with external systems, in order to fully synchronize the security information. I think the above (1) makes your point about circular dependency, (2) makes= it clear the only time when the SHOULD NOT would be disobeyed, (3) has log= ical integrity. Does it work for all you folks? Hope it helps, Gregory On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: Regarding requirement number 24, changing "should not" to "must not" does h= elp a lot. However, it might be worth adding a bit of explanation. How abou= t: OLD 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Therefore, proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. NEW 24. The new authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding). In order to ensure the rapid initialization and/or return to service of failed nodes it is important to reduce reliance on these external systems to the greatest extent possible. Also, it is necessary to avoid a circular dependency between the security mechanisms and routing (which itself is required to deliver IP packets to any external systems which are not directly connected at the link layer). Therefore, proposed solutions MUST NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is however acceptable for the proposed solutions to require post initialization synchronization with external systems in order to fully synchronize the security information. Does this look okay to you? Thanks, Ross -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Friday, August 12, 2011 5:09 AM To: Ross Callon; adrian@olddog.co.uk; stbryant@= cisco.com Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs= .all@tools.ietf.org= ; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.c= om Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 Hi Ross, Thanks for the detailed review! > This last point has a relationship with the requirement currently > listed as number 24. It says "Therefore, proposed solutions SHOULD > NOT require connections to external systems...". However, note that if > the proposed solution is being used to authenticate OSPF or IS-IS, > and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any > information to or getting any response from a not-directly-attached > remote system, then it isn't going to work. In this regard I think > that the "SHOULD NOT" in requirement 24 is not strong enough, and > the potential for deadlock should be explicitly mentioned. Would it work if we replace SHOULD NOT with a MUST NOT? > Section 3, 9th bullet item (about DOS attacks): Routers are occasional in= tended > victims of DDOS attacks, which may be aimed at the router's control > plane. As such it is normal for routers to make use of packet [clipped] > against DDOS. Thus in defining security mechanisms there should be a > strong preference for mechanisms that don't hide nor encrypt the > information that the router hardware is able to inspect at full > line rate for DDOS protection (such as IP addresses, and TCP ports). > I think that a bit more text along the lines might be appropriate > to be added to this bullet item. How about something on these lines: New mechanisms must resist DoS attacks described as in-scope in the threats= section 2.1 above. Routers protect the control plane by implementing mecha= nisms to filter completely or rate limit traffic not required at the contro= l plane level (i.e., unwanted traffic). This is done by deep inspecting th= e packets and only accepting the legitimate ones. The new mechanisms should= n't thus hide or encrypt the information carried in the control plane packe= ts so that routers can inspect these packets at the line rate. I have taken note of your other comments and those will get fixed in the ne= xt revision. Cheers, Manav -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --_000_DF7F294AF4153D498141CBEFADB17704C349142784EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg;

 

<= p class=3DMsoNormal>I think that the first issue we need to deal wit= h is what text to put into the requirements document. It is not obvious to = me how to reduce your  discussion of possible solutions into text for = the requirements.

&n= bsp;

thanks, Ross

 

<= p class=3DMsoNormal>From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Thursday, August 18, 2011 2:20 AM
To: Ross Callon<= br>Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-karp-thre= ats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.= co.uk; stbryant@cisco.com
Subject: Re: reliance on external syste= ms (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03<= /span>

 

inline...

On Mon, Aug 15, 2011 at 7:31 PM, Ross Callon <rcallon@juniper.net> wrote:

But if the key= management protocol was running over the out of band management network, t= hen which version of OSPF would it be generating keys for? If it were gener= ating keys to be used for the version of OSPF running on its production net= work, then there is a clear bootstrapping path either initially or to recov= er from any bad state: first the OOB network comes up, then the keys are ex= changed, then the regular network comes up.  If it were generating key= s for the version that made the OOB network work, then what would happen if= it got out of sync?

 

GML> There are= two issues here wrt the AKM operation: (1) How the credentials and bootstr= apping crypto inputs get on the device, and (2) how peers find each other.&= nbsp;

 

GML> For (1) the answer is the same as for= how the device will receive inputs in order to be securely managed:  = the crypto inputs (e.g. for a public key pair used for a self-signed cert, = or in an SSH negotiation, or PSK, or whatever) are either generated locally= on the device via a console connection at initial device bring up, or manu= ally typed in (could be cut-n-paste) via config lines, or via an uploaded c= onfig file. Once these initial config elements are created/entered, then th= e AKM can be run successfully.

 

GML> for (2) it w= ill completely depend upon the particular routing protocol and the solution= we come up with for that routing protocol. However, since the AKM is NOT D= ESIGNED INTO THE ROUTING PROTOCOL ITSELF, there can be config associated wi= th the AKM's operation which tells the device how to reach a particular rou= ting peer(s). Sometimes this might be "send the message out this inter= face" sometimes it may be "send it to this IP address, or that ho= st name"... it will just depend on the specifics and characteristics o= f the routing protocol being worked on. 

 

GML&g= t; Does that make sense?

 

GML> Gregory =

 

 

Didn’t you sort of suggest= below that if the key management protocol needs to talk to some external d= evice, then the external device needs to – like the initial method= 217;s used to bring up the router – either be local to the router, or= run over a separate OOB network? It seems to make sense to add the option = of operating over a separate OOB network to the text that I was proposing. =

 

In the early days of the Arpanet, there was one “event”= where the entire network crashed, and the operators had to first fix only = the router’s which were adjacent to the network management station, t= hen fix the ones which were adjacent to the one’s already fixed, and = recurse in this way through the network. I don’t think that this is a= method that we want to recommend as the normal method to recover from majo= r events (it would seem to get progressively uglier as networks get bigger)= .

 

Ross

 

From: = Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Monday, August 15, 2011 10:06 AM
To: Ross Callon; Gregory Lebo= vitz
Cc: rt= g-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.o= rg; russw@riw.us;= Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com


Subject: RE: reliance on external systems (req 24), RE: R= tgDir review: draft-ietf-karp-threats-reqs-03

 

This imo can certainly happen. I used to know = ;at least one big deployment in Europe that ran OSPF on its out-of-man= agement plane - not sure if they still do. If we define a new KMP that secu= res OSPF, then it could certainly run over the OOB ports.=

 

Cheers, Manav

 

<= hr size=3D2 width=3D"100%" align=3Dcenter>

From: Ross Callon [m= ailto:rcallon@juni= per.net]
Sent: Monday, August 15, 2011 6:48 PM
To:= Gregory Lebovitz
Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-iet= f-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com
Sub= ject: RE: reliance on external systems (req 24), RE: RtgDir review: dra= ft-ietf-karp-threats-reqs-03

Would a security protocol, for example used fo= r automated key management, operate over the out of band management plane, = or would it operate over the normal data plane, or between two systems dire= ctly attached at the link layer, or in some other way?

 <= /o:p>

Ross<= o:p>

 <= /span>

Fr= om: Gregory Lebovitz [mailto:gregory.ietf@gmai= l.com]
Sent: Saturday, August 13, 2011 3:10 AM
To:= Ross Callon
Cc: Bhatia, Manav (Manav); rtg-dir@ietf.org; draft-ietf-kar= p-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com
Subject:= Re: reliance on external systems (req 24), RE: RtgDir review: draft-ie= tf-karp-threats-reqs-03

 =

Hey all.

 

Ross, the circular dependency issue is not really an issue. I rem= ember you raising it early on in the KARP formation process, and me explain= ing the following, which was taken from the survey of about 7 operators I d= id before I wrote the original text (which later became the drafts to formi= ng KARP):

  

=

When operators bring up new routers, or bring up replaced/fixed= routers, they do so by having a human local to the device rack it, connect= it to a console server, and then send the coordinates to a NOC operator. S= aid NOC operator then starts to build up the config on the device. A few st= atic routes, or a default route, is placed into the device first in order t= o test basic network connectivity and to setup up secure, inband management= . At this point keys are often created for SSH use. Many other items are co= nfigured on the device that have to do with OAM, and all are tested, BEFORE= dynamic routing is turned on. In other words, the device has to function w= ell on the network as a healthy host before it becomes a forwarding agent. = Once all this is clear and verified, then routing is turned on protocol by = protocol and confirmed.

 

The above process was ubiquitously followed by operator= s. NONE ever relied on routing protocols for management connectivity, not a= t least at the point of boot strapping. Any credentials or validating data = that would need to be fetched in order to secure the routing protocol would= be loaded or fetched BEFORE routing protocols were turned on, using defaul= t or static routes, just as all other config / data is fetched at device br= ing up.

 

I recall when I explained this to you at the onset of all this work you= said something to the effect of, "Oh, I get it. That makes me feel mu= ch better. So it's not really an issue then," and we moved on.

 

Having said= all that, I'm not opposed to your NEW proposal below. If everyone else agr= ees I would live with it. However, I will point out that a healthy use of &= quot;SHOULD NOT" would contain a clear explanation of the circumstance= /condition under which it is acceptable to break the guidance, and reminder= that aside from such circumstance/condition, the guidance ought be followe= d. I think both the OLD and NEW text already contained the explanation of w= hen requiring connections to external systems is acceptable:  to requi= re post-initialization synchronization "in order to fully synchronize = the security information." Thus, the SHOULD NOT was ok, because we sta= ted the condition under which it was reasonable to defy the SHOULD NOT. Say= ing "MUST NOT" and then telling them when it's okay to break the = condition really is the same as a "SHOULD NOT", no? Would the fol= lowing address your concerns, and also have logic integrity:

=

 

NEW II<= /p>


24.  The new authentication and security mechanism= s should not rely
    on systems external to the routing syste= m (the equipment that
    is performing forwarding).  In = order to ensure the rapid
    initialization and/or return to = service of failed nodes it is
    important to reduce reliance= on these external systems to the
    greatest extent possible= . Also, it is necessary to avoid a
    circular dependency bet= ween the security mechanisms and routing

 &n= bsp;  protocols whereby the operation of the security mechanism w= ould 

    require a rou= ting protocol -- which we are trying to secure -- to already

=

    be running in order to properly forwar= d packets.
    Therefore, proposed solutions SHOULD NOT requir= e connections to
    external systems, beyond those directly i= nvolved in peering
    relationships, in order to return to fu= ll service.  The condition under 
    which it = is acceptable for the proposed solutions to require connections<= /p>

    to external systems is for post

    initialization synchronization with external= systems, in order to
    fully synchronize the security infor= mation. 

 

I think the above (1) makes your point about circular dependency, (2) m= akes it clear the only time when the SHOULD NOT would be disobeyed, (3) has= logical integrity. Does it work for all you folks?

 

Hope it helps,

Gregory

 

=

On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <rcallon@juniper.net> wro= te:

Regarding requirement number 24, changing "should n= ot" to "must not" does help a lot. However, it might be wort= h adding a bit of explanation. How about:

OLD

24.  The n= ew authentication and security mechanisms should not rely
    = on systems external to the routing system (the equipment that is
  =   performing forwarding).  In order to ensure the rapid
 =   initialization and/or return to service of failed nodes it is
&n= bsp;   important to reduce reliance on these external systems to the    greatest extent possible.  Therefore, proposed solutio= ns SHOULD
    NOT require connections to external systems, bey= ond those
    directly involved in peering relationships, in o= rder to return
    to full service.  It is however accept= able for the proposed
    solutions to require post initializa= tion synchronization with
    external systems in order to ful= ly synchronize the security
    information.

NEW
24.  The new authentication and security mechanisms should not rely    on systems external to the routing system (the equipment th= at
    is performing forwarding).  In order to ensure the= rapid
    initialization and/or return to service of failed n= odes it is
    important to reduce reliance on these external = systems to the
    greatest extent possible. Also, it is neces= sary to avoid a
    circular dependency between the security m= echanisms and routing
    (which itself is required to deliver= IP packets to any external
    systems which are not directly= connected at the link layer).
    Therefore, proposed solutio= ns MUST NOT require connections to
    external systems, beyon= d those directly involved in peering
    relationships, in ord= er to return to full service.  It is
    however acceptab= le for the proposed solutions to require post
    initializati= on synchronization with external systems in order to
    fully= synchronize the security information.


Does this look okay to yo= u?

Thanks, Ross

-----Original Message-----
From: Bhatia, M= anav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Friday, August= 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc: rtg-dir@ietf.org; draft-ie= tf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com
Subj= ect: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,
=
Thanks for the detailed review!

> This last point has a relat= ionship with the requirement currently
> listed as number 24. It says= "Therefore, proposed solutions SHOULD
> NOT require connections= to external systems...". However, note that if
> the proposed s= olution is being used to authenticate OSPF or IS-IS,
> and if OSPF or= IS-IS will not bring up links until they are
> authenticated, and if= the proposed solution requires sending any
> information to or getti= ng any response from a not-directly-attached
> remote system, then it= isn't going to work. In this regard I think
> that the "SHOULD = NOT" in requirement 24 is not strong enough, and
> the potential= for deadlock should be explicitly mentioned.

Would it work if we re= place SHOULD NOT with a MUST NOT?

> Section 3, 9th bullet item (a= bout DOS attacks): Routers are occasional intended
> victims of DDOS = attacks, which may be aimed at the router's control
> plane. As such = it is normal for routers to make use of packet

[clipped]

>= against DDOS. Thus in defining security mechanisms there should be a
&g= t; strong preference for mechanisms that don't hide nor encrypt the
>= information that the router hardware is able to  inspect at full
&= gt; line rate for DDOS protection (such as IP addresses, and TCP ports).> I think that a bit more text along the lines might be appropriate
= > to be added to this bullet item.

How about something on these l= ines:

New mechanisms must resist DoS attacks described as in-scope i= n the threats section 2.1 above. Routers protect the control plane by imple= menting mechanisms to filter completely or rate limit traffic not required = at the control plane level (i.e., unwanted traffic).  This is done by = deep inspecting the packets and only accepting the legitimate ones. The new= mechanisms shouldn't thus hide or encrypt the information carried in the c= ontrol plane packets so that routers can inspect these packets at the line = rate.

I have taken note of your other comments and those will get fi= xed in the next revision.

Cheers, Manav

<= br>

 

--
----
IETF related email from
Gregory M. Lebovitz
Junip= er Networks

=



 

--
----
IETF related email from
Gregory M. Lebovitz<= br>Juniper Networks

= --_000_DF7F294AF4153D498141CBEFADB17704C349142784EMBX01WFjnprn_-- From gregory.ietf@gmail.com Sun Aug 21 08:53:17 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081DD21F8A71 for ; Sun, 21 Aug 2011 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXmEhOE+bweD for ; Sun, 21 Aug 2011 08:53:15 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0830121F87C5 for ; Sun, 21 Aug 2011 08:53:14 -0700 (PDT) Received: by pzk33 with SMTP id 33so14068445pzk.18 for ; Sun, 21 Aug 2011 08:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BNFH548ltIIKP4bnPFqAjJ3eMCUvg+lV12U7XmTnREY=; b=lOWWU3S14EsHBoIWJLFyaBqoywX5oyqGYBbRwWPs09RO55nII14/98HAGQ/uLuOx98 2VyWt4sF3QgMa50ST/neY97Ries43r/mpqz6PJDE4kXuOB5B82fhE3OLp0WsWu+UUDJJ B+DQbVsQp1XpsJF/h9RmDsTaUnlkH1s68vSlU= MIME-Version: 1.0 Received: by 10.142.221.16 with SMTP id t16mr767098wfg.83.1313942057285; Sun, 21 Aug 2011 08:54:17 -0700 (PDT) Received: by 10.68.42.136 with HTTP; Sun, 21 Aug 2011 08:54:17 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sun, 21 Aug 2011 08:54:17 -0700 Message-ID: From: Gregory Lebovitz To: Ross Callon Content-Type: multipart/alternative; boundary=000e0cd146c2947a5404ab05f9f0 X-Mailman-Approved-At: Mon, 22 Aug 2011 02:39:32 -0700 Cc: "rtg-dir@ietf.org" , Gregory Lebovitz , "Bhatia, Manav \(Manav\)" , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Brian Weis , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 15:53:17 -0000 --000e0cd146c2947a5404ab05f9f0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ok by me. We are using a SHOULD NOT, and explaining why it's a SHOULD NOT b= y describing a case or two where it is needed. This, IMHO, is the right way t= o use as SHOULD NOT. Thanks for the good team work. On Thu, Aug 18, 2011 at 11:15 AM, Ross Callon wrote: > I am coming to the conclusion that we want some combination of a SHOULD > NOT, as well as a note that if the security protocols that are used to > secure routing depends upon connecting to systems that are not direct > neighbors of the routers, then there MUST be one or more options to ensur= e > against circular dependencies. **** > > ** ** > > Thus three examples of a way to ensure against circular dependencies migh= t > be (i) using a separate network so that the security protocols run out of > band from the normal routing protocols, (ii) using unicast routing to all= ow > exchange of security protocols in order to pass information needed to > bootstrap multicast routing; (iii) Using routing internal to a routing > domain (the IGP, either OSPF or IS-IS) to allow communication within that > domain, in order to pass information used to operate BGP. **** > > ** ** > > The current (=93old=94) text is: **** > > ** ** > > OLD**** > > ** ** > > 24. The new authentication and security mechanisms should not rely**** > > on systems external to the routing system (the equipment that is**** > > performing forwarding). In order to ensure the rapid**** > > initialization and/or return to service of failed nodes it is**** > > important to reduce reliance on these external systems to the**** > > greatest extent possible. Therefore, proposed solutions SHOULD**** > > NOT require connections to external systems, beyond those**** > > directly involved in peering relationships, in order to return**** > > to full service. It is however acceptable for the proposed**** > > solutions to require post initialization synchronization with**** > > external systems in order to fully synchronize the security**** > > information.**** > > ** ** > > We might for example add to this an additional new paragraph: **** > > ** ** > > NEW (add to the above): **** > > ** ** > > If authentication and security mechanisms rely on systems external to > the routing**** > > system, then there MUST be one or more options available to avoid > circular **** > > dependencies. For example, it is not acceptable to have the operation > of OSPF**** > > within a routing domain depend upon correct operation of a security > protocol,**** > > have correct operation of the security protocol depend upon the abili= ty > to **** > > exchange IP packets between remote systems, and have the ability to > exchange**** > > IP packets between remote systems depend upon correct operation of th= e > same**** > > instance of OSPF within the same routing domain. However, it is okay = to > have **** > > operation of multicast routing and/or interdomain routing depend upon > operation**** > > of a security protocol, which depends upon exchange of IP packets > between **** > > remote systems, which depends upon the correct operation of OSPF for > unicast **** > > routing. Similarly it would be okay to have the operation of OSPF > depend upon **** > > a security protocol, which in turn uses an out of band network to > exchange**** > > information with remote systems. **** > > ** ** > > Ross**** > > ** ** > > *From:* Brian Weis [mailto:bew@cisco.com] > *Sent:* Thursday, August 18, 2011 1:05 PM > *To:* Gregory Lebovitz > *Cc:* Ross Callon; Bhatia, Manav (Manav); rtg-dir@ietf.org; > draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory > Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > *Subject:* Re: reliance on external systems (req 24), RE: RtgDir review: > draft-ietf-karp-threats-reqs-03**** > > ** ** > > All,**** > > ** ** > > I prefer the SHOULD NOT wording. Recall that multicast routing protocols > (e.g., PIM) are independent from unicast routing, and as such security > system mechanism for multicast routing protocols can rely on systems > external to the routing system without worrying about a circular dependan= cy. > **** > > ** ** > > Thanks,**** > > Brian**** > > ** ** > > On Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote:**** > > Hey all.**** > > ** ** > > Ross, the circular dependency issue is not really an issue. I remember yo= u > raising it early on in the KARP formation process, and me explaining the > following, which was taken from the survey of about 7 operators I did bef= ore > I wrote the original text (which later became the drafts to forming KARP)= : > **** > > **** > > When operators bring up new routers, or bring up replaced/fixed routers, > they do so by having a human local to the device rack it, connect it to a > console server, and then send the coordinates to a NOC operator. Said NOC > operator then starts to build up the config on the device. A few static > routes, or a default route, is placed into the device first in order to t= est > basic network connectivity and to setup up secure, inband management. At > this point keys are often created for SSH use. Many other items are > configured on the device that have to do with OAM, and all are tested, > BEFORE dynamic routing is turned on. In other words, the device has to > function well on the network as a healthy host before it becomes a > forwarding agent. Once all this is clear and verified, then routing is > turned on protocol by protocol and confirmed.**** > > ** ** > > The above process was ubiquitously followed by operators. NONE ever relie= d > on routing protocols for management connectivity, not at least at the poi= nt > of boot strapping. Any credentials or validating data that would need to = be > fetched in order to secure the routing protocol would be loaded or fetche= d > BEFORE routing protocols were turned on, using default or static routes, > just as all other config / data is fetched at device bring up.**** > > ** ** > > I recall when I explained this to you at the onset of all this work you > said something to the effect of, "Oh, I get it. That makes me feel much > better. So it's not really an issue then," and we moved on.**** > > ** ** > > Having said all that, I'm not opposed to your NEW proposal below. If > everyone else agrees I would live with it. However, I will point out that= a > healthy use of "SHOULD NOT" would contain a clear explanation of the > circumstance/condition under which it is acceptable to break the guidance= , > and reminder that aside from such circumstance/condition, the guidance ou= ght > be followed. I think both the OLD and NEW text already contained the > explanation of when requiring connections to external systems is acceptab= le: > to require post-initialization synchronization "in order to fully > synchronize the security information." Thus, the SHOULD NOT was ok, becau= se > we stated the condition under which it was reasonable to defy the SHOULD > NOT. Saying "MUST NOT" and then telling them when it's okay to break the > condition really is the same as a "SHOULD NOT", no? Would the following > address your concerns, and also have logic integrity:**** > > ** ** > > NEW II**** > > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing**** > > protocols whereby the operation of the security mechanism would **** > > require a routing protocol -- which we are trying to secure -- to > already**** > > be running in order to properly forward packets. > Therefore, proposed solutions SHOULD NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. The condition > under > which it is acceptable for the proposed solutions to require > connections**** > > to external systems is for post**** > > initialization synchronization with external systems, in order to > fully synchronize the security information. **** > > **** > > I think the above (1) makes your point about circular dependency, (2) mak= es > it clear the only time when the SHOULD NOT would be disobeyed, (3) has > logical integrity. Does it work for all you folks?**** > > ** ** > > Hope it helps,**** > > Gregory**** > > ** ** > > On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon wrote= : > > **** > > Regarding requirement number 24, changing "should not" to "must not" does > help a lot. However, it might be worth adding a bit of explanation. How > about: > > OLD > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. > > NEW > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. > > > Does this look okay to you? > > Thanks, Ross > > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com > Cc: rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; > russw@riw.us; Gregory Lebovitz; gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 > > Hi Ross, > > Thanks for the detailed review! > > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note that if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. > > Would it work if we replace SHOULD NOT with a MUST NOT? > > > Section 3, 9th bullet item (about DOS attacks): Routers are occasional > intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet > > [clipped] > > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. > > How about something on these lines: > > New mechanisms must resist DoS attacks described as in-scope in the threa= ts > section 2.1 above. Routers protect the control plane by implementing > mechanisms to filter completely or rate limit traffic not required at the > control plane level (i.e., unwanted traffic). This is done by deep > inspecting the packets and only accepting the legitimate ones. The new > mechanisms shouldn't thus hide or encrypt the information carried in the > control plane packets so that routers can inspect these packets at the li= ne > rate. > > I have taken note of your other comments and those will get fixed in the > next revision. > > Cheers, Manav**** > > > > **** > > ** ** > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks**** > > ** ** > > > -- > Brian Weis > Security Standards and Technology, SRTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com**** > > ** ** > > ** ** > > ** ** > > ** ** > --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd146c2947a5404ab05f9f0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ok by me. We are using a SHOULD NOT, and explaining why it's a SHOULD N= OT by describing a case or two where it is needed. This, IMHO, is the right= way to use as SHOULD NOT. Thanks for the good team work.

On Thu, Aug 18, 2011 at 11:15 AM, Ross Callon <rcallon@juniper.net> wrote:

I am coming to the conclusion that we want some combination of a SHO= ULD NOT, as well as a note that if the security protocols that are used to = secure routing depends upon connecting to systems that are not direct neigh= bors of the routers, then there MUST be one or more options to ensure again= st circular dependencies.

=A0

Thus three examples of a way to ensure against circular d= ependencies might be (i) using a separate network so that the security prot= ocols run out of band from the normal routing protocols, (ii) using unicast= routing to allow exchange of security protocols in order to pass informati= on needed to bootstrap multicast routing; (iii) Using routing internal to a= routing domain (the IGP, either OSPF or IS-IS) to allow communication with= in that domain, in order to pass information used to operate BGP.

=A0

The current (=93old=94) text is:

=A0

OLD

=A0

24.= =A0 The new authentication and security mechanisms should not rely

=A0=A0=A0 on systems external to the routing system (the equipme= nt that is

=A0= =A0=A0 performing forwarding).=A0 In order to ensure the rapid

=A0=A0=A0 initialization and/or return to service of failed nodes it= is

=A0= =A0=A0 important to reduce reliance on these external systems to the=

=A0=A0=A0 greatest extent possible.=A0 Therefore, proposed sol= utions SHOULD

=A0= =A0=A0 NOT require connections to external systems, beyond those<= /u>

=A0=A0=A0 directly involved in peering relationships, in order to = return

=A0= =A0=A0 to full service.=A0 It is however acceptable for the proposed=

=A0=A0=A0 solutions to require post initialization synchroniza= tion with

=A0= =A0=A0 external systems in order to fully synchronize the security

=A0=A0=A0 information.

=A0

We might for example add to this an additional new = paragraph:

=A0

NEW (add to the above):

=A0

=

=A0= =A0=A0 If authentication and security mechanisms rely on systems external t= o the routing

=A0= =A0=A0 system, then there MUST be one or more options available to avoid ci= rcular

=A0=A0=A0=A0dependencies. For example, it is not= acceptable to have the operation of OSPF

=A0= =A0=A0 within a routing domain depend upon correct operation of a security = protocol,

=A0=A0=A0 have correct operation of the securi= ty protocol depend upon the ability to

=A0= =A0=A0=A0exchange IP packets between remote systems, and have the ability t= o exchange

=A0=A0=A0 IP packets between remote systems d= epend upon correct operation of the same

=A0= =A0=A0 instance of OSPF within the same routing domain. However, it is okay= to have

=A0=A0=A0=A0operation of multicast routing and= /or interdomain routing depend upon operation

=A0= =A0 =A0of a security protocol, which depends upon exchange of IP packets be= tween

=A0=A0=A0=A0remote systems, which depends upon th= e correct operation of OSPF for unicast

=A0= =A0=A0=A0routing. Similarly it would be okay to have the operation of OSPF = depend upon

=A0=A0=A0=A0a security protocol, which in t= urn uses an out of band network to exchange

=A0= =A0 =A0information with remote systems.

=A0=

Ross

<= /u>=A0

From:= Brian Weis [mailto:bew@cisco.com]
Sent: Thursday, = August 18, 2011 1:05 PM
To: Gregory Lebovitz
Cc: Ross Callon; Bhatia, Manav (Manav= ); rtg-dir@ietf.org; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovi= tz; adrian@olddog.= co.uk; stbryant= @cisco.com
Subject: Re: reliance on external systems (req 24), RE: RtgDir revie= w: draft-ietf-karp-threats-reqs-03

=A0

<= p class=3D"MsoNormal"> All,

=A0

I prefer the SHOULD NOT wording. Recall that = multicast routing protocols (e.g., PIM) are independent from unicast routin= g, and as such security system mechanism for multicast routing protocols ca= n rely on=A0systems external to the routing system without worrying about a= circular dependancy.

=A0

Thanks,

B= rian

=A0

On Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote= :

Hey all.

=A0

Ross, the circular d= ependency issue is not really an issue. I remember you raising it early on = in the KARP formation process, and me explaining the following, which was t= aken from the survey of about 7 operators I did before I wrote the original= text (which later became the drafts to forming KARP):

=A0=A0

When operators bring up new routers, or bring up replaced/= fixed routers, they do so by having a human local to the device rack it, co= nnect it to a console server, and then send the coordinates to a NOC operat= or. Said NOC operator then starts to build up the config on the device. A f= ew static routes, or a default route, is placed into the device first in or= der to test basic network connectivity and to setup up secure, inband manag= ement. At this point keys are often created for SSH use. Many other items a= re configured on the device that have to do with OAM, and all are tested, B= EFORE dynamic routing is turned on. In other words, the device has to funct= ion well on the network as a healthy host before it becomes a forwarding ag= ent. Once all this is clear and verified, then routing is turned on protoco= l by protocol and confirmed.

=A0

The above process was ubiquitously followed by operators. NO= NE ever relied on routing protocols for management connectivity, not at lea= st at the point of boot strapping. Any credentials or validating data that = would need to be fetched in order to secure the routing protocol would be l= oaded or fetched BEFORE routing protocols were turned on, using default or = static routes, just as all other config / data is fetched at device bring u= p.

=A0

I recall when I explained this to you at the onset of all th= is work you said something to the effect of, "Oh, I get it. That makes= me feel much better. So it's not really an issue then," and we mo= ved on.

=A0

Having said all that, I'm not opposed to your NEW propos= al below. If everyone else agrees I would live with it. However, I will poi= nt out that a healthy use of "SHOULD NOT" would contain a clear e= xplanation of the circumstance/condition under which it is acceptable to br= eak the guidance, and reminder that aside from such circumstance/condition,= the guidance ought be followed. I think both the OLD and NEW text already = contained the explanation of when requiring connections to external systems= is acceptable: =A0to require post-initialization synchronization "in = order to fully synchronize the security information." Thus, the SHOULD= NOT was ok, because we stated the condition under which it was reasonable = to defy the SHOULD NOT. Saying "MUST NOT" and then telling them w= hen it's okay to break the condition really is the same as a "SHOU= LD NOT", no? Would the following address your concerns, and also have = logic integrity:

=A0

NEW II


24.= =A0The new authentication and security mechanisms should not rely
=A0 = =A0 on systems external to the routing system (the equipment that
=A0 =A0 is performing forwarding). =A0In order to ensure the rapid
=A0 = =A0 initialization and/or return to service of failed nodes it is
=A0 = =A0 important to reduce reliance on these external systems to the
=A0 = =A0 greatest extent possible. Also, it is necessary to avoid a
=A0 =A0 circular dependency between the security mechanisms and routing<= /u>

=A0=A0 =A0protocols=A0whereby the= operation of the security mechanism would=A0

<= p class=3D"MsoNormal"> =A0=A0 =A0require a routing protocol -- which we are trying to secure -- to= already

=A0=A0 =A0be ru= nning in order to properly forward packets.
=A0 =A0 Therefore, proposed = solutions SHOULD NOT require connections to
=A0 =A0 external systems, beyond those directly involved in peering
=A0 = =A0 relationships, in order to return to full service. =A0The condition und= er=A0
=A0=A0 =A0which it is acceptable for the proposed solutions to req= uire connections

=A0=A0 =A0to external systems is for post

=A0 =A0 initialization synchronizat= ion with external systems, in order to
=A0 =A0 fully synchronize the sec= urity information.=A0

=A0

I think the above (1) makes your point about circular dependency, (= 2) makes it clear the only time when the SHOULD NOT would be disobeyed, (3)= has logical integrity. Does it work for all you folks?

=A0

Hope it helps,

Gregory

=A0

On Fri, Aug 12, 2011 at 12= :00 PM, Ross Callon <rcallon@juniper.net> wrote:

Regarding requirement number 24, changing "should not" to "m= ust not" does help a lot. However, it might be worth adding a bit of e= xplanation. How about:

OLD

24. =A0The new authentication and = security mechanisms should not rely
=A0 =A0 on systems external to the routing system (the equipment that is=A0 =A0 performing forwarding). =A0In order to ensure the rapid
=A0 =A0= initialization and/or return to service of failed nodes it is
=A0 =A0 i= mportant to reduce reliance on these external systems to the
=A0 =A0 greatest extent possible. =A0Therefore, proposed solutions SHOULD=A0 =A0 NOT require connections to external systems, beyond those
=A0 = =A0 directly involved in peering relationships, in order to return
=A0 = =A0 to full service. =A0It is however acceptable for the proposed
=A0 =A0 solutions to require post initialization synchronization with
= =A0 =A0 external systems in order to fully synchronize the security
=A0 = =A0 information.

NEW

24. =A0The new authentication and securi= ty mechanisms should not rely
=A0 =A0 on systems external to the routing system (the equipment that
= =A0 =A0 is performing forwarding). =A0In order to ensure the rapid
=A0 = =A0 initialization and/or return to service of failed nodes it is
=A0 = =A0 important to reduce reliance on these external systems to the
=A0 =A0 greatest extent possible. Also, it is necessary to avoid a
=A0 = =A0 circular dependency between the security mechanisms and routing
=A0 = =A0 (which itself is required to deliver IP packets to any external
=A0 = =A0 systems which are not directly connected at the link layer).
=A0 =A0 Therefore, proposed solutions MUST NOT require connections to
= =A0 =A0 external systems, beyond those directly involved in peering
=A0 = =A0 relationships, in order to return to full service. =A0It is
=A0 =A0 = however acceptable for the proposed solutions to require post
=A0 =A0 initialization synchronization with external systems in order to=A0 =A0 fully synchronize the security information.


Does this l= ook okay to you?

Thanks, Ross

-----Original Message-----
F= rom: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; adrian@olddog.co.uk; stbryant@cisco.com
Cc:= rtg-dir@ietf.org= ; draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory Lebovitz;= gregory.ietf@g= mail.com
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,=

Thanks for the detailed review!

> This last point has a r= elationship with the requirement currently
> listed as number 24. It = says "Therefore, proposed solutions SHOULD
> NOT require connections to external systems...". However, note th= at if
> the proposed solution is being used to authenticate OSPF or I= S-IS,
> and if OSPF or IS-IS will not bring up links until they are > authenticated, and if the proposed solution requires sending any
&g= t; information to or getting any response from a not-directly-attached
&= gt; remote system, then it isn't going to work. In this regard I think<= br> > that the "SHOULD NOT" in requirement 24 is not strong enough= , and
> the potential for deadlock should be explicitly mentioned.
Would it work if we replace SHOULD NOT with a MUST NOT?

> Se= ction 3, 9th bullet item (about DOS attacks): Routers are occasional intend= ed
> victims of DDOS attacks, which may be aimed at the router's contro= l
> plane. As such it is normal for routers to make use of packet
=
[clipped]

> against DDOS. Thus in defining security mechanism= s there should be a
> strong preference for mechanisms that don't hide nor encrypt the> information that the router hardware is able to =A0inspect at full> line rate for DDOS protection (such as IP addresses, and TCP ports).=
> I think that a bit more text along the lines might be appropriate
&= gt; to be added to this bullet item.

How about something on these li= nes:

New mechanisms must resist DoS attacks described as in-scope in= the threats section 2.1 above. Routers protect the control plane by implem= enting mechanisms to filter completely or rate limit traffic not required a= t the control plane level (i.e., unwanted traffic). =A0This is done by deep= inspecting the packets and only accepting the legitimate ones. The new mec= hanisms shouldn't thus hide or encrypt the information carried in the c= ontrol plane packets so that routers can inspect these packets at the line = rate.

I have taken note of your other comments and those will get fixed in th= e next revision.

Cheers, Manav



=A0

--
----
IETF relat= ed email from
Gregory M. Lebovitz
Juniper Networks

<= /div>

=A0=


--=A0
Brian Weis
Secu= rity Standards and Technology, SRTG, Cisco Systems
Telephon= e: +1 408 526 4796
Email:=A0bew@cisco= .com<= u>

=A0

=A0

=A0

=A0




--
----
IETF related email from=
Gregory M. Lebovitz
Juniper Networks
--000e0cd146c2947a5404ab05f9f0-- From manav.bhatia@alcatel-lucent.com Sun Aug 21 17:27:47 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1721F86AA for ; Sun, 21 Aug 2011 17:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnEi-Je0YtHr for ; Sun, 21 Aug 2011 17:27:46 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E25AC21F85CE for ; Sun, 21 Aug 2011 17:27:45 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7M0Sf7E005307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Aug 2011 19:28:43 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7M0SdJZ022915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Aug 2011 05:58:39 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 22 Aug 2011 05:58:39 +0530 Message-ID: <4E51A257.1000704@alcatel-lucent.com> Date: Mon, 22 Aug 2011 05:57:03 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 ThunderBrowse/3.8 MIME-Version: 1.0 To: Ross Callon References: <7C362EEF9C7896468B36C9B79200D8350CFF8E2E17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Mon, 22 Aug 2011 02:39:32 -0700 Cc: "rtg-dir@ietf.org" , Gregory Lebovitz , "draft-ietf-karp-threats-reqs.all@tools.ietf.org" , "adrian@olddog.co.uk" , "russw@riw.us" , Brian Weis , Gregory Lebovitz , "stbryant@cisco.com" Subject: Re: [RTG-DIR] reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 00:27:47 -0000 Hi Ross, This looks ok to me. If everyone agrees then i shall update the draft with the below addition. Cheers, Manav On 8/18/2011 11:45 PM, Ross Callon wrote: > I am coming to the conclusion that we want some combination of a SHOULD > NOT, as well as a note that if the security protocols that are used to > secure routing depends upon connecting to systems that are not direct > neighbors of the routers, then there MUST be one or more options to > ensure against circular dependencies. > > Thus three examples of a way to ensure against circular dependencies > might be (i) using a separate network so that the security protocols run > out of band from the normal routing protocols, (ii) using unicast > routing to allow exchange of security protocols in order to pass > information needed to bootstrap multicast routing; (iii) Using routing > internal to a routing domain (the IGP, either OSPF or IS-IS) to allow > communication within that domain, in order to pass information used to > operate BGP. > > The current (“old”) text is: > > OLD > > 24. The new authentication and security mechanisms should not rely > > on systems external to the routing system (the equipment that is > > performing forwarding). In order to ensure the rapid > > initialization and/or return to service of failed nodes it is > > important to reduce reliance on these external systems to the > > greatest extent possible. Therefore, proposed solutions SHOULD > > NOT require connections to external systems, beyond those > > directly involved in peering relationships, in order to return > > to full service. It is however acceptable for the proposed > > solutions to require post initialization synchronization with > > external systems in order to fully synchronize the security > > information. > > We might for example add to this an additional new paragraph: > > NEW (add to the above): > > If authentication and security mechanisms rely on systems external to > the routing > > system, then there MUST be one or more options available to avoid circular > > dependencies. For example, it is not acceptable to have the operation of > OSPF > > within a routing domain depend upon correct operation of a security > protocol, > > have correct operation of the security protocol depend upon the ability to > > exchange IP packets between remote systems, and have the ability to exchange > > IP packets between remote systems depend upon correct operation of the same > > instance of OSPF within the same routing domain. However, it is okay to > have > > operation of multicast routing and/or interdomain routing depend upon > operation > > of a security protocol, which depends upon exchange of IP packets between > > remote systems, which depends upon the correct operation of OSPF for > unicast > > routing. Similarly it would be okay to have the operation of OSPF depend > upon > > a security protocol, which in turn uses an out of band network to exchange > > information with remote systems. > > Ross > > *From:*Brian Weis [mailto:bew@cisco.com] > *Sent:* Thursday, August 18, 2011 1:05 PM > *To:* Gregory Lebovitz > *Cc:* Ross Callon; Bhatia, Manav (Manav); rtg-dir@ietf.org; > draft-ietf-karp-threats-reqs.all@tools.ietf.org; russw@riw.us; Gregory > Lebovitz; adrian@olddog.co.uk; stbryant@cisco.com > *Subject:* Re: reliance on external systems (req 24), RE: RtgDir review: > draft-ietf-karp-threats-reqs-03 > > All, > > I prefer the SHOULD NOT wording. Recall that multicast routing protocols > (e.g., PIM) are independent from unicast routing, and as such security > system mechanism for multicast routing protocols can rely on systems > external to the routing system without worrying about a circular dependancy. > > Thanks, > > Brian > > On Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote: > > Hey all. > > Ross, the circular dependency issue is not really an issue. I > remember you raising it early on in the KARP formation process, and > me explaining the following, which was taken from the survey of > about 7 operators I did before I wrote the original text (which > later became the drafts to forming KARP): > > When operators bring up new routers, or bring up replaced/fixed > routers, they do so by having a human local to the device rack it, > connect it to a console server, and then send the coordinates to a > NOC operator. Said NOC operator then starts to build up the config > on the device. A few static routes, or a default route, is placed > into the device first in order to test basic network connectivity > and to setup up secure, inband management. At this point keys are > often created for SSH use. Many other items are configured on the > device that have to do with OAM, and all are tested, BEFORE dynamic > routing is turned on. In other words, the device has to function > well on the network as a healthy host before it becomes a forwarding > agent. Once all this is clear and verified, then routing is turned > on protocol by protocol and confirmed. > > The above process was ubiquitously followed by operators. NONE ever > relied on routing protocols for management connectivity, not at > least at the point of boot strapping. Any credentials or validating > data that would need to be fetched in order to secure the routing > protocol would be loaded or fetched BEFORE routing protocols were > turned on, using default or static routes, just as all other config > / data is fetched at device bring up. > > I recall when I explained this to you at the onset of all this work > you said something to the effect of, "Oh, I get it. That makes me > feel much better. So it's not really an issue then," and we moved on. > > Having said all that, I'm not opposed to your NEW proposal below. If > everyone else agrees I would live with it. However, I will point out > that a healthy use of "SHOULD NOT" would contain a clear explanation > of the circumstance/condition under which it is acceptable to break > the guidance, and reminder that aside from such > circumstance/condition, the guidance ought be followed. I think both > the OLD and NEW text already contained the explanation of when > requiring connections to external systems is acceptable: to require > post-initialization synchronization "in order to fully synchronize > the security information." Thus, the SHOULD NOT was ok, because we > stated the condition under which it was reasonable to defy the > SHOULD NOT. Saying "MUST NOT" and then telling them when it's okay > to break the condition really is the same as a "SHOULD NOT", no? > Would the following address your concerns, and also have logic > integrity: > > NEW II > > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > > protocols whereby the operation of the security mechanism would > > require a routing protocol -- which we are trying to secure -- to > already > > be running in order to properly forward packets. > Therefore, proposed solutions SHOULD NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. The condition under > which it is acceptable for the proposed solutions to require connections > > to external systems is for post > > initialization synchronization with external systems, in order to > fully synchronize the security information. > > I think the above (1) makes your point about circular dependency, > (2) makes it clear the only time when the SHOULD NOT would be > disobeyed, (3) has logical integrity. Does it work for all you folks? > > Hope it helps, > > Gregory > > On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon > wrote: > > Regarding requirement number 24, changing "should not" to "must not" > does help a lot. However, it might be worth adding a bit of > explanation. How about: > > OLD > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that is > performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Therefore, proposed solutions SHOULD > NOT require connections to external systems, beyond those > directly involved in peering relationships, in order to return > to full service. It is however acceptable for the proposed > solutions to require post initialization synchronization with > external systems in order to fully synchronize the security > information. > > NEW > > 24. The new authentication and security mechanisms should not rely > on systems external to the routing system (the equipment that > is performing forwarding). In order to ensure the rapid > initialization and/or return to service of failed nodes it is > important to reduce reliance on these external systems to the > greatest extent possible. Also, it is necessary to avoid a > circular dependency between the security mechanisms and routing > (which itself is required to deliver IP packets to any external > systems which are not directly connected at the link layer). > Therefore, proposed solutions MUST NOT require connections to > external systems, beyond those directly involved in peering > relationships, in order to return to full service. It is > however acceptable for the proposed solutions to require post > initialization synchronization with external systems in order to > fully synchronize the security information. > > > Does this look okay to you? > > Thanks, Ross > > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com > ] > Sent: Friday, August 12, 2011 5:09 AM > To: Ross Callon; adrian@olddog.co.uk ; > stbryant@cisco.com > Cc: rtg-dir@ietf.org ; > draft-ietf-karp-threats-reqs.all@tools.ietf.org > ; > russw@riw.us ; Gregory Lebovitz; > gregory.ietf@gmail.com > Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03 > > Hi Ross, > > Thanks for the detailed review! > > > This last point has a relationship with the requirement currently > > listed as number 24. It says "Therefore, proposed solutions SHOULD > > NOT require connections to external systems...". However, note > that if > > the proposed solution is being used to authenticate OSPF or IS-IS, > > and if OSPF or IS-IS will not bring up links until they are > > authenticated, and if the proposed solution requires sending any > > information to or getting any response from a not-directly-attached > > remote system, then it isn't going to work. In this regard I think > > that the "SHOULD NOT" in requirement 24 is not strong enough, and > > the potential for deadlock should be explicitly mentioned. > > Would it work if we replace SHOULD NOT with a MUST NOT? > > > Section 3, 9th bullet item (about DOS attacks): Routers are > occasional intended > > victims of DDOS attacks, which may be aimed at the router's control > > plane. As such it is normal for routers to make use of packet > > [clipped] > > > against DDOS. Thus in defining security mechanisms there should be a > > strong preference for mechanisms that don't hide nor encrypt the > > information that the router hardware is able to inspect at full > > line rate for DDOS protection (such as IP addresses, and TCP ports). > > I think that a bit more text along the lines might be appropriate > > to be added to this bullet item. > > How about something on these lines: > > New mechanisms must resist DoS attacks described as in-scope in the > threats section 2.1 above. Routers protect the control plane by > implementing mechanisms to filter completely or rate limit traffic > not required at the control plane level (i.e., unwanted traffic). > This is done by deep inspecting the packets and only accepting the > legitimate ones. The new mechanisms shouldn't thus hide or encrypt > the information carried in the control plane packets so that routers > can inspect these packets at the line rate. > > I have taken note of your other comments and those will get fixed in > the next revision. > > Cheers, Manav > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > > > -- > Brian Weis > Security Standards and Technology, SRTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > From acee.lindem@ericsson.com Mon Aug 22 14:02:46 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB6A21F8591 for ; Mon, 22 Aug 2011 14:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTulPS2gqYwT for ; Mon, 22 Aug 2011 14:02:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E357021F859F for ; Mon, 22 Aug 2011 14:02:45 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7ML3ec2012581; Mon, 22 Aug 2011 16:03:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 22 Aug 2011 17:03:34 -0400 From: Acee Lindem To: Alia Atlas Date: Mon, 22 Aug 2011 17:03:32 -0400 Thread-Topic: New Version Notification - draft-ietf-ospf-auth-trailer-ospfv3-06.txt Thread-Index: AcxhDvRQL330XljlQ/Kcka63xXlgaA== Message-ID: References: <20110822205120.21619.38513.idtracker@ietfa.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 Cc: "rtg-dir@ietf.org" , "draft-ietf-ospf-auth-trailer-ospfv3@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] Fwd: New Version Notification - draft-ietf-ospf-auth-trailer-ospfv3-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:02:46 -0000 Hi Alia, I believe this version addresses your comments. Note that we removed the te= xt regarding an IPsec license given the discussion in the last KARP WG meet= ing with respect to a PIM authentication draft. Hence, you second comment w= as resolved differently. Thanks, Acee Begin forwarded message: From: "internet-drafts@ietf.org" > Date: August 22, 2011 4:51:20 PM EDT To: "ospf-chairs@tools.ietf.org" >, "draft-ietf-ospf-= auth-trailer-ospfv3@tools.ietf.org" >, "stbryant@cisco.c= om" > Subject: New Version Notification - draft-ietf-ospf-auth-trailer-ospfv3-06.= txt New version (-06) has been submitted for draft-ietf-ospf-auth-trailer-ospfv= 3-06.txt. http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-06.= txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-auth-trailer-ospfv3-06 IETF Secretariat. From adrian@olddog.co.uk Tue Aug 23 05:42:38 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBE621F871E; Tue, 23 Aug 2011 05:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uU-VGyUU7AH; Tue, 23 Aug 2011 05:42:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 103F321F858D; Tue, 23 Aug 2011 05:42:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NChhjn023681; Tue, 23 Aug 2011 13:43:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NChfXd023664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 13:43:42 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E386CF0.5050700@pi.nu> In-Reply-To: <4E386CF0.5050700@pi.nu> Date: Tue, 23 Aug 2011 13:43:42 +0100 Message-ID: <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENZSdLZyA Content-Language: en-gb Cc: rtg-dir@ietf.org, pwe3@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:42:39 -0000 The authors are snoozing in the sun somewhere. > OAM appears in the table of content and as header 7. It is not > expanded in the document anywhere. Should be done at first occurance. RFC Ed note entered > page 6. The last paragraph of section 1 talks about TC bits > (and EXP bits). We don't have TC bits - the correct name is TC field. RFC Ed note entered > First paragraph section three: > This paragraph talks in genral about "load balanced paths" while the > rest of the document is very specific about ECMP, it is the intention > that this should work for any load balancing paradigm? Authors? > Second paragraph section three: > Normally a label is assigned by the down stream node, this scheme > is doing upstream allocation. Don't see a problem under normal > operation, but if the label "by accident" becomes top of stack > this could have "interesting" effects. Think this is mentioned in 1.2 > Sectyion 4 second paagraph: > > OLD > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. A PE that is using PW signalling and that does > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > A PE that is using PW signalling and which does not receive a FL Sub- > TLV from its peer MUST NOT include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > NEW > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. An ingress PE that is using PW signalling > and that does not send a FL Sub-TLV MUST NOT include a flow label > in the PW packet. An ingress PE that is using PW signalling and > which does not receive a FL Sub-TLV from its egress peer MUST NOT > include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > END I think this is right. No doubt the authors were thinking of bidirectional PWs, but with current state of the art, I think Loa is right and have entered the RFC Ed note > The IANA section: > > In the IANA section we should use a TBD entry for the Flow label > indicator; and maybe add 0x17 as suggest value in the text. I think this is wrong because early allocation was done (as you note below). IANA has indicated they understand the action. > The text in the IANA section needs to aligned with the rest of > the text, or maybe even better have the rest of the text align > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > else but in the iana section. OLD o FL (value 0x17) is the flow label sub-TLV identifier assigned by IANA (seeSection 11 ). NEW o FL (value 0x17) is the flow label indicator sub-TLV identifier assigned by IANA (see Section 11). END > To make it easier to find the references to the IANA registries > should start with "Pseudowire Name Spaces (PWE3)" point to > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > sub-registry, and ask for assigment of the next free value from > the Experts review space (suggested value 0x17). > > On the other hand it looks like we have an early assignment > (Flow Label shows up with the value 0x17). If this is the case > after making the text changes suggest above this should be mentioned > in the IANA section. RFC Ed note entered Thanks, Adrian From adrian@olddog.co.uk Tue Aug 23 05:45:22 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3626D21F8A35; Tue, 23 Aug 2011 05:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6inTXdZtzzzP; Tue, 23 Aug 2011 05:45:21 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 316F221F89CC; Tue, 23 Aug 2011 05:45:21 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCdllM002703; Tue, 23 Aug 2011 13:39:47 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCdjq8002697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 13:39:46 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E386CF0.5050700@pi.nu> In-Reply-To: Date: Tue, 23 Aug 2011 13:46:26 +0100 Message-ID: <075501cc6192$acbdef70$0639ce50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENZSdLZyAgAAEdZA= Content-Language: en-gb Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, rtg-dir@ietf.org, pwe3@ietf.org Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:45:22 -0000 Ah, I see why there might have been no response before. Sending again with the correct email alias. A > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 23 August 2011 13:44 > To: 'Loa Andersson'; 'rtg-ads@tools.ietf.org' > Cc: 'pwe3@ietf.org'; 'rtg-dir@ietf.org'; 'draft-ietf-pwe3-fat.all@tools.ietf.org' > Subject: RE: [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 > > The authors are snoozing in the sun somewhere. > > > OAM appears in the table of content and as header 7. It is not > > expanded in the document anywhere. Should be done at first occurance. > > RFC Ed note entered > > > page 6. The last paragraph of section 1 talks about TC bits > > (and EXP bits). We don't have TC bits - the correct name is TC field. > > RFC Ed note entered > > > First paragraph section three: > > This paragraph talks in genral about "load balanced paths" while the > > rest of the document is very specific about ECMP, it is the intention > > that this should work for any load balancing paradigm? > > Authors? > > > Second paragraph section three: > > Normally a label is assigned by the down stream node, this scheme > > is doing upstream allocation. Don't see a problem under normal > > operation, but if the label "by accident" becomes top of stack > > this could have "interesting" effects. > > Think this is mentioned in 1.2 > > > Sectyion 4 second paagraph: > > > > OLD > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. A PE that is using PW signalling and that does > > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > > A PE that is using PW signalling and which does not receive a FL Sub- > > TLV from its peer MUST NOT include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > NEW > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. An ingress PE that is using PW signalling > > and that does not send a FL Sub-TLV MUST NOT include a flow label > > in the PW packet. An ingress PE that is using PW signalling and > > which does not receive a FL Sub-TLV from its egress peer MUST NOT > > include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > END > > I think this is right. No doubt the authors were thinking of bidirectional PWs, but > with current state of the art, I think Loa is right and have entered the RFC Ed note > > > The IANA section: > > > > In the IANA section we should use a TBD entry for the Flow label > > indicator; and maybe add 0x17 as suggest value in the text. > > I think this is wrong because early allocation was done (as you note below). > IANA has indicated they understand the action. > > > The text in the IANA section needs to aligned with the rest of > > the text, or maybe even better have the rest of the text align > > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > > else but in the iana section. > > OLD > o FL (value 0x17) is the flow label sub-TLV identifier assigned by > IANA (seeSection 11 ). > NEW > o FL (value 0x17) is the flow label indicator sub-TLV identifier > assigned by IANA (see Section 11). > END > > > To make it easier to find the references to the IANA registries > > should start with "Pseudowire Name Spaces (PWE3)" point to > > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > > sub-registry, and ask for assigment of the next free value from > > the Experts review space (suggested value 0x17). > > > > On the other hand it looks like we have an early assignment > > (Flow Label shows up with the value 0x17). If this is the case > > after making the text changes suggest above this should be mentioned > > in the IANA section. > > RFC Ed note entered > > Thanks, > Adrian From adrian@olddog.co.uk Tue Aug 23 05:45:58 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28621F84E4; Tue, 23 Aug 2011 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgnZulzNRTxy; Tue, 23 Aug 2011 05:45:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E13E321F85F2; Tue, 23 Aug 2011 05:45:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCl1iD006647; Tue, 23 Aug 2011 13:47:01 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCkxvw006641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 13:47:00 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E386CF0.5050700@pi.nu> <4E3ADAE2.5060907@pi.nu> In-Reply-To: <4E3ADAE2.5060907@pi.nu> Date: Tue, 23 Aug 2011 13:47:00 +0100 Message-ID: <075c01cc6192$c0a04470$41e0cd50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENQKYhKOUlIhtb8A= Content-Language: en-gb Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, rtg-dir@ietf.org, pwe3@ietf.org Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:45:58 -0000 Authors, This needs an answer please. It seems to me that you really don't want your hash algorithm examining labels, but also Loa is right that GAL could mess things up. Your thoughts? Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: 04 August 2011 18:46 > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; pwe3@ietf.org; draft-ietf-pwe3-fat.all@tools.ietf.org > Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 > > All, > > > I have one more point on this - I should have captured it in > the previous mail but had to think and discuss a bit about it! > > Doing ECMP hashing over the label stack as described is OK, but > has one thing that needs to be taken care of. Introducing a > reserved label - most prominently the GAL - into the label > stack will change the outcome of the hash. Since we are ECMP-ing > on the hash result, we will no longer to be able to guarantee > that normal traffic and OAM packets will no longer be fate > sharing - draft-ietf-pwe3-fat-pw should say explicitly that > reserved labels should be excluded from ECMP hashing. > > /Loa > > On 2011-08-02 14:32, Loa Andersson wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for > > draft-ietf-pwe3-fat-pw-07. > > > > The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review > > is to provide assistance to the Routing ADs. For more information > > about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: draft-ietf-pwe3-fat-pw-07 > > Reviewer: Loa Andersson > > Review Date: 2 Aug 2011 > > IETF LC End Date: 3 Aug 2011 > > Intended Status: Standards Track > > > > Summary: > > I have no major concerns about this document, howver I thing it > > would be good to reslove the mostly editorial comments below > > (especially on the IANA section) before publication. > > > > Comments: > > > > Unexpanded acronyms: > > > > OAM appears in the table of content and as header 7. It is not > > expanded in the document anywhere. Should be done at first occurance. > > > > page 6. The last paragraph of section 1 talks about TC bits > > (and EXP bits). We don't have TC bits - the correct name is TC field. > > > > First paragraph section three: > > This paragraph talks in genral about "load balanced paths" while the > > rest of the document is very specific about ECMP, it is the intention > > that this should work for any load balancing paradigm? > > > > Second paragraph section three: > > Normally a label is assigned by the down stream node, this scheme > > is doing upstream allocation. Don't see a problem under normal > > operation, but if the label "by accident" becomes top of stack > > this could have "interesting" effects. > > > > Sectyion 4 second paagraph: > > > > OLD > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. A PE that is using PW signalling and that does > > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > > A PE that is using PW signalling and which does not receive a FL Sub- > > TLV from its peer MUST NOT include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > NEW > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. An ingress PE that is using PW signalling > > and that does not send a FL Sub-TLV MUST NOT include a flow label > > in the PW packet. An ingress PE that is using PW signalling and > > which does not receive a FL Sub-TLV from its egress peer MUST NOT > > include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > The IANA section: > > > > In the IANA section we should use a TBD entry for the Flow label > > indicator; and maybe add 0x17 as suggest value in the text. > > > > The text in the IANA section needs to aligned with the rest of > > the text, or maybe even better have the rest of the text align > > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > > else but in the iana section. > > > > To make it easier to find the references to the IANA registries > > should start with "Pseudowire Name Spaces (PWE3)" point to > > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > > sub-registry, and ask for assigment of the next free value from > > the Experts review space (suggested value 0x17). > > > > On the other hand it looks like we have an early assigment > > (Flow Label shows up with the value 0x17). If this is the case > > after making the text changes suggest above this should be mentioned > > in the IANA section. > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From stbryant@cisco.com Wed Aug 24 02:50:11 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E09421F8AE9; Wed, 24 Aug 2011 02:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+yMkZ9jzYad; Wed, 24 Aug 2011 02:50:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0795821F8A69; Wed, 24 Aug 2011 02:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4295; q=dns/txt; s=iport; t=1314179480; x=1315389080; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZWiU+g35rsxb50b7DtxR8GPwUN5F6taYBrTKsJy3qxE=; b=Ee+iFOheYYdm3k8FIU4z4EPpq6qpD2LN0bUknbwA8PNLsQ1qhQmVb9fS 5/WGyznr8j04OPP5Lg9KSnbrPdwFGzcAUtFZovSx+syfum/8rYAvnv3l7 yFIRdtasVvWUui7Xqnr2ogBZHIPl5aLQDKOSSnOWdo19OWkM9wlHdAOlt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALzIVE6Q/khL/2dsb2JhbABCp3J3gUABAQEBAgEBAQELBAECASItBgMKARALGAkWDwkDAgECARUwEwEFAgEBHodPBJw3AYMmDwGbeoZJBJMZkHw X-IronPort-AV: E=Sophos;i="4.68,274,1312156800"; d="scan'208";a="112214089" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2011 09:51:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7O9p37R012498; Wed, 24 Aug 2011 09:51:03 GMT Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p7O9p3o9007468; Wed, 24 Aug 2011 10:51:03 +0100 (BST) Message-ID: <4E54C987.5000108@cisco.com> Date: Wed, 24 Aug 2011 10:51:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <4E386CF0.5050700@pi.nu> <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> In-Reply-To: <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org, pwe3@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org, 'Loa Andersson' Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 09:50:11 -0000 On 23/08/2011 13:43, Adrian Farrel wrote: > The authors are snoozing in the sun somewhere. > >> OAM appears in the table of content and as header 7. It is not >> expanded in the document anywhere. Should be done at first occurance. > RFC Ed note entered > >> page 6. The last paragraph of section 1 talks about TC bits >> (and EXP bits). We don't have TC bits - the correct name is TC field. > RFC Ed note entered > >> First paragraph section three: >> This paragraph talks in genral about "load balanced paths" while the >> rest of the document is very specific about ECMP, it is the intention >> that this should work for any load balancing paradigm? > Authors? Although we invented the FL for ECMP, there are other types of load balance (for example channel bonding and link bundling) that might which to take advantage of the flow identification. This was discussed by the WG LC. >> Second paragraph section three: >> Normally a label is assigned by the down stream node, this scheme >> is doing upstream allocation. Don't see a problem under normal >> operation, but if the label "by accident" becomes top of stack >> this could have "interesting" effects. > Think this is mentioned in 1.2 > >> Sectyion 4 second paagraph: >> >> OLD >> The absence of a FL Sub-TLV indicates that the PE is unable to >> process flow labels. A PE that is using PW signalling and that does >> not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. >> A PE that is using PW signalling and which does not receive a FL Sub- >> TLV from its peer MUST NOT include a flow label in the PW packet. >> This preserves backwards compatibility with existing PW >> specifications. >> NEW >> The absence of a FL Sub-TLV indicates that the PE is unable to >> process flow labels. An ingress PE that is using PW signalling >> and that does not send a FL Sub-TLV MUST NOT include a flow label >> in the PW packet. An ingress PE that is using PW signalling and >> which does not receive a FL Sub-TLV from its egress peer MUST NOT >> include a flow label in the PW packet. >> This preserves backwards compatibility with existing PW >> specifications. >> END > I think this is right. No doubt the authors were thinking of bidirectional PWs, > but with current state of the art, I think Loa is right and have entered the RFC > Ed note The change is I think the addition of the term "An ingress". Surely it is redundant (but harmless) as only an ingress PE can impose a FL ... or are you concerned to discriminate between TPE and SPE? > >> The IANA section: >> >> In the IANA section we should use a TBD entry for the Flow label >> indicator; and maybe add 0x17 as suggest value in the text. > I think this is wrong because early allocation was done (as you note below). > IANA has indicated they understand the action. > >> The text in the IANA section needs to aligned with the rest of >> the text, or maybe even better have the rest of the text align >> with the IANA section; e.g. Flow Labe intdicator is not used anywhere >> else but in the iana section. > OLD > o FL (value 0x17) is the flow label sub-TLV identifier assigned by > IANA (seeSection 11 ). > NEW > o FL (value 0x17) is the flow label indicator sub-TLV identifier > assigned by IANA (see Section 11). > END > >> To make it easier to find the references to the IANA registries >> should start with "Pseudowire Name Spaces (PWE3)" point to >> "Pseudowire Interface Parameters Sub-TLV type Registry" as a >> sub-registry, and ask for assigment of the next free value from >> the Experts review space (suggested value 0x17). >> >> On the other hand it looks like we have an early assignment >> (Flow Label shows up with the value 0x17). If this is the case >> after making the text changes suggest above this should be mentioned >> in the IANA section. > RFC Ed note entered > > Thanks, > Adrian > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adrian@olddog.co.uk Wed Aug 24 06:19:37 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABEB21F8AF0; Wed, 24 Aug 2011 06:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynmu8cGcz04N; Wed, 24 Aug 2011 06:19:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 091C521F8AE6; Wed, 24 Aug 2011 06:19:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7ODKhcl024766; Wed, 24 Aug 2011 14:20:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7ODKfAp024759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 14:20:42 +0100 From: "Adrian Farrel" To: References: <4E386CF0.5050700@pi.nu> <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> <4E54C987.5000108@cisco.com> In-Reply-To: <4E54C987.5000108@cisco.com> Date: Wed, 24 Aug 2011 14:20:41 +0100 Message-ID: <00f401cc6260$9fb14880$df13d980$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENQKPj7ffAiMSCC2UeTgk0A== Content-Language: en-gb Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, rtg-dir@ietf.org, rtg-ads@tools.ietf.org, pwe3@ietf.org, 'Loa Andersson' Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:19:37 -0000 [Fixing the tools alias] > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 24 August 2011 10:51 > To: adrian@olddog.co.uk > Cc: 'Loa Andersson'; rtg-ads@tools.ietf.org; rtg-dir@ietf.org; pwe3@ietf.org; > draft-ietf-pwe3-fat.all@tools.ietf.org > Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 > > On 23/08/2011 13:43, Adrian Farrel wrote: > > The authors are snoozing in the sun somewhere. > > > >> OAM appears in the table of content and as header 7. It is not > >> expanded in the document anywhere. Should be done at first occurance. > > RFC Ed note entered > > > >> page 6. The last paragraph of section 1 talks about TC bits > >> (and EXP bits). We don't have TC bits - the correct name is TC field. > > RFC Ed note entered > > > >> First paragraph section three: > >> This paragraph talks in genral about "load balanced paths" while the > >> rest of the document is very specific about ECMP, it is the intention > >> that this should work for any load balancing paradigm? > > Authors? > Although we invented the FL for ECMP, there are other types > of load balance (for example channel bonding and link bundling) > that might which to take advantage of the flow identification. > This was discussed by the WG LC. > > >> Second paragraph section three: > >> Normally a label is assigned by the down stream node, this scheme > >> is doing upstream allocation. Don't see a problem under normal > >> operation, but if the label "by accident" becomes top of stack > >> this could have "interesting" effects. > > Think this is mentioned in 1.2 > > > >> Sectyion 4 second paagraph: > >> > >> OLD > >> The absence of a FL Sub-TLV indicates that the PE is unable to > >> process flow labels. A PE that is using PW signalling and that does > >> not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > >> A PE that is using PW signalling and which does not receive a FL Sub- > >> TLV from its peer MUST NOT include a flow label in the PW packet. > >> This preserves backwards compatibility with existing PW > >> specifications. > >> NEW > >> The absence of a FL Sub-TLV indicates that the PE is unable to > >> process flow labels. An ingress PE that is using PW signalling > >> and that does not send a FL Sub-TLV MUST NOT include a flow label > >> in the PW packet. An ingress PE that is using PW signalling and > >> which does not receive a FL Sub-TLV from its egress peer MUST NOT > >> include a flow label in the PW packet. > >> This preserves backwards compatibility with existing PW > >> specifications. > >> END > > I think this is right. No doubt the authors were thinking of bidirectional PWs, > > but with current state of the art, I think Loa is right and have entered the RFC > > Ed note > > The change is I think the addition of the term "An ingress". Surely it > is redundant (but harmless) as only an ingress PE can impose a FL ... > or are you concerned to discriminate between TPE and SPE? > > >> The IANA section: > >> > >> In the IANA section we should use a TBD entry for the Flow label > >> indicator; and maybe add 0x17 as suggest value in the text. > > I think this is wrong because early allocation was done (as you note below). > > IANA has indicated they understand the action. > > > >> The text in the IANA section needs to aligned with the rest of > >> the text, or maybe even better have the rest of the text align > >> with the IANA section; e.g. Flow Labe intdicator is not used anywhere > >> else but in the iana section. > > OLD > > o FL (value 0x17) is the flow label sub-TLV identifier assigned by > > IANA (seeSection 11 ). > > NEW > > o FL (value 0x17) is the flow label indicator sub-TLV identifier > > assigned by IANA (see Section 11). > > END > > > >> To make it easier to find the references to the IANA registries > >> should start with "Pseudowire Name Spaces (PWE3)" point to > >> "Pseudowire Interface Parameters Sub-TLV type Registry" as a > >> sub-registry, and ask for assigment of the next free value from > >> the Experts review space (suggested value 0x17). > >> > >> On the other hand it looks like we have an early assignment > >> (Flow Label shows up with the value 0x17). If this is the case > >> after making the text changes suggest above this should be mentioned > >> in the IANA section. > > RFC Ed note entered > > > > Thanks, > > Adrian From takeda.tomonori@lab.ntt.co.jp Mon Aug 29 05:29:54 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6620421F8AF2 for ; Mon, 29 Aug 2011 05:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXAJFQZqPv40 for ; Mon, 29 Aug 2011 05:29:54 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id D401221F8AF8 for ; Mon, 29 Aug 2011 05:29:53 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id p7TCVG56015326; Mon, 29 Aug 2011 21:31:16 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BC2EB6D6F; Mon, 29 Aug 2011 21:31:16 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B707D6D6B; Mon, 29 Aug 2011 21:31:16 +0900 (JST) Received: from [129.60.80.55] (panasonic.nslab.ecl.ntt.co.jp [129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p7TCVGMg028316; Mon, 29 Aug 2011 21:31:16 +0900 Message-ID: <4E5B868E.6020702@lab.ntt.co.jp> Date: Mon, 29 Aug 2011 21:31:10 +0900 From: Tomonori Takeda User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja-JP; rv:1.9.2.15) Gecko/20110323 Lanikai/3.1.9 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: draft-ietf-intarea-ipv6-required.all@tools.ietf.org, rtg-dir@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-intarea-ipv6-required-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:29:54 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-intarea-ipv6-required-01.txt Reviewer: Tomonori Takeda Review Date: August 29, 2011 IETF LC End Date: September 2, 2011 Intended Status: Standards Track Summary: No issues found. This document is ready for publication. Comments: This document redefines an IP-capable node as one which supports IPv6 only or IPv4/IPv6 dual stack. This document updates various RFCs to reflect this change. NOTE: My viewpoint of reviewing this document is the impact on IP/(G)MPLS routers. Major Issues: None Minor Issues: None Nits: None Thanks, Tomonori Takeda From thomas@thomasclausen.org Tue Aug 30 00:46:19 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B08A21F891D for ; Tue, 30 Aug 2011 00:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3ftQ4IG-Dyg for ; Tue, 30 Aug 2011 00:46:17 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id B8DC821F88B7 for ; Tue, 30 Aug 2011 00:46:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9532D4300E4; Tue, 30 Aug 2011 00:47:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.1.5] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 25F2443007E; Tue, 30 Aug 2011 00:47:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: Date: Tue, 30 Aug 2011 09:47:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5948F513-A5C8-4474-A693-AE48DC38845C@thomasclausen.org> References: To: Yiqun Cai X-Mailer: Apple Mail (2.1244.3) Cc: rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 07:46:19 -0000 Dear Yiqun, Thank you for your detailed reply to my review. As a reviewer, I = appreciate when the authors engage such as you have done, and I am = pleased to continue in these iterations with you. Do accept my apologies = for the delay in getting back to you - life had a way of interfering in = an unpredictable manner these past two weeks, but I should be back now.=20= Executive summary for ADs: o Some suggestions for readability made to the authors o Question as to if Experimental is a more appropriate = status than Proposed Standard, as this document apparently is a first-attempt to do = multicast-multi-topology o Continued issues regarding IANA registry creation / = assignments discussed. o Continued discussion as to clarity of (in-)validation of = received packets I am looking forward to reviewing an updated version of this document.=20= A couple of comments in-line below, after having re-read the I-D and = your email. On Aug 9, 2011, at 23:12 , Yiqun Cai wrote: > Thomas, >=20 > Thank you very much for the review. Please see comments inline. >=20 >=20 > On 6/28/11 9:47 AM, "Thomas Heide Clausen" = wrote: >=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. The >> Routing Directorate seeks to review all routing or routing-related = drafts as >> they pass through IETF last call and IESG review, and sometimes on = special >> request. The purpose of the review is to provide assistance to the = Routing >> ADs. For more information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it would >> be helpful if you could consider them along with any other IETF Last = Call >> comments that you receive, and strive to resolve them through = discussion or by >> updating the draft. >>=20 >> Document: draft-ietf-pim-mtid-08.txt >> Reviewer: Thomas Heide Clausen >> Review Date: 2011-06-27 >> IETF LC End Date: 2011-06-27 >> Intended Status: Proposed Standard >>=20 >> Summary: >>=20 >> I have some minor concerns about this document that I think should be = resolved >> before publication. >>=20 >> Comments: >>=20 >> This is the first PIM document I have reviewed, so I went back and = read some >> of the previous=20 >> RFCs. It may mean that my review is not sufficiently in-depth. >>=20 >> The document is relatively difficult to read. Specifically the = introduction >> reads more like a >> problem statement (e.g. "if PIM was able to access .... it would be = ...") than >> it does a specification. >> I would much prefer to have perhaps a very short motivational = subsection to >> the introduction, >> then introduce that which this document actually introduces (and = how). >> Currently, that is difficult >> to extract. >=20 > This was actually described in the 4th paragraph in the = "Introduction". >=20 > "This document introduces a new type of PIM Join Attribute ...". >=20 > As Marshall pointed out in another review comment, there are = potentially > quite a few use cases that can benefit from this functionality. We = hoped to > capture at least one of them. Marshall is quite right, and I think that you do well in capturing one = in the text.=20 My comment is one of clarity as to what the document provides: "if PIM = was able to =85 it would be=85.." and "This capability would = facilitate=85" etc. reads as a problem statement. I would suggest that = it would be clearer to the reader what this document provides by = phrasing it akin to "Using the PIM Join Attribute, specified in this = document, PIM can =85." and "This capability enables=85." I remember from my initial read-through of the document that I thought = "Well, true, if PIM had this capability it would be nice, someone should = go specify that". As this is the document "specifying that", I suggest = affirming what this document provides, rather than suggesting what PIM = lacks in the introduction. >> I feel that RFC2119 language is not used consistently, and that = terminology in >> general is=20 >> used somewhat inconsistently. Is "MT-ID" and "PIM MT-ID" the same or = different >> things, for example? >> I would suggest that this is in part due to the absence of the by now >> traditional "Terminology" section, >> which (in my opinion) has as its primary role to ensure that = spec-authors are >> conscious and consistent >> in their choice of words inside a spec. >=20 > We will add a section to clarify that. Great, thanks! That will help. I note from the below that you intend to = go through the document for 2119-terminology tightening, which I = appreciate and which I think will help the document. Will you add a = proper terminology section? As a relative newcomer to PIM, I know that = such would have helped me understand the spec. A suggestion here would = also be that this terminology section points to relevant RFCs from which = terminology is imported (ala: "This document furthermore uses the = terminology defined in RFCxxxx, RFCyyyy and RFCzzzz, specifically the = terms foo, bar and foobar"). This, for readability purposes. >> I find that there are some internal inconsistencies in the document, = i.e. >> where it is stating different >> things in different sections (e.g. that one MUST NOT include a MT-ID = Join >> Attribute with value 0 -- >> yet that when performing a validity check, a Join packet with an = MT-ID=3D0 is >> still considered valid). >=20 > Indeed. >=20 > However it was done on practical purpose, >=20 > 1. we want to specify a valid range > 2. we also want to specify what an implementation should behave if = another > implementation includes a value that is outside of that range. >=20 > What we learned from our experience is that if we don't specify how to > handle error cases, we will consistently run into interop issues that = can't > be solved easily. Quite so, I agree that it is good to specify error cases. My issue is, that you state that: o an implementation MUST NOT include a MT-ID Join = Attribute with value 0 o yet, when performing a validity check, join packet with = MT-ID=3D0 is considered valid. If you really mean "MUST NOT", then you must also consider a packet = received that violates that "MUST NOT" as to be invalid. Otherwise, the specification appears incoherent. >> One concern that I do have with the document is, that there are no = references >> to any kind of >> previous work (typically, I would expect this to have been well = studied in >> academia) suggesting >> the usefulness and justifying the validity of the proposed approach. = Note: I >> am not saying that >> the approach isn't useful and valid - I am saying that I do not know, = and >> would feel comforted by >> some supporting references to this effect. >=20 > Actually, this is the first attempt to integrate multi-topology = routing > with multicast. Oh=85..this raises a red flag with me, then, even more than before. My = worry when I read through the document was, that I had no idea if, or = how well, it would work in an operational setting, so I looked to the = references for some evidence - be that a whitepaper documenting an = operational deployment, or academic studies, or the like. Finding = nothing of the kind did leave me concerned as to if we understood the = validity of the proposal, which was why I raised this issue in my = review.=20 You tell me that this is a first attempt at integrating multicast and = multi-topology routing - and that is, indeed, both interesting and = commendable.=20 Alas, if you are right in the above (and I have no reason to doubt you), = then I would suggest that this document is a candidate to be published = as "Experimental", rather than as "Proposed Standard", until we have = studied the matter and obtained a better understanding of behavior and = performance characteristics?=20 Were there any WG discussions regarding Exp-vs-PS that I should go look = at? >> Major Issues: >>=20 >> o I have actually not found any single "major issues", however I feel = that the >> document is >> hard to read and that the collection of the "minor issues" below = would >> constitute a single >> "major issue". >>=20 >> Minor Issues: >>=20 >> o The RFC2119 language is typically seen in a terminology section; = something >> which >> I feel that this document should have, if for no reason other than to = help new >> readers >> to PIM family of documents. It could be as simple as importing = (pointing to) >> relevant=20 >> terminology from RFC5496/5384/4601 >=20 > We will fix as suggested. >=20 Thanks. >>=20 >> o Also, the RFC2119 paragraph does not reflect the errata ("NOT = RECOMMENDED" >> is missing) >=20 > Will fix. >=20 Thanks. >>=20 >> o Penultimate paragraph of section 2 "It might further need to = perform the >> function >> of splitting and merging. But the detailed processing is beyond the = scope of >> the=20 >> document". It would be beneficial with elaboration of under which = conditions >> "splitting and merging" is required, as well as some guidance - for = example, >> in form >> of a pointer to where these conditions are detailed. >>=20 >> o Ultimate paragraph of section 2: "the MT-ID Join Attribute may be = simply >> referred to as MT-ID" >> -- suggest "the MT-ID Join Attribute will be referred to as MT-ID >>=20 >=20 > Ok Thanks. >=20 >> o This may be a matter of individual style, but I do not like empty = section >> introductions,=20 >> such as 3.=20 >>=20 >> o 3rd paragraph in 3.1, suggest removing "please" >>=20 >> o Suggest that the figure in 3.1 be given a proper figure environment = and >> number, and >> that references (especially later in the document) be given to that = figure >> number. >>=20 >=20 > Ok. Thanks. >> o As a relatively newcomer to PIM, examples are appreciated. Alas, = the example >> in=20 >> section 3.1 actually didn't help my understanding much. Also, that = example is >> filled with details, whose importance I am not sure I capture: is the = choice >> of=20 >> "OSPF 1000" and "OSPF 2000" (etc.) important, or are they simply = illustrative. >>=20 >=20 > The text was added based on the comment from WG LC. Some people do = like to > see how MT-IDs are assigned numerically. Alright, then. Would it be possible to simply add a sentence clarifying = that these numbers are mere examples, without any other significance? >> o First paragraph on page 5 states "The above example shows that the = naming >> spaces of=20 >> MT-ID are not required to be the same between PIM and IGPs". That = appears >> reasonable=20 >> -- however the last bullet point in section 3.2 on the same page goes = on to >> say that=20 >> "...the PIM MT-ID is RECOMMENDED to be assigned using the same value = as the >> IGP=20 >> topology identifier". >=20 > Yes. The text describes two different cases and provides two = different > recommendations depending on how the topologies are built. RECOMMENDED is a SHOULD - which I read to mean "If you do NOT follow = this recommendation, you should know that there may be consequences - = and these consequences are =85.." See below. >> Citing RFC2119: >>=20 >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that = there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. >>=20 >> It appears to me that if this RFC2119 meaning is intended, then it = would be >> important >> to (i) explain why and (ii) give guidance as to understand what the >> implications are of >> not following the recommendation. My issue with this text is that you say "RECOMMENDED" - but that I do = not see any consequences of following (or not) the recommendation. In = other words, the 2119-meaning of "RECOMMENDED" appears to be too strong. = Maybe writing "suggested" (lower-case, non-2119) would suffice?=20 In either case, I would like to understand why you recommend or suggest = this. Could you add an explanatory sentence/paragraph? >> o Also, the document contains many uses of "must", "may" and "should" = in >> lowercase - I am >> wondering if some (all?) of these should be capitalized to RFC2119 = terms. I am >> trying to >> point out those I catch, but I would recommend that the authors = review the >> document to >> ensure that they capitalize those where they mean RFC2119 = terminology. >>=20 >=20 > We will go through the document one more time and fix them if = appropriate. Thanks. >> o On the same first paragraph on page 5, when I read " .... shows = that ....", >> then I actually >> expect a bit more rigor - tainted by having spent too much time in = academia, >> perhaps, >> but I read "...shows that ..." to entail (close to) a formal proof. = Maybe >> "....illustrates that..." >> is a better choice of words? >>=20 >=20 > Sure. Thanks. >> Same holds for the last bullet point on page 5. >>=20 >> o Same paragraph, what exactly is meant by "...the prefix covering = S...."? I >> assume that >> it has something to do with that routing state for S is not = maintained by the >> two routing >> topologies? >>=20 >=20 > In multicast jargons, S usually refers to a /32 host address = (assuming > IPv4). But the routing table usually contains only a prefix that = covers or > includes S, instead of S. OK, let's ascribe that to me not knowing multicast jargon ;)=20 I suggest inserting a rephrasing of this paragraph into the terminology = section, then? >> o Generally to section 3.1, it is somewhat unclear what this = specification >> does, vs. what >> PIM already does, which caused me to chase off reading PIM RFCs. >>=20 >> Reading through the specification, would it be correct to say that: >>=20 >> - This I-D introduces a new name-space, the "PIM MT-ID" >> - A given topology is provisioned with that "PIM MT-ID" by way of a >> "MT-ID PIM Join Attribute", defined by this specification? >>=20 >> If yes, then I would suggest calling that out explicitly. >=20 > No it is not a new name-space. >=20 > This document introduces a new type of Join Attribute which was = introduced > by RFC5384. Then I strongly suggest stating that, almost as you phrased it above, in = section 3. >=20 >>=20 >> o Section 3.2, second bullet-point talks about "...a value is not = required to >> be the same as=20 >> the MT-ID used by the unicast routing protocol ...." However the = ultimate >> paragraph in >> section 2 defines MT-ID to be a "Join Attribute", which is a = PIM-entity >> (RFC5384). Do >> you mean to say that this MT-ID should be used also in an unicast = routing >> protocol, or >> is it a terminology issue? >=20 > MT-ID is used by unicast routing protocols (such as OSPF and IS-IS). = This > document introduces its use to PIM via PIM Join Attribute. >=20 I _think_ that this will be addressed by the previous comment on = RECOMMENDED, so I will await that. >>=20 >> o Page 6, second bullet "This value must be unique and consistent = within the >> network domain...." >>=20 >> - must or MUST? >> - "network domain" is a wonderfully vague term. A quick google leads = to the >> first many results relating to either "LAN-style domain controllers" = or DNS. >> Suggest that his might be a good candidate term for replacement, or = for >> definition in a terminology section. >=20 > It is probably better that we remove "domain". Thanks. >> o Section 4.2.1, "...it may chose" - may or MAY? Also, can guideline = be given >> as to when >> a PIM router would chose to, or not, encode the PIM MT-ID? Finally, = "PIM >> MT-ID", is that >> the same as what the ultimate paragraph of section 2 calls "MT-ID". >=20 > In this document, yes they are the same. If they are the same, then I suggest picking one, defining in a = terminology section - and sticking to that choice through the document. = If both terms are used in literature, pick the most used term, and have = the terminology section state "MT-ID - is . In some = literature, this is also occasionally called PIM MT-ID"=20 >=20 >>=20 >> o Section 4.2.1: missing colon before bullet points >>=20 >> o Section 4.2.1 first bullet point: why MUST NOT? What are the = consequences of >> including a Join Attribute when the MT-ID=3D0? >> Specifically, in 4.2.3, the ultimate bullet, the validation rules = simply state >> that if >> the value is 0, then the Join Attribute "...is ignored" (there is a = SHOULD or >> MUST=20 >> needed here?) and that the rest of the message is processed as if = that Join >> Attribute was not included. >=20 > In common practice (as with OSPF and IS-IS too), 0 is reserved for > "default" topology. Including 0 will cause unnecessary interop issues = that > brings no additional gain. Thus we prevent the inclusion of it. This actually links in with the IANA section of this document, which I = find somewhat hard to read/parse. You mention that you will rework that, = so I look forward to seeing an updated version.=20 Still, does this document create an IANA registry for MT-IDs? Generally, = I would expect an I-D to state something of the form: "IANA is requested to create a registry for =85.. with initial = assignments and allocation policies according to table 42" (which the RFC editor tends to reword to something like "IANA has = created a registry for =85.") This makes it clear if the registry, its policies, etc., are to be found = in this document, and are therefore completely documented in this = document. If this document does not create said IANA registry, I would expect the = IANA section to say something like "IANA is requested to allocate a =85. = from the XXXX registry, defined in RFCxxxx" - that way I would know = where to go look for assignments, policies, =85. Now, if this document creates an IANA registry for MT-IDs, then setting = aside 0 as a non-allocatable, non-usable value simply removes a value = from that space - there's nothing "magic" as such about the number 0. If = there is a common practice that a specific value such as 0 has a = commonly understood meaning, and that therefore that value should be = avoided, it would actually be immensely useful to have that explanation = with the IANA registry creation - effectively this would be guidance to = IANA as to how to assign values from that registry. If this document doesn't create that IANA registry, then I would expect = this discussion to be in the document which does? >> o Section 4.2.1 2nd and 3rd bullet points, why "SHOULD NOT"? Can any = guidance >> be provided with respect to the consequences of ignoring such = recommendation >> (or, if there are no negative consequences, then the benefits of = following >> them)? >>=20 >=20 > Because these packets do not require the receiving router to perform = any RPF > action. And when a router doesn't perform RPF action, MT-ID is not = needed. Suggest saying that in the document. Is it a SHOULD or a MUST? It sounds = a bit like a MUST to me? >> o Section 4.2.2 first bullet - prefer section references (if using = xml2rfc >> tags) >> rather than "next section" or "in section Conflict Resolution". This = is a >> general comment, >> but this seemed like a good point to mention this. >>=20 > Ok >=20 Thanks. >> o Section 4.2.3, first bullet: as t his is about "Validating a PIM = MT-ID Join >> Attribute", I find it >> curious that it suggests to check that there is at most 1 PIM MT-ID = Join >> Attribute included - >> then goes on to say that it's OK if there are more, just ignore all = but the >> last. I would suggest >> that either this is a validation check and so if more than 1 PIM = MT-ID Join >> Attribute then >> the packet is malformed and should be discarded - or, that this be = specified >> somewhere >> other than a section specifying how to determine if an attribute is = valid or >> not. >=20 > That is exactly why we wanted to include this document how to handle = error > case. We can choose to discard, or ignore the attributes but continue = with > the next update. The second is more appropriate for PIM because > "discarding" would require a rewinding of the operation already done = on > previous PDUs which is hard to do. That's fine, but then it is not "Validating" - a packet with one or more = PIM MT-ID Join Attributes are all valid.=20 You state that an implementation must validate "There is at most 1 PIM = MT-ID attribute encoded". Therefore, if I receive a packet with 2, it = can't be valid. Yet, in the next sentence you say that it's ok if there = are more than one, just use the last. Either it is "at most 1" or it is "there may be more, use the last". It = can't be both. By the way, you use the terms "encoded" and "included" for PIM MT-ID = attributes in this bullet, both. Are there any differences? If yes, what = are they? If no, why different words? >> o Same section & bullet: the title is "Validating a PIM MT-ID Join = Attribute", >> i.e. validating _a_ single >> such. Yet, the bullet talks about having possibly multiple PIM MT-ID = Join >> Attributes encoded. >> Encoded where? Should this section be retitled "Validating a Join = Packet with >> a PIM MT-ID=20 >> Join Attribute" instead? >=20 > The paragraph does attempt to describe how to validate the particular = type > of Join Attribute that is PIM MT-ID. It doesn't specify how to = validate > Join Attributes or the Join message in general. Then it is even more confusing. Would "Validating PIM MT-ID Join = Attributes in a received Join Packet" be a more correct title (we can = fuss over if it is too long or not, but semantically it seems more = correct)? >=20 >>=20 >> o Section 5: Suggest that encoding, byte-order, ..., be called out = (NBO, >> unsigned integer, ....) for >> newly defined fields. >>=20 >=20 > Ok. Thanks. >=20 >> o Section 5: Suggest calling out that reserved bits SHOULD be cleared = on >> transmission and=20 >> MUST be ignored on reception. >>=20 >=20 > Yes it s ithere. >=20 Sorry, no, I do not find that. Can you point me to where you say that, = please? >> o Section 5: Suggest citing the spec defining the format used = (RFC5384?), >> least it appears >> odd to have an 8 bit "Length" field, and yet defining its value to = always be >> 2. >>=20 >=20 > That would be RFC4601. >=20 >> o Section 6, IANA considerations. >>=20 >> - Suggest that "The IANA" be replaced by simply "IANA" >>=20 >=20 > Ok. >=20 >> - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option = Type >> ...." >>=20 >=20 > Not yet but IANA will. See comment above. The IANA section contains instructions to what we as = protocol authors request (kindly) that the good folks at IANA do for us. = To make their life easier (and the document more readable), suggest = rephrasing as instructions (as also discussed above with registry = creation). >> - I do not understand what the IANA action for the ultimate paragraph = in 6.1 >> is about? >>=20 >=20 > The headings are wrong. We will fix them. >=20 Thanks. Respectfully Yours, Thomas >> Respectfully Yours, >>=20 >> Thomas >=20 > Thanks again. >=20 >=20 > --=20 > Yiqun >=20 From jari.arkko@piuha.net Mon Aug 29 05:35:43 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292BB21F8B11 for ; Mon, 29 Aug 2011 05:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBxd1vZBSGAz for ; Mon, 29 Aug 2011 05:35:42 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5888221F8B09 for ; Mon, 29 Aug 2011 05:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DE3282D223; Mon, 29 Aug 2011 15:36:58 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3H1+zAwFYtw; Mon, 29 Aug 2011 15:36:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1A7BC2CE66; Mon, 29 Aug 2011 15:36:57 +0300 (EEST) Message-ID: <4E5B87E8.1090807@piuha.net> Date: Mon, 29 Aug 2011 15:36:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Tomonori Takeda References: <4E5B868E.6020702@lab.ntt.co.jp> In-Reply-To: <4E5B868E.6020702@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Aug 2011 09:39:36 -0700 Cc: draft-ietf-intarea-ipv6-required.all@tools.ietf.org, rtg-dir@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-intarea-ipv6-required-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:35:43 -0000 Thanks for your review. Jari On 29.08.2011 15:31, Tomonori Takeda wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-intarea-ipv6-required-01.txt > Reviewer: Tomonori Takeda > Review Date: August 29, 2011 > IETF LC End Date: September 2, 2011 > Intended Status: Standards Track > > Summary: > > No issues found. This document is ready for publication. > > Comments: > > This document redefines an IP-capable node as one which supports IPv6 > only or IPv4/IPv6 dual stack. This document updates various RFCs to > reflect this change. > > NOTE: My viewpoint of reviewing this document is the impact on > IP/(G)MPLS routers. > > Major Issues: > > None > > Minor Issues: > > None > > Nits: > > None > > > Thanks, > Tomonori Takeda > From ycai@cisco.com Tue Aug 30 18:29:24 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15B21F8E75 for ; Tue, 30 Aug 2011 18:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7nInEk07JLg for ; Tue, 30 Aug 2011 18:29:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8885A21F8E74 for ; Tue, 30 Aug 2011 18:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=25294; q=dns/txt; s=iport; t=1314754251; x=1315963851; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Tpj/YQgn6vkgV/79I2XB2gcDbXj9gJOx3ObhOI4tJto=; b=manYimx0xCQ9gQRtHPcm1K6JsEDuX+efetVf+X/KdZ8DBooGUkrtg/JA 1clm16Mr0aaht4gT7b4zwRB1T5WsTxez9vBHRDSztWpz+LO8YH57nH9ZX uA/KQ4XmFVW40oMog91Yl+kDfxl+1vF1uYovcCGZxN4dd7wnnjzl72ib2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJmNXU6rRDoG/2dsb2JhbABCp1dsd4FAAQEBAQIBEgEHIgEvCgMFDQEIFASBBQEBBA4FCRAJh1AEmRUBnxyGVASHOC+LPoUXjA4 X-IronPort-AV: E=Sophos;i="4.68,304,1312156800"; d="scan'208";a="17998707" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 31 Aug 2011 01:30:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7V1UoLu009955; Wed, 31 Aug 2011 01:30:50 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 18:30:50 -0700 Received: from 10.155.35.16 ([10.155.35.16]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 Aug 2011 01:30:49 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 30 Aug 2011 18:31:32 -0700 From: Yiqun Cai To: Thomas Heide Clausen Message-ID: Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt Thread-Index: Acxnfbaoz/tAs+shx0+NIagY9VJkHQ== In-Reply-To: <5948F513-A5C8-4474-A693-AE48DC38845C@thomasclausen.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 31 Aug 2011 01:30:50.0196 (UTC) FILETIME=[9DBE2940:01CC677D] X-Mailman-Approved-At: Tue, 30 Aug 2011 22:03:46 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 01:29:24 -0000 Thomas, Thanks for the comment. We will review it and get back to you some time next week or the week after (next week is a short week here in the US). Thanks. On 8/30/11 12:47 AM, "Thomas Heide Clausen" wrote: > Dear Yiqun, >=20 > Thank you for your detailed reply to my review. As a reviewer, I apprecia= te > when the authors engage such as you have done, and I am pleased to conti= nue > in these iterations with you. Do accept my apologies for the delay in get= ting > back to you - life had a way of interfering in an unpredictable manner th= ese > past two weeks, but I should be back now. >=20 > Executive summary for ADs: >=20 > o Some suggestions for readability made to the authors >=20 > o Question as to if Experimental is a more appropriate status than Propos= ed > Standard, as > this document apparently is a first-attempt to do multicast-multi-topolog= y >=20 > o Continued issues regarding IANA registry creation / assignments discuss= ed. >=20 > o Continued discussion as to clarity of (in-)validation of received packe= ts >=20 > I am looking forward to reviewing an updated version of this document. >=20 > A couple of comments in-line below, after having re-read the I-D and your > email. >=20 > On Aug 9, 2011, at 23:12 , Yiqun Cai wrote: >=20 >> Thomas, >>=20 >> Thank you very much for the review. Please see comments inline. >>=20 >>=20 >> On 6/28/11 9:47 AM, "Thomas Heide Clausen" wr= ote: >>=20 >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this draft= . The >>> Routing Directorate seeks to review all routing or routing-related draf= ts as >>> they pass through IETF last call and IESG review, and sometimes on spec= ial >>> request. The purpose of the review is to provide assistance to the Rout= ing >>> ADs. For more information about the Routing Directorate, please see >>> http://www.ietf.org/iesg/directorate/routing.html >>>=20 >>> Although these comments are primarily for the use of the Routing ADs, i= t >>> would >>> be helpful if you could consider them along with any other IETF Last Ca= ll >>> comments that you receive, and strive to resolve them through discussio= n or >>> by >>> updating the draft. >>>=20 >>> Document: draft-ietf-pim-mtid-08.txt >>> Reviewer: Thomas Heide Clausen >>> Review Date: 2011-06-27 >>> IETF LC End Date: 2011-06-27 >>> Intended Status: Proposed Standard >>>=20 >>> Summary: >>>=20 >>> I have some minor concerns about this document that I think should be >>> resolved >>> before publication. >>>=20 >>> Comments: >>>=20 >>> This is the first PIM document I have reviewed, so I went back and read= some >>> of the previous >>> RFCs. It may mean that my review is not sufficiently in-depth. >>>=20 >>> The document is relatively difficult to read. Specifically the introduc= tion >>> reads more like a >>> problem statement (e.g. "if PIM was able to access .... it would be ...= ") >>> than >>> it does a specification. >>> I would much prefer to have perhaps a very short motivational subsectio= n to >>> the introduction, >>> then introduce that which this document actually introduces (and how). >>> Currently, that is difficult >>> to extract. >>=20 >> This was actually described in the 4th paragraph in the "Introduction". >>=20 >> "This document introduces a new type of PIM Join Attribute ...". >>=20 >> As Marshall pointed out in another review comment, there are potentiall= y >> quite a few use cases that can benefit from this functionality. We hope= d to >> capture at least one of them. >=20 > Marshall is quite right, and I think that you do well in capturing one in= the > text.=20 >=20 > My comment is one of clarity as to what the document provides: "if PIM w= as > able to =8A it would be=8A.." and "This capability would facilitate=8A" etc. r= eads > as a problem statement. I would suggest that it would be clearer to the r= eader > what this document provides by phrasing it akin to "Using the PIM Join > Attribute, specified in this document, PIM can =8A." and "This capability > enables=8A." >=20 > I remember from my initial read-through of the document that I thought "W= ell, > true, if PIM had this capability it would be nice, someone should go spec= ify > that". As this is the document "specifying that", I suggest affirming wha= t > this document provides, rather than suggesting what PIM lacks in the > introduction. >=20 >=20 >=20 >>> I feel that RFC2119 language is not used consistently, and that termino= logy >>> in >>> general is=20 >>> used somewhat inconsistently. Is "MT-ID" and "PIM MT-ID" the same or >>> different >>> things, for example? >>> I would suggest that this is in part due to the absence of the by now >>> traditional "Terminology" section, >>> which (in my opinion) has as its primary role to ensure that spec-autho= rs >>> are >>> conscious and consistent >>> in their choice of words inside a spec. >>=20 >> We will add a section to clarify that. >=20 > Great, thanks! That will help. I note from the below that you intend to g= o > through the document for 2119-terminology tightening, which I appreciate = and > which I think will help the document. Will you add a proper terminology > section? As a relative newcomer to PIM, I know that such would have helpe= d me > understand the spec. A suggestion here would also be that this terminolog= y > section points to relevant RFCs from which terminology is imported (ala: = "This > document furthermore uses the terminology defined in RFCxxxx, RFCyyyy and > RFCzzzz, specifically the terms foo, bar and foobar"). This, for readabil= ity > purposes. >=20 >>> I find that there are some internal inconsistencies in the document, i.= e. >>> where it is stating different >>> things in different sections (e.g. that one MUST NOT include a MT-ID Jo= in >>> Attribute with value 0 -- >>> yet that when performing a validity check, a Join packet with an MT-ID=3D= 0 is >>> still considered valid). >>=20 >> Indeed. >>=20 >> However it was done on practical purpose, >>=20 >> 1. we want to specify a valid range >> 2. we also want to specify what an implementation should behave if anot= her >> implementation includes a value that is outside of that range. >>=20 >> What we learned from our experience is that if we don't specify how to >> handle error cases, we will consistently run into interop issues that ca= n't >> be solved easily. >=20 > Quite so, I agree that it is good to specify error cases. >=20 > My issue is, that you state that: >=20 > o an implementation MUST NOT include a MT-ID Join Attribute with value 0 > o yet, when performing a validity check, join packet with MT-ID=3D0 is > considered valid. >=20 > If you really mean "MUST NOT", then you must also consider a packet recei= ved > that violates that "MUST NOT" as to be invalid. >=20 > Otherwise, the specification appears incoherent. >=20 >=20 >>> One concern that I do have with the document is, that there are no >>> references >>> to any kind of >>> previous work (typically, I would expect this to have been well studie= d in >>> academia) suggesting >>> the usefulness and justifying the validity of the proposed approach. No= te: I >>> am not saying that >>> the approach isn't useful and valid - I am saying that I do not know, a= nd >>> would feel comforted by >>> some supporting references to this effect. >>=20 >> Actually, this is the first attempt to integrate multi-topology routing >> with multicast. >=20 > Oh=8A..this raises a red flag with me, then, even more than before. My worr= y > when I read through the document was, that I had no idea if, or how well,= it > would work in an operational setting, so I looked to the references for s= ome > evidence - be that a whitepaper documenting an operational deployment, or > academic studies, or the like. Finding nothing of the kind did leave me > concerned as to if we understood the validity of the proposal, which was = why I > raised this issue in my review. >=20 > You tell me that this is a first attempt at integrating multicast and > multi-topology routing - and that is, indeed, both interesting and > commendable.=20 >=20 > Alas, if you are right in the above (and I have no reason to doubt you), = then > I would suggest that this document is a candidate to be published as > "Experimental", rather than as "Proposed Standard", until we have studied= the > matter and obtained a better understanding of behavior and performance > characteristics?=20 >=20 > Were there any WG discussions regarding Exp-vs-PS that I should go look a= t? >=20 >>> Major Issues: >>>=20 >>> o I have actually not found any single "major issues", however I feel t= hat >>> the >>> document is >>> hard to read and that the collection of the "minor issues" below would >>> constitute a single >>> "major issue". >>>=20 >>> Minor Issues: >>>=20 >>> o The RFC2119 language is typically seen in a terminology section; some= thing >>> which >>> I feel that this document should have, if for no reason other than to h= elp >>> new >>> readers >>> to PIM family of documents. It could be as simple as importing (pointin= g to) >>> relevant=20 >>> terminology from RFC5496/5384/4601 >>=20 >> We will fix as suggested. >>=20 >=20 > Thanks. >=20 >>>=20 >>> o Also, the RFC2119 paragraph does not reflect the errata ("NOT RECOMME= NDED" >>> is missing) >>=20 >> Will fix. >>=20 >=20 > Thanks. >=20 >>>=20 >>> o Penultimate paragraph of section 2 "It might further need to perform = the >>> function >>> of splitting and merging. But the detailed processing is beyond the sco= pe of >>> the=20 >>> document". It would be beneficial with elaboration of under which condi= tions >>> "splitting and merging" is required, as well as some guidance - for exa= mple, >>> in form >>> of a pointer to where these conditions are detailed. >>>=20 >>> o Ultimate paragraph of section 2: "the MT-ID Join Attribute may be sim= ply >>> referred to as MT-ID" >>> -- suggest "the MT-ID Join Attribute will be referred to as MT-ID >>>=20 >>=20 >> Ok >=20 > Thanks. >=20 >>=20 >>> o This may be a matter of individual style, but I do not like empty sec= tion >>> introductions,=20 >>> such as 3.=20 >>>=20 >>> o 3rd paragraph in 3.1, suggest removing "please" >>>=20 >>> o Suggest that the figure in 3.1 be given a proper figure environment a= nd >>> number, and >>> that references (especially later in the document) be given to that fig= ure >>> number. >>>=20 >>=20 >> Ok. >=20 > Thanks. >=20 >>> o As a relatively newcomer to PIM, examples are appreciated. Alas, the >>> example >>> in=20 >>> section 3.1 actually didn't help my understanding much. Also, that exam= ple >>> is >>> filled with details, whose importance I am not sure I capture: is the c= hoice >>> of=20 >>> "OSPF 1000" and "OSPF 2000" (etc.) important, or are they simply >>> illustrative. >>>=20 >>=20 >> The text was added based on the comment from WG LC. Some people do like= to >> see how MT-IDs are assigned numerically. >=20 > Alright, then. Would it be possible to simply add a sentence clarifying t= hat > these numbers are mere examples, without any other significance? >=20 >>> o First paragraph on page 5 states "The above example shows that the na= ming >>> spaces of=20 >>> MT-ID are not required to be the same between PIM and IGPs". That appea= rs >>> reasonable=20 >>> -- however the last bullet point in section 3.2 on the same page goes o= n to >>> say that=20 >>> "...the PIM MT-ID is RECOMMENDED to be assigned using the same value as= the >>> IGP=20 >>> topology identifier". >>=20 >> Yes. The text describes two different cases and provides two different >> recommendations depending on how the topologies are built. >=20 > RECOMMENDED is a SHOULD - which I read to mean "If you do NOT follow this > recommendation, you should know that there may be consequences - and thes= e > consequences are =8A.." See below. >=20 >>> Citing RFC2119: >>>=20 >>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. >>>=20 >>> It appears to me that if this RFC2119 meaning is intended, then it woul= d be >>> important >>> to (i) explain why and (ii) give guidance as to understand what the >>> implications are of >>> not following the recommendation. >=20 > My issue with this text is that you say "RECOMMENDED" - but that I do not= see > any consequences of following (or not) the recommendation. In other words= , the > 2119-meaning of "RECOMMENDED" appears to be too strong. Maybe writing > "suggested" (lower-case, non-2119) would suffice? >=20 > In either case, I would like to understand why you recommend or suggest t= his. > Could you add an explanatory sentence/paragraph? >=20 >>> o Also, the document contains many uses of "must", "may" and "should" i= n >>> lowercase - I am >>> wondering if some (all?) of these should be capitalized to RFC2119 term= s. I >>> am >>> trying to >>> point out those I catch, but I would recommend that the authors review = the >>> document to >>> ensure that they capitalize those where they mean RFC2119 terminology. >>>=20 >>=20 >> We will go through the document one more time and fix them if appropriat= e. >=20 > Thanks. >=20 >>> o On the same first paragraph on page 5, when I read " .... shows that >>> ....", >>> then I actually >>> expect a bit more rigor - tainted by having spent too much time in acad= emia, >>> perhaps, >>> but I read "...shows that ..." to entail (close to) a formal proof. May= be >>> "....illustrates that..." >>> is a better choice of words? >>>=20 >>=20 >> Sure. >=20 > Thanks. >=20 >>> Same holds for the last bullet point on page 5. >>>=20 >>> o Same paragraph, what exactly is meant by "...the prefix covering S...= ."? I >>> assume that >>> it has something to do with that routing state for S is not maintained = by >>> the >>> two routing >>> topologies? >>>=20 >>=20 >> In multicast jargons, S usually refers to a /32 host address (assuming >> IPv4). But the routing table usually contains only a prefix that covers= or >> includes S, instead of S. >=20 > OK, let's ascribe that to me not knowing multicast jargon ;) >=20 > I suggest inserting a rephrasing of this paragraph into the terminology > section, then? >=20 >>> o Generally to section 3.1, it is somewhat unclear what this specificat= ion >>> does, vs. what >>> PIM already does, which caused me to chase off reading PIM RFCs. >>>=20 >>> Reading through the specification, would it be correct to say that: >>>=20 >>> - This I-D introduces a new name-space, the "PIM MT-ID" >>> - A given topology is provisioned with that "PIM MT-ID" by way of a >>> "MT-ID PIM Join Attribute", defined by this specification? >>>=20 >>> If yes, then I would suggest calling that out explicitly. >>=20 >> No it is not a new name-space. >>=20 >> This document introduces a new type of Join Attribute which was introduc= ed >> by RFC5384. >=20 > Then I strongly suggest stating that, almost as you phrased it above, in > section 3. >=20 >>=20 >>>=20 >>> o Section 3.2, second bullet-point talks about "...a value is not requi= red >>> to >>> be the same as=20 >>> the MT-ID used by the unicast routing protocol ...." However the ultima= te >>> paragraph in >>> section 2 defines MT-ID to be a "Join Attribute", which is a PIM-entity >>> (RFC5384). Do >>> you mean to say that this MT-ID should be used also in an unicast routi= ng >>> protocol, or >>> is it a terminology issue? >>=20 >> MT-ID is used by unicast routing protocols (such as OSPF and IS-IS). Th= is >> document introduces its use to PIM via PIM Join Attribute. >>=20 >=20 > I _think_ that this will be addressed by the previous comment on RECOMMEN= DED, > so I will await that. >=20 >>>=20 >>> o Page 6, second bullet "This value must be unique and consistent withi= n the >>> network domain...." >>>=20 >>> - must or MUST? >>> - "network domain" is a wonderfully vague term. A quick google leads to= the >>> first many results relating to either "LAN-style domain controllers" or= DNS. >>> Suggest that his might be a good candidate term for replacement, or for >>> definition in a terminology section. >>=20 >> It is probably better that we remove "domain". >=20 > Thanks. >=20 >>> o Section 4.2.1, "...it may chose" - may or MAY? Also, can guideline be >>> given >>> as to when >>> a PIM router would chose to, or not, encode the PIM MT-ID? Finally, "PI= M >>> MT-ID", is that >>> the same as what the ultimate paragraph of section 2 calls "MT-ID". >>=20 >> In this document, yes they are the same. >=20 > If they are the same, then I suggest picking one, defining in a terminolo= gy > section - and sticking to that choice through the document. If both terms= are > used in literature, pick the most used term, and have the terminology sec= tion > state "MT-ID - is . In some literature, this is also occasiona= lly > called PIM MT-ID" >=20 >>=20 >>>=20 >>> o Section 4.2.1: missing colon before bullet points >>>=20 >>> o Section 4.2.1 first bullet point: why MUST NOT? What are the conseque= nces >>> of >>> including a Join Attribute when the MT-ID=3D0? >>> Specifically, in 4.2.3, the ultimate bullet, the validation rules simpl= y >>> state >>> that if >>> the value is 0, then the Join Attribute "...is ignored" (there is a SHO= ULD >>> or >>> MUST=20 >>> needed here?) and that the rest of the message is processed as if that = Join >>> Attribute was not included. >>=20 >> In common practice (as with OSPF and IS-IS too), 0 is reserved for >> "default" topology. Including 0 will cause unnecessary interop issues t= hat >> brings no additional gain. Thus we prevent the inclusion of it. >=20 > This actually links in with the IANA section of this document, which I fi= nd > somewhat hard to read/parse. You mention that you will rework that, so I = look > forward to seeing an updated version. >=20 > Still, does this document create an IANA registry for MT-IDs? Generally, = I > would expect an I-D to state something of the form: >=20 > "IANA is requested to create a registry for =8A.. with initial assignments = and > allocation policies according to table 42" >=20 > (which the RFC editor tends to reword to something like "IANA has created= a > registry for =8A.") >=20 > This makes it clear if the registry, its policies, etc., are to be found = in > this document, and are therefore completely documented in this document. >=20 > If this document does not create said IANA registry, I would expect the I= ANA > section to say something like "IANA is requested to allocate a =8A. from th= e > XXXX registry, defined in RFCxxxx" - that way I would know where to go lo= ok > for assignments, policies, =8A. >=20 > Now, if this document creates an IANA registry for MT-IDs, then setting a= side > 0 as a non-allocatable, non-usable value simply removes a value from that > space - there's nothing "magic" as such about the number 0. If there is a > common practice that a specific value such as 0 has a commonly understood > meaning, and that therefore that value should be avoided, it would actual= ly be > immensely useful to have that explanation with the IANA registry creation= - > effectively this would be guidance to IANA as to how to assign values fro= m > that registry. >=20 > If this document doesn't create that IANA registry, then I would expect t= his > discussion to be in the document which does? >=20 >>> o Section 4.2.1 2nd and 3rd bullet points, why "SHOULD NOT"? Can any >>> guidance >>> be provided with respect to the consequences of ignoring such recommend= ation >>> (or, if there are no negative consequences, then the benefits of follow= ing >>> them)? >>>=20 >>=20 >> Because these packets do not require the receiving router to perform any= RPF >> action. And when a router doesn't perform RPF action, MT-ID is not nee= ded. >=20 > Suggest saying that in the document. Is it a SHOULD or a MUST? It sounds = a bit > like a MUST to me? >=20 >>> o Section 4.2.2 first bullet - prefer section references (if using xml2= rfc >>> tags) >>> rather than "next section" or "in section Conflict Resolution". This is= a >>> general comment, >>> but this seemed like a good point to mention this. >>>=20 >> Ok >>=20 >=20 > Thanks. >=20 >>> o Section 4.2.3, first bullet: as t his is about "Validating a PIM MT-I= D >>> Join >>> Attribute", I find it >>> curious that it suggests to check that there is at most 1 PIM MT-ID Joi= n >>> Attribute included - >>> then goes on to say that it's OK if there are more, just ignore all but= the >>> last. I would suggest >>> that either this is a validation check and so if more than 1 PIM MT-ID = Join >>> Attribute then >>> the packet is malformed and should be discarded - or, that this be spec= ified >>> somewhere >>> other than a section specifying how to determine if an attribute is val= id or >>> not. >>=20 >> That is exactly why we wanted to include this document how to handle err= or >> case. We can choose to discard, or ignore the attributes but continue w= ith >> the next update. The second is more appropriate for PIM because >> "discarding" would require a rewinding of the operation already done on >> previous PDUs which is hard to do. >=20 > That's fine, but then it is not "Validating" - a packet with one or more = PIM > MT-ID Join Attributes are all valid. >=20 > You state that an implementation must validate "There is at most 1 PIM MT= -ID > attribute encoded". Therefore, if I receive a packet with 2, it can't be > valid. Yet, in the next sentence you say that it's ok if there are more t= han > one, just use the last. >=20 > Either it is "at most 1" or it is "there may be more, use the last". It c= an't > be both. >=20 > By the way, you use the terms "encoded" and "included" for PIM MT-ID > attributes in this bullet, both. Are there any differences? If yes, what = are > they? If no, why different words? >=20 >>> o Same section & bullet: the title is "Validating a PIM MT-ID Join >>> Attribute", >>> i.e. validating _a_ single >>> such. Yet, the bullet talks about having possibly multiple PIM MT-ID Jo= in >>> Attributes encoded. >>> Encoded where? Should this section be retitled "Validating a Join Packe= t >>> with >>> a PIM MT-ID=20 >>> Join Attribute" instead? >>=20 >> The paragraph does attempt to describe how to validate the particular ty= pe >> of Join Attribute that is PIM MT-ID. It doesn't specify how to validate >> Join Attributes or the Join message in general. >=20 > Then it is even more confusing. Would "Validating PIM MT-ID Join Attribut= es in > a received Join Packet" be a more correct title (we can fuss over if it i= s too > long or not, but semantically it seems more correct)? >=20 >>=20 >>>=20 >>> o Section 5: Suggest that encoding, byte-order, ..., be called out (NBO= , >>> unsigned integer, ....) for >>> newly defined fields. >>>=20 >>=20 >> Ok. >=20 > Thanks. >=20 >>=20 >>> o Section 5: Suggest calling out that reserved bits SHOULD be cleared o= n >>> transmission and >>> MUST be ignored on reception. >>>=20 >>=20 >> Yes it s ithere. >>=20 >=20 > Sorry, no, I do not find that. Can you point me to where you say that, pl= ease? >=20 >>> o Section 5: Suggest citing the spec defining the format used (RFC5384?= ), >>> least it appears >>> odd to have an 8 bit "Length" field, and yet defining its value to alwa= ys be >>> 2. >>>=20 >>=20 >> That would be RFC4601. >>=20 >>> o Section 6, IANA considerations. >>>=20 >>> - Suggest that "The IANA" be replaced by simply "IANA" >>>=20 >>=20 >> Ok. >>=20 >>> - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option T= ype >>> ...." >>>=20 >>=20 >> Not yet but IANA will. >=20 > See comment above. The IANA section contains instructions to what we as > protocol authors request (kindly) that the good folks at IANA do for us. = To > make their life easier (and the document more readable), suggest rephrasi= ng as > instructions (as also discussed above with registry creation). >=20 >>> - I do not understand what the IANA action for the ultimate paragraph i= n 6.1 >>> is about? >>>=20 >>=20 >> The headings are wrong. We will fix them. >>=20 >=20 > Thanks. >=20 > Respectfully Yours, >=20 > Thomas >=20 >>> Respectfully Yours, >>>=20 >>> Thomas >>=20 >> Thanks again. >>=20 >>=20 >> --=20 >> Yiqun >>=20 >=20 --=20 Yiqun