From mailman-bounces@ietf.org Wed Dec 1 08:52:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29283 for ; Wed, 1 Dec 2004 08:52:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZUz8-0000UY-0O for rpsec-web-archive@ietf.org; Wed, 01 Dec 2004 08:57:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSeP-0000zM-Ff for rpsec-web-archive@ietf.org; Wed, 01 Dec 2004 06:28:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rpsec-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:47:23 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rpsec-web-archive@ietf.org: List Password // URL ---- -------- rpsec@ietf.org lLFY https://www1.ietf.org/mailman/options/rpsec/rpsec-web-archive%40ietf.org From rpsec-bounces@ietf.org Thu Dec 2 12:25:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11530 for ; Thu, 2 Dec 2004 12:25:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZunR-0001tO-4g for rpsec-web-archive@ietf.org; Thu, 02 Dec 2004 12:31:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZqGF-00069S-Ba; Thu, 02 Dec 2004 07:40:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZqCZ-0003Ql-UP; Thu, 02 Dec 2004 07:36:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09185; Thu, 2 Dec 2004 07:36:50 -0500 (EST) Message-Id: <200412021236.HAA09185@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 02 Dec 2004 07:36:50 -0500 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-ospf-vuln-01.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : OSPF Security Vulnerabilities Analysis Author(s) : E. Jones, O. Le Moigne Filename : draft-ietf-rpsec-ospf-vuln-01.txt Pages : 20 Date : 2004-12-1 Internet infrastructure protocols were designed at the very early stages of computer networks when 'cyberspace' was still perceived as a benign environment. As a consequence, malicious attacks were not considered to be a major risk when these protocols were designed, leaving today's Internet vulnerable. This paper provides an analysis of OSPF vulnerabilities that could be exploited to modify the normal routing process across a single domain together with an assessment of when internal OSPF mechanisms can or cannot be leveraged to better secure a domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-ospf-vuln-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-ospf-vuln-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-ospf-vuln-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-2080514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-ospf-vuln-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-ospf-vuln-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-2080514.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --NextPart-- From rpsec-bounces@ietf.org Fri Dec 3 00:42:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13429 for ; Fri, 3 Dec 2004 00:42:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca6IP-0002Dp-D0 for rpsec-web-archive@ietf.org; Fri, 03 Dec 2004 00:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3u2-00088y-Tv; Thu, 02 Dec 2004 22:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca1O3-0003up-P3 for rpsec@megatron.ietf.org; Thu, 02 Dec 2004 19:33:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19385 for ; Thu, 2 Dec 2004 19:33:24 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca1Tf-0003xi-RN for rpsec@ietf.org; Thu, 02 Dec 2004 19:39:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2004 19:41:38 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB30WpbW004089; Thu, 2 Dec 2004 19:32:52 -0500 (EST) Date: Thu, 2 Dec 2004 19:32:14 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part one) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 >> The security of BGP is critical to the continued health and well being >> of large scale internetworks, both public and private. While securing >> the information transmitted between two BGP speakers is a relatively >> easy technical matter, securing BGP, as a routed system, is somewhat >> more complex. This document describes a set of requirements for >> securing BGP, including securing peering relationships between BGP >> speakers, and authenticating routing information carried within BGP. > > I like everything except when you say "somewhat". I will pull that out and > keep the rest... Okay? Fine with me.... >> into a BGP routing infrastructure to force a particular data path for >> traffic that can then be sniffed and used for further destructive >> behavior. >> >> This sentence is, overall, a bit long and unwieldy. Maybe adding a >> couple of commas would make it better, but it might need to be split >> into two sentences. > > Rephrased sentence: These attacks are often combined. That's better. :-) >> "Undetectable or difficult to recognize attacks against the BGP >> protocol itself, attacks falling within the normal operating >> parameters of the BGP protocol, are outside the scope of this >> document." >> >> I'm not certain this revised sentence even says what the group is >> trying to say (?). > > I am not sure I like that sentence very much period. I don't think we > should say that something is difficult so we won't do it. I would rather > say it as follows. Does this sound better? > > Rephrased: Attacks that do not involve direct manipulation of BGP, and > the information contained within it, are outside the scope of this > document. That's much better.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Dec 3 01:03:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14830 for ; Fri, 3 Dec 2004 01:03:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca6dA-0002fc-Pz for rpsec-web-archive@ietf.org; Fri, 03 Dec 2004 01:09:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3uX-0008Oi-Sd; Thu, 02 Dec 2004 22:15:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca1eo-000551-RW for rpsec@megatron.ietf.org; Thu, 02 Dec 2004 19:50:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21274 for ; Thu, 2 Dec 2004 19:50:43 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca1kR-0004Lo-MM for rpsec@ietf.org; Thu, 02 Dec 2004 19:56:36 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2004 19:58:58 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB30oCbW006641; Thu, 2 Dec 2004 19:50:13 -0500 (EST) Date: Thu, 2 Dec 2004 19:49:35 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 2) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db >> "Verifiable, within the context of a routing system, and as it's used in >> this document, means the ability to validate the authorization of a >> specific autonomous system to advertise a given prefix (or block of IP >> addresses), and the ability to verify the immediate peer transmitting >> the update has a route to the destination indicated in the update." >> >> Or something like that (?). Yeah. Another option is just to say verifiable means meeting all the requirements laid out in this doc. In effect, the entire doc explains what is required to create "verifiability" in the routing environment. I don't know how to say that, or to define verifiability in short, without repeating the entire doc (?). Maybe it's worth having some discussion in the group about whether or not the definition should be taken out, or simplt refer to the body of the doc (?). > How about this for a rephrase: Verifiable, within the context of a > routing system, as detailed in this document, means the ability to > validate the originator of a specific prefix (or block of IP addresses) > and the ability to validate the session through which the prefix was > received. This would work, since it refers to the rest of the doc, as well. >> o Any developed and deployed security system MUST NOT disallow the >> forming of peering relationships between secure and nonsevure BGP >> speakers, and MUST be backward compatible in the formatting, >> transmission, and processing of routing information transmitted >> through a BGP peering session. The BGP peering FSM SHOULD be >> preserved. > > It probably works better if we just say "MUST allow" (I hate double > negatives). I think the legacy peering FSM bits MUST be preferred. > Otherwise badness eh? The case where it does not have to be preserved > would be a brand new "secured" connection. Yes, a single positive would be not be not better than a double negative. Or something like that. >> This supports the Incremental Deployment requirement above. >> >> o Any proposed security system SHOULD support the intermixing of >> secured and unsecured routes in a single BGP session between a >> single pair of BGP speakers. BGP implementations SHOULD be able >> to distinguish secured and unsecured routes without reference to >> items that can be stripped from a propagated routing update. > > This was a bit painful to parse. The way I read it though it sounds like > we are getting painted into a corner. Does this mean a whole new > "secured" prefix propagation system is necessary? Not necessarily.... I kindof threw the second sentence in because I was thinking about it at the time I was writing. :-) What' I'm trying to get at here is that if you can strip stuff out of the updates in a partially deployed system, then you can never tell if someone has simply stripped the security "stuff" out, or if the update never had it in the first place. I think this is something that needs to be addressed, someplace, since it's a huge open hole in the way things work. Something like IRV (if anyone remembers what that is/was), for instance, works around that problem. Distributing the security information seperate from the update would also solve this. I think we need some discussion around this, and decide if this is a problem that actually needs to be addressed, and what the wording addressing it should looke like. > Since the paragraph will be rephrased in the bullets I agree. However, I > think we need to come to terms with the secured propagation thing. We > put the mix of secured/unsecured routing bit of that paragraph in there > to cover flag days etc... Right.... Exactly. And the part I'm discussing above is part of the same problem, I think. > I got two very nice emails on this from Radia and Tao (on the other > thread). I will forward to the group. I saw those.... As long as we can reference something that's easy for anyone reading the doc to get to, or several sources, that would be best, rather than trying to explain it all over again. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Dec 3 01:16:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15594 for ; Fri, 3 Dec 2004 01:16:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca6pg-0002uk-KF for rpsec-web-archive@ietf.org; Fri, 03 Dec 2004 01:22:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3v8-0000EE-Rw; Thu, 02 Dec 2004 22:15:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca1vV-0005za-VI for rpsec@megatron.ietf.org; Thu, 02 Dec 2004 20:08:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22950 for ; Thu, 2 Dec 2004 20:08:00 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca219-0004jt-7V for rpsec@ietf.org; Thu, 02 Dec 2004 20:13:51 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2004 20:16:13 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB317SqS008286; Thu, 2 Dec 2004 20:07:29 -0500 (EST) Date: Thu, 2 Dec 2004 20:06:51 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 3) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 >> There are many other ways in which a differential between the speed of >> disseminating the information validating routing information and the >> routing information itself can be exploited to attack the routing >> system on a temporary basis. Because of the possible attacks that >> might be possible during differentials of routing and security >> information, any security system designed to secure BGP MUST provide >> for the distribution of security information at the same speed as the >> distribution of changes in routing information. This would include: >> >> o The distribution of information about the keys used by individual >> actors within the system, including the keys used by individual >> autonomous systems to sign certificates and other objects. >> >> o The distribution of information about the autonomous system >> authorized to advertise a given block of IP addresses (or an >> address space). >> >> o The distribution of information about connectivity between >> autonomous systems and autonomous system policies, if such >> information is distributed within the security system. >> >> Thoughts on this wording? > > Again, very nice... Just one thought though. In a secured BGP system, > if I "own" a prefix and I withdraw it from the routing table no one else > should be able to readvertise it. Yes, this is correct.... > So perhaps the false routing information rationale does not hang together > very well? I would classify it as "nice to have" if a system could prove that information had been withdrawn. I don't know about making it a "must," though, I don't know that we've actually discussed verification of withdrawn information at all in the past (or maybe we did, and I'm just getting too old to remember these things (?)). >> Two types of verification MAY be offered for the NLRI and the >> AS_PATH: >> >> o Contents of the UPDATE message SHOULD be authenticated in >> real-time as the UPDATE message is processed. >> o The route information base MAY be authenticated periodically or in >> an event driven manner by scanning the data and verifying the >> originating AS and the verifiability of the AS-PATH list. >> >> All BGP implementations that implement security MUST utilize at least >> one of the above methods for validating routing information. Real >> time verification is preferred in order to prevent transitive >> failures based on periodic or event driven scan intervals. >> >> I'm not certain we need this section? It seems like this would be >> covered, if anyplace, under the flexibility section before in the >> document, where we discuss the ability to support local trust >> levels. It seems, to me, that the decision to validate routing >> information before or after installation actually bears on your local >> decisions about trust for peers, etc. > > We may want to move the section but it seems that the point is pretty > important. We need to clearly state the two alternatives and attempt to > detail a preference. Anyone else have a thought on that? I would move it, I think.... >> The originating AS of a prefix may occasionally need to be changed >> either due to a re-assignment or a network transition. Any BGP >> security mechanism MUST support the change of an originating AS for a >> prefix within normal convergence times of the internetwork. >> >> I think we can drop this, if we reword the other section above on the >> timeleness of security information within the system. > > Okay... But we need to clearly state it. Those darn vendors will take a > mile if you give them an inch. This is important for operators. We already > have enough barriers to doing business. (Hey! I resemble that remark!) :-) Sure.... I was just thinking this should/would/could be incorprated into another section, rather than dropped. >> An associated delegation criteria is the requirement to allow for >> non-BGP IP end user implementations. As a result, all secured BGP >> implementations MUST allow for the propagation of a prefix by more >> than one originator AS. >> >> I think this requirement probably needs to be highlighted a bit more, >> maybe, and probably give an example of why, or provide the number of >> routes from a current view of the public Internet routing table with >> this property. > > I am too saturated to put together a view of these. It should be > possible with a Perl script to put one together though. I would be > curious to see who is doing it. It has been a long time since I was on > the customer end of things. I think it's still rather common, if not "normal practice." I asked a couple of folks a couple of weeks ago about it, and it looks like the table is about 10%+ inconsistent origin, which is almost always the case of a single prefix originated for the same customer by two different providers, or the process of accepting a single customer's routes into two providers using a private as for peering, and then stripping the private as' on the sp edge.... I would say it's common enough any given system must be able to support it. >> The data generated by logging may be very large depending on the >> number of peers, the number of prefixes received, the authentication >> model used and routing policies. >> >> Path and NLRI attributes MUST be logged using a standard format. The >> format must be scalable with the amount of data logged and the >> frequency of log generation. The frequency of log generation should >> be controllable by the operator. The logging mechanisms for the >> tracked information MUST be standardized across all platforms. >> Logging ability both on and off line is considered highly desirable. >> >> This text comes out of the blue, really. Is there actually a >> requirement for logging? How does it relate to the path attribute >> tracking considered in this section? It should probably be made into a >> seperate section, really. > > There really is a need for tracking/logging in a commonly formatted, > viewable, fashion. This is an important aspect of proper security. > When the RFC for the mechanism itself comes out we will probably be > better able to detail exactly what should be logged. At a minimum we > need to log the prefix, the originator, whether they were secured etc... > The fact that operators have to build this stuff from scratch to get the > same results is a good indicator. > > The logging mechanisms may have some bearing on building a rudimentary > sort of IDS into the secured protocol as well... Do you agree? I think logging is important, but I would give it it's own section, and possibly it's own justification. I think you've hit the first part of it with your comment about intrusion detection. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Dec 5 15:02:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03560 for ; Sun, 5 Dec 2004 15:02:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb2gH-0006j4-T2 for rpsec-web-archive@ietf.org; Sun, 05 Dec 2004 15:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb2TP-0005gX-BC; Sun, 05 Dec 2004 14:55:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb2Of-0004w9-RX for rpsec@megatron.ietf.org; Sun, 05 Dec 2004 14:50:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02677 for ; Sun, 5 Dec 2004 14:50:15 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb2Uq-0006Ua-Dq for rpsec@ietf.org; Sun, 05 Dec 2004 14:56:42 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iB5JnbBw031227 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sun, 5 Dec 2004 14:49:41 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 05 Dec 2004 14:49:32 -0500 From: Blaine Christian To: Message-ID: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3185102983_1991455" X-Spam-Score: 0.1 (/) X-Scan-Signature: f2a0ef77bcf420ac38a986c8cadc5fce Cc: Michael Petry Subject: [RPSEC] Newest Draft of BGP Routing Protocol Security document X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a23818fb0eec942c015c9afea589725 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3185102983_1991455 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello all, The most recently updated draft is attached to this email. Please note that I have yet to submit the draft. Before it gets submitted I would appreciate as much feedback as possible. I am doing my best to represent the rough consensus of this group and the operators. Please note that I could use some verbiage to quickly describe transitive trust, distributed trust, and hierarchichal trust. It would be outstanding if we could have some verbiage along with a reference to a publicly reachable document for further elaboration. Regards, Blaine --B_3185102983_1991455 Content-type: application/octet-stream; name="draft-christian-bgpsecrec-02.html" Content-disposition: attachment; filename="draft-christian-bgpsecrec-02.html" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1s IGxhbmc9ImVuIj48aGVhZD48dGl0bGU+QkdQIFNlY3VyaXR5IFJlcXVpcmVtZW50czwvdGl0 bGU+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4KPG1ldGEgbmFtZT0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IkJH UCBTZWN1cml0eSBSZXF1aXJlbWVudHMiPgo8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRl bnQ9InhtbDJyZmMgdjEuMjQgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5bGUg dHlwZT0ndGV4dC9jc3MnPgo8IS0tCiAgICBib2R5IHsKICAgICAgICBmb250LWZhbWlseTog dmVyZGFuYSwgY2hhcmNvYWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWY7CiAgICAg ICAgZm9udC1zaXplOiBzbWFsbCA7IGNvbG9yOiAjMDAwMDAwIDsgYmFja2dyb3VuZC1jb2xv cjogI2ZmZmZmZiA7IH0KICAgIC50aXRsZSB7IGNvbG9yOiAjOTkwMDAwOyBmb250LXNpemU6 IHgtbGFyZ2UgOwogICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyB0ZXh0LWFsaWduOiByaWdo dDsKICAgICAgICBmb250LWZhbWlseTogaGVsdmV0aWNhLCBtb25hY28sICJNUyBTYW5zIFNl cmlmIiwgYXJpYWwsIHNhbnMtc2VyaWY7CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IH0KICAgIC5maWxlbmFtZSB7IGNvbG9yOiAjNjY2NjY2OyBmb250LXNpemU6 IDE4cHg7IGxpbmUtaGVpZ2h0OiAyOHB4OwogICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyB0 ZXh0LWFsaWduOiByaWdodDsKICAgICAgICBmb250LWZhbWlseTogaGVsdmV0aWNhLCBhcmlh bCwgc2Fucy1zZXJpZjsKICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsg fQogICAgdGQucmZjYnVnIHsgYmFja2dyb3VuZC1jb2xvcjogIzAwMDAwMCA7IHdpZHRoOiAz MHB4IDsgaGVpZ2h0OiAzMHB4IDsgCiAgICAgICAgdGV4dC1hbGlnbjoganVzdGlmeTsgdmVy dGljYWwtYWxpZ246IG1pZGRsZSA7IHBhZGRpbmctdG9wOiAycHggOyB9CiAgICB0ZC5yZmNi dWcgc3Bhbi5SRkMgeyBjb2xvcjogIzY2NjY2NjsgZm9udC13ZWlnaHQ6IGJvbGQ7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwMDAwIDsK ICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2Fu cyBTZXJpZiIsIGhlbHZldGljYSwgdmVyZGFuYSwgc2Fucy1zZXJpZjsKICAgICAgICBmb250 LXNpemU6IHgtc21hbGwgOyB9CiAgICB0ZC5yZmNidWcgc3Bhbi5ob3RUZXh0IHsgY29sb3I6 ICNmZmZmZmY7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsK ICAgICAgICB0ZXh0LWFsaWduOiBjZW50ZXIgOwogICAgICAgIGZvbnQtZmFtaWx5OiBjaGFy Y29hbCwgbW9uYWNvLCBnZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCB2ZXJk YW5hLCBzYW5zLXNlcmlmOwogICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbCA7IGJhY2tncm91 bmQtY29sb3I6ICMwMDAwMDA7IH0KLyogaW5mbyBjb2RlIGZyb20gU2FudGFLbGF1c3MgYXQg aHR0cDovL3d3dy5tYWRhYm91dHN0eWxlLmNvbS90b29sdGlwMi5odG1sICovCiAgICBkaXYj Y291bnRlcnttYXJnaW4tdG9wOiAxMDBweH0KCiAgICBhLmluZm97CiAgICAgICAgcG9zaXRp b246cmVsYXRpdmU7IC8qdGhpcyBpcyB0aGUga2V5Ki8KICAgICAgICB6LWluZGV4OjI0Owog ICAgICAgIHRleHQtZGVjb3JhdGlvbjpub25lfQoKICAgIGEuaW5mbzpob3Zlcnt6LWluZGV4 OjI1OyBiYWNrZ3JvdW5kLWNvbG9yOiM5OTAwMDAgOyBjb2xvcjogI2ZmZmZmZiA7fQoKICAg IGEuaW5mbyBzcGFue2Rpc3BsYXk6IG5vbmV9CgogICAgYS5pbmZvOmhvdmVyIHNwYW57IC8q dGhlIHNwYW4gd2lsbCBkaXNwbGF5IGp1c3Qgb24gOmhvdmVyIHN0YXRlKi8KICAgICAgICBk aXNwbGF5OmJsb2NrOwogICAgICAgIHBvc2l0aW9uOmFic29sdXRlOwogICAgICAgIGZvbnQt c2l6ZTogc21hbGxlciA7CiAgICAgICAgdG9wOjJlbTsgbGVmdDoyZW07IHdpZHRoOjE1ZW07 CiAgICAgICAgcGFkZGluZzogMnB4IDsKICAgICAgICBib3JkZXI6MXB4IHNvbGlkICMzMzMz MzM7CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjojZWVlZWVlOyBjb2xvcjojOTkwMDAwOwog ICAgICAgIHRleHQtYWxpZ246IGxlZnQgO30KCiAgICAgQSB7IGZvbnQtd2VpZ2h0OiBib2xk OyB9CiAgICAgQTpsaW5rIHsgY29sb3I6ICM5OTAwMDA7IGJhY2tncm91bmQtY29sb3I6IHRy YW5zcGFyZW50IDsgfQogICAgIEE6dmlzaXRlZCB7IGNvbG9yOiAjMzMzMzMzOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudCA7IH0KICAgICBBOmFjdGl2ZSB7IGNvbG9yOiAjMzMz MzMzOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudCA7IH0KCiAgICBwIHsgbWFyZ2lu LWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgIHAuY29weXJpZ2h0IHsgZm9u dC1zaXplOiB4LXNtYWxsIDsgfQogICAgcC50b2MgeyBmb250LXNpemU6IHNtYWxsIDsgZm9u dC13ZWlnaHQ6IGJvbGQgOyBtYXJnaW4tbGVmdDogM2VtIDt9CgogICAgc3Bhbi5lbXBoIHsg Zm9udC1zdHlsZTogaXRhbGljOyB9CiAgICBzcGFuLnN0cm9uZyB7IGZvbnQtd2VpZ2h0OiBi b2xkOyB9CiAgICBzcGFuLnZlcmIgeyBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IiwgQ291 cmllciwgbW9ub3NwYWNlIDsgfQoKICAgIG9sLnRleHQgeyBtYXJnaW4tbGVmdDogMmVtOyBt YXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgdWwudGV4dCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1h cmdpbi1yaWdodDogMmVtOyB9CiAgICBsaSB7IG1hcmdpbi1sZWZ0OiAzZW07ICB9CgogICAg cHJlIHsgbWFyZ2luLWxlZnQ6IDNlbTsgY29sb3I6ICMzMzMzMzM7ICBiYWNrZ3JvdW5kLWNv bG9yOiB0cmFuc3BhcmVudDsKICAgICAgICBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3Iiwg Q291cmllciwgbW9ub3NwYWNlIDsgZm9udC1zaXplOiBzbWFsbCA7CiAgICAgICAgfQoKICAg IGgzIHsgY29sb3I6ICMzMzMzMzM7IGZvbnQtc2l6ZTogbWVkaXVtIDsKICAgICAgICBmb250 LWZhbWlseTogaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZiA7CiAgICAgICAgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KICAgIGg0IHsgZm9udC1zaXplOiBzbWFsbDsg Zm9udC1mYW1pbHk6IGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWYgOyB9CgogICAgdGFi bGUuYnVnIHsgd2lkdGg6IDMwcHggOyBoZWlnaHQ6IDE1cHggOyB9CiAgICB0ZC5idWcgeyBj b2xvcjogI2ZmZmZmZiA7IGJhY2tncm91bmQtY29sb3I6ICM5OTAwMDAgOwogICAgICAgIHRl eHQtYWxpZ246IGNlbnRlciA7IHdpZHRoOiAzMHB4IDsgaGVpZ2h0OiAxNXB4IDsKICAgICAg ICAgfQogICAgdGQuYnVnIEEubGluazIgeyBjb2xvcjogI2ZmZmZmZiA7IGZvbnQtd2VpZ2h0 OiBib2xkOwogICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICBmb250LWZh bWlseTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZl dGljYSwgc2Fucy1zZXJpZjsKICAgICAgICBmb250LXNpemU6IHgtc21hbGwgOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudCB9CgogICAgdGQuaGVhZGVyIHsgY29sb3I6ICNmZmZm ZmY7IGZvbnQtc2l6ZTogeC1zbWFsbCA7CiAgICAgICAgZm9udC1mYW1pbHk6IGFyaWFsLCBo ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IHZlcnRpY2FsLWFsaWduOiB0b3A7CiAgICAgICAgYmFj a2dyb3VuZC1jb2xvcjogIzY2NjY2NiA7IHdpZHRoOiAzMyUgOyB9CiAgICB0ZC5hdXRob3Ig eyBmb250LXdlaWdodDogYm9sZDsgbWFyZ2luLWxlZnQ6IDRlbTsgZm9udC1zaXplOiB4LXNt YWxsIDsgfQogICAgdGQuYXV0aG9yLXRleHQgeyBmb250LXNpemU6IHgtc21hbGw7IH0KICAg IHRhYmxlLmRhdGEgeyB2ZXJ0aWNhbC1hbGlnbjogdG9wIDsgYm9yZGVyLWNvbGxhcHNlOiBj b2xsYXBzZSA7CiAgICAgICAgYm9yZGVyLXN0eWxlOiBzb2xpZCBzb2xpZCBzb2xpZCBzb2xp ZCA7CiAgICAgICAgYm9yZGVyLWNvbG9yOiBibGFjayBibGFjayBibGFjayBibGFjayA7CiAg ICAgICAgZm9udC1zaXplOiBzbWFsbCA7IHRleHQtYWxpZ246IGNlbnRlciA7IH0KICAgIHRh YmxlLmRhdGEgdGggeyBmb250LXdlaWdodDogYm9sZCA7CiAgICAgICAgYm9yZGVyLXN0eWxl OiBzb2xpZCBzb2xpZCBzb2xpZCBzb2xpZCA7CiAgICAgICAgYm9yZGVyLWNvbG9yOiBibGFj ayBibGFjayBibGFjayBibGFjayA7IH0KICAgIHRhYmxlLmRhdGEgdGQgewogICAgICAgIGJv cmRlci1zdHlsZTogc29saWQgc29saWQgc29saWQgc29saWQgOwogICAgICAgIGJvcmRlci1j b2xvcjogIzMzMzMzMyAjMzMzMzMzICMzMzMzMzMgIzMzMzMzMyA7IH0KCiAgICBociB7IGhl aWdodDogMXB4IH0KLS0+Cjwvc3R5bGU+CjwvaGVhZD4KPGJvZHk+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIHdpZHRoPSI2NiUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIj48dHI+PHRkPjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSIxMDAl IiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMSI+Cjx0cj48dGQg Y2xhc3M9ImhlYWRlciI+Um91dGluZyBQcm90b2NvbCBTZWN1cml0eTwvdGQ+PHRkIGNsYXNz PSJoZWFkZXIiPkIuIENocmlzdGlhbiwgRWQuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJo ZWFkZXIiPlJlcXVpcmVtZW50czwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPktNQyBUZWxlY29t IFNvbHV0aW9uczwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldC1E cmFmdDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkIuIEFreW9sPC90ZD48L3RyPgo8dHI+PHRk IGNsYXNzPSJoZWFkZXIiPkV4cGlyZXM6IEp1bmUgNSwgMjAwNTwvdGQ+PHRkIGNsYXNzPSJo ZWFkZXIiPlIuIFdoaXRlPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNw OzwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkNpc2NvIFN5c3RlbXM8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+Si4gSGFh czwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFz cz0iaGVhZGVyIj5OZXh0IEhvcCBUZWNobm9sb2dpZXM8L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+Uy4gTXVycGh5PC90 ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRkIGNsYXNzPSJo ZWFkZXIiPlRydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtczwvdGQ+PC90cj4KPHRyPjx0ZCBj bGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5EZWNlbWJlciA1 LCAyMDA0PC90ZD48L3RyPgo8L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPgo8ZGl2IGFsaWdu PSJyaWdodCI+PHNwYW4gY2xhc3M9InRpdGxlIj48YnIgLz5CR1AgU2VjdXJpdHkgUmVxdWly ZW1lbnRzPC9zcGFuPjwvZGl2Pgo8ZGl2IGFsaWduPSJyaWdodCI+PHNwYW4gY2xhc3M9InRp dGxlIj48YnIgLz5kcmFmdC1jaHJpc3RpYW4tYmdwc2VjcmVjLTAyPC9zcGFuPjwvZGl2PgoK PGgzPlN0YXR1cyBvZiB0aGlzIE1lbW88L2gzPgo8cD4KQnkgc3VibWl0dGluZyB0aGlzIElu dGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55IGFwcGxpY2Fi bGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3 YXJlIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRo IFNlY3Rpb24gNiBvZiBSRkMgMzY2OC48L3A+CjxwPgpJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwpUYXNrIEZvcmNl IChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLgpOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMK SW50ZXJuZXQtRHJhZnRzLjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwphbmQgbWF5IGJlIHVw ZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFu eSB0aW1lLgpJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg cmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluIHByb2dyZXNzLiI8L3A+CjxwPgpUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURy YWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEgaHJlZj0naHR0cDovL3d3dy5pZXRmLm9yZy9p ZXRmLzFpZC1hYnN0cmFjdHMudHh0Jz5odHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFi c3RyYWN0cy50eHQ8L2E+LjwvcD4KPHA+ClRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEgaHJlZj0naHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCc+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bDwvYT4uPC9wPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdW5l IDUsIDIwMDUuPC9wPgoKPGgzPkNvcHlyaWdodCBOb3RpY2U8L2gzPgo8cD4KQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQu PC9wPgoKPGgzPkFic3RyYWN0PC9oMz4KCjxwPiBUaGUgc2VjdXJpdHkgb2YgQkdQIGlzIGNy aXRpY2FsIHRvIHRoZSBwcm9wZXIgb3BlcmF0aW9uIG9mIGxhcmdlLXNjYWxlCiAgICAgICAg ICAgICAgICBpbnRlcm5ldHdvcmtzLCBib3RoIHB1YmxpYyBhbmQgcHJpdmF0ZS4gV2hpbGUg c2VjdXJpbmcgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkCiAgICAgICAgICAgICAgICBi ZXR3ZWVuIHR3byBCR1Agc3BlYWtlcnMgaXMgYSByZWxhdGl2ZWx5IGVhc3kgdGVjaG5pY2Fs IG1hdHRlciwgc2VjdXJpbmcgQkdQLCBhcyBhCiAgICAgICAgICAgICAgICByb3V0ZWQgc3lz dGVtLCBpcyBtb3JlIGNvbXBsZXguIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9m IHJlcXVpcmVtZW50cyBmb3IKICAgICAgICAgICAgICAgIHNlY3VyaW5nIEJHUCwgaW5jbHVk aW5nIHNlY3VyaW5nIHBlZXJpbmcgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIEJHUCBzcGVha2Vy cywgYW5kCiAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGluZyB0aGUgcm91dGluZyBpbmZv cm1hdGlvbiBjYXJyaWVkIHdpdGhpbiBCR1AuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMSI+PC9h PjxiciAvPjxociAvPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xIj48L2E+PGgzPjEuJm5ic3A7 SW50cm9kdWN0aW9uPC9oMz4KCjxwPiBUaHJlYXRzIHRvIG5ldHdvcmtpbmcgcHJvdG9jb2xz IGdlbmVyYWxseSBmYWxsIHVuZGVyIG9uZSBvZiB0aGUgdGhyZWUgY2F0ZWdvcmllcyBhcwog ICAgICAgICAgICAgICAgZGVmaW5lZCBpbiA8YSBjbGFzcz0iaW5mbyIgaHJlZj0iI1JGQzIx OTYiPlJGQyAyMTk2PHNwYW4+RnJhc2VyLCBSRkMgMjE5NiAtIFNpdGUgU2VjdXJpdHkgSGFu ZGJvb2ssIFNlcHRlbWJlciAxOTk3Ljwvc3Bhbj48L2E+WzFdOgo8L3A+Cjx1bCBjbGFzcz0i dGV4dCI+CjxsaT5VbmF1dGhvcml6ZWQgYWNjZXNzIHRvIHJlc291cmNlcyBhbmQvb3IgaW5m b3JtYXRpb24KPC9saT4KPGxpPlVuaW50ZW5kZWQgYW5kL29yIHVuYXV0aG9yaXplZCBkaXNj bG9zdXJlIG9mIGluZm9ybWF0aW9uCjwvbGk+CjxsaT5EZW5pYWwgb2Ygc2VydmljZQo8L2xp Pgo8L3VsPgo8cD4gQSBudW1iZXIgb2YgYXR0YWNrcyBjYW4gYmUgcmVhbGl6ZWQgd2hpY2gs IGlmIGV4cGxvaXRlZCwgY2FuIGxlYWQgdG8gb25lIG9mIHRoZQogICAgICAgICAgICAgICAg YWJvdmUgbWVudGlvbmVkIHRocmVhdHMuIFRoZXNlIGFyZSB0eXBpY2FsbHkgY2xhc3NpZmll ZCBhcyBwYXNzaXZlIGF0dGFja3MgYW5kCiAgICAgICAgICAgICAgICBhY3RpdmUgYXR0YWNr cy4gUGFzc2l2ZSBhdHRhY2tzIGFyZSBvbmVzIHdoZXJlIGFuIGF0dGFja2VyIHNpbXBseSBy ZWFkcyBpbmZvcm1hdGlvbgogICAgICAgICAgICAgICAgb2ZmIHRoZSBuZXR3b3JrIGFuZCBv YnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gQWN0aXZl IGF0dGFja3MKICAgICAgICAgICAgICAgIGFyZSBvbmVzIHdoZXJlIHRoZSBhdHRhY2tlciB3 cml0ZXMgZGF0YSB0byB0aGUgbmV0d29yayBhbmQgY2FuIGluY2x1ZGUgcmVwbGF5CiAgICAg ICAgICAgICAgICBhdHRhY2tzLCBtZXNzYWdlIGluc2VydGlvbiwgbWVzc2FnZSBkZWxldGlv biwgbWVzc2FnZSBtb2RpZmljYXRpb24gYW5kCiAgICAgICAgICAgICAgICBtYW4taW4tdGhl LW1pZGRsZSBhdHRhY2tzLiBUaGVzZSBhdHRhY2tzIGFyZSBvZnRlbiBjb21iaW5lZC4KPC9w Pgo8cD4gQXR0YWNrcyB0aGF0IGRvIG5vdCBpbnZvbHZlIGRpcmVjdCBtYW5pcHVsYXRpb24g b2YgQkdQLCBhbmQgdGhlIGluZm9ybWF0aW9uCiAgICAgICAgICAgICAgICBjb250YWluZWQg d2l0aGluIGl0LCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gV2hl biBwb3NzaWJsZSwgdGhlCiAgICAgICAgICAgICAgICByZXF1aXJlbWVudHMgd2lsbCBhdHRl bXB0IHRvIG1pbmltaXplIHRoZSBleHRlbnQgb2YgdGhlIGRhbWFnZSB0aGF0IG9jY3VycyB3 aGVuIGVuZAogICAgICAgICAgICAgICAgc3lzdGVtcyBjb21lIHVuZGVyIGF0dGFjay4KPC9w Pgo8cD4gVGhlIGludGVudCBvZiB0aGlzIHJlcXVpcmVtZW50cyBkb2N1bWVudCBpcyB0byBw cmV2ZW50IGF0dGFja3MgdGhhdCBvcmlnaW5hdGUgZmFsc2UKICAgICAgICAgICAgICAgIGRh dGEgb3IgY3JlYXRlIGludmFsaWQgcm91dGluZyBwYXRocyBhbmQgdGhlcmVmb3JlIGFkZHJl c3NlcyBpc3N1ZXMgcmVsYXRpbmcgdG8gZGF0YQogICAgICAgICAgICAgICAgaW50ZWdyaXR5 IGFuZCBwZWVyIGVudGl0eSBhdXRoZW50aWNhdGlvbi4gQXMgZGVzY3JpYmVkIGluIDxhIGNs YXNzPSJpbmZvIiBocmVmPSIjUkZDMzU1MiI+UkZDCiAgICAgICAgICAgICAgICAzNTUyPHNw YW4+UmVzY29ybGEsIEtvcnZlciBhbmQgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkLCBS RkMgMzU1MiAtIEd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDIFRleHQgb24gU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMsIEp1bHkgMjAwMy48L3NwYW4+PC9hPlsyXSwgZGF0YSBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiBlbnN1cmVzIHRoYXQgZGF0YSBpcyBub3QgbW9kaWZpZWQgaW4gdHJh bnNpdAogICAgICAgICAgICAgICAgYW5kIHBlZXIgZW50aXR5IGF1dGhlbnRpY2F0aW9uIGVu c3VyZXMgdGhhdCB0aGVyZSBpcyBhIHJlYXNvbmFibGUgZ3VhcmFudGVlIHRoYXQgdGhlCiAg ICAgICAgICAgICAgICBzZW5kZXIgYW5kIHJlY2lwaWVudCBvZiB0aGUgZGF0YSBhcmUgdGhl IGludGVuZGVkIHBhcnRpZXMuCjwvcD4KPHA+IEd1YXJhbnRlZWQgcGFja2V0IGRlbGl2ZXJ5 IGlzIG5vdCBwYXJ0IG9mIHRoZSBCR1AgcHJvdG9jb2wgc2VjdXJpdHkgbW9kZWwuIEp1c3QK ICAgICAgICAgICAgICAgIGJlY2F1c2UgYSBwYWNrZXQgaXMgYWRkcmVzc2VkIHRvIGEgc3Bl Y2lmaWMgZGVzdGluYXRpb24gZG9lcyBub3QgbWVhbiBpdCB3aWxsIGJlCiAgICAgICAgICAg ICAgICByZWNlaXZlZCwgZXZlbiB3aXRoIGEgInNlY3VyZSIgcm91dGUuIEZvciBleGFtcGxl OiBhbiBhdHRhY2tlciBjb3VsZCBoYXZlCiAgICAgICAgICAgICAgICBjb21wcm9taXNlZCBh biBpbnRlcm1lZGlhdGUgcm91dGVyIGFuZCBpbnN0YWxsZWQgYSBzdGF0aWMgcm91dGUgZm9y IHRhcmdldCBhZGRyZXNzCiAgICAgICAgICAgICAgICBBLkIuQy5EIHBvaW50aW5nIHRvIGFu IGluYXBwcm9wcmlhdGUgZGlyZWN0aW9uIG9yIGFuIGF0dGFja2VyIG1pZ2h0IHNwbGljZSBp bnRvIGEKICAgICAgICAgICAgICAgIGNpcmN1aXQgYmV0d2VlbiB0d28gc2VjdXJlIHJvdXRl cnMgYW5kIGluc3RhbGwgYSBkZXZpY2UgdGhhdCBkaXZlcnRzIEEuQi5DLkQgdHJhZmZpYwog ICAgICAgICAgICAgICAgd2l0aG91dCByZXF1aXJpbmcgdGhlIGNvbXByb21pc2Ugb2YgY29u dHJvbCBwbGFuZSBkZXZpY2VzLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIiPjwvYT48YnIgLz48 aHIgLz4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMiI+PC9hPjxoMz4yLiZuYnNwO0RlcGxveW1l bnQgUmVxdWlyZW1lbnRzPC9oMz4KCjxwPiBXZSBoYXZlIGRldGVybWluZWQsIHRocm91Z2gg ZGlzY3Vzc2lvbiB3aXRoIHdpdGggc2V2ZXJhbCBsYXJnZSBpbnRlcm5ldHdvcmsKICAgICAg ICAgICAgICAgIG9wZXJhdG9ycyBhbmQgZXF1aXBtZW50IHZlbmRvcnMsIHRoYXQgdGhlIGZv bGxvd2luZyBhdHRyaWJ1dGVzIGFyZSBpbXBvcnRhbnQgdG8gdGhlCiAgICAgICAgICAgICAg ICBvbmdvaW5nIHBlcmZvcm1hbmNlIG9mIGludGVyZG9tYWluIHJvdXRpbmcgc3lzdGVtcyBz dWNoIGFzIEJHUDoKPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+Q29udmVyZ2VuY2UgU3Bl ZWQ6IENvbnZlcmdlbmNlIHNwZWVkIGlzIGEgbWFqb3IgY29uY2VybiB0byBtYW55IG9wZXJh dG9ycyBvZgogICAgICAgICAgICAgICAgICAgIGxhcmdlIHNjYWxlIGludGVybmV0d29ya2lu ZyBzeXN0ZW1zLiBOZXR3b3JrcywgYW5kIGludGVybmV0d29ya3MsIGFyZSBjYXJyeWluZwog ICAgICAgICAgICAgICAgICAgIGV2ZXIgaW5jcmVhc2luZyBhbW91bnRzIG9mIGluZm9ybWF0 aW9uIHRoYXQgaXMgdGltZSBhbmQgZGVsYXkgc2Vuc2l0aXZlOwogICAgICAgICAgICAgICAg ICAgIGluY3JlYXNpbmcgY29udmVyZ2VuY2UgdGltZXMgY2FuIGFkdmVyc2VseSBhZmZlY3Qg dGhlIHVzYWJpbGl0eSBvZiB0aGUgbmV0d29yaywKICAgICAgICAgICAgICAgICAgICBhbmQg dGhlIGFiaWxpdHkgb2YgYW4gaW50ZXJuZXR3b3JrIHRvIGdyb3cuIEJHUCdzIGNvbnZlcmdl bmNlIHNwZWVkLCB3aXRoIGEKICAgICAgICAgICAgICAgICAgICBzZWN1cml0eSBzeXN0ZW0g aW4gb3BlcmF0aW9uLCBTSE9VTEQgYmUgZXF1aXZhbGVudCB0byBCR1AgcnVubmluZyB3aXRo b3V0IHRoZQogICAgICAgICAgICAgICAgICAgIHNlY3VyaXR5IHN5c3RlbSBpbiBvcGVyYXRp b24uIFRoaXMgaW5jbHVkZXMgdGhlIHByZXNlcnZhdGlvbiBvZiBvcHRpbWl6YXRpb25zCiAg ICAgICAgICAgICAgICAgICAgY3VycmVudGx5IHVzZWQgdG8gcHJvZHVjZSBhY2NlcHRhYmxl IGNvbnZlcmdlbmNlIHNwZWVkcyBvbiBjdXJyZW50IGhhcmR3YXJlLAogICAgICAgICAgICAg ICAgICAgIGluY2x1ZGluZyB1cGRhdGUgcGFja2luZywgcGVlciBncm91cHMsIGFuZCBvdGhl cnMuIEN1cnJlbnQgdGltZXJzLCBpbmNsdWRpbmcKICAgICAgICAgICAgICAgICAgICBob2xk IHRpbWVycywga2VlcGFsaXZlIHRpbWVycywgYW5kIHRoZSBwZWVyaW5nIHByb2Nlc3MsIFNI T1VMRCBOT1QgYmUgaW1wYWN0ZWQKICAgICAgICAgICAgICAgICAgICBieSB0aGUgc2VjdXJp dHkgc3lzdGVtLiBUd28gdHlwZXMgb2YgdmVyaWZpY2F0aW9uIE1BWSBiZSBvZmZlcmVkIGZv ciB0aGUgTkxSSQogICAgICAgICAgICAgICAgICAgIGFuZCB0aGUgQVNfUEFUSCBpbiBvcmRl ciB0byBhbGxvdyBmb3IgYSBzZWxlY3Rpb24gb2Ygb3B0aW1pemF0aW9uczogCjx1bCBjbGFz cz0idGV4dCI+CjxsaT4gQ29udGVudHMgb2YgdGhlIFVQREFURSBtZXNzYWdlIFNIT1VMRCBi ZSBhdXRoZW50aWNhdGVkIGluIHJlYWwtdGltZSBhcwogICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhlIFVQREFURSBtZXNzYWdlIGlzIHByb2Nlc3NlZC4KPC9saT4KPGxpPiBUaGUg cm91dGUgaW5mb3JtYXRpb24gYmFzZSBNQVkgYmUgYXV0aGVudGljYXRlZCBwZXJpb2RpY2Fs bHkgb3IgaW4gYW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV2ZW50IGRyaXZlbiBt YW5uZXIgYnkgc2Nhbm5pbmcgdGhlIGRhdGEgYW5kIHZlcmlmeWluZyB0aGUgb3JpZ2luYXRp bmcKICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFTIGFuZCB0aGUgdmVyaWZpYWJpbGl0 eSBvZiB0aGUgQVMtUEFUSCBsaXN0LiAKPC9saT4KPC91bD48cD4gQWxsIEJHUCBpbXBsZW1l bnRhdGlvbnMgdGhhdCBpbXBsZW1lbnQgc2VjdXJpdHkgTVVTVCB1dGlsaXplIGF0IGxlYXN0 CiAgICAgICAgICAgICAgICAgICAgb25lIG9mIHRoZSBhYm92ZSBtZXRob2RzIGZvciB2YWxp ZGF0aW5nIHJvdXRpbmcgaW5mb3JtYXRpb24uIFJlYWwgdGltZQogICAgICAgICAgICAgICAg ICAgIHZlcmlmaWNhdGlvbiBpcyBwcmVmZXJyZWQgaW4gb3JkZXIgdG8gcHJldmVudCB0cmFu c2l0aXZlIGZhaWx1cmVzIGJhc2VkIG9uCiAgICAgICAgICAgICAgICAgICAgcGVyaW9kaWMg b3IgZXZlbnQgZHJpdmVuIHNjYW4gaW50ZXJ2YWxzLiAKPC9saT4KPGxpPkluY3JlbWVudGFs IERlcGxveW1lbnQ6IFdlIHdpbGwgbm90IGJlIGFibGUgdG8gZGVwbG95IGEgbmV3bHkgc2Vj dXJlZCBCR1AKICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCBpbnN0YW50YW5lb3VzbHkg YW5kIHdpbGwgYmUgdW5hYmxlIHRvIGRpY3RhdGUgYSBwYXJ0aXRpb25pbmcgb2YgbGFyZ2UK ICAgICAgICAgICAgICAgICAgICBpbnRlcm5ldHdvcmtzIGJ5IHRoZSBvcGVyYXRvcnMuIEJH UCBNVVNUIHN1cHBvcnQgYm90aCBzZWN1cmVkIGFuZCB1bnNlY3VyZWQKICAgICAgICAgICAg ICAgICAgICByb3V0ZXMgd2l0aCB0aGUgc2VjdXJpdHkgc3lzdGVtIGluIHBsYWNlLiBUaGUg c2VjdXJpdHkgc3lzdGVtIE1VU1QgYWxsb3cgdGhlCiAgICAgICAgICAgICAgICAgICAgZm9y bWluZyBvZiBwZWVyaW5nIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBzZWN1cmUgYW5kIG5vbi1z ZWN1cmUgQkdQIHNwZWFrZXJzLCBhbmQKICAgICAgICAgICAgICAgICAgICBNVVNUIGJlIGJh Y2t3YXJkIGNvbXBhdGlibGUgaW4gdGhlIG1lc3NhZ2UgZm9ybWF0dGluZywgdHJhbnNtaXNz aW9uLCBhbmQKICAgICAgICAgICAgICAgICAgICBwcm9jZXNzaW5nIG9mIHJvdXRpbmcgaW5m b3JtYXRpb24gY2FycmllZCB0aHJvdWdoIGEgbWl4ZWQgc2VjdXJpdHkgZW52aXJvbm1lbnQu CiAgICAgICAgICAgICAgICAgICAgTWVzc2FnZSBmb3JtYXR0aW5nIGluIGEgZnVsbHkgc2Vj dXJlZCBlbnZpcm9ubWVudCBNQVkgYmUgaGFuZGxlZCBpbiBhCiAgICAgICAgICAgICAgICAg ICAgbm9uLWJhY2t3YXJkIGNvbXBhdGlibGUgZmFzaGlvbi4KPC9saT4KPGxpPlRydXN0IGxl dmVsIFZhcmlhYmlsaXR5OiBFYWNoIHNlY3VyZWQgZW52aXJvbm1lbnQgbWF5IGhhdmUgZGlm ZmVyZW50IGxldmVscyBvZgogICAgICAgICAgICAgICAgICAgIHJlcXVpcmVtZW50cyBpbiB0 ZXJtcyBvZiB3aGF0IGlzIGFjY2VwdGFibGUgb3IgdW5hY2NlcHRhYmxlLiBJbiBlbnZpcm9u bWVudHMKICAgICAgICAgICAgICAgICAgICB0aGF0IHJlcXVpcmUgc3RyaWN0IHNlY3VyaXR5 IGl0IG1heSBub3QgYmUgYWNjZXB0YWJsZSB0byB0ZW1wb3JhcmlseSByb3V0ZSB0bwogICAg ICAgICAgICAgICAgICAgIGEgZGVzdGluYXRpb24gd2hpbGUgd2FpdGluZyBmb3Igc2VjdXJp dHkgdmVyaWZpY2F0aW9uIHRvIGJlIHBlcmZvcm1lZC4gSG93ZXZlciwKICAgICAgICAgICAg ICAgICAgICBpbiBtYW55IGNvbW1lcmNpYWwgZW52aXJvbm1lbnRzIHRoZSByYXBpZGl0eSBv ZiByb3V0ZSBpbnN0YWxsYXRpb24gbWF5IGJlIG9mCiAgICAgICAgICAgICAgICAgICAgcGFy YW1vdW50IGltcG9ydGFuY2U7IGluIG9yZGVyIHRvIGZhY2lsaXRhdGUgdGhlIG1vcmUgY29t bW9uIG9jY3VyZW5jZSBvZiByb3V0ZQogICAgICAgICAgICAgICAgICAgIHdpdGhkcmF3bCBk dWUgdG8gbmV0d29yayBmYWlsdXJlLiBCYXNlZCBvbiB0aGUgdHdvIGRpdmVyZ2VudCByZXF1 aXJlbWVudHMsIHRoZQogICAgICAgICAgICAgICAgICAgIHNlY3VyaXR5IHN5c3RlbSBNVVNU IHN1cHBvcnQgYSByYW5nZSBvZiBwb3NzaWJsZSBvdXRwdXRzIGZvciBsb2NhbCBkZXRlcm1p bmF0aW9uCiAgICAgICAgICAgICAgICAgICAgb2YgdGhlIHRydXN0IGxldmVsIGZvciBhIHNw ZWNpZmljIHJvdXRlLiBBbnkgZ2l2ZW4gcm91dGUgc2hvdWxkIGJlIHRydXN0YWJsZSB0bwog ICAgICAgICAgICAgICAgICAgIGEgbG9jYWxseSBjb25maWd1cmVkIGRlZ3JlZSwgYmFzZWQg b24gdGhlIGNvbXBsZXRlbmVzcyBvZiBzZWN1cml0eSBpbmZvcm1hdGlvbgogICAgICAgICAg ICAgICAgICAgIGZvciB0aGUgdXBkYXRlIGFuZCBvdGhlciBmYWN0b3JzLiBUaGUgc2VjdXJp dHkgc3lzdGVtIFNIT1VMRCBhbGxvdyB0aGUgb3BlcmF0b3IKICAgICAgICAgICAgICAgICAg ICB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgc3BlZWQgb2YgY29udmVyZ2VuY2UgaXMgbW9y ZSBpbXBvcnRhbnQgdGhhbiBzZWN1cml0eQogICAgICAgICAgICAgICAgICAgIG9wZXJhdGlv bnMsIG9yIHNlY3VyaXR5IG9wZXJhdGlvbnMgYXJlIG1vcmUgaW1wb3J0YW50IHRoYW4gdGhl IHNwZWVkIG9mCiAgICAgICAgICAgICAgICAgICAgY29udmVyZ2VuY2UuIFRoaXMgZmFjaWxp dGF0ZXMgdGhlIGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2Ygc2VjdXJpdHkgb24gc3lzdGVt cwogICAgICAgICAgICAgICAgICAgIG5vdCBkZXNpZ25lZCB0byBzdXBwb3J0IGluY3JlYXNl ZCBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cyBpbXBvc2VkIGJ5IHRoZQogICAgICAgICAgICAg ICAgICAgIHNlY3VyaXR5IHN5c3RlbS4KPC9saT4KPC91bD4KPGEgbmFtZT0iYW5jaG9yMyI+ PC9hPjxiciAvPjxociAvPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zIj48L2E+PGgzPjMuJm5i c3A7VGhlIFRydXN0IE1vZGVsPC9oMz4KCjxwPiBJbiBleGFtaW5pbmcgdGhlIHZhcmlvdXMg ZW52aXJvbm1lbnRzIGluIHdoaWNoIEJHUCBpcyBkZXBsb3llZCwgYW5kIHRocm91Z2gKICAg ICAgICAgICAgICAgIGRpc2N1c3Npb25zIHdpdGggdmFyaW91cyBvcGVyYXRvcnMgd29ya2lu ZyB3aXRoIHRoZSBjb250ZXh0IG9mIHRoZSBwdWJsaWMgSW50ZXJuZXQsCiAgICAgICAgICAg ICAgICBhbmQgb3RoZXIgaW50ZXJuZXR3b3JrcywgaXQgaXMgYXBwYXJlbnQgdGhhdCB0cnVz dCBtb2RlbHMgYXJlIGxhcmdlbHkgZW52aXJvbm1lbnQKICAgICAgICAgICAgICAgIHNwZWNp ZmljLiBGb3IgaW5zdGFuY2UsIGluIHRoZSBwdWJsaWMgSW50ZXJuZXQsIGEgZGlzdHJpYnV0 ZWQgdHJ1c3QgbW9kZWwsIGZvbGxvd2luZwogICAgICAgICAgICAgICAgdGhlIGN1cnJlbnQg dHJhbnNpdGl2ZSB0cnVzdCBwYXR0ZXJuIG9mIGNvbnRyYWN0dWFsIGFuZCBwZWVyaW5nIGFy cmFuZ2VtZW50cywgd291bGQKICAgICAgICAgICAgICAgIGZpdCB0aGUgdGhlIGJ1c2luZXNz IG1vZGVscyBvZiB0aGUgcGFydGljaXBhbnRzLiBJbiBvdGhlciBlbnZpcm9ubWVudHMgYQog ICAgICAgICAgICAgICAgaGllcmFyY2hpY2FsIHRydXN0IG1vZGVsIHdvdWxkIHdvcmsgYmV0 dGVyLiBUaHVzLCBhbnkgdHJ1c3Qgc3lzdGVtIHNwZWNpZmllZCBpbiBhCiAgICAgICAgICAg ICAgICBzZWN1cml0eSBtZWNoYW5pc20gZGVzaWduZWQgZm9yIEJHUCBtdXN0IGJlIGZsZXhp YmxlLCBhbmQgc3VwcG9ydCBib3RoIGEgdHJ1ZQogICAgICAgICAgICAgICAgZGlzdHJpYnV0 ZWQgdHJ1c3QgbW9kZWwgYW5kIGEgZnVsbHkgaGllcmFyY2hpY2FsIHRydXN0IG1vZGVsLgo8 L3A+CjxwPiBTaW5jZSBoaWVyYXJjaGljYWwgdHJ1c3QgbW9kZWxzIGFyZSBhIHN1YnNldCAo b3IgYSBzcGVjaWFsIGNhc2Ugb2YpIGEgZGlzdHJpYnV0ZWQKICAgICAgICAgICAgICAgIHRy dXN0IG1vZGVsLCBhbnkgc2VjdXJpdHkgc3lzdGVtIGRlc2lnbmVkIGZvciBCR1AgTVVTVCBz dXBwb3J0IGEgZGlzdHJpYnV0ZWQgdHJ1c3QKICAgICAgICAgICAgICAgIG1vZGVsLCBhbmQg TVVTVCBhbHNvIHN1cHBvcnQgYSBoaWVyYXJjaGljYWwgdHJ1c3QgbW9kZWwsIGlmIGRlc2ly ZWQuCjwvcD4KPHA+IElmIHR3byBpbnRlcm5ldHdvcmtzIHVzaW5nIGRpZmZlcmluZyB0cnVz dCBtb2RlbHMgYXJlIGludGVyY29ubmVjdGVkIHRoZXkgTVVTVCBiZQogICAgICAgICAgICAg ICAgYWJsZSB0byBpbnRlcm9wZXJhdGUgdXNpbmcgbG9jYWxseSBkZXRlcm1pbmVkIGxldmVs cyBvZiB0cnVzdCB0byBjb21wZW5zYXRlIGZvcgogICAgICAgICAgICAgICAgZGlmZmVyZW5j ZXMgaW4gdGhlaXIgdHJ1c3QgbW9kZWxzLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjQiPjwvYT48 YnIgLz48aHIgLz4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNCI+PC9hPjxoMz40LiZuYnNwO1Ro ZSBBUy1QYXRoIEF0dHJpYnV0ZSBhbmQgTkxSSSBBdXRoZW50aWNhdGlvbjwvaDM+Cgo8cD4g QkdQIGRpc3RyaWJ1dGVzIHJvdXRpbmcgaW5mb3JtYXRpb24gYWNyb3NzIHRoZSBJbnRlcm5l dCAoYmV0d2VlbiBCR1Agc3BlYWtlcnMpIHVzaW5nCiAgICAgICAgICAgICAgICBCR1AgVVBE QVRFIG1lc3NhZ2VzLiBUaGUgVVBEQVRFIG1lc3NhZ2UgY29udGFpbnMgd2l0aGRyYXduIHJv dXRlcywgcGF0aCBhdHRyaWJ1dGVzCiAgICAgICAgICAgICAgICBhbmQgb25lIG9yIG1vcmUg TkxSSXMgKE5ldHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uIGlzIHN5bm9u eW1vdXMgd2l0aAogICAgICAgICAgICAgICAgYWR2ZXJ0aXNlZCBwcmVmaXgpLiBGb3IgdGhl IHJlbWFpbmRlciBvZiB0aGlzIHNlY3Rpb24sIHdlIHdpbGwgZm9jdXMgb24gdGhlIEFTLVBh dGgKICAgICAgICAgICAgICAgIEF0dHJpYnV0ZSBhbmQgdGhlIE5MUkkuIEF0dHJpYnV0ZXMg c3VjaCBhcyBsb2NhbCBwcmVmIGFyZSBsb2NhbGx5IHNwZWNpZmljIGFuZCwgYXMKICAgICAg ICAgICAgICAgIHN1Y2gsIGFyZSBwcm90ZWN0ZWQgYnkgQkdQIHNlc3Npb24gc2VjdXJpdHku CjwvcD4KPHA+VGhlIEFTX1BBVEggZm9yIHNwZWNpZmljIHByZWZpeGVzIG11c3QgYmUgcHJv dGVjdGVkIGluIGFueSBwcm9wb3NlZCBzZWN1cml0eSBzeXN0ZW0KICAgICAgICAgICAgICAg IGluIHRocmVlIHdheXM6CjwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPkF1dGhvcml6YXRp b24gb2YgT3JpZ2luYXRpbmcgQVM6IEZvciBhbGwgcHJlZml4ZXMgYW5ub3VuY2VkIGluIEJH UCwgdGhlCiAgICAgICAgICAgICAgICAgICAgb3JpZ2luYXRpbmcgQVMgTVVTVCBiZSB2ZXJp ZmlhYmxlIHRocm91Z2ggdGhlIHRydXN0IG1vZGVsIGFzIHRoZSBhdXRob3JpemVkCiAgICAg ICAgICAgICAgICAgICAgYW5ub3VuY2VyIG9mIHRoZSBwcmVmaXguIFRoZSB2ZXJpZmljYXRp b24gbWVjaGFuaXNtIG11c3QgYWNjb3VudCBmb3IgZXhpc3RpbmcKICAgICAgICAgICAgICAg ICAgICBCR1AgbWVjaGFuaXNtcyBzdWNoIGFzIHN1bW1hcml6YXRpb24uIEZvciB0aGUgcHVy cG9zZSBvZiB0aGlzIGRvY3VtZW50IHRoZSB0ZXJtCiAgICAgICAgICAgICAgICAgICAgdmVy aWZpYWJsZSBpcyBkZWZpbmVkIGFzIHRoZSByZXN1bHRhbnQgb2YgYSBzZWN1cmVkIHJvdXRp bmcgc3lzdGVtcyBhcyBkZXNjcmliZWQKICAgICAgICAgICAgICAgICAgICBpbiB0aGlzIGRv Y3VtZW50LiBUaGUgdGVybSBzcGVjaWZpY2FsbHkgaW5kaWNhdGVzIHRoZSBhYmlsaXR5IHRv IHZhbGlkYXRlIHRoZQogICAgICAgICAgICAgICAgICAgIG9yaWdpbmF0b3Igb2YgYSBzcGVj aWZpYyBwcmVmaXggKG9yIGJsb2NrIG9mIElQIGFkZHJlc3NlcykgYW5kIHRoZSBhYmlsaXR5 IHRvCiAgICAgICAgICAgICAgICAgICAgdmFsaWRhdGUgdGhlIHNlc3Npb24gdGhyb3VnaCB3 aGljaCB0aGUgcHJlZml4IHdhcyByZWNlaXZlZAo8L2xpPgo8bGk+VGhlIEFTX1BBVEggbGlz dCBNVVNUIGNvcnJlc3BvbmQgdG8gYSB2ZXJpZmlhYmxlIGxpc3Qgb2YgYXV0b25vbW91cyBz eXN0ZW1zIGJhc2VkCiAgICAgICAgICAgICAgICAgICAgb24gdGhlIHBlZXJpbmcgdG9wb2xv Z3kgb2YgdGhlIG5ldHdvcmsuCjwvbGk+CjxsaT5Bbm5vdW5jaW5nIEFTIENoZWNrOiBGb3Ig YWxsIEJHUCBwZWVycywgYSBCR1AgSW1wbGVtZW50YXRpb24gTVVTVCBlbnN1cmUgdGhhdCB0 aGUKICAgICAgICAgICAgICAgICAgICBmaXJzdCBlbGVtZW50IG9mIHRoZSBBU19QQVRIIGxp c3QgY29ycmVzcG9uZHMgdG8gdGhlIGxvY2FsbHkgY29uZmlndXJlZCBBUyBvZgogICAgICAg ICAgICAgICAgICAgIHRoYXQgcGVlci4KPC9saT4KPC91bD4KPHA+IFRoZXJlIGFyZSBtYW55 IHdheXMgaW4gd2hpY2ggYSBkaWZmZXJlbnRpYWwgYmV0d2VlbiB0aGUgc3BlZWQgb2YgcHJl Zml4L0FTIHBhdGgKICAgICAgICAgICAgICAgIGF0dHJpYnV0ZSBwcm9wYWdhdGlvbiBhbmQg dGhlIGluZm9ybWF0aW9uIHZhbGlkYXRpbmcgdGhlIHRoZSBwcmVmaXgvQVMgcGF0aAogICAg ICAgICAgICAgICAgYXR0cmlidXRlIGluZm9ybWF0aW9uIGNhbiBiZSBleHBsb2l0ZWQgdG8g YXR0YWNrIHRoZSByb3V0aW5nIHN5c3RlbSBvbiBhIHRlbXBvcmFyeQogICAgICAgICAgICAg ICAgYmFzaXMuIFRoZXNlIHR5cGVzIG9mIGF0dGFja3MgYXJlIGRvbWluYW50bHkgZXhwbG9p dGF0aXZlIG9mIHRoZSBtb21lbnQgaW4gdGltZSBpdAogICAgICAgICAgICAgICAgdGFrZXMg dG8gZm9sbG93IHRoZSB3aXRoZHJhdyBvZiBhIE5MUkkgd2l0aCBhbiB1cGRhdGUuIEFzIGEg cmVzdWx0IG9mIHRoaXMgcG90ZW50aWFsCiAgICAgICAgICAgICAgICBmb3IgdGVtcG9yYXJ5 IGRpc3J1cHRpb24sIEJHUCBzZWN1cml0eSBzb2x1dGlvbnMgTVVTVCBwcm9wYWdhdGUgc2Vj dXJpdHkgaW5mb3JtYXRpb24KICAgICAgICAgICAgICAgIGF0IHRoZSBzYW1lIHJhdGUgYXMg dGhlIEJHUCB1cGRhdGVzIGFuZCB3aXRoZHJhd2xzLiBUaGUgZm9sbG93aW5nIGl0ZW1zIGFy ZSByZXF1aXJlZAogICAgICAgICAgICAgICAgdG8gcHJvcGFnYXRlIGF0IHRoZSBzYW1lIHJh dGU6IAo8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5UaGUgZGlzdHJpYnV0aW9uIG9mIGtl eSBpbmZvcm1hdGlvbiB1c2VkIGJ5IGluZGl2aWR1YWwgYWN0b3JzIHdpdGhpbiB0aGUgc3lz dGVtLAogICAgICAgICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUga2V5cyB1c2VkIGJ5IGlu ZGl2aWR1YWwgYXV0b25vbW91cyBzeXN0ZW1zIHRvIHNpZ24gY2VydGlmaWNhdGVzCiAgICAg ICAgICAgICAgICAgICAgYW5kIG90aGVyIG9iamVjdHMKPC9saT4KPGxpPlRoZSBkaXN0cmli dXRpb24gb2YgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEFTIGF1dGhvcml6ZWQgdG8gYWR2ZXJ0 aXNlIGEgZ2l2ZW4KICAgICAgICAgICAgICAgICAgICBibG9jayBvZiBJUCBhZGRyZXNzZXMg KG9yIGFuIGFkZHJlc3Mgc3BhY2UpCjwvbGk+CjxsaT5UaGUgZGlzdHJpYnV0aW9uIG9mIGlu Zm9ybWF0aW9uIGFib3V0IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGF1dG9ub21vdXMgc3lzdGVt cyBhbmQKICAgICAgICAgICAgICAgICAgICBhdXRvbm9tb3VzIHN5c3RlbSBwb2xpY2VzLCBp ZiBzdWNoIGluZm9ybWF0aW9uIGlzIHRvIGJlIGRpc3RyaWJ1dGVkIHdpdGhpbiB0aGUKICAg ICAgICAgICAgICAgICAgICBzZWN1cml0eSBzeXN0ZW0uCjwvbGk+CjwvdWw+CjxhIG5hbWU9 ImFuY2hvcjUiPjwvYT48YnIgLz48aHIgLz4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNSI+PC9h PjxoMz41LiZuYnNwO0FkZHJlc3MgQWxsb2NhdGlvbiBhbmQgYWR2ZXJ0aXNlbWVudDwvaDM+ Cgo8cD4gQXMgcGFydCBvZiB0aGUgcmVndWxhciBvcGVyYXRpb24gb2YgdGhlIEludGVybmV0 LCBhZGRyZXNzZXMgdGhhdCBhcmUgYWxsb2NhdGVkIHRvIGFuCiAgICAgICAgICAgICAgICBv cmdhbml6YXRpb24gbWF5IGJlLCBhbmQgYXJlIHF1aXRlIGNvbW1vbmx5LCBhZHZlcnRpc2Vk IGJ5IGEgZGlmZmVyZW50CiAgICAgICAgICAgICAgICBvcmdhbml6YXRpb25zLiBDb21tb24g cmVhc29ucyBmb3IgdGhpcyBwcmFjdGljZSBpbmNsdWRlIG11bHRpLWhvbWluZyBhbmQgcm91 dGUKICAgICAgICAgICAgICAgIHJlZHVjdGlvbiBmb3IgdGhlIHB1cnBvc2VzIG9mIHJlc291 cmNlIGNvbnNlcnZhdGlvbi4gVGhlcmUgYXJlIHR3byBtb2RlcyBvZiBkZWxlZ2F0aW9uOgo8 L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5BIEJHUCBzcGVha2VyIGFuZCBsaXN0ZW5lciBo YXZlIGNob3NlbiB0byByZXN0cmljdCB0aGUgYW1vdW50IG9mIHJlY2VpdmVkCiAgICAgICAg ICAgICAgICAgICAgcHJlZml4ZXMgZm9yIHRoZSBsaXN0ZW5lci4gVGhlIGxpc3RlbmVyIGhh cyBjaG9zZW4gdG8gaG9ub3Igcm91dGUgYW5ub3VuY2VtZW50cwogICAgICAgICAgICAgICAg ICAgIHNlbnQgaW4gYSBzdW1tYXJ5IGZhc2hpb24gYnkgdGhlIHNwZWFrZXIuCjwvbGk+Cjxs aT4gQWRkcmVzcyBzcGFjZSB0aGF0IGlzIGJlaW5nIGRlbGVnYXRlZCBpcyBwYXJ0IG9mIGEg bGFyZ2VyIGFsbG9jYXRpb24gdGhhdCBpcwogICAgICAgICAgICAgICAgICAgIG93bmVkIGJ5 IGFuIGF1dG9ub21vdXMgc3lzdGVtLiBUaGUgb3duZXIgdGhlbiBkZWxlZ2F0ZXMgdGhlIHNt YWxsZXIgYmxvY2sgdG8KICAgICAgICAgICAgICAgICAgICBhbm90aGVyIEFTIGZvciBwdXJw b3NlcyBvZiBhZHZlcnRpc2VtZW50LiBUaGlzIG1vZGUgaXMgY29tbW9ubHkgb2JzZXJ2ZWQg aW4gbXVsdGktaG9taW5nLgo8L2xpPgo8L3VsPgo8cD4gVGhlc2UgdHdvIG1vZGVzIGxlYWQg dG8gYSBzaW5nbGUgY29tbW9uIHJlcXVpcmVtZW50OiBBbnkgQkdQIFNlY3VyaXR5IHNvbHV0 aW9uIE1VU1QKICAgICAgICAgICAgICAgIHN1cHBvcnQgZGVsZWdhdGlvbiBvZiBhbiBhZGRy ZXNzIGJsb2NrIG9mIGFueSBzaXplIHJlZ2FyZGxlc3Mgb2YgaXRzIHJlbGF0aW9uc2hpcCB0 bwogICAgICAgICAgICAgICAgb3RoZXIgYWRkcmVzcyBibG9ja3MgdG8gYW5vdGhlciBlbnRp dHkgdmlhIHZlcmlmaWFibGUgbWVhbnMuCjwvcD4KPHA+IEFuIGFzc29jaWF0ZWQgZGVsZWdh dGlvbiBjcml0ZXJpYSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gYWxsb3cgZm9yIG5vbi1CR1Ag SVAgZW5kCiAgICAgICAgICAgICAgICB1c2VyIGltcGxlbWVudGF0aW9ucy4gQXMgYSByZXN1 bHQsIGFsbCBzZWN1cmVkIEJHUCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBhbGxvdyBmb3IKICAg ICAgICAgICAgICAgIHRoZSBwcm9wYWdhdGlvbiBvZiBhIHByZWZpeCBieSBtb3JlIHRoYW4g b25lIG9yaWdpbmF0b3IgQVMgd2l0aGluIG5vcm1hbCBuZXR3b3JrCiAgICAgICAgICAgICAg ICBjb252ZXJnZW5jZSB0aW1lcy4KPC9wPgo8YSBuYW1lPSJhbmNob3I2Ij48L2E+PGJyIC8+ PGhyIC8+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYiPjwvYT48aDM+Ni4mbmJzcDtOTFJJIGFu ZCBQYXRoIEF0dHJpYnV0ZSBUcmFja2luZzwvaDM+Cgo8cD4gTm9uLXJlcHVkaWF0aW9uIG9m IHJvdXRpbmcgdXBkYXRlcywgdGhlIGFiaWxpdHkgZm9yIGEgcmVjZWl2ZXIgdG8ga25vdyBl eGFjdGx5IHdobwogICAgICAgICAgICAgICAgb3JpZ2luYXRlZCBhbmQgZm9yd2FyZGVkIGEg cm91dGluZyB1cGRhdGUsIGlzIGEgZGVzaXJhYmxlIHRyYWl0LiBJbiBvcmRlciB0byByYXBp ZGx5CiAgICAgICAgICAgICAgICBpZGVudGlmeSBhZ3Jlc3NvcnMgYW5kIHBhcnRpZXMgYXQg ZmF1bHQgZm9yIHJvdXRlIHRhYmxlIGRpc3J1cHRpb24gaXQgaXMgaW1wb3J0YW50CiAgICAg ICAgICAgICAgICB0byB0cmFjayBhbmQgbG9nIHByZWZpeCBvcmlnaW5hdGlvbiBpbmZvcm1h dGlvbiBhbG9uZyB3aXRoIGFzc29jaWF0ZWQgc2VjdXJpdHkgaW5mb3JtYXRpb24uCjwvcD4K PHA+IEFueSBzZWN1cml0eSBzeXN0ZW0gU0hPVUxEIHByb3ZpZGUgYSBtZXRob2QgdG8gYWxs b3cgdGhlIHJlY2VpdmVyIG9mIGFuIHVwZGF0ZSB0bwogICAgICAgICAgICAgICAgdmVyaWZ5 IHRoYXQgdGhlIG9yaWdpbmF0b3IgYWN0dWFsbHkgb3JpZ2luYXRlZCB0aGUgdXBkYXRlLCBh bmQgdGhhdCB0aGUgQVMncyBsaXN0ZWQKICAgICAgICAgICAgICAgIGluIHRoZSBBU19QQVRI IGFjdHVhbGx5IGZvcndhcmRlZCB0aGUgdXBkYXRlLgo8L3A+CjxwPiBUaGUgZGF0YSBnZW5l cmF0ZWQgYnkgbG9nZ2luZyBtYXkgYmUgdmVyeSBsYXJnZSBkZXBlbmRpbmcgb24gdGhlIG51 bWJlciBvZiBwZWVycywKICAgICAgICAgICAgICAgIHRoZSBudW1iZXIgb2YgcHJlZml4ZXMg cmVjZWl2ZWQsIHRoZSBhdXRoZW50aWNhdGlvbiBtb2RlbCB1c2VkLCBhbmQgcm91dGluZwog ICAgICAgICAgICAgICAgcG9saWNpZXMuIEFzIHN1Y2gsIGVmZmljaWVudCBkYXRhIHN0cnVj dHVyZXMgYW5kIHN0b3JhZ2UgbWVjaGFuaXNtcyBNVVNUIGJlCiAgICAgICAgICAgICAgICBk ZXZlbG9wZWQgdG8gYWxsb3cgZm9yIGFuIGVmZmVjdGl2ZSBtZWFucyBvZiByZXByb2R1Y2lu ZyBpbmNpZGVudHMgYW5kIG91dGFnZXMKPC9wPgo8cD4gUGF0aCBhbmQgTkxSSSBhdHRyaWJ1 dGVzIE1VU1QgYmUgbG9nZ2VkIHVzaW5nIGEgc3RhbmRhcmQgZm9ybWF0LiBUaGUgZm9ybWF0 IG11c3QgYmUKICAgICAgICAgICAgICAgIHNjYWxhYmxlIHdpdGggdGhlIGFtb3VudCBvZiBk YXRhIGxvZ2dlZCBhbmQgdGhlIGZyZXF1ZW5jeSBvZiBsb2cgZ2VuZXJhdGlvbi4gVGhlCiAg ICAgICAgICAgICAgICBmcmVxdWVuY3kgb2YgbG9nIGdlbmVyYXRpb24gc2hvdWxkIGJlIGNv bnRyb2xsYWJsZSBieSB0aGUgb3BlcmF0b3IuIFRoZSBsb2dnaW5nCiAgICAgICAgICAgICAg ICBtZWNoYW5pc21zIGZvciB0aGUgdHJhY2tlZCBpbmZvcm1hdGlvbiBNVVNUIGJlIHN0YW5k YXJkaXplZCBhY3Jvc3MgYWxsIHBsYXRmb3Jtcy4KICAgICAgICAgICAgICAgIExvZ2dpbmcg YWJpbGl0eSBib3RoIG9uIGFuZCBvZmYgbGluZSBpcyBjb25zaWRlcmVkIGhpZ2hseSBkZXNp cmFibGUuCjwvcD4KPGEgbmFtZT0iYW5jaG9yNyI+PC9hPjxiciAvPjxociAvPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi43Ij48L2E+PGgzPjcuJm5ic3A7VHJhbnNwb3J0IFByb3RlY3Rpb248 L2gzPgoKPHA+IFRyYW5zcG9ydCBwcm90ZWN0aW9uIGlzIGFuIGltcG9ydGFudCBhc3BlY3Qg b2YgQkdQIHJvdXRpbmcgcHJvdG9jb2wgc2VjdXJpdHkuIFRoZQogICAgICAgICAgICAgICAg cG90ZW50aWFsIHRvIGNyZWF0ZSBhIGxpbmtlZCB0cmFuc3BvcnQvTkxSSS9BUy1QQVRIIGF1 dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBzaG91bGQKICAgICAgICAgICAgICAgIG5vdCBiZSBv dmVybG9va2VkIGFuZCBtYXkgcHJvdmlkZSBmb3IgdGhlIGFjY2VsZXJhdGVkIGRlcGxveW1l bnQgb2YgYSBCR1Agc2VjdXJpdHkKICAgICAgICAgICAgICAgIHN5c3RlbS4gQ3VycmVudCBz ZWN1cml0eSBtZWNoYW5pc21zIGZvciBCR1AgdHJhbnNwb3J0IGFyZSBpbmFkZXF1YXRlIGFu ZCByZXF1aXJlCiAgICAgICAgICAgICAgICBzaWduaWZpY2FudCBvcGVyYXRvciBpbnRlcmFj dGlvbiB0byBtYWludGFpbiBhIHJlc3BlY3RhYmxlIGxldmVsIG9mIHNlY3VyaXR5Lgo8L3A+ CjxwPiBBbnkgcHJvcG9zZWQgc2VjdXJpdHkgbWVjaGFuaXNtIE1VU1QgaW5jbHVkZSBwcm92 aXNpb25zIGZvciBzZWN1cmluZyBib3RoIGludGVybmFsCiAgICAgICAgICAgICAgICBCR1Ag YW5kIGV4dGVybmFsIEJHUCBwZWVyaW5nIHNlc3Npb25zLiBLZXkgbWFpbnRlbmFuY2UgY2Fu IGJlIGVzcGVjaWFsbHkgb25lcm91cyB0bwogICAgICAgICAgICAgICAgdGhlIG9wZXJhdG9y cy4gVGhlIG51bWJlciBvZiBrZXlzIHJlcXVpcmVkIGFuZCB0aGUgbWFpbnRlbmFuY2Ugb2Yg a2V5cwogICAgICAgICAgICAgICAgKHVwZGF0ZS93aXRoZHJhdy9yZW5ldykgbWF5IGhhdmUg YW4gYWRkaXRpdmUgYWZmZWN0IHRvIGEgYmFycmllciB0byBkZXBsb3ltZW50LiBBCiAgICAg ICAgICAgICAgICBoaWdobHkgc2VjdXJhYmxlIEJHUCByb3V0aW5nIHN5c3RlbSBTSE9VTEQg cmVxdWlyZSBubyBtb3JlIHRoYW4gdGhyZWUga2V5cyBhbmQgZWFjaAogICAgICAgICAgICAg ICAga2V5IHNob3VsZCBiZSB1cGRhdGVhYmxlIHdpdGhpbiBzaW1pbGFyIHRpbWVmcmFtZXMg YXMgcHJlZml4IHByb3BhZ2F0aW9uLiBUaGUKICAgICAgICAgICAgICAgIHByZWZlcnJlZCBu dW1iZXIgb2Yga2V5cyBpcyBPTkUgcGVyIEFTLgo8L3A+CjxwPlRyYW5zcG9ydCBwcm90ZWN0 aW9uIHN5c3RlbXMgU0hPVUxEIGZ1bmN0aW9uIGFzIGEgY29tcG9uZW50IG9mIHRoZSBCR1Ag cm91dGluZwogICAgICAgICAgICAgICAgcHJvdG9jb2wgc2VjdXJpdHkgbWVjaGFuaXNtLiBU aGlzIGluY2x1ZGVzIHRoZSB1c2Ugb2YgdGhlIHNhbWUga2V5CiAgICAgICAgICAgICAgICBn ZW5lcmF0aW9uL21hbmFnZW1lbnQgc3lzdGVtcyBhcyB0aGUgcmVzdCBvZiB0aGUgc2VjdXJp dHkgc3lzdGVtLgo8L3A+CjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzMSI+PC9hPjxiciAvPjxo ciAvPgo8aDM+OCZuYnNwO1JlZmVyZW5jZXM8L2gzPgo8dGFibGUgd2lkdGg9Ijk5JSIgYm9y ZGVyPSIwIj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBu YW1lPSJSRkMyMTk2Ij5bMV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RnJh c2VyLCAiUkZDIDIxOTYgLSBTaXRlIFNlY3VyaXR5IEhhbmRib29rIiwgU2VwdGVtYmVyIDE5 OTcuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3Ai PjxhIG5hbWU9IlJGQzM1NTIiPlsyXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5SZXNjb3JsYSwgS29ydmVyIGFuZCBJbnRlcm5ldCBBcmNoaXRlY3R1cmUgQm9hcmQsICJS RkMgMzU1MiAtIEd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDIFRleHQgb24gU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMiLCBKdWx5IDIwMDMuPC90ZD48L3RyPgo8L3RhYmxlPgoKPGEgbmFt ZT0icmZjLmF1dGhvcnMiPjwvYT48YnIgLz48aHIgLz4KPGgzPkF1dGhvcnMnIEFkZHJlc3Nl czwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5CbGFpbmUgQ2hyaXN0aWFuIChlZGl0b3IpPC90 ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+S01DIFRlbGVjb20gU29sdXRpb25zPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3It dGV4dCI+MzA1IENodXJjaCBTdHJlZXQgU3VpdGUgNzE1PC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ SHVudHN2aWxsZSwgQUwgIDM1ODAxPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3It dGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+VVM8L3RkPjwvdHI+ Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRkPiZuYnNwOzwvdGQ+PC90 cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPkJvcmEgQWt5b2w8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5DaXNjbyBTeXN0 ZW1zPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+MTcwIFRhc21hbiBEcml2ZTwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPlNhbiBKb3NlLCBDQSAgOTUxMzQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5VUzwvdGQ+ PC90cj4KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90 ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+UnVzcyBXaGl0ZTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkNpc2Nv IFN5c3RlbXM8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij43MDI1IEtpdCBDcmVlayBSb2FkPC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNz PSJhdXRob3ItdGV4dCI+UmVzZWFyY2ggVHJpYW5nbGUgUGFyaywgTkMgIDk1MTM0PC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNz PSJhdXRob3ItdGV4dCI+VVM8L3RkPjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZu YnNwOzwvdGQ+PHRkPiZuYnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkplZmZyZXkgSGFhczwv dGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPk5leHQgSG9wIFRlY2hub2xvZ2llczwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPjgyNSBWaWN0b3JzIFdheSBTdWl0ZSAxMDA8L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5B bm4gQXJib3IsIE1JICA0ODEwODwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPlVTPC90ZD48L3RyPgo8 dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3RkPjx0ZD4mbmJzcDs8L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5TYW5keSBNdXJwaHk8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5UcnVzdGVkIElu Zm9ybWF0aW9uIFN5c3RlbXM8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4zMDYwIFdhc2hpbmd0b24g Um9hZDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+ Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkdsZW53b29kLCBNRCAgMjEzNzg8L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5VUzwvdGQ+PC90cj4KPC90YWJsZT4KCjxhIG5hbWU9ImFuY2hvcjgiPjwv YT48YnIgLz48aHIgLz4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQSI+PC9hPjxoMz5BcHBlbmRp eCBBLiZuYnNwO0Fja25vd2xlZGdlbWVudHM8L2gzPgoKPHA+IFRoZSBmb2xsb3dpbmcgaW5k aXZpZHVhbHMgY29udHJpYnV0ZWQgdG8gdGhlIGRldmVsb3BtZW50IGFuZCByZXZpZXcgb2Yg dGhpcyBkcmFmdC4KICAgICAgICAgICAgICAgIFN0ZXZlIEtlbnQsIE1pa2UgVGlib2RlYXUs IFRob21hcyBSZW56eSwgS2FhcnRoaWsgU2l2YWt1bWFyLCBUYW8gV2FuLCBSYWRpYSBQZXJs bWFuLCBhbmQgTWVyaWtlCiAgICAgICAgICAgICAgICBLYWVvLiAKPC9wPgo8cD4gVGhpcyBk cmFmdCB3YXMgZGV2ZWxvcGVkIGJhc2VkIG9uIGNvbnZlcnNhdGlvbnMgd2l0aCB2YXJpb3Vz IG5ldHdvcmsgb3BlcmF0b3JzCiAgICAgICAgICAgICAgICBpbmNsdWRpbmcgQ2hyaXMgTW9y cm93LCBKYXJlZCBNYXVjaCwgVGltIEJhdHRsZXMsIGFuZCBSeWFuIE1jRG93ZWxsLgo8L3A+ PGEgbmFtZT0icmZjLmNvcHlyaWdodCI+PC9hPjxiciAvPjxociAvPgo8aDM+SW50ZWxsZWN0 dWFsIFByb3BlcnR5IFN0YXRlbWVudDwvaDM+CjxwIGNsYXNzPSdjb3B5cmlnaHQnPgpUaGUg SUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl IG9mIGFueQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIGNsYWltZWQKdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IApkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBv ciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIAp1bmRlciBzdWNoIHJpZ2h0cyBt aWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdApyZXByZXNlbnQg dGhhdCBpdCBoYXMgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFu eQpzdWNoIHJpZ2h0cy4KSW5mb3JtYXRpb24gb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNw ZWN0IHRvCnJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZSBmb3VuZCBpbiBCQ1AgNzgg YW5kIEJDUCA3OS48L3A+CjxwIGNsYXNzPSdjb3B5cmlnaHQnPgpDb3BpZXMgb2YgSVBSIGRp c2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQphc3N1cmFu Y2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLApvciB0aGUgcmVzdWx0IG9m IGFuIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IKcGVybWlz c2lvbiBmb3IgdGhlIHVzZSBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1l bnRlcnMgb3IKdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBm cm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSCnJlcG9zaXRvcnkgYXQgaHR0cDovL3d3dy5pZXRm Lm9yZy9pcHIuPC9wPgo8cCBjbGFzcz0nY29weXJpZ2h0Jz4KVGhlIElFVEYgaW52aXRlcyBh bnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uCmFueSBjb3B5 cmlnaHRzLApwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsCm9yIG90aGVyCnByb3By aWV0YXJ5IHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJl cXVpcmVkCnRvIGltcGxlbWVudCB0aGlzIHN0YW5kYXJkLgpQbGVhc2UgYWRkcmVzcyB0aGUg aW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi1pcHJAaWV0Zi5vcmcuPC9wPgo8aDM+ RGlzY2xhaW1lciBvZiBWYWxpZGl0eTwvaDM+CjxwIGNsYXNzPSdjb3B5cmlnaHQnPgpUaGlz IGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJv dmlkZWQKb24gYW4gJnF1b3Q7QVMgSVMmcXVvdDsgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRP UiwKVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUyBPUiBJUyBTUE9OU09SRUQg QlkgKElGIEFOWSksClRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5H SU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTQpBTEwgV0FSUkFOVElFUywgCkVYUFJFU1Mg T1IgSU1QTElFRCwKSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkg VEhBVCBUSEUgVVNFIE9GIFRIRQpJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRApXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJ TElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS48L3A+CjxoMz5Db3B5 cmlnaHQgU3RhdGVtZW50PC9oMz4KPHAgY2xhc3M9J2NvcHlyaWdodCc+CkNvcHlyaWdodCAo QykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLgpUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QgdG8gdGhlIHJpZ2h0cywKbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQg aW4gQkNQIDc4LAphbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLAp0aGUgYXV0aG9y cyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy48L3A+CjxoMz5BY2tub3dsZWRnbWVudDwvaDM+ CjxwIGNsYXNzPSdjb3B5cmlnaHQnPgpGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5j dGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlCkludGVybmV0IFNvY2lldHkuPC9w Pgo8L2JvZHk+PC9odG1sPgo= --B_3185102983_1991455 Content-type: application/msword; name="draft-christian-bgpsecrec-02.txt"; x-mac-creator="4D535744"; x-mac-type="54455854" Content-disposition: attachment; filename="draft-christian-bgpsecrec-02.txt" Content-Transfer-Encoding: base64 CgpSb3V0aW5nIFByb3RvY29sIFNlY3VyaXR5ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQi4gQ2hyaXN0aWFuLCBFZC4KUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgS01DIFRlbGVjb20gU29sdXRpb25zCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCLiBB a3lvbApFeHBpcmVzOiBKdW5lIDUsIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUi4gV2hpdGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Si4gSGFhcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOZXh0IEhvcCBUZWNobm9sb2dpZXMKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gTXVycGh5CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRydXN0ZWQgSW5mb3JtYXRp b24gU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIERlY2VtYmVyIDUsIDIwMDQKCgogICAgICAgICAgICAgICAgICAgICAg IEJHUCBTZWN1cml0eSBSZXF1aXJlbWVudHMKICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0 LWNocmlzdGlhbi1iZ3BzZWNyZWMtMDIKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1 Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0 aGF0IGFueQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdo aWNoIGhlIG9yIHNoZSBpcyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgUkZDCiAgIDM2NjguCgogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzCiAgIEludGVybmV0LURyYWZ0cy4KCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHBy b3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQg YXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAg VGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBh Y2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdW5lIDUsIDIwMDUuCgpDb3B5cmln aHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0 KS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCgpBYnN0cmFjdAoKICAgVGhlIHNlY3VyaXR5IG9m IEJHUCBpcyBjcml0aWNhbCB0byB0aGUgcHJvcGVyIG9wZXJhdGlvbiBvZgogICBsYXJnZS1z Y2FsZSBpbnRlcm5ldHdvcmtzLCBib3RoIHB1YmxpYyBhbmQgcHJpdmF0ZS4gIFdoaWxlIHNl Y3VyaW5nCiAgIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBiZXR3ZWVuIHR3byBCR1Ag c3BlYWtlcnMgaXMgYSByZWxhdGl2ZWx5CgoKCkNocmlzdGlhbiwgZXQgYWwuICAgICAgICAg RXhwaXJlcyBKdW5lIDUsIDIwMDUgICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAg RGVjZW1iZXIgMjAwNAoKCiAgIGVhc3kgdGVjaG5pY2FsIG1hdHRlciwgc2VjdXJpbmcgQkdQ LCBhcyBhIHJvdXRlZCBzeXN0ZW0sIGlzIG1vcmUKICAgY29tcGxleC4gIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGEgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3Igc2VjdXJpbmcKICAgQkdQ LCBpbmNsdWRpbmcgc2VjdXJpbmcgcGVlcmluZyByZWxhdGlvbnNoaXBzIGJldHdlZW4gQkdQ IHNwZWFrZXJzLAogICBhbmQgYXV0aGVudGljYXRpbmcgdGhlIHJvdXRpbmcgaW5mb3JtYXRp b24gY2FycmllZCB3aXRoaW4gQkdQLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCkNocmlzdGlhbiwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdW5l IDUsIDIwMDUgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgQkdQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAgRGVjZW1iZXIgMjAw NAoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRocmVhdHMgdG8gbmV0d29ya2luZyBwcm90b2Nv bHMgZ2VuZXJhbGx5IGZhbGwgdW5kZXIgb25lIG9mIHRoZSB0aHJlZQogICBjYXRlZ29yaWVz IGFzIGRlZmluZWQgaW4gUkZDIDIxOTYgWzFdOgogICBvICBVbmF1dGhvcml6ZWQgYWNjZXNz IHRvIHJlc291cmNlcyBhbmQvb3IgaW5mb3JtYXRpb24KICAgbyAgVW5pbnRlbmRlZCBhbmQv b3IgdW5hdXRob3JpemVkIGRpc2Nsb3N1cmUgb2YgaW5mb3JtYXRpb24KICAgbyAgRGVuaWFs IG9mIHNlcnZpY2UKCiAgIEEgbnVtYmVyIG9mIGF0dGFja3MgY2FuIGJlIHJlYWxpemVkIHdo aWNoLCBpZiBleHBsb2l0ZWQsIGNhbiBsZWFkIHRvCiAgIG9uZSBvZiB0aGUgYWJvdmUgbWVu dGlvbmVkIHRocmVhdHMuICBUaGVzZSBhcmUgdHlwaWNhbGx5IGNsYXNzaWZpZWQKICAgYXMg cGFzc2l2ZSBhdHRhY2tzIGFuZCBhY3RpdmUgYXR0YWNrcy4gIFBhc3NpdmUgYXR0YWNrcyBh cmUgb25lcwogICB3aGVyZSBhbiBhdHRhY2tlciBzaW1wbHkgcmVhZHMgaW5mb3JtYXRpb24g b2ZmIHRoZSBuZXR3b3JrIGFuZAogICBvYnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJp dmF0ZSBpbmZvcm1hdGlvbi4gIEFjdGl2ZSBhdHRhY2tzIGFyZQogICBvbmVzIHdoZXJlIHRo ZSBhdHRhY2tlciB3cml0ZXMgZGF0YSB0byB0aGUgbmV0d29yayBhbmQgY2FuIGluY2x1ZGUK ICAgcmVwbGF5IGF0dGFja3MsIG1lc3NhZ2UgaW5zZXJ0aW9uLCBtZXNzYWdlIGRlbGV0aW9u LCBtZXNzYWdlCiAgIG1vZGlmaWNhdGlvbiBhbmQgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNr cy4gIFRoZXNlIGF0dGFja3MgYXJlIG9mdGVuCiAgIGNvbWJpbmVkLgoKICAgQXR0YWNrcyB0 aGF0IGRvIG5vdCBpbnZvbHZlIGRpcmVjdCBtYW5pcHVsYXRpb24gb2YgQkdQLCBhbmQgdGhl CiAgIGluZm9ybWF0aW9uIGNvbnRhaW5lZCB3aXRoaW4gaXQsIGFyZSBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzCiAgIGRvY3VtZW50LiAgV2hlbiBwb3NzaWJsZSwgdGhlIHJlcXVpcmVt ZW50cyB3aWxsIGF0dGVtcHQgdG8gbWluaW1pemUKICAgdGhlIGV4dGVudCBvZiB0aGUgZGFt YWdlIHRoYXQgb2NjdXJzIHdoZW4gZW5kIHN5c3RlbXMgY29tZSB1bmRlcgogICBhdHRhY2su CgogICBUaGUgaW50ZW50IG9mIHRoaXMgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGlzIHRvIHBy ZXZlbnQgYXR0YWNrcyB0aGF0CiAgIG9yaWdpbmF0ZSBmYWxzZSBkYXRhIG9yIGNyZWF0ZSBp bnZhbGlkIHJvdXRpbmcgcGF0aHMgYW5kIHRoZXJlZm9yZQogICBhZGRyZXNzZXMgaXNzdWVz IHJlbGF0aW5nIHRvIGRhdGEgaW50ZWdyaXR5IGFuZCBwZWVyIGVudGl0eQogICBhdXRoZW50 aWNhdGlvbi4gIEFzIGRlc2NyaWJlZCBpbiBSRkMgMzU1MiBbMl0sIGRhdGEgaW50ZWdyaXR5 CiAgIHByb3RlY3Rpb24gZW5zdXJlcyB0aGF0IGRhdGEgaXMgbm90IG1vZGlmaWVkIGluIHRy YW5zaXQgYW5kIHBlZXIKICAgZW50aXR5IGF1dGhlbnRpY2F0aW9uIGVuc3VyZXMgdGhhdCB0 aGVyZSBpcyBhIHJlYXNvbmFibGUgZ3VhcmFudGVlCiAgIHRoYXQgdGhlIHNlbmRlciBhbmQg cmVjaXBpZW50IG9mIHRoZSBkYXRhIGFyZSB0aGUgaW50ZW5kZWQgcGFydGllcy4KCiAgIEd1 YXJhbnRlZWQgcGFja2V0IGRlbGl2ZXJ5IGlzIG5vdCBwYXJ0IG9mIHRoZSBCR1AgcHJvdG9j b2wgc2VjdXJpdHkKICAgbW9kZWwuICBKdXN0IGJlY2F1c2UgYSBwYWNrZXQgaXMgYWRkcmVz c2VkIHRvIGEgc3BlY2lmaWMgZGVzdGluYXRpb24KICAgZG9lcyBub3QgbWVhbiBpdCB3aWxs IGJlIHJlY2VpdmVkLCBldmVuIHdpdGggYSAic2VjdXJlIiByb3V0ZS4gIEZvcgogICBleGFt cGxlOiBhbiBhdHRhY2tlciBjb3VsZCBoYXZlIGNvbXByb21pc2VkIGFuIGludGVybWVkaWF0 ZSByb3V0ZXIKICAgYW5kIGluc3RhbGxlZCBhIHN0YXRpYyByb3V0ZSBmb3IgdGFyZ2V0IGFk ZHJlc3MgQS5CLkMuRCBwb2ludGluZyB0bwogICBhbiBpbmFwcHJvcHJpYXRlIGRpcmVjdGlv biBvciBhbiBhdHRhY2tlciBtaWdodCBzcGxpY2UgaW50byBhIGNpcmN1aXQKICAgYmV0d2Vl biB0d28gc2VjdXJlIHJvdXRlcnMgYW5kIGluc3RhbGwgYSBkZXZpY2UgdGhhdCBkaXZlcnRz IEEuQi5DLkQKICAgdHJhZmZpYyB3aXRob3V0IHJlcXVpcmluZyB0aGUgY29tcHJvbWlzZSBv ZiBjb250cm9sIHBsYW5lIGRldmljZXMuCgoKCgoKCgoKCgoKQ2hyaXN0aWFuLCBldCBhbC4g ICAgICAgICBFeHBpcmVzIEp1bmUgNSwgMjAwNSAgICAgICAgICAgICAgICAgIFtQYWdlIDNd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCR1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAg ICAgICAgICBEZWNlbWJlciAyMDA0CgoKMi4gIERlcGxveW1lbnQgUmVxdWlyZW1lbnRzCgog ICBXZSBoYXZlIGRldGVybWluZWQsIHRocm91Z2ggZGlzY3Vzc2lvbiB3aXRoIHdpdGggc2V2 ZXJhbCBsYXJnZQogICBpbnRlcm5ldHdvcmsgb3BlcmF0b3JzIGFuZCBlcXVpcG1lbnQgdmVu ZG9ycywgdGhhdCB0aGUgZm9sbG93aW5nCiAgIGF0dHJpYnV0ZXMgYXJlIGltcG9ydGFudCB0 byB0aGUgb25nb2luZyBwZXJmb3JtYW5jZSBvZiBpbnRlcmRvbWFpbgogICByb3V0aW5nIHN5 c3RlbXMgc3VjaCBhcyBCR1A6CiAgIG8gIENvbnZlcmdlbmNlIFNwZWVkOiBDb252ZXJnZW5j ZSBzcGVlZCBpcyBhIG1ham9yIGNvbmNlcm4gdG8gbWFueQogICAgICBvcGVyYXRvcnMgb2Yg bGFyZ2Ugc2NhbGUgaW50ZXJuZXR3b3JraW5nIHN5c3RlbXMuICBOZXR3b3JrcywgYW5kCiAg ICAgIGludGVybmV0d29ya3MsIGFyZSBjYXJyeWluZyBldmVyIGluY3JlYXNpbmcgYW1vdW50 cyBvZiBpbmZvcm1hdGlvbgogICAgICB0aGF0IGlzIHRpbWUgYW5kIGRlbGF5IHNlbnNpdGl2 ZTsgaW5jcmVhc2luZyBjb252ZXJnZW5jZSB0aW1lcyBjYW4KICAgICAgYWR2ZXJzZWx5IGFm ZmVjdCB0aGUgdXNhYmlsaXR5IG9mIHRoZSBuZXR3b3JrLCBhbmQgdGhlIGFiaWxpdHkgb2YK ICAgICAgYW4gaW50ZXJuZXR3b3JrIHRvIGdyb3cuICBCR1AncyBjb252ZXJnZW5jZSBzcGVl ZCwgd2l0aCBhIHNlY3VyaXR5CiAgICAgIHN5c3RlbSBpbiBvcGVyYXRpb24sIFNIT1VMRCBi ZSBlcXVpdmFsZW50IHRvIEJHUCBydW5uaW5nIHdpdGhvdXQKICAgICAgdGhlIHNlY3VyaXR5 IHN5c3RlbSBpbiBvcGVyYXRpb24uICBUaGlzIGluY2x1ZGVzIHRoZSBwcmVzZXJ2YXRpb24K ICAgICAgb2Ygb3B0aW1pemF0aW9ucyBjdXJyZW50bHkgdXNlZCB0byBwcm9kdWNlIGFjY2Vw dGFibGUgY29udmVyZ2VuY2UKICAgICAgc3BlZWRzIG9uIGN1cnJlbnQgaGFyZHdhcmUsIGlu Y2x1ZGluZyB1cGRhdGUgcGFja2luZywgcGVlciBncm91cHMsCiAgICAgIGFuZCBvdGhlcnMu ICBDdXJyZW50IHRpbWVycywgaW5jbHVkaW5nIGhvbGQgdGltZXJzLCBrZWVwYWxpdmUKICAg ICAgdGltZXJzLCBhbmQgdGhlIHBlZXJpbmcgcHJvY2VzcywgU0hPVUxEIE5PVCBiZSBpbXBh Y3RlZCBieSB0aGUKICAgICAgc2VjdXJpdHkgc3lzdGVtLiAgVHdvIHR5cGVzIG9mIHZlcmlm aWNhdGlvbiBNQVkgYmUgb2ZmZXJlZCBmb3IgdGhlCiAgICAgIE5MUkkgYW5kIHRoZSBBU19Q QVRIIGluIG9yZGVyIHRvIGFsbG93IGZvciBhIHNlbGVjdGlvbiBvZgogICAgICBvcHRpbWl6 YXRpb25zOgogICAgICAqICBDb250ZW50cyBvZiB0aGUgVVBEQVRFIG1lc3NhZ2UgU0hPVUxE IGJlIGF1dGhlbnRpY2F0ZWQgaW4KICAgICAgICAgcmVhbC10aW1lIGFzIHRoZSBVUERBVEUg bWVzc2FnZSBpcyBwcm9jZXNzZWQuCiAgICAgICogIFRoZSByb3V0ZSBpbmZvcm1hdGlvbiBi YXNlIE1BWSBiZSBhdXRoZW50aWNhdGVkIHBlcmlvZGljYWxseSBvcgogICAgICAgICBpbiBh biBldmVudCBkcml2ZW4gbWFubmVyIGJ5IHNjYW5uaW5nIHRoZSBkYXRhIGFuZCB2ZXJpZnlp bmcKICAgICAgICAgdGhlIG9yaWdpbmF0aW5nIEFTIGFuZCB0aGUgdmVyaWZpYWJpbGl0eSBv ZiB0aGUgQVMtUEFUSCBsaXN0LgogICAgICBBbGwgQkdQIGltcGxlbWVudGF0aW9ucyB0aGF0 IGltcGxlbWVudCBzZWN1cml0eSBNVVNUIHV0aWxpemUgYXQKICAgICAgbGVhc3Qgb25lIG9m IHRoZSBhYm92ZSBtZXRob2RzIGZvciB2YWxpZGF0aW5nIHJvdXRpbmcgaW5mb3JtYXRpb24u CiAgICAgIFJlYWwgdGltZSB2ZXJpZmljYXRpb24gaXMgcHJlZmVycmVkIGluIG9yZGVyIHRv IHByZXZlbnQgdHJhbnNpdGl2ZQogICAgICBmYWlsdXJlcyBiYXNlZCBvbiBwZXJpb2RpYyBv ciBldmVudCBkcml2ZW4gc2NhbiBpbnRlcnZhbHMuCiAgIG8gIEluY3JlbWVudGFsIERlcGxv eW1lbnQ6IFdlIHdpbGwgbm90IGJlIGFibGUgdG8gZGVwbG95IGEgbmV3bHkKICAgICAgc2Vj dXJlZCBCR1AgcHJvdG9jb2wgaW5zdGFudGFuZW91c2x5IGFuZCB3aWxsIGJlIHVuYWJsZSB0 byBkaWN0YXRlCiAgICAgIGEgcGFydGl0aW9uaW5nIG9mIGxhcmdlIGludGVybmV0d29ya3Mg YnkgdGhlIG9wZXJhdG9ycy4gIEJHUCBNVVNUCiAgICAgIHN1cHBvcnQgYm90aCBzZWN1cmVk IGFuZCB1bnNlY3VyZWQgcm91dGVzIHdpdGggdGhlIHNlY3VyaXR5IHN5c3RlbQogICAgICBp biBwbGFjZS4gIFRoZSBzZWN1cml0eSBzeXN0ZW0gTVVTVCBhbGxvdyB0aGUgZm9ybWluZyBv ZiBwZWVyaW5nCiAgICAgIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBzZWN1cmUgYW5kIG5vbi1z ZWN1cmUgQkdQIHNwZWFrZXJzLCBhbmQgTVVTVAogICAgICBiZSBiYWNrd2FyZCBjb21wYXRp YmxlIGluIHRoZSBtZXNzYWdlIGZvcm1hdHRpbmcsIHRyYW5zbWlzc2lvbiwKICAgICAgYW5k IHByb2Nlc3Npbmcgb2Ygcm91dGluZyBpbmZvcm1hdGlvbiBjYXJyaWVkIHRocm91Z2ggYSBt aXhlZAogICAgICBzZWN1cml0eSBlbnZpcm9ubWVudC4gIE1lc3NhZ2UgZm9ybWF0dGluZyBp biBhIGZ1bGx5IHNlY3VyZWQKICAgICAgZW52aXJvbm1lbnQgTUFZIGJlIGhhbmRsZWQgaW4g YSBub24tYmFja3dhcmQgY29tcGF0aWJsZSBmYXNoaW9uLgogICBvICBUcnVzdCBsZXZlbCBW YXJpYWJpbGl0eTogRWFjaCBzZWN1cmVkIGVudmlyb25tZW50IG1heSBoYXZlCiAgICAgIGRp ZmZlcmVudCBsZXZlbHMgb2YgcmVxdWlyZW1lbnRzIGluIHRlcm1zIG9mIHdoYXQgaXMgYWNj ZXB0YWJsZSBvcgogICAgICB1bmFjY2VwdGFibGUuICBJbiBlbnZpcm9ubWVudHMgdGhhdCBy ZXF1aXJlIHN0cmljdCBzZWN1cml0eSBpdCBtYXkKICAgICAgbm90IGJlIGFjY2VwdGFibGUg dG8gdGVtcG9yYXJpbHkgcm91dGUgdG8gYSBkZXN0aW5hdGlvbiB3aGlsZQogICAgICB3YWl0 aW5nIGZvciBzZWN1cml0eSB2ZXJpZmljYXRpb24gdG8gYmUgcGVyZm9ybWVkLiAgSG93ZXZl ciwgaW4KICAgICAgbWFueSBjb21tZXJjaWFsIGVudmlyb25tZW50cyB0aGUgcmFwaWRpdHkg b2Ygcm91dGUgaW5zdGFsbGF0aW9uCiAgICAgIG1heSBiZSBvZiBwYXJhbW91bnQgaW1wb3J0 YW5jZTsgaW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0aGUgbW9yZQogICAgICBjb21tb24gb2Nj dXJlbmNlIG9mIHJvdXRlIHdpdGhkcmF3bCBkdWUgdG8gbmV0d29yayBmYWlsdXJlLiAgQmFz ZWQKCgoKQ2hyaXN0aWFuLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1bmUgNSwgMjAwNSAg ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCR1Ag U2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICBEZWNlbWJlciAyMDA0CgoKICAgICAg b24gdGhlIHR3byBkaXZlcmdlbnQgcmVxdWlyZW1lbnRzLCB0aGUgc2VjdXJpdHkgc3lzdGVt IE1VU1QKICAgICAgc3VwcG9ydCBhIHJhbmdlIG9mIHBvc3NpYmxlIG91dHB1dHMgZm9yIGxv Y2FsIGRldGVybWluYXRpb24gb2YgdGhlCiAgICAgIHRydXN0IGxldmVsIGZvciBhIHNwZWNp ZmljIHJvdXRlLiAgQW55IGdpdmVuIHJvdXRlIHNob3VsZCBiZQogICAgICB0cnVzdGFibGUg dG8gYSBsb2NhbGx5IGNvbmZpZ3VyZWQgZGVncmVlLCBiYXNlZCBvbiB0aGUKICAgICAgY29t cGxldGVuZXNzIG9mIHNlY3VyaXR5IGluZm9ybWF0aW9uIGZvciB0aGUgdXBkYXRlIGFuZCBv dGhlcgogICAgICBmYWN0b3JzLiAgVGhlIHNlY3VyaXR5IHN5c3RlbSBTSE9VTEQgYWxsb3cg dGhlIG9wZXJhdG9yIHRvCiAgICAgIGRldGVybWluZSB3aGV0aGVyIHRoZSBzcGVlZCBvZiBj b252ZXJnZW5jZSBpcyBtb3JlIGltcG9ydGFudCB0aGFuCiAgICAgIHNlY3VyaXR5IG9wZXJh dGlvbnMsIG9yIHNlY3VyaXR5IG9wZXJhdGlvbnMgYXJlIG1vcmUgaW1wb3J0YW50CiAgICAg IHRoYW4gdGhlIHNwZWVkIG9mIGNvbnZlcmdlbmNlLiAgVGhpcyBmYWNpbGl0YXRlcyB0aGUg aW5jcmVtZW50YWwKICAgICAgZGVwbG95bWVudCBvZiBzZWN1cml0eSBvbiBzeXN0ZW1zIG5v dCBkZXNpZ25lZCB0byBzdXBwb3J0CiAgICAgIGluY3JlYXNlZCBwcm9jZXNzaW5nIHJlcXVp cmVtZW50cyBpbXBvc2VkIGJ5IHRoZSBzZWN1cml0eSBzeXN0ZW0uCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDaHJpc3RpYW4sIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgSnVuZSA1LCAyMDA1ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgIEJHUCBTZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgIERl Y2VtYmVyIDIwMDQKCgozLiAgVGhlIFRydXN0IE1vZGVsCgogICBJbiBleGFtaW5pbmcgdGhl IHZhcmlvdXMgZW52aXJvbm1lbnRzIGluIHdoaWNoIEJHUCBpcyBkZXBsb3llZCwgYW5kCiAg IHRocm91Z2ggZGlzY3Vzc2lvbnMgd2l0aCB2YXJpb3VzIG9wZXJhdG9ycyB3b3JraW5nIHdp dGggdGhlIGNvbnRleHQKICAgb2YgdGhlIHB1YmxpYyBJbnRlcm5ldCwgYW5kIG90aGVyIGlu dGVybmV0d29ya3MsIGl0IGlzIGFwcGFyZW50IHRoYXQKICAgdHJ1c3QgbW9kZWxzIGFyZSBs YXJnZWx5IGVudmlyb25tZW50IHNwZWNpZmljLiAgRm9yIGluc3RhbmNlLCBpbiB0aGUKICAg cHVibGljIEludGVybmV0LCBhIGRpc3RyaWJ1dGVkIHRydXN0IG1vZGVsLCBmb2xsb3dpbmcg dGhlIGN1cnJlbnQKICAgdHJhbnNpdGl2ZSB0cnVzdCBwYXR0ZXJuIG9mIGNvbnRyYWN0dWFs IGFuZCBwZWVyaW5nIGFycmFuZ2VtZW50cywKICAgd291bGQgZml0IHRoZSB0aGUgYnVzaW5l c3MgbW9kZWxzIG9mIHRoZSBwYXJ0aWNpcGFudHMuICBJbiBvdGhlcgogICBlbnZpcm9ubWVu dHMgYSBoaWVyYXJjaGljYWwgdHJ1c3QgbW9kZWwgd291bGQgd29yayBiZXR0ZXIuICBUaHVz LCBhbnkKICAgdHJ1c3Qgc3lzdGVtIHNwZWNpZmllZCBpbiBhIHNlY3VyaXR5IG1lY2hhbmlz bSBkZXNpZ25lZCBmb3IgQkdQIG11c3QKICAgYmUgZmxleGlibGUsIGFuZCBzdXBwb3J0IGJv dGggYSB0cnVlIGRpc3RyaWJ1dGVkIHRydXN0IG1vZGVsIGFuZCBhCiAgIGZ1bGx5IGhpZXJh cmNoaWNhbCB0cnVzdCBtb2RlbC4KCiAgIFNpbmNlIGhpZXJhcmNoaWNhbCB0cnVzdCBtb2Rl bHMgYXJlIGEgc3Vic2V0IChvciBhIHNwZWNpYWwgY2FzZSBvZikgYQogICBkaXN0cmlidXRl ZCB0cnVzdCBtb2RlbCwgYW55IHNlY3VyaXR5IHN5c3RlbSBkZXNpZ25lZCBmb3IgQkdQIE1V U1QKICAgc3VwcG9ydCBhIGRpc3RyaWJ1dGVkIHRydXN0IG1vZGVsLCBhbmQgTVVTVCBhbHNv IHN1cHBvcnQgYQogICBoaWVyYXJjaGljYWwgdHJ1c3QgbW9kZWwsIGlmIGRlc2lyZWQuCgog ICBJZiB0d28gaW50ZXJuZXR3b3JrcyB1c2luZyBkaWZmZXJpbmcgdHJ1c3QgbW9kZWxzIGFy ZSBpbnRlcmNvbm5lY3RlZAogICB0aGV5IE1VU1QgYmUgYWJsZSB0byBpbnRlcm9wZXJhdGUg dXNpbmcgbG9jYWxseSBkZXRlcm1pbmVkIGxldmVscyBvZgogICB0cnVzdCB0byBjb21wZW5z YXRlIGZvciBkaWZmZXJlbmNlcyBpbiB0aGVpciB0cnVzdCBtb2RlbHMuCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKQ2hyaXN0aWFuLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1 bmUgNSwgMjAwNSAgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICBCR1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICBEZWNlbWJlciAy MDA0CgoKNC4gIFRoZSBBUy1QYXRoIEF0dHJpYnV0ZSBhbmQgTkxSSSBBdXRoZW50aWNhdGlv bgoKICAgQkdQIGRpc3RyaWJ1dGVzIHJvdXRpbmcgaW5mb3JtYXRpb24gYWNyb3NzIHRoZSBJ bnRlcm5ldCAoYmV0d2VlbiBCR1AKICAgc3BlYWtlcnMpIHVzaW5nIEJHUCBVUERBVEUgbWVz c2FnZXMuICBUaGUgVVBEQVRFIG1lc3NhZ2UgY29udGFpbnMKICAgd2l0aGRyYXduIHJvdXRl cywgcGF0aCBhdHRyaWJ1dGVzIGFuZCBvbmUgb3IgbW9yZSBOTFJJcyAoTmV0d29yawogICBM YXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gaXMgc3lub255bW91cyB3aXRoIGFkdmVy dGlzZWQgcHJlZml4KS4KICAgRm9yIHRoZSByZW1haW5kZXIgb2YgdGhpcyBzZWN0aW9uLCB3 ZSB3aWxsIGZvY3VzIG9uIHRoZSBBUy1QYXRoCiAgIEF0dHJpYnV0ZSBhbmQgdGhlIE5MUkku ICBBdHRyaWJ1dGVzIHN1Y2ggYXMgbG9jYWwgcHJlZiBhcmUgbG9jYWxseQogICBzcGVjaWZp YyBhbmQsIGFzIHN1Y2gsIGFyZSBwcm90ZWN0ZWQgYnkgQkdQIHNlc3Npb24gc2VjdXJpdHku CgogICBUaGUgQVNfUEFUSCBmb3Igc3BlY2lmaWMgcHJlZml4ZXMgbXVzdCBiZSBwcm90ZWN0 ZWQgaW4gYW55IHByb3Bvc2VkCiAgIHNlY3VyaXR5IHN5c3RlbSBpbiB0aHJlZSB3YXlzOgog ICBvICBBdXRob3JpemF0aW9uIG9mIE9yaWdpbmF0aW5nIEFTOiBGb3IgYWxsIHByZWZpeGVz IGFubm91bmNlZCBpbgogICAgICBCR1AsIHRoZSBvcmlnaW5hdGluZyBBUyBNVVNUIGJlIHZl cmlmaWFibGUgdGhyb3VnaCB0aGUgdHJ1c3QgbW9kZWwKICAgICAgYXMgdGhlIGF1dGhvcml6 ZWQgYW5ub3VuY2VyIG9mIHRoZSBwcmVmaXguICBUaGUgdmVyaWZpY2F0aW9uCiAgICAgIG1l Y2hhbmlzbSBtdXN0IGFjY291bnQgZm9yIGV4aXN0aW5nIEJHUCBtZWNoYW5pc21zIHN1Y2gg YXMKICAgICAgc3VtbWFyaXphdGlvbi4gIEZvciB0aGUgcHVycG9zZSBvZiB0aGlzIGRvY3Vt ZW50IHRoZSB0ZXJtCiAgICAgIHZlcmlmaWFibGUgaXMgZGVmaW5lZCBhcyB0aGUgcmVzdWx0 YW50IG9mIGEgc2VjdXJlZCByb3V0aW5nCiAgICAgIHN5c3RlbXMgYXMgZGVzY3JpYmVkIGlu IHRoaXMgZG9jdW1lbnQuICBUaGUgdGVybSBzcGVjaWZpY2FsbHkKICAgICAgaW5kaWNhdGVz IHRoZSBhYmlsaXR5IHRvIHZhbGlkYXRlIHRoZSBvcmlnaW5hdG9yIG9mIGEgc3BlY2lmaWMK ICAgICAgcHJlZml4IChvciBibG9jayBvZiBJUCBhZGRyZXNzZXMpIGFuZCB0aGUgYWJpbGl0 eSB0byB2YWxpZGF0ZSB0aGUKICAgICAgc2Vzc2lvbiB0aHJvdWdoIHdoaWNoIHRoZSBwcmVm aXggd2FzIHJlY2VpdmVkCiAgIG8gIFRoZSBBU19QQVRIIGxpc3QgTVVTVCBjb3JyZXNwb25k IHRvIGEgdmVyaWZpYWJsZSBsaXN0IG9mCiAgICAgIGF1dG9ub21vdXMgc3lzdGVtcyBiYXNl ZCBvbiB0aGUgcGVlcmluZyB0b3BvbG9neSBvZiB0aGUgbmV0d29yay4KICAgbyAgQW5ub3Vu Y2luZyBBUyBDaGVjazogRm9yIGFsbCBCR1AgcGVlcnMsIGEgQkdQIEltcGxlbWVudGF0aW9u IE1VU1QKICAgICAgZW5zdXJlIHRoYXQgdGhlIGZpcnN0IGVsZW1lbnQgb2YgdGhlIEFTX1BB VEggbGlzdCBjb3JyZXNwb25kcyB0bwogICAgICB0aGUgbG9jYWxseSBjb25maWd1cmVkIEFT IG9mIHRoYXQgcGVlci4KCiAgIFRoZXJlIGFyZSBtYW55IHdheXMgaW4gd2hpY2ggYSBkaWZm ZXJlbnRpYWwgYmV0d2VlbiB0aGUgc3BlZWQgb2YKICAgcHJlZml4L0FTIHBhdGggYXR0cmli dXRlIHByb3BhZ2F0aW9uIGFuZCB0aGUgaW5mb3JtYXRpb24gdmFsaWRhdGluZwogICB0aGUg dGhlIHByZWZpeC9BUyBwYXRoIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbiBjYW4gYmUgZXhwbG9p dGVkIHRvCiAgIGF0dGFjayB0aGUgcm91dGluZyBzeXN0ZW0gb24gYSB0ZW1wb3JhcnkgYmFz aXMuICBUaGVzZSB0eXBlcyBvZgogICBhdHRhY2tzIGFyZSBkb21pbmFudGx5IGV4cGxvaXRh dGl2ZSBvZiB0aGUgbW9tZW50IGluIHRpbWUgaXQgdGFrZXMgdG8KICAgZm9sbG93IHRoZSB3 aXRoZHJhdyBvZiBhIE5MUkkgd2l0aCBhbiB1cGRhdGUuICBBcyBhIHJlc3VsdCBvZiB0aGlz CiAgIHBvdGVudGlhbCBmb3IgdGVtcG9yYXJ5IGRpc3J1cHRpb24sIEJHUCBzZWN1cml0eSBz b2x1dGlvbnMgTVVTVAogICBwcm9wYWdhdGUgc2VjdXJpdHkgaW5mb3JtYXRpb24gYXQgdGhl IHNhbWUgcmF0ZSBhcyB0aGUgQkdQIHVwZGF0ZXMKICAgYW5kIHdpdGhkcmF3bHMuICBUaGUg Zm9sbG93aW5nIGl0ZW1zIGFyZSByZXF1aXJlZCB0byBwcm9wYWdhdGUgYXQgdGhlCiAgIHNh bWUgcmF0ZToKICAgbyAgVGhlIGRpc3RyaWJ1dGlvbiBvZiBrZXkgaW5mb3JtYXRpb24gdXNl ZCBieSBpbmRpdmlkdWFsIGFjdG9ycwogICAgICB3aXRoaW4gdGhlIHN5c3RlbSwgaW5jbHVk aW5nIHRoZSBrZXlzIHVzZWQgYnkgaW5kaXZpZHVhbAogICAgICBhdXRvbm9tb3VzIHN5c3Rl bXMgdG8gc2lnbiBjZXJ0aWZpY2F0ZXMgYW5kIG90aGVyIG9iamVjdHMKICAgbyAgVGhlIGRp c3RyaWJ1dGlvbiBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgQVMgYXV0aG9yaXplZCB0bwog ICAgICBhZHZlcnRpc2UgYSBnaXZlbiBibG9jayBvZiBJUCBhZGRyZXNzZXMgKG9yIGFuIGFk ZHJlc3Mgc3BhY2UpCiAgIG8gIFRoZSBkaXN0cmlidXRpb24gb2YgaW5mb3JtYXRpb24gYWJv dXQgY29ubmVjdGl2aXR5IGJldHdlZW4KICAgICAgYXV0b25vbW91cyBzeXN0ZW1zIGFuZCBh dXRvbm9tb3VzIHN5c3RlbSBwb2xpY2VzLCBpZiBzdWNoCiAgICAgIGluZm9ybWF0aW9uIGlz IHRvIGJlIGRpc3RyaWJ1dGVkIHdpdGhpbiB0aGUgc2VjdXJpdHkgc3lzdGVtLgoKCgoKCkNo cmlzdGlhbiwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdW5lIDUsIDIwMDUgICAgICAgICAg ICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5 IFJlcXVpcmVtZW50cyAgICAgICAgICAgRGVjZW1iZXIgMjAwNAoKCjUuICBBZGRyZXNzIEFs bG9jYXRpb24gYW5kIGFkdmVydGlzZW1lbnQKCiAgIEFzIHBhcnQgb2YgdGhlIHJlZ3VsYXIg b3BlcmF0aW9uIG9mIHRoZSBJbnRlcm5ldCwgYWRkcmVzc2VzIHRoYXQgYXJlCiAgIGFsbG9j YXRlZCB0byBhbiBvcmdhbml6YXRpb24gbWF5IGJlLCBhbmQgYXJlIHF1aXRlIGNvbW1vbmx5 LAogICBhZHZlcnRpc2VkIGJ5IGEgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMuICBDb21tb24g cmVhc29ucyBmb3IgdGhpcwogICBwcmFjdGljZSBpbmNsdWRlIG11bHRpLWhvbWluZyBhbmQg cm91dGUgcmVkdWN0aW9uIGZvciB0aGUgcHVycG9zZXMgb2YKICAgcmVzb3VyY2UgY29uc2Vy dmF0aW9uLiAgVGhlcmUgYXJlIHR3byBtb2RlcyBvZiBkZWxlZ2F0aW9uOgogICBvICBBIEJH UCBzcGVha2VyIGFuZCBsaXN0ZW5lciBoYXZlIGNob3NlbiB0byByZXN0cmljdCB0aGUgYW1v dW50IG9mCiAgICAgIHJlY2VpdmVkIHByZWZpeGVzIGZvciB0aGUgbGlzdGVuZXIuICBUaGUg bGlzdGVuZXIgaGFzIGNob3NlbiB0bwogICAgICBob25vciByb3V0ZSBhbm5vdW5jZW1lbnRz IHNlbnQgaW4gYSBzdW1tYXJ5IGZhc2hpb24gYnkgdGhlCiAgICAgIHNwZWFrZXIuCiAgIG8g IEFkZHJlc3Mgc3BhY2UgdGhhdCBpcyBiZWluZyBkZWxlZ2F0ZWQgaXMgcGFydCBvZiBhIGxh cmdlcgogICAgICBhbGxvY2F0aW9uIHRoYXQgaXMgb3duZWQgYnkgYW4gYXV0b25vbW91cyBz eXN0ZW0uICBUaGUgb3duZXIgdGhlbgogICAgICBkZWxlZ2F0ZXMgdGhlIHNtYWxsZXIgYmxv Y2sgdG8gYW5vdGhlciBBUyBmb3IgcHVycG9zZXMgb2YKICAgICAgYWR2ZXJ0aXNlbWVudC4g IFRoaXMgbW9kZSBpcyBjb21tb25seSBvYnNlcnZlZCBpbiBtdWx0aS1ob21pbmcuCgogICBU aGVzZSB0d28gbW9kZXMgbGVhZCB0byBhIHNpbmdsZSBjb21tb24gcmVxdWlyZW1lbnQ6IEFu eSBCR1AgU2VjdXJpdHkKICAgc29sdXRpb24gTVVTVCBzdXBwb3J0IGRlbGVnYXRpb24gb2Yg YW4gYWRkcmVzcyBibG9jayBvZiBhbnkgc2l6ZQogICByZWdhcmRsZXNzIG9mIGl0cyByZWxh dGlvbnNoaXAgdG8gb3RoZXIgYWRkcmVzcyBibG9ja3MgdG8gYW5vdGhlcgogICBlbnRpdHkg dmlhIHZlcmlmaWFibGUgbWVhbnMuCgogICBBbiBhc3NvY2lhdGVkIGRlbGVnYXRpb24gY3Jp dGVyaWEgaXMgdGhlIHJlcXVpcmVtZW50IHRvIGFsbG93IGZvcgogICBub24tQkdQIElQIGVu ZCB1c2VyIGltcGxlbWVudGF0aW9ucy4gIEFzIGEgcmVzdWx0LCBhbGwgc2VjdXJlZCBCR1AK ICAgaW1wbGVtZW50YXRpb25zIE1VU1QgYWxsb3cgZm9yIHRoZSBwcm9wYWdhdGlvbiBvZiBh IHByZWZpeCBieSBtb3JlCiAgIHRoYW4gb25lIG9yaWdpbmF0b3IgQVMgd2l0aGluIG5vcm1h bCBuZXR3b3JrIGNvbnZlcmdlbmNlIHRpbWVzLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkNocmlzdGlhbiwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdW5lIDUsIDIwMDUgICAgICAg ICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3Vy aXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAgRGVjZW1iZXIgMjAwNAoKCjYuICBOTFJJIGFu ZCBQYXRoIEF0dHJpYnV0ZSBUcmFja2luZwoKICAgTm9uLXJlcHVkaWF0aW9uIG9mIHJvdXRp bmcgdXBkYXRlcywgdGhlIGFiaWxpdHkgZm9yIGEgcmVjZWl2ZXIgdG8KICAga25vdyBleGFj dGx5IHdobyBvcmlnaW5hdGVkIGFuZCBmb3J3YXJkZWQgYSByb3V0aW5nIHVwZGF0ZSwgaXMg YQogICBkZXNpcmFibGUgdHJhaXQuICBJbiBvcmRlciB0byByYXBpZGx5IGlkZW50aWZ5IGFn cmVzc29ycyBhbmQgcGFydGllcwogICBhdCBmYXVsdCBmb3Igcm91dGUgdGFibGUgZGlzcnVw dGlvbiBpdCBpcyBpbXBvcnRhbnQgdG8gdHJhY2sgYW5kIGxvZwogICBwcmVmaXggb3JpZ2lu YXRpb24gaW5mb3JtYXRpb24gYWxvbmcgd2l0aCBhc3NvY2lhdGVkIHNlY3VyaXR5CiAgIGlu Zm9ybWF0aW9uLgoKICAgQW55IHNlY3VyaXR5IHN5c3RlbSBTSE9VTEQgcHJvdmlkZSBhIG1l dGhvZCB0byBhbGxvdyB0aGUgcmVjZWl2ZXIgb2YKICAgYW4gdXBkYXRlIHRvIHZlcmlmeSB0 aGF0IHRoZSBvcmlnaW5hdG9yIGFjdHVhbGx5IG9yaWdpbmF0ZWQgdGhlCiAgIHVwZGF0ZSwg YW5kIHRoYXQgdGhlIEFTJ3MgbGlzdGVkIGluIHRoZSBBU19QQVRIIGFjdHVhbGx5IGZvcndh cmRlZAogICB0aGUgdXBkYXRlLgoKICAgVGhlIGRhdGEgZ2VuZXJhdGVkIGJ5IGxvZ2dpbmcg bWF5IGJlIHZlcnkgbGFyZ2UgZGVwZW5kaW5nIG9uIHRoZQogICBudW1iZXIgb2YgcGVlcnMs IHRoZSBudW1iZXIgb2YgcHJlZml4ZXMgcmVjZWl2ZWQsIHRoZSBhdXRoZW50aWNhdGlvbgog ICBtb2RlbCB1c2VkLCBhbmQgcm91dGluZyBwb2xpY2llcy4gIEFzIHN1Y2gsIGVmZmljaWVu dCBkYXRhIHN0cnVjdHVyZXMKICAgYW5kIHN0b3JhZ2UgbWVjaGFuaXNtcyBNVVNUIGJlIGRl dmVsb3BlZCB0byBhbGxvdyBmb3IgYW4gZWZmZWN0aXZlCiAgIG1lYW5zIG9mIHJlcHJvZHVj aW5nIGluY2lkZW50cyBhbmQgb3V0YWdlcwoKICAgUGF0aCBhbmQgTkxSSSBhdHRyaWJ1dGVz IE1VU1QgYmUgbG9nZ2VkIHVzaW5nIGEgc3RhbmRhcmQgZm9ybWF0LiAgVGhlCiAgIGZvcm1h dCBtdXN0IGJlIHNjYWxhYmxlIHdpdGggdGhlIGFtb3VudCBvZiBkYXRhIGxvZ2dlZCBhbmQg dGhlCiAgIGZyZXF1ZW5jeSBvZiBsb2cgZ2VuZXJhdGlvbi4gIFRoZSBmcmVxdWVuY3kgb2Yg bG9nIGdlbmVyYXRpb24gc2hvdWxkCiAgIGJlIGNvbnRyb2xsYWJsZSBieSB0aGUgb3BlcmF0 b3IuICBUaGUgbG9nZ2luZyBtZWNoYW5pc21zIGZvciB0aGUKICAgdHJhY2tlZCBpbmZvcm1h dGlvbiBNVVNUIGJlIHN0YW5kYXJkaXplZCBhY3Jvc3MgYWxsIHBsYXRmb3Jtcy4KICAgTG9n Z2luZyBhYmlsaXR5IGJvdGggb24gYW5kIG9mZiBsaW5lIGlzIGNvbnNpZGVyZWQgaGlnaGx5 IGRlc2lyYWJsZS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkNocmlzdGlhbiwgZXQgYWwu ICAgICAgICAgRXhwaXJlcyBKdW5lIDUsIDIwMDUgICAgICAgICAgICAgICAgICBbUGFnZSA5 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAg ICAgICAgICAgRGVjZW1iZXIgMjAwNAoKCjcuICBUcmFuc3BvcnQgUHJvdGVjdGlvbgoKICAg VHJhbnNwb3J0IHByb3RlY3Rpb24gaXMgYW4gaW1wb3J0YW50IGFzcGVjdCBvZiBCR1Agcm91 dGluZyBwcm90b2NvbAogICBzZWN1cml0eS4gIFRoZSBwb3RlbnRpYWwgdG8gY3JlYXRlIGEg bGlua2VkIHRyYW5zcG9ydC9OTFJJL0FTLVBBVEgKICAgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtIHNob3VsZCBub3QgYmUgb3Zlcmxvb2tlZCBhbmQgbWF5IHByb3ZpZGUgZm9yCiAgIHRo ZSBhY2NlbGVyYXRlZCBkZXBsb3ltZW50IG9mIGEgQkdQIHNlY3VyaXR5IHN5c3RlbS4gIEN1 cnJlbnQKICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBmb3IgQkdQIHRyYW5zcG9ydCBhcmUgaW5h ZGVxdWF0ZSBhbmQgcmVxdWlyZQogICBzaWduaWZpY2FudCBvcGVyYXRvciBpbnRlcmFjdGlv biB0byBtYWludGFpbiBhIHJlc3BlY3RhYmxlIGxldmVsIG9mCiAgIHNlY3VyaXR5LgoKICAg QW55IHByb3Bvc2VkIHNlY3VyaXR5IG1lY2hhbmlzbSBNVVNUIGluY2x1ZGUgcHJvdmlzaW9u cyBmb3Igc2VjdXJpbmcKICAgYm90aCBpbnRlcm5hbCBCR1AgYW5kIGV4dGVybmFsIEJHUCBw ZWVyaW5nIHNlc3Npb25zLiAgS2V5IG1haW50ZW5hbmNlCiAgIGNhbiBiZSBlc3BlY2lhbGx5 IG9uZXJvdXMgdG8gdGhlIG9wZXJhdG9ycy4gIFRoZSBudW1iZXIgb2Yga2V5cwogICByZXF1 aXJlZCBhbmQgdGhlIG1haW50ZW5hbmNlIG9mIGtleXMgKHVwZGF0ZS93aXRoZHJhdy9yZW5l dykgbWF5IGhhdmUKICAgYW4gYWRkaXRpdmUgYWZmZWN0IHRvIGEgYmFycmllciB0byBkZXBs b3ltZW50LiAgQSBoaWdobHkgc2VjdXJhYmxlCiAgIEJHUCByb3V0aW5nIHN5c3RlbSBTSE9V TEQgcmVxdWlyZSBubyBtb3JlIHRoYW4gdGhyZWUga2V5cyBhbmQgZWFjaAogICBrZXkgc2hv dWxkIGJlIHVwZGF0ZWFibGUgd2l0aGluIHNpbWlsYXIgdGltZWZyYW1lcyBhcyBwcmVmaXgK ICAgcHJvcGFnYXRpb24uICBUaGUgcHJlZmVycmVkIG51bWJlciBvZiBrZXlzIGlzIE9ORSBw ZXIgQVMuCgogICBUcmFuc3BvcnQgcHJvdGVjdGlvbiBzeXN0ZW1zIFNIT1VMRCBmdW5jdGlv biBhcyBhIGNvbXBvbmVudCBvZiB0aGUKICAgQkdQIHJvdXRpbmcgcHJvdG9jb2wgc2VjdXJp dHkgbWVjaGFuaXNtLiAgVGhpcyBpbmNsdWRlcyB0aGUgdXNlIG9mCiAgIHRoZSBzYW1lIGtl eSBnZW5lcmF0aW9uL21hbmFnZW1lbnQgc3lzdGVtcyBhcyB0aGUgcmVzdCBvZiB0aGUKICAg c2VjdXJpdHkgc3lzdGVtLgoKOCAgUmVmZXJlbmNlcwoKICAgWzFdICBGcmFzZXIsICJSRkMg MjE5NiAtIFNpdGUgU2VjdXJpdHkgSGFuZGJvb2siLCBTZXB0ZW1iZXIgMTk5Ny4KCiAgIFsy XSAgUmVzY29ybGEsIEtvcnZlciBhbmQgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkLCAi UkZDIDM1NTIgLQogICAgICAgIEd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDIFRleHQgb24g U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLAogICAgICAgIEp1bHkgMjAwMy4KCgpBdXRob3Jz JyBBZGRyZXNzZXMKCiAgIEJsYWluZSBDaHJpc3RpYW4gKGVkaXRvcikKICAgS01DIFRlbGVj b20gU29sdXRpb25zCiAgIDMwNSBDaHVyY2ggU3RyZWV0IFN1aXRlIDcxNQogICBIdW50c3Zp bGxlLCBBTCAgMzU4MDEKICAgVVMKCgogICBCb3JhIEFreW9sCiAgIENpc2NvIFN5c3RlbXMK ICAgMTcwIFRhc21hbiBEcml2ZQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0CiAgIFVTCgoKCgpD aHJpc3RpYW4sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVuZSA1LCAyMDA1ICAgICAgICAg ICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEJHUCBTZWN1cml0 eSBSZXF1aXJlbWVudHMgICAgICAgICAgIERlY2VtYmVyIDIwMDQKCgogICBSdXNzIFdoaXRl CiAgIENpc2NvIFN5c3RlbXMKICAgNzAyNSBLaXQgQ3JlZWsgUm9hZAogICBSZXNlYXJjaCBU cmlhbmdsZSBQYXJrLCBOQyAgOTUxMzQKICAgVVMKCgogICBKZWZmcmV5IEhhYXMKICAgTmV4 dCBIb3AgVGVjaG5vbG9naWVzCiAgIDgyNSBWaWN0b3JzIFdheSBTdWl0ZSAxMDAKICAgQW5u IEFyYm9yLCBNSSAgNDgxMDgKICAgVVMKCgogICBTYW5keSBNdXJwaHkKICAgVHJ1c3RlZCBJ bmZvcm1hdGlvbiBTeXN0ZW1zCiAgIDMwNjAgV2FzaGluZ3RvbiBSb2FkCiAgIEdsZW53b29k LCBNRCAgMjEzNzgKICAgVVMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDaHJp c3RpYW4sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVuZSA1LCAyMDA1ICAgICAgICAgICAg ICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEJHUCBTZWN1cml0eSBS ZXF1aXJlbWVudHMgICAgICAgICAgIERlY2VtYmVyIDIwMDQKCgpBcHBlbmRpeCBBLiAgQWNr bm93bGVkZ2VtZW50cwoKICAgVGhlIGZvbGxvd2luZyBpbmRpdmlkdWFscyBjb250cmlidXRl ZCB0byB0aGUgZGV2ZWxvcG1lbnQgYW5kIHJldmlldwogICBvZiB0aGlzIGRyYWZ0LiAgU3Rl dmUgS2VudCwgTWlrZSBUaWJvZGVhdSwgVGhvbWFzIFJlbnp5LCBLYWFydGhpawogICBTaXZh a3VtYXIsIFRhbyBXYW4sIFJhZGlhIFBlcmxtYW4sIGFuZCBNZXJpa2UgS2Flby4KCiAgIFRo aXMgZHJhZnQgd2FzIGRldmVsb3BlZCBiYXNlZCBvbiBjb252ZXJzYXRpb25zIHdpdGggdmFy aW91cyBuZXR3b3JrCiAgIG9wZXJhdG9ycyBpbmNsdWRpbmcgQ2hyaXMgTW9ycm93LCBKYXJl ZCBNYXVjaCwgVGltIEJhdHRsZXMsIGFuZCBSeWFuCiAgIE1jRG93ZWxsLgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDaHJpc3RpYW4sIGV0IGFsLiAgICAg ICAgIEV4cGlyZXMgSnVuZSA1LCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgIEJHUCBTZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAg ICAgIERlY2VtYmVyIDIwMDQKCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50Cgog ICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9y IHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVy IHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1w bGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0 aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIg c3VjaCByaWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRv ZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVm Zm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0 aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMg Y2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQ UiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAg YXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJl c3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNl IG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3VjaCBwcm9wcmlldGFyeSByaWdo dHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBj YW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0 CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYgaW52aXRlcyBhbnkg aW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQogICBjb3B5 cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3By aWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJl IHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3Jn LgoKCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkKCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMg SVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hF IFJFUFJFU0VOVFMKICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJO RVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0Ug RElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwKICAgSU5DTFVE SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBP UiBBTlkgSU1QTElFRAogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KCgpDb3B5cmlnaHQgU3RhdGVtZW50Cgog ICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMgZG9j dW1lbnQgaXMgc3ViamVjdAogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJp Y3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZAogICBleGNlcHQgYXMgc2V0IGZvcnRo IHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKCkFja25v d2xlZGdtZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBj dXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlCiAgIEludGVybmV0IFNvY2lldHkuCgoKCgpDaHJp c3RpYW4sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVuZSA1LCAyMDA1ICAgICAgICAgICAg ICAgICBbUGFnZSAxM10KDAo= --B_3185102983_1991455 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --B_3185102983_1991455-- From rpsec-bounces@ietf.org Thu Dec 9 10:45:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02791 for ; Thu, 9 Dec 2004 10:45:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcQaj-0007tj-Q8 for rpsec-web-archive@ietf.org; Thu, 09 Dec 2004 10:52:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQRN-0005gG-Pu; Thu, 09 Dec 2004 10:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQIu-00044h-9i for rpsec@megatron.ietf.org; Thu, 09 Dec 2004 10:34:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01630 for ; Thu, 9 Dec 2004 10:34:02 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcQPr-0007fg-Bd for rpsec@ietf.org; Thu, 09 Dec 2004 10:41:19 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.1/8.13.1) with ESMTP id iB9FXRwO015420 for ; Thu, 9 Dec 2004 07:33:27 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.1/8.12.11/Submit) with ESMTP id iB9FXQFR015417 for ; Thu, 9 Dec 2004 07:33:26 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Thu, 9 Dec 2004 07:33:26 -0800 (PST) From: Tony Tauber To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [RPSEC] Draft IETF-61 minutes X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Unless I hear otherwise today or tomorrow morning, these will be submitted as the minutes for IETF-61 in Washington, DC. Thanks, Tony ---- Routing Protocol Security Requirements WG (rpsec) Tuesday, November 9 at 1300-1400 =================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing Requirements document status draft-ietf-rpsec-generic-requirements-00.txt Made contact with the Editor (Jean-Jaques Puig) who has gotten busy with other things lately but will have more time to devote in Jan. Likewise engaged some other contributors (Danny McPherson and Emanuele Jones). Will work to revise in that timeframe. OSPF Vulnerability Analysis status draft-ietf-rpsec-OSPF-vuln-00.txt Is a WG doc but must wait to progress until the progression of the Generic Threats and Requirements docs. Have talked with the primary Author (Emanuele Jones) and asked that increment the version number and re-submit the document to ensure that it does not expire from the I-D repository. Threats document status Sandy Murphy draft-ietf-rpsec-routing-threats-07.txt Sandy presented her changes to the document. Some changes were refinements to the language to collapse a number of redundant or conflicting terms. Also worked through other dangling or otherwise problematic references. Byzantine Failures (section 4.8) removed The document will go to Working Group Last Call. BGP Attack Tree document status draft-convery-bgpattack-02.txt Similarly to the OSPF Vulnerabilities draft, this document may not progress yet. BGP Attack Tree Risk Analysis R. Kuhn et al. "Incorporating Subjective Risk Values in BGP Attack Trees" Risk assessment of BGP attacks, using NASA/AIAA standard procedure for fault trees Includes costs associated with countermeasures and the effectiveness of countermeasures in reducing risks. Kent and Metzger vigorously disputed the usefulness of this approach for security risk assessment. Sandy Murphy wasn't too sure about it either. Uses NASA/AIAA for trying to quantify probability of certain risks. Spreadsheet to do this stuff with goal to model the effect of countermeasures also. DOS attacks particularly hard to model. Steve Kent: The methodology developed by AIA was appropriate for their environment, but they tend to be wanting when applying them to attacks, because the propbablility generally goes from close to 0 to close to 1. Why did you decide to do this sort of analysis for security. R Kuhn: This is common in many industries, so we decided to use this one. S Kent: I believe this methodology is questionable in this environment. R Kuhn: There is always the risk of human mistakes, even in the nuclear industry, for instance. Perry M: You're making certain statistical assumptions that are not valid. Before a fault is found, it won't be exploited at all. When a fault is found, it will be exploited in bulk until it's fixed. The variables are not independant. R Kuhn: We don't expect to get accurate numbers, but rather a risk comparison. Perry M: This analysis won't give you even a good risk comparison. R Kuhn: This is the type o feedback we're looking for. Sandy Murphy: One of the items in the attack tree said something about disabling a certain portion of the Internet, is your analysis in respect to a single router, or in respect to the entire Internet. How are you doing analysis on the entire Internet. R Kuhn: We are following the attack tree, as it's been published. Sandy M: How did you do these calculations? R Kuhn: There's a standard fault tree calculation, we can look at them later. Sandy M: The reason I ask is because faults are not exploited equally throughout the network. The nuclear power plant error does add some randomess, but the malcious operator are applicable to the malicious operator case. R Kuhn: Most of these attack tress work with a single router. Sandy M: While DOS is a big problem, the biggest problems have not been DOS attacks, but rather misconfigurations of routers. The calculations then lead away from the obvserved results. R Kuhn: The countermeasures we're looking at should however impact Markus Leach: This work is interesting, but I'd be hesitent to let this work broadly impact the work the WG is doing. It wouldn't occur to me use AIAA analysis to work with the types of systems we are dealing with here. AIAA analysis is for failure analysis, rather than malicious attacks, or malicious actors. R Kuhn: I agree completely. It doesn't map completely, but we thought it might be useful. BGP Security Requirements Blaine Christian draft-christian-bgpsecreq-01.txt Goal: Provide a means to verify and assure peering relationships and prefix advertisements, etc. Threats: Unauthorized announcements Must support increment deployment Web of trust must be supported, also Strict hierarchy of authority (users should be able to decide which one they want) Need to make this a working group document. Steve Kent: Biggest concern is the lack of rationale. We need to motivate each of those requirements. Start from the semantics of the protocol, and say: "These are security things that must be done, and these are the performance concerns." For instance, we're concerned about computational speed, we're concerned about update size, etc. You need to start from: "This is what BGP is supposed to do," and how to secure them. Once you're past that, you can get to work on performance issues, and then think through processes. Blaine C: The hope was, through the process, and get comments. Steve K: I'd be glad to send you text showing what text we used when to come to these conclusions. Sandy Murphy: One thing I had noticed is that the doc covers requirements for solutions, and other requirements for security of the protocol. These should be better defined in the document. Sandy Murphy: BGP is a distributed system, you might have a strong requirement for security, but someone three hops away might not. How can people trust, or understand, the levels of trust other people might have when they produce their information? Blaine C: This is a big question--can you actually put that sort of thing in the decisions process. Tony T: Should we accept this as a WG doc? Russ W: If we accept this as a WG doc, should we take the work off the DT list, or pushed to the main list. Bill Fenner: If we make it a WG doc, then we should push it onto the main list. [ Consensus call on adoption of the document as a WG work item. ] Tony T: The sense of the room is that it should be a WG doc. We'll confirm on the list. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Dec 9 13:34:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19357 for ; Thu, 9 Dec 2004 13:34:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcTEe-0003VZ-9O for rpsec-web-archive@ietf.org; Thu, 09 Dec 2004 13:41:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSsG-0000bb-Re; Thu, 09 Dec 2004 13:18:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSnl-0007p4-JD for rpsec@megatron.ietf.org; Thu, 09 Dec 2004 13:14:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17463 for ; Thu, 9 Dec 2004 13:14:03 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSum-00033x-C6 for rpsec@ietf.org; Thu, 09 Dec 2004 13:21:21 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.1/8.13.1) with ESMTP id iB9IDXUF016841 for ; Thu, 9 Dec 2004 10:13:33 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.1/8.12.11/Submit) with ESMTP id iB9IDXoC016838 for ; Thu, 9 Dec 2004 10:13:33 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Thu, 9 Dec 2004 10:13:33 -0800 (PST) From: Tony Tauber To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [RPSEC] Consensus Call - BGP Security Requirements X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi all, I believe I've been remiss in confirming on the list the consensus at the meeting in Washington, DC (IETF-61); that the BGP Security Requirements document that Blaine Christian has edited as output from the Design Team of the same be accepted as a Working Group item. If there is some disagreement with this action, please say so. Otherwise, the Design Team will go dormant and the work will progress on the regular RPSEC list (as it has been). Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Dec 10 10:18:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21873 for ; Fri, 10 Dec 2004 10:18:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcmeF-0006wK-Po for rpsec-web-archive@ietf.org; Fri, 10 Dec 2004 10:25:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcmPH-0006Nh-HP; Fri, 10 Dec 2004 10:10:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcmFO-0000l9-6M for rpsec@megatron.ietf.org; Fri, 10 Dec 2004 09:59:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19852 for ; Fri, 10 Dec 2004 09:59:52 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcmMa-0006aq-V7 for rpsec@ietf.org; Fri, 10 Dec 2004 10:07:21 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iBAEx8eT016690 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 10 Dec 2004 09:59:10 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 10 Dec 2004 09:59:02 -0500 Subject: Re: [RPSEC] Consensus Call - BGP Security Requirements From: Blaine Christian To: Tony Tauber , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Silence indicates assent ... I will retitle the draft accordingly and if there are last minute objections I will be happy to change it. On 12/9/04 1:13 PM, "Tony Tauber" wrote: > Hi all, > > I believe I've been remiss in confirming on the list the consensus > at the meeting in Washington, DC (IETF-61); that the BGP Security > Requirements document that Blaine Christian has edited as output from > the Design Team of the same be accepted as a Working Group item. > > If there is some disagreement with this action, please say so. > > Otherwise, the Design Team will go dormant and the work will progress > on the regular RPSEC list (as it has been). > > Thanks, > > Tony > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 15 16:31:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16910 for ; Wed, 15 Dec 2004 16:31:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cegry-0003aa-IC for rpsec-web-archive@ietf.org; Wed, 15 Dec 2004 16:39:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CegCo-0008DG-0H; Wed, 15 Dec 2004 15:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceg2A-0002Q6-LA; Wed, 15 Dec 2004 15:46:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08901; Wed, 15 Dec 2004 15:46:04 -0500 (EST) Message-Id: <200412152046.PAA08901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 15 Dec 2004 15:46:04 -0500 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-00.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian, et al. Filename : draft-ietf-rpsec-bgpsecrec-00.txt Pages : 13 Date : 2004-12-15 The security of BGP is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routed system, is more complex. This document describes a set of requirements for securing BGP, including securing peering relationships between BGP speakers, and authenticating the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-bgpsecrec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-15161424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-15161424.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --NextPart-- From rpsec-bounces@ietf.org Mon Dec 27 15:31:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19417 for ; Mon, 27 Dec 2004 15:31:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj1h8-0005qb-K7 for rpsec-web-archive@ietf.org; Mon, 27 Dec 2004 15:42:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1UF-00063Q-Fb; Mon, 27 Dec 2004 15:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1Qs-0004TZ-Kf for rpsec@megatron.ietf.org; Mon, 27 Dec 2004 15:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18985 for ; Mon, 27 Dec 2004 15:25:32 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj1be-0005gA-9F for rpsec@ietf.org; Mon, 27 Dec 2004 15:36:42 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 Dec 2004 15:25:03 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBRKP1gF017539 for ; Mon, 27 Dec 2004 15:25:01 -0500 (EST) Date: Mon, 27 Dec 2004 15:24:21 -0500 (Eastern Standard Time) From: Russ White To: rpsec@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [RPSEC] Thoughts on BGP Security Req's Draft (I) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Part of the comments we've received on this draft is there's no real "intro" section, to speak of, or rather something that explains what it is we're trying to secure. So, I've written some _possible_ text up, and would like to see it discussed, modified, and possibly inserted in the next version. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone -- System Description BGP is described in [BGP] as a routing protocol. Essentially, BGP speakers exchange information about reachable destinations in an internetwork through a peering session. Once this information has been exchanged, each BGP speaker locally determines a loop free path to each reachable destination, based on local policy, policy indicators (or policies) carried in the update, and the AS Path carried in the BGP update. There are at least two points at which BGP could be secured, examining this short description: o The session between two BGP speakers can be secured such that BGP data received by one of the BGP speakers can be cryptographically verified to have been transmitted by the other speaker. o The policy indicators carried within the update can be verified in some way, if the receiving BGP speaker knows the correct policies of each AS along the AS Path. To this point, we've simply treated the BGP update as an independant set of data, completely outside the context of what that data is used for, or the data's use on a large scale throughout the internetwork. There are, however, several questions we can ask about the data carried within the update, in a larger sense. For instance, the receiving BGP speaker could also attempt to check: o The authorization of the originating autonomous system, as listed in the AS Path of the BGP update, can be verified. This means the BGP speaker can check that the originating AS, as listed in the AS Path of the update, is actually authorized to originate the destination address indicated. o The validity of the AS Path carried within the update. This last check, the validity of the AS Path carried within the update, is a matter of some contention. There are various views on what can be verified using the AS Path: o That the path listed in the AS Path actually exists, the AS Path describes a real path to the destination within the operating internetwork. o That the update has actually travelled the path listed in the AS Path of the update itself. o That the transmitter of this update is authorized by some previous transmitter to advertise the reachable destinations contained within the update. While the first two are arguably provable within the context of BGP, the third is questionable because of aggregation and filtering normally applied within the internetworks BGP actually operates in, and because of ambiguities in the concept of IP address ownership within those systems. In this draft, then, we do not attmept to set requirements dealing with the third issue, but leave this as an area of study for the various systems designed for securing BGP. We could use some discussion on this wording, and its concepts, before adopting it as a part of the draft. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Dec 27 16:58:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07770 for ; Mon, 27 Dec 2004 16:58:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj345-0003gH-7J for rpsec-web-archive@ietf.org; Mon, 27 Dec 2004 17:10:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj2Q6-0005fz-FN; Mon, 27 Dec 2004 16:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1hf-0004A4-BH for rpsec@megatron.ietf.org; Mon, 27 Dec 2004 15:42:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20440 for ; Mon, 27 Dec 2004 15:42:53 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj1sR-00067c-IG for rpsec@ietf.org; Mon, 27 Dec 2004 15:54:03 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 27 Dec 2004 15:52:28 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBRKgMEv008375 for ; Mon, 27 Dec 2004 15:42:23 -0500 (EST) Date: Mon, 27 Dec 2004 15:41:42 -0500 (Eastern Standard Time) From: Russ White To: rpsec@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [RPSEC] BGP Security Requirements Draft: Section 2 (II) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Y'all: More thoughts on the current section 2 of the bgp security requirements doc below. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone -- In the deployment requirements section, 2, I would split each of the items in the bulleted list up into separate subsections, instead of keeping all this information in a single bulleted list. I would rereword as follows: 2. Deployment Requirements We have determined, through discussion with several large internetwork operators and equipment vendors, that some attributes of BGP are critical to the operation of the Internet and internetworks using BGP to provide routing information. Each section below discusses one of these attributes in detail. 2.1. Convergence Speed (The text as it sits here is pretty much fine today, though making it into a section might allow it to be broken up into multiple paragraphs, instead of one long one). 2.2. Incremental Deployment I think there are multiple requirements here that aren't called out in the text very well, and one I'd like to see added, if possible. Something like this: We will not be able to deploy a newly secured BGP protocol instantaneously, and will be unable to dictate a partitioning of large internetworks by network operators. Because of this, there are several requirements any proposed mechanism to secure BGP must consider: o BGP MUST support transmitting, receiving, and acting on both secured and unsecured routing information with any security system in place. o The security system MUST allow the formation of peering relationships with peers supporting or not supporting any security system designed for BGP. o The security system MUST use backward compatible in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible fashion. The one I'd like to see added here is this: o In an environment where secure and nonsecured routing information is transmitted, there MUST be some mechanism for a receiver to determine if the originator, or any intervening autonomous system, intended the information to be secured. IMHO, this one is critical in an incramental deployment. I don't know if I've worded it right, though.... Thoughts would be appreciated. 2.3. Trust level Variability (Again, I think the wording in the document is probably fine, but it should be split into separate paragraphs, and thought through a little more thoroughly). _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Dec 27 17:01:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08417 for ; Mon, 27 Dec 2004 17:01:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj36B-0003qJ-Mr for rpsec-web-archive@ietf.org; Mon, 27 Dec 2004 17:12:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj2ky-00086x-Nd; Mon, 27 Dec 2004 16:50:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1rJ-0000Qg-15 for rpsec@megatron.ietf.org; Mon, 27 Dec 2004 15:52:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21525 for ; Mon, 27 Dec 2004 15:52:51 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj224-0006cE-BW for rpsec@ietf.org; Mon, 27 Dec 2004 16:04:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 27 Dec 2004 16:02:25 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBRKqIEv010300 for ; Mon, 27 Dec 2004 15:52:19 -0500 (EST) Date: Mon, 27 Dec 2004 15:51:38 -0500 (Eastern Standard Time) From: Russ White To: rpsec@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [RPSEC] BGP Req's Draft, Section 6 (III) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Y'all: Some comments on section 6 below. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone -- I think section 6 is a little confused, and confusing.... IMHO, I would split it in half. 6. Non-Repudiation of Received Updates Non-repudiation of routing updates, the ability for a receiver to know exactly who originated and forwarded a routing update, is a desirable trait. In order to rapidly identify agressors and parties at fault for route table disruption it is important to track and log prefix origination information along with associated security information. Any security system SHOULD provide a method to allow the receiver of an update to verify that the originator actually originated the update, and that the AS's listed in the AS_PATH actually forwarded the update. 7. Logging Requirements for Security While security systems often primarily rely on cryptographic mechanisms to verify data transmitted through the network, it's also important for network operators to be able to track normal BGP operation, and to be able to easily recognize variant behaviour when it occurs. Towards this end, standardized logging mechanisms SHOULD be proposed for BGP in conjuction with, or in parallel to, any proposed security mechanisms. The data generated by logging may be very large depending on the number of peers, the number of prefixes received, the authentication model used, and routing policies. As such, efficient data structures and storage mechanisms MUST be developed to allow for an effective means of reproducing incidents and outages Path and NLRI attributes MUST be logged using a standard format. The format must be scalable with the amount of data logged and the frequency of log generation. The frequency of log generation should be controllable by the operator. The logging mechanisms for the tracked information MUST be standardized across all platforms. Logging ability both on and off line is considered highly desirable. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Dec 27 18:42:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18539 for ; Mon, 27 Dec 2004 18:42:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj4gX-000718-Ii for rpsec-web-archive@ietf.org; Mon, 27 Dec 2004 18:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj4NK-00037u-RT; Mon, 27 Dec 2004 18:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj4En-0000IZ-Ey for rpsec@megatron.ietf.org; Mon, 27 Dec 2004 18:25:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17554 for ; Mon, 27 Dec 2004 18:25:14 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj4Pa-0006bD-N9 for rpsec@ietf.org; Mon, 27 Dec 2004 18:36:27 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBRNOYjf009746; Mon, 27 Dec 2004 18:24:34 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 27 Dec 2004 18:24:26 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0036680432==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b --===============0036680432== Content-Type: multipart/alternative; boundary="============_-1107932624==_ma============" --============_-1107932624==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Russ, Since Alex suggested that it would be be better for me to provide text, than to just comment on text, I have taken the liberty of drafting a fair amount of new text for the intro. I did have a few questions on some of your original text; the questions are marked by angle brackets. The original text is plain, new text is bold. I used standard security terms (RFC 2828) to characterize requirements, and I noted the issue of the dynamics of the two different forms of inputs to the BGP routing algorithm. I also tried to characterize the two types of inputs to the algorithm in a more general fashion. Steve ------ System Description BGP is described in [BGP] as a routing protocol. Each pair of BGP speakers exchanges information about reachable destinations (address prefixes) in an internetwork through a peering session. Once this information has been exchanged, each BGP speaker locally determines a loop free path to each reachable destination, based on local policy, policy indicators carried in the update, and the AS Path carried in the BGP update. A principle goal for BGP security is to ensure that BGP speakers can execute the BGP route selection algorithm using inputs that are accurate. These inputs come from two sources, as indicated above: UPDATEs received via peering sessions and local policy data introduced by the managers of the AS to which each speaker belongs. This suggests that security requirements for BGP should address the integrity and authenticity of both sources of inputs. Note that the two data sources have different characteristics in terms of the dynamics of the data, i.e., data in UPDATEs is presumed to be 1. A BGP speaker operates on the assumption that the peering session between it and another BGP speaker is secure, specifically: - the peer is the one identified in a configuration database - that all traffic received via the peering session originates from the peer, has not been modified en route, and is "fresh." Using common security terminology, a BGP speaker requires peer-entity authentication and connection-oriented integrity for the session. Much of the data contained in an UPDATE often originates from an AS other than the immediate peer of a BGP speaker that receives the UPDATE. The security requirements defined for a peering session (above) cannot establish the integrity and authenticity of much of the content of an UPDATE, since those requirements address only immediate, pairwise integrity and authenticity security features. BGP specifies how each AS along the path is supposed to process the data it receives to produce any UPDATEs that are emitted as a result of receiving an UPDATE. Thus another aspect of securing UPDATE-based (vs. locally configured) inputs is to allow a BGP speaker to determine if the content of an UPDATE is "valid" as defined by the BGP processing specifications. This is a challenging requirement because BGP allows each AS along a path considerable discretion in processing a received UPDATE. However, there are many aspects of processing that are verifiable, at least in principle. - The last AS in the path is the origin AS, and it should be possible to verify the authorization of the AS in question to originate the prefixes in the UPDATE. - The AS path contained in the UPDATE nominally indicates the path traveled by the UPDATE. Note that the use of aggregation by ASes may cause the AS path to omit some ASes via which the UPDATE was propagated, so one has to exercise care in evaluating this aspect of UPDATE validity. However, one can verify some aspect of path validity, e.g., no AS should appear in a path unless a speaker from the AS in question emitted the UPDATE (or an UPDATE from which this UPDATE is derived). Also, the order of the ASes in the path should reflect the order that UPDATEs traversed these ASes, etc. Since UPDATEs represent realtime inputs to the route calculation process it is desirable that verification of UPDATE validity be based on realtime data. 2. The local policy data used by a speaker is configured by managers for the AS to which the speaker belongs, as noted above. Some of this data represents purely local information for which the AS is authoritative, e.g., agreements to forward transit traffic based on contractual arrangements. For such data, only locally-applied security procedures can be employed to help ensure accuracy. However, other data may be gleaned from authoritative sources and thus an architecture for BGP security should establish mechanisms to facilitate secure distribution of this data. Security for this data implies that each AS can identify the source of the data, determine that the data has not been modified en route, and be able to determine whether the source is authoritative for the data in question. Since there is no requirement that this data be acquired directly from each source (BGP does not specify how the data is acquired and it is common for such data to be distributed via repositories operated by third parties), connectionless integrity and data origin authentication, are the appropriate security requirements. Note that since this data is fairly static, verification of its accuracy can be based on similarly static measures without significant loss of security functionality. --============_-1107932624==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Thoughts on BGP Security Req's Draft (I)
Russ,

Since Alex suggested that it would be be better for me to provide text, than to just comment on text, I have taken the liberty of drafting a fair amount of new text for the intro.  I did have a few questions on some of your original text; the questions are marked by angle brackets. The original text is plain, new text is bold. I used standard security terms (RFC 2828) to characterize requirements, and I noted the issue of the dynamics of the two different forms of inputs to the BGP routing algorithm. I also tried to characterize the two types of inputs to the algorithm in a more general fashion.

Steve
------

System Description

BGP is described in [BGP] as a routing protocol. Each pair of BGP speakers exchanges information about reachable destinations (address prefixes) in an internetwork through a peering session. Once this information has been exchanged, each BGP speaker locally determines a loop free path to each reachable destination, based on local policy, policy indicators

<what is a "policy indicator?" is this term used in the BGP RFC?

(or policies) <what policies are carried in UPDATEs? are you referring to community value attributes? if so, it would be better to use that term, and give examples that illustrate how some of these values act as policy info.>
carried in the update, and the AS Path carried in the BGP update.

A principle goal for BGP security is to ensure that BGP speakers can execute the BGP route selection algorithm using inputs that are accurate. These inputs come from two sources, as indicated above: UPDATEs received via peering sessions and local policy data introduced by the managers of the AS to which each speaker belongs. This suggests that security requirements for BGP should address the integrity and authenticity of both sources of inputs. Note that the two data sources have different characteristics in terms of the dynamics of the data, i.e., data in UPDATEs is presumed to be

1. A BGP speaker operates on the assumption that the peering session between it and another BGP speaker is secure, specifically:
   - the peer is the one identified in a configuration database
    - that all traffic received via the peering session originates from the peer, has not been modified en route, and is "fresh."

Using common security terminology, a BGP speaker requires peer-entity authentication and connection-oriented integrity for the session.

<note that the wording immediately above does not mandate use of cryptography, but rather establishes requirements, consistent with the focus of this document on requirements, vs. solution mechanisms.>

Much of the data contained in an UPDATE often originates from an AS other than the immediate peer of a BGP speaker that receives the UPDATE. The security requirements defined for a peering session (above) cannot establish the integrity and authenticity of much of the content of an UPDATE, since those requirements address only immediate, pairwise integrity and authenticity security features. BGP specifies how each AS along the path is supposed to process the data it receives to produce any UPDATEs that are emitted as a result of receiving an UPDATE. Thus another aspect of securing UPDATE-based (vs. locally configured) inputs is to allow a BGP speaker to determine if the content of an UPDATE is "valid" as defined by the BGP processing specifications.

This is a challenging requirement because BGP allows each AS along a path considerable discretion in processing a received UPDATE. However, there are many aspects of processing that are verifiable, at least in principle.
    - The last AS in the path is the origin AS, and it should be possible to verify the authorization of the AS in question to originate the prefixes in the UPDATE.
    - The AS path contained in the UPDATE nominally indicates the path traveled by the UPDATE. Note that the use of aggregation by ASes may cause the AS path to omit some ASes via which the UPDATE was propagated, so one has to exercise care in evaluating this aspect of UPDATE validity. However, one can verify some aspect of path validity, e.g., no AS should appear in a path unless a speaker from the AS in question emitted the UPDATE (or an UPDATE from which this UPDATE is derived). Also, the order of the ASes in the path should reflect the order that UPDATEs traversed these ASes, etc. Since UPDATEs represent realtime inputs to the route calculation process it is desirable that verification of UPDATE validity be based on realtime data.

2. The local policy data used by a speaker is configured by managers for the AS to which the speaker belongs, as noted above. Some of this data represents purely local information for which the AS is authoritative, e.g., agreements to forward transit traffic based on contractual arrangements. For such data, only locally-applied security procedures can be employed to help ensure accuracy. However, other data may be gleaned from authoritative sources and thus an architecture for BGP security should establish mechanisms to facilitate secure distribution of this data.
Security for this data implies that each AS can identify the source of the data, determine that the data has not been modified en route, and be able to determine whether the source is authoritative for the data in question. Since there is no requirement that this data be acquired directly from each source (BGP does not specify how the data is acquired and it is common for such data to be distributed via repositories operated by third parties), connectionless integrity and data origin authentication, are the appropriate security requirements. Note that since this data is fairly static, verification of its accuracy can be based on similarly static measures without significant loss of security functionality.
--============_-1107932624==_ma============-- --===============0036680432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0036680432==-- From rpsec-bounces@ietf.org Mon Dec 27 20:37:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25081 for ; Mon, 27 Dec 2004 20:37:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj6TF-0001Ga-Q8 for rpsec-web-archive@ietf.org; Mon, 27 Dec 2004 20:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj6FX-000840-7p; Mon, 27 Dec 2004 20:34:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj6AA-0006oY-FU for rpsec@megatron.ietf.org; Mon, 27 Dec 2004 20:28:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24600 for ; Mon, 27 Dec 2004 20:28:37 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj6Ky-00014Q-St for rpsec@ietf.org; Mon, 27 Dec 2004 20:39:49 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 Dec 2004 20:28:07 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBS1S2gF004349; Mon, 27 Dec 2004 20:28:02 -0500 (EST) Date: Mon, 27 Dec 2004 20:27:28 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 > BGP is described in [BGP] as a routing protocol. Each pair of BGP > speakers exchanges information about reachable destinations (address > prefixes) in an internetwork through a peering session. Once this > information has been exchanged, each BGP speaker locally determines a > loop free path to each reachable destination, based on local policy, > policy indicators > (or policies) community value attributes? if so, it would be better to use that term, and > give examples that illustrate how some of these values act as policy info.> I think it might be better to add a definition to define some local term, within the draft, to mean communities+meds+any future things someone might dream up. It would make the document more easily readable, probably (?). > A principle goal for BGP security is to ensure that BGP speakers can > execute the BGP route selection algorithm using inputs that are accurate. I wouldn't phrase it this way. BGP primarily wants to find loop free paths through an internetwork, not execture an algorithm. It executes an algorithm in order to find loop free paths, but the algorithm isn't the focus of the protocol, the final result--loop free paths--is. > These inputs come from two sources, as indicated above: UPDATEs received > via peering sessions and local policy data introduced by the managers of > the AS to which each speaker belongs. This suggests that security > requirements for BGP should address the integrity and authenticity of > both sources of inputs. Note that the two data sources have different > characteristics in terms of the dynamics of the data, i.e., data in > UPDATEs is presumed to be > 1. A BGP speaker operates on the assumption that the peering session between > it and another BGP speaker is secure, specifically: > - the peer is the one identified in a configuration database > - that all traffic received via the peering session originates from > the peer, has not been modified en route, and is "fresh." > > Using common security terminology, a BGP speaker requires peer-entity > authentication and connection-oriented integrity for the session. > > cryptography, but rather establishes requirements, consistent with the focus > of this document on requirements, vs. solution mechanisms.> This sounds fine to me.... > Much of the data contained in an UPDATE often originates from an AS other > than the immediate peer of a BGP speaker that receives the UPDATE. The > security requirements defined for a peering session (above) cannot > establish the integrity and authenticity of much of the content of an > UPDATE, since those requirements address only immediate, pairwise > integrity and authenticity security features. BGP specifies how each AS > along the path is supposed to process the data it receives to produce any > UPDATEs that are emitted as a result of receiving an UPDATE. Thus another > aspect of securing UPDATE-based (vs. locally configured) inputs is to > allow a BGP speaker to determine if the content of an UPDATE is "valid" > as defined by the BGP processing specifications. > This is a challenging requirement because BGP allows each AS along a path > considerable discretion in processing a received UPDATE. However, there are > many aspects of processing that are verifiable, at least in principle. > - The last AS in the path is the origin AS, and it should be possible to > verify the authorization of the AS in question to originate the prefixes in > the UPDATE. I think this should actually be the first AS in the update, but different people use different terms for this. It depends on whether the last person puts the last as in the path, or the last person puts the first as in the path. > - The AS path contained in the UPDATE nominally indicates the path > traveled by the UPDATE. Note that the use of aggregation by ASes may > cause the AS path to omit some ASes via which the UPDATE was propagated, > so one has to exercise care in evaluating this aspect of UPDATE validity. > However, one can verify some aspect of path validity, e.g., no AS should > appear in a path unless a speaker from the AS in question emitted the > UPDATE (or an UPDATE from which this UPDATE is derived). Also, the order > of the ASes in the path should reflect the order that UPDATEs traversed > these ASes, etc. Since UPDATEs represent realtime inputs to the route > calculation process it is desirable that verification of UPDATE validity > be based on realtime data. And this is where I'll disagree. The worry isn't over the validity of the information in a specific update, in terms of "has it been altered," but rather the validity of what's in the update verses what the real world looks like. In other words, it's not that someone has replaced "these" bits with "those" bits, it just matters if the replacement will cause invalid routing decisions to be made. It's hard to think of metaphors for this, but I would say it's similar to making certain the plastic card containing your credit card numbers looks the same as the plastic card the credit card company issued you. That's not a valuable piece of validity in the credit card world--we're more worried about the authenticity of the information the card contains, than the authenticity of the card itself. Again, I don't care if it's the original update, only that the information in the update represents the real world. When I'm trying to decide if an update carries valid information or not, I don't care where it came from, I care about whether the information it carries reflects the real world. In other words, if someone hands me a BGP update, I don't want to trust Jack more than I trust Jill, just because Jack is Jack. I want to be able to evaluate Jack's and Jill's information based on reality. I have a two pointed challenges for you: -- First, prove BGP cares that the path contained in an update is the path the update actually took. It's well known that the update path is manipulated for many legitimate reasons today. -- Second, find a requirement to actually back up your assertion that this is important. The only point where what you're discussing here matters is in non-repudiation, not in update validity. See above on the concept of what's in the update verses the actual update. I don't see any reason to include language of this type--pushing concepts into BGP that don't exist in the protocol itself, and pushing the focus onto a subsidiary point, while ignoring the larger point. > 2. The local policy data used by a speaker is configured by managers for > the AS to which the speaker belongs, as noted above. Some of this data > represents purely local information for which the AS is authoritative, > e.g., agreements to forward transit traffic based on contractual > arrangements. For such data, only locally-applied security procedures can > be employed to help ensure accuracy. However, other data may be gleaned > from authoritative sources and thus an architecture for BGP security > should establish mechanisms to facilitate secure distribution of this > data. > > Security for this data implies that each AS can identify the source of > the data, determine that the data has not been modified en route, and be > able to determine whether the source is authoritative for the data in > question. Since there is no requirement that this data be acquired > directly from each source (BGP does not specify how the data is acquired > and it is common for such data to be distributed via repositories > operated by third parties), connectionless integrity and data origin > authentication, are the appropriate security requirements. Note that > since this data is fairly static, verification of its accuracy can be > based on similarly static measures without significant loss of security > functionality. I don't know that I understand these two paragraphs at all, really (?). Are you saying that each AS should have a way to propogate policy to all other AS' without embedding that information in BGP? It seems to me that this should be down in the requirements sections, if we're going to add this sort of requirement, rather than in the intro? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Dec 27 21:25:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27894 for ; Mon, 27 Dec 2004 21:25:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj7EB-0002Qk-MZ for rpsec-web-archive@ietf.org; Mon, 27 Dec 2004 21:36:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj6rN-0001Hx-Ve; Mon, 27 Dec 2004 21:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj6qO-0000OQ-KN for rpsec@megatron.ietf.org; Mon, 27 Dec 2004 21:12:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27159 for ; Mon, 27 Dec 2004 21:12:15 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj71D-00026Q-QF for rpsec@ietf.org; Mon, 27 Dec 2004 21:23:28 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 27 Dec 2004 21:21:52 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBS2BhEv000316; Mon, 27 Dec 2004 21:11:43 -0500 (EST) Date: Mon, 27 Dec 2004 21:11:03 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 >> - The AS path contained in the UPDATE nominally indicates the path >> traveled by the UPDATE. Note that the use of aggregation by ASes may cause >> the AS path to omit some ASes via which the UPDATE was propagated, so one >> has to exercise care in evaluating this aspect of UPDATE validity. However, >> one can verify some aspect of path validity, e.g., no AS should appear in a >> path unless a speaker from the AS in question emitted the UPDATE (or an >> UPDATE from which this UPDATE is derived). Also, the order of the ASes in >> the path should reflect the order that UPDATEs traversed these ASes, etc. >> Since UPDATEs represent realtime inputs to the route calculation process it >> is desirable that verification of UPDATE validity be based on realtime >> data. > > And this is where I'll disagree. The worry isn't over the validity of the > information in a specific update, in terms of "has it been altered," but > rather the validity of what's in the update verses what the real world > looks like. In other words, it's not that someone has replaced "these" > bits with "those" bits, it just matters if the replacement will cause > invalid routing decisions to be made. Actually, I was thinking about this some more, and I have another possible way to put it. Suppose you have this: A---B---C---D Suppose A sends an update to B, and this update finally gets to D through some process. Now, there are two questions we can ask about this update: -- Did the update actually traverse the path A/B/C/D? -- Does the path A/B/C/D actually exist? I think these are two fundamentally different questions--one is a question about non-repudiation, the other about the validity of the information contained in the update. I don't know that we should assume answering the first question always answers the second question, and even if we did, I don't think such an assumption should be buried in the document. Each question should really be called out on its own, so we get at the real requirements at hand, rather than assuming we don't need the answer the second question if we answer the first. I hope that makes more sense (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 08:09:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24221 for ; Tue, 28 Dec 2004 08:09:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHH0-0001hn-1u for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 08:20:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjH3L-0004WW-FM; Tue, 28 Dec 2004 08:06:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjH1T-00040z-0m for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 08:04:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23192 for ; Tue, 28 Dec 2004 08:04:21 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHCD-0001OP-Na for rpsec@ietf.org; Tue, 28 Dec 2004 08:15:40 -0500 Received: from [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e] (alumange.muada.com [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iBSD2oW2020151 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 28 Dec 2004 14:02:51 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document Date: Tue, 28 Dec 2004 14:02:59 +0100 To: Russ White X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit [Catching up... Does anyone have working URLs for the documents under discussion the past months?] On 16-nov-04, at 4:20, Russ White wrote: > +----B---+ > | | | > A | C > | | | > +----D---+ > -- D owns 10.1.0.0/16. > -- D suballocates 10.1.1.0/24 to A. D can provide a certificate > proving this suballocation to any and all interested parties in the > network--this, we can all agree on. > -- A determines it would like to advertise 10.1.1.0/24 to D and B, but > would not like B to readvertise 10.1.1.0/24 to C. A therefore marks, > in some way, it's route to B so B cannot readvertise 10.1.1.0/24. We > don't care how this marking works, just so long as we assume such a > marking exists, and B will always honor this marking. BGP has no way to make this happen today, unless B has configured community support for this. (I'm not a big fan of the word "readvertise" in this context, BTW.) > -- D continues to advertise 10.1.0.0/16 to B. > -- B continues to adveritse 10.1.0.0/16 to C > Now, a series of questions: > -- Does 10.1.0.0/16 contain 10.1.1.0/24? I assume the answer is yes. > -- Does B, in fact, "gain authorization" to advertise 10.1.1.0/24 as a > part of "gaining authorization" to advertise 10.1.0.0/16? Yes. > -- Can A, then, prevent B from advertising 10.1.1.0/24? No, as long as > we agree that 10.1.1.0/24 is a part of 10.1.0.0/16. > In what sense, then, is A "given" the address space 10.1.1.0/24? D is > still advertising it, without A's consent, correct? Either we must > specify that D can no longer advertise address space it has > suballocated (in other words, there can be no overlapping > advertisements in the protocol), or the concept of "ownership" in this > case is looser than we are expecting. In fact, the concept of > "ownership" of address space, in this context, prevents A from ever > controlling where address space it "owns" is avertised. [...] > If you can find some hole in the logic, other than asserting that A > shouldn't have such a policy, or that it all works without > aggregation, and we can't expect the aggregation case to work anyway, > then I would like to hear it. (I think that trying to express policies that disallow ASes further upstream from advertising stuff to ASes even further upstream is a road that doesn't lead anywhere useful.) However, you pose a very interesting question. It sure looks like a lot of people are assuming the following addressing hierarchy: ICANN -> RIRs -> origin AS The problem with this model is that it doesn't allow for aggregation of any kind, and now that routing table growth has kicked into a somewhat higher gear again, this is really a child we shouldn't throw out with the bath water. Note that today aggregation doesn't work very well as there is no reasonable way to do it automatically. Either I have to configure that 96.0.0.0/8 and 97.0.0.0/8 are always aggregated into 96.0.0.0/7, or it never happens. What I as an operator want, is that aggregation happens if the underlying BGP attributes are the same or close enough, and if they aren't, it doesn't happen. However, adding these mechanisms to BGP isn't trivial as it requires exceptions to the longest match first rule to be useful across AS boundaries. If we want to do this, it makes sense to propagate aggregates with holes in them as aggregates with holes in them, i.e., it would be possible to advertise "10.1.0.0/16 except 10.1.1.0/24". But in order for this to work well, an AS that sees both this route and 10.1.1.0/24 would have to be able to propagate 10.1.0.0/16 _without_ the exception, which is an "interesting" thing to do, authorization wise. All of this begs the question: if we're going to rebuild so many parts of BGP, wouldn't it make more sense to start with a clean slate? It would be great if we could separate the authenticity and authorization issues from the reachability issues. This would increase performance and decrease complexity. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 08:24:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25647 for ; Tue, 28 Dec 2004 08:24:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHW1-00026n-NK for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 08:35:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHHl-00072V-Cz; Tue, 28 Dec 2004 08:21:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHAh-0005UL-6e for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 08:13:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24636 for ; Tue, 28 Dec 2004 08:13:53 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHLc-0001oV-7z for rpsec@ietf.org; Tue, 28 Dec 2004 08:25:12 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 28 Dec 2004 08:23:35 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-281.cisco.com [10.82.217.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBSDDLEv002974; Tue, 28 Dec 2004 08:13:22 -0500 (EST) Date: Tue, 28 Dec 2004 08:12:42 -0500 (Eastern Standard Time) From: Russ White To: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > (I'm not a big fan of the word "readvertise" in this context, BTW.) I don't know of a better word. Wish I could think of one, then I'd be famous (not rich, but at least halfway towards the dream of all mankind, it seems! :-) ). >> In what sense, then, is A "given" the address space 10.1.1.0/24? D is still >> advertising it, without A's consent, correct? Either we must specify that D >> can no longer advertise address space it has suballocated (in other words, >> there can be no overlapping advertisements in the protocol), or the concept >> of "ownership" in this case is looser than we are expecting. In fact, the >> concept of "ownership" of address space, in this context, prevents A from >> ever controlling where address space it "owns" is avertised. > However, you pose a very interesting question. It sure looks like a lot > of people are assuming the following addressing hierarchy: > > ICANN -> RIRs -> origin AS > > The problem with this model is that it doesn't allow for aggregation of > any kind, and now that routing table growth has kicked into a somewhat > higher gear again, this is really a child we shouldn't throw out with the > bath water. > > Note that today aggregation doesn't work very well as there is no > reasonable way to do it automatically. Either I have to configure that > 96.0.0.0/8 and 97.0.0.0/8 are always aggregated into 96.0.0.0/7, or it > never happens. What I as an operator want, is that aggregation happens if > the underlying BGP attributes are the same or close enough, and if they > aren't, it doesn't happen. However, adding these mechanisms to BGP isn't > trivial as it requires exceptions to the longest match first rule to be > useful across AS boundaries. http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest-match-05.txt There should actually be a later version available, but I can't seem to find it (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 08:43:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26486 for ; Tue, 28 Dec 2004 08:43:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHnt-0002Vc-DM for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 08:54:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHTH-0001HY-CJ; Tue, 28 Dec 2004 08:33:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHSX-000159-VA for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 08:32:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26114 for ; Tue, 28 Dec 2004 08:32:20 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHdT-0002IL-1M for rpsec@ietf.org; Tue, 28 Dec 2004 08:43:39 -0500 Received: from [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e] (alumange.muada.com [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iBSDV6W2020527 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 28 Dec 2004 14:31:07 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document Date: Tue, 28 Dec 2004 14:31:12 +0100 To: Russ White X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit On 28-dec-04, at 14:12, Russ White wrote: >> (I'm not a big fan of the word "readvertise" in this context, BTW.) > I don't know of a better word. Wish I could think of one, then I'd be > famous (not rich, but at least halfway towards the dream of all > mankind, it seems! :-) ). I would describe this as "announcing an aggregate covering a more specific" but typing that all the time gets time consuming of course... >> Note that today aggregation doesn't work very well as there is no >> reasonable way to do it automatically. Either I have to configure >> that 96.0.0.0/8 and 97.0.0.0/8 are always aggregated into 96.0.0.0/7, >> or it never happens. What I as an operator want, is that aggregation >> happens if the underlying BGP attributes are the same or close >> enough, and if they aren't, it doesn't happen. However, adding these >> mechanisms to BGP isn't trivial as it requires exceptions to the >> longest match first rule to be useful across AS boundaries. > http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest- > match-05.txt > There should actually be a later version available, but I can't seem > to find it (?). Didn't you co-write it?? Unfortunately, you don't address the part that I'm concerned about in this draft: if I receive an aggregate from ISP1 and the original route from ISP2, longest match first dictates that I must always use ISP2. With the draft in effect I'd use ISP1. The latter case can be harmful if there is no reachability through ISP1 (which I can't tell from looking at the aggregate) and in both cases I don't get to distribute traffic as per my choice. Now obviously the way this is done today (where I get the aggregate from one ISP and the more specific from both) isn't what we want. A good step in the right direction would be to be able to compare the attributes of the aggregate and the more specific without taking the prefix length into account. And in order to be able to avoid unreachability within an aggregate, we need to know either a list of exceptions, or at least whether or not exceptions exist. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 08:53:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27158 for ; Tue, 28 Dec 2004 08:53:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHxh-0002ll-8T for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 09:04:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHio-00051v-Uk; Tue, 28 Dec 2004 08:49:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHiA-0004p2-PK for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 08:48:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26949 for ; Tue, 28 Dec 2004 08:48:28 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHt5-0002d5-Ud for rpsec@ietf.org; Tue, 28 Dec 2004 08:59:48 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 28 Dec 2004 05:48:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-281.cisco.com [10.82.217.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iBSDlu6o008879; Tue, 28 Dec 2004 05:47:57 -0800 (PST) Date: Tue, 28 Dec 2004 08:47:16 -0500 (Eastern Standard Time) From: Russ White To: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 >> I don't know of a better word. Wish I could think of one, then I'd be >> famous (not rich, but at least halfway towards the dream of all mankind, it >> seems! :-) ). > > I would describe this as "announcing an aggregate covering a more specific" > but typing that all the time gets time consuming of course... Another place where we need to invent a word, I suppose... :-) >> http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest- >> match-05.txt > >> There should actually be a later version available, but I can't seem to >> find it (?). > > Didn't you co-write it?? Yes, I have a later version locally, but I'm not certain what happened to the posting. :-) > Unfortunately, you don't address the part that I'm concerned about in > this draft: if I receive an aggregate from ISP1 and the original route > from ISP2, longest match first dictates that I must always use ISP2. With > the draft in effect I'd use ISP1. The latter case can be harmful if there > is no reachability through ISP1 (which I can't tell from looking at the > aggregate) and in both cases I don't get to distribute traffic as per my > choice. Actually, that isn't true, the way the draft is currently written. You have to have the overlap on a single router, so you have to have the aggregate plus the component on a single route to mark the component as not advertised. This is because you want to make certain you have the same next hop for both the aggregate and the component. The draft also knocks out the component learned on other edges, but you have to do that, in order to keep the component from being advertised at the outbound edge. We've also discussed doing the overlapping check on the outbound edge, but we decided against it, for some reason that I can't remember at this point. > Now obviously the way this is done today (where I get the aggregate from > one ISP and the more specific from both) isn't what we want. A good step > in the right direction would be to be able to compare the attributes of > the aggregate and the more specific without taking the prefix length into > account. And in order to be able to avoid unreachability within an > aggregate, we need to know either a list of exceptions, or at least > whether or not exceptions exist. The problem is you don't always know what the exceptions are, to generate them. Longest match routing works because you assume either one of two things about each possible aggregate: -- It can reach all the destinations implied in the aggregate. -- Destinations it cannot reach are simply unreachable (nonexistant). Most of the time, the exception to these two assumptions involves policy--yes, x _is_ reachable along this path, but I don't want it to be reached along this path--rather than actual reachability problems. In other words, I don't know of any case where these two aren't true where filtering of routing information within an aggregate isn't involved, as well (?). At that point, we spiral down the long rathole of filtering, and the other possible bad side effects of it, etc, etc.... :-) :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 09:29:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29218 for ; Tue, 28 Dec 2004 09:29:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjIWY-0003iI-4H for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 09:40:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjIFq-0003nw-SM; Tue, 28 Dec 2004 09:23:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjI9C-0002i7-6I for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 09:16:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28507 for ; Tue, 28 Dec 2004 09:16:24 -0500 (EST) Received: from server2.tcw.telecomplete.net ([213.160.116.2] helo=mx-0.telecomplete.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjIJx-0003PX-Lf for rpsec@ietf.org; Tue, 28 Dec 2004 09:27:43 -0500 Received: from server2.tcw.telecomplete.net ([127.0.0.1]) by mx-0.telecomplete.net with esmtp (Exim 4.22) id 1CjI8w-0007ge-Mm; Tue, 28 Dec 2004 14:16:10 +0000 Date: Tue, 28 Dec 2004 14:16:10 +0000 (GMT) From: "Stephen J. Wilcox" X-X-Sender: steve@server2.tcw.telecomplete.net To: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 On Tue, 28 Dec 2004, Iljitsch van Beijnum wrote: > Note that today aggregation doesn't work very well as there is no reasonable > way to do it automatically. Either I have to configure that 96.0.0.0/8 and > 97.0.0.0/8 are always aggregated into 96.0.0.0/7, or it never happens. What I > as an operator want, is that aggregation happens if the underlying BGP > attributes are the same or close enough, and if they aren't, it doesn't > happen. However, adding these mechanisms to BGP isn't trivial as it requires > exceptions to the longest match first rule to be useful across AS boundaries. this is only useful for leaf networks, transit networks will NOT want this to occur as longest match will ensure that their competitors routes are installed. but if i'm a leaf network i have a bag of tricks to reduce the routing table anyway eg filter aggressively and default to upstreams. therefore i dont think auto-aggregation by anyting but the source is useful. > If we want to do this, it makes sense to propagate aggregates with holes in > them as aggregates with holes in them, i.e., it would be possible to advertise > "10.1.0.0/16 except 10.1.1.0/24". But in order for this to work well, an AS > that sees both this route and 10.1.1.0/24 would have to be able to propagate > 10.1.0.0/16 _without_ the exception, which is an "interesting" thing to do, > authorization wise. this equates to advertising two routes - route /16, ignore /24 - which seems to suggest you increase the amount of bgp data being propagated and also the amount of processing when switching packets (both forward and drop routes would need to be installed into the routing and forwarding table of routers). > All of this begs the question: if we're going to rebuild so many parts of BGP, > wouldn't it make more sense to start with a clean slate? It would be great if > we could separate the authenticity and authorization issues from the > reachability issues. This would increase performance and decrease complexity. Well, thats a whole different question. But even if you create BGP-5 I dont see how you are addressing the fundemental issues Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 11:55:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09675 for ; Tue, 28 Dec 2004 11:55:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjKni-0007On-1f for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 12:06:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjKZu-0006f3-GX; Tue, 28 Dec 2004 11:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjKRJ-00051h-Oz for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 11:43:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09097 for ; Tue, 28 Dec 2004 11:43:14 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjKcG-00077L-Cw for rpsec@ietf.org; Tue, 28 Dec 2004 11:54:37 -0500 Received: from [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e] (alumange.muada.com [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iBSGh2W2022573 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 28 Dec 2004 17:43:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8F9F0D90-58EF-11D9-BFE9-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document Date: Tue, 28 Dec 2004 17:43:11 +0100 To: "Stephen J. Wilcox" X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: "" X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit On 28-dec-04, at 15:16, Stephen J. Wilcox wrote: >> Note that today aggregation doesn't work very well as there is no >> reasonable >> way to do it automatically. [...] >> However, adding these mechanisms to BGP isn't trivial as it requires >> exceptions to the longest match first rule to be useful across AS >> boundaries. > this is only useful for leaf networks, transit networks will NOT want > this to > occur as longest match will ensure that their competitors routes are > installed. Hence the need to modify the longest match first rule. If it's only useful in leaf networks there is little point: > but if i'm a leaf network i have a bag of tricks to reduce the routing > table > anyway >> If we want to do this, it makes sense to propagate aggregates with >> holes in >> them as aggregates with holes in them, i.e., it would be possible to >> advertise "10.1.0.0/16 except 10.1.1.0/24". > this equates to advertising two routes - route /16, ignore /24 Or more. Worst case would be 129: a /16 and alternating /24 holes/non-holes. (Assuming /24 as the longest usable prefix.) > which seems to suggest you increase the amount of bgp data being > propagated Yes. This would only be useful if there are also (bigger) savings somewhere else. Note that these holes could be encoded quite efficiently in on or more bitmaps, so the above worst case would be a regular /16 route along with a 32 byte bitmap. These savings would happen if the holes + more specifics are only present in part of the network, and only a single aggregate is present elsewhere. > and also the amount of processing when switching packets (both forward > and drop routes would need to be installed into the routing and > forwarding table of routers). Well, either you don't care about the holes and your tables will be smaller, or you do care and there is more stuff in your tables. But with an n-way trie it's hard to tell the difference, as long as you have the memory... With what we have today there is no choice. >> All of this begs the question: if we're going to rebuild so many >> parts of BGP, wouldn't it make more sense to start with a clean >> slate? > Well, thats a whole different question. But even if you create BGP-5 I > dont see how you are addressing the fundemental issues The fundamental issues have been discussed here in this wg for some time, especially the problem of how the source of a route / destination of a packet gets the destination of a route / source of a packet from using the route by sending a packet for individual ASes beyond the immediate next hop AS. This essentially takes us outside the realm of hop-by-hop routing, but, from RFC 1771: "To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that a BGP speaker advertise to its peers (other BGP speakers which it communicates with) in neighboring ASs only those routes that it itself uses. This rule reflects the "hop-by-hop" routing paradigm generally used throughout the current Internet. Note that some policies cannot be supported by the "hop-by-hop" routing paradigm and thus require techniques such as source routing to enforce. For example, BGP does not enable one AS to send traffic to a neighboring AS intending that the traffic take a different route from that taken by traffic originating in the neighboring AS. On the other hand, BGP can support any policy conforming to the "hop-by-hop" routing paradigm." I haven't read any drafts as I seem to have managed to miss any working links to them, but from the discussion here it's clear that we're not just talking about making what BGP does today secure, but rather make securely what we think BGP should have been doing all along. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 14:09:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17809 for ; Tue, 28 Dec 2004 14:09:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMtf-0002FL-T9 for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 14:20:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMbw-0000lz-Cv; Tue, 28 Dec 2004 14:02:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMWc-000862-65 for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 13:56:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17073 for ; Tue, 28 Dec 2004 13:56:52 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMha-0001w9-7b for rpsec@ietf.org; Tue, 28 Dec 2004 14:08:14 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBSIu9jh010312; Tue, 28 Dec 2004 13:56:12 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Dec 2004 11:54:09 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Iljitsch, > >However, you pose a very interesting question. It sure looks like a >lot of people are assuming the following addressing hierarchy: > >ICANN -> RIRs -> origin AS Not sure exactly what you are referring to here. There is an important distinction between an address allocation hierarchy, and the ability to determine who is authorized to advertise itself as an orign AS. In the papers we've written on BGP security, we do describe an address allocation hierarchy that is rooted at ICANN and that goes through RIRs to ISPs (or subscribers), etc. We also note that some subscribers get allocations directly from an RIR. Do you think that this is an inaccurate model for allocation? With regard to the authorization to advertise an AS as an origin for a prefix, we understand that one needs an explicit authorization mechanism, one that accommodates dual homing, subscribers who leave ISPs and take their addresses with them, etc. S-BGP includes a mechanism that accommodates this. >The problem with this model is that it doesn't allow for aggregation >of any kind, and now that routing table growth has kicked into a >somewhat higher gear again, this is really a child we shouldn't >throw out with the bath water. You are right that a simplistic model, one that looks only at address allocation, and does not take into account the various ways that an AS can be authorized to originate prefixes, also would be unlikely to accommodate aggregation. > > >All of this begs the question: if we're going to rebuild so many >parts of BGP, wouldn't it make more sense to start with a clean >slate? It would be great if we could separate the authenticity and >authorization issues from the reachability issues. This would >increase performance and decrease complexity. I'm not sure what you mean by this last paragraph. When we approached BGP security we did so cognizant of the limitations of the extant protocol. We started from the premise of what a speaker assumes is true when it gets an Update, and then worked from that basis to determine what the security requirements were, and then proposed mechanisms to satisfy those requirements. In the BGP context, we are interested in authentication, integrity, and authorization only to the extent that the support the goal of allowing a speaker to verify inputs to the reachability/routing computation. Anothr way of saying this, that I think we should articulate in the document (if there is agreement) is that main purpose of BGP security should be to enable speakers to verify Updates, because speakers make routing (reachability) decisions based on a combination of dynamic info from Updates and static config data. That suggests a two-pronged approach, one that provides a speaker with data to verify the dynamic aspects of an Update, and one that supports distribution of (static) data to support verification of the less dynamic aspects of an Update. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 14:09:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17894 for ; Tue, 28 Dec 2004 14:09:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMu4-0002Ha-E3 for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 14:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMbx-0000mG-Np; Tue, 28 Dec 2004 14:02:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMXa-0008Jd-EX for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 13:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17152 for ; Tue, 28 Dec 2004 13:57:52 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMiY-0001x5-FW for rpsec@ietf.org; Tue, 28 Dec 2004 14:09:14 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBSIu9jn010312; Tue, 28 Dec 2004 13:56:22 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Dec 2004 13:20:48 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 At 9:11 PM -0500 12/27/04, Russ White wrote: >>> - The AS path contained in the UPDATE nominally indicates the >>>path traveled by the UPDATE. Note that the use of aggregation by >>>ASes may cause the AS path to omit some ASes via which the UPDATE >>>was propagated, so one has to exercise care in evaluating this >>>aspect of UPDATE validity. However, one can verify some aspect of >>>path validity, e.g., no AS should appear in a path unless a >>>speaker from the AS in question emitted the UPDATE (or an UPDATE >>>from which this UPDATE is derived). Also, the order of the ASes in >>>the path should reflect the order that UPDATEs traversed these >>>ASes, etc. Since UPDATEs represent realtime inputs to the route >>>calculation process it is desirable that verification of UPDATE >>>validity be based on realtime data. >> >>And this is where I'll disagree. The worry isn't over the validity >>of the information in a specific update, in terms of "has it been >>altered," but rather the validity of what's in the update verses >>what the real world looks like. In other words, it's not that >>someone has replaced "these" bits with "those" bits, it just >>matters if the replacement will cause invalid routing decisions to >>be made. > >Actually, I was thinking about this some more, and I have another >possible way to put it. Suppose you have this: > >A---B---C---D > >Suppose A sends an update to B, and this update finally gets to D >through some process. Now, there are two questions we can ask about >this update: > >-- Did the update actually traverse the path A/B/C/D? > >-- Does the path A/B/C/D actually exist? > >I think these are two fundamentally different questions--one is a >question about non-repudiation, the other about the validity of the >information contained in the update. I don't know that we should >assume answering the first question always answers the second >question, and even if we did, I don't think such an assumption >should be buried in the document. As I noted elsewhere, NR is not the right security term here, but I understand the question you are raising. I think the answer is that we do care about how the Update got to D, at least to some extent. There are lots of inter-As links in the Internet, but each AS decides what traffic is allowed to traverse which links, in a local sense. BGP is the way that ASes tell one another the subset of path info that they want to advertise, and for what traffic (based on destination address prefix matching rules) vs. the much larger set of paths (sequences of links) that exist, or even paths that exist but are restricted to other sets of NLRI. This says that even if we receive an Update that represents a path that exists, that does not necessarily imply that the route represented by the Update has been authorized by the ASes along the path. Moreover, there is an issue of timeliness, i.e., do these ASes currently authorize advertisement of this route? I'm not saying that one cannot find other ways to verify that all of the ASes along the path authorize propagation of the route in an Update. But, I am saying that the simplest model is the one that the BGP spec defines. if we try to develop another model that promises to yield the same answer, we will have a much harder job, since we will bneed to demonstrate that the results are equivalent in all cases. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 14:10:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18052 for ; Tue, 28 Dec 2004 14:10:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMui-0002JG-D0 for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 14:21:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMby-0000mL-2T; Tue, 28 Dec 2004 14:02:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMXa-0008Je-Fu for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 13:57:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17150 for ; Tue, 28 Dec 2004 13:57:52 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMiX-0001x4-Fu for rpsec@ietf.org; Tue, 28 Dec 2004 14:09:14 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBSIu9jl010312; Tue, 28 Dec 2004 13:56:21 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Dec 2004 13:56:01 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0323618831==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 --===============0323618831== Content-Type: multipart/alternative; boundary="============_-1107862318==_ma============" --============_-1107862318==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:27 PM -0500 12/27/04, Russ White wrote: >>BGP is described in [BGP] as a routing protocol. Each pair of BGP >>speakers exchanges information about reachable destinations >>(address prefixes) in an internetwork through a peering session. >>Once this information has been exchanged, each BGP speaker locally >>determines a loop free path to each reachable destination, based on >>local policy, policy indicators > >> >This isn't used in the BGP drafts, but it's easier to come up with >some term than to try and add each individual thing a BGP speaker >may make a decision on, such as the MED, various communities, etc. >Note communities and extended communities, often used to express >policy, are not covered in the base BGP draft, so there's no need to >be concerned with these concepts there. Well, if they are no to be included, we just need a concise definition of what you do want to include, and an example for clarity. > >>(or policies) >referring to community value attributes? if so, it would be better >>to use that term, and give examples that illustrate how some of >>these values act as policy info.> > >I think it might be better to add a definition to define some local >term, within the draft, to mean communities+meds+any future things >someone might dream up. It would make the document more easily >readable, probably (?). > >>A principle goal for BGP security is to ensure that BGP speakers >>can execute the BGP route selection algorithm using inputs that are >>accurate. > >I wouldn't phrase it this way. BGP primarily wants to find loop free >paths through an internetwork, not execture an algorithm. It >executes an algorithm in order to find loop free paths, but the >algorithm isn't the focus of the protocol, the final result--loop >free paths--is. I agree that the ultimate goal is to become aware of paths, but since we agree that the PBGP specs says that the means by which the paths are computed is via the algorithm defined in the spec, it seems appropriate to emphasize that aspect. > >>These inputs come from two sources, as indicated above: UPDATEs >>received via peering sessions and local policy data introduced by >>the managers of the AS to which each speaker belongs. This suggests >>that security requirements for BGP should address the integrity and >>authenticity of both sources of inputs. Note that the two data >>sources have different characteristics in terms of the dynamics of >>the data, i.e., data in UPDATEs is presumed to be > >>1. A BGP speaker operates on the assumption that the peering >>session between it and another BGP speaker is secure, specifically: >> - the peer is the one identified in a configuration database >> - that all traffic received via the peering session >>originates from the peer, has not been modified en route, and is >>"fresh." >> >>Using common security terminology, a BGP speaker requires >>peer-entity authentication and connection-oriented integrity for >>the session. >> >>>cryptography, but rather establishes requirements, consistent with >>the focus of this document on requirements, vs. solution >>mechanisms.> > >This sounds fine to me.... OK. > >>Much of the data contained in an UPDATE often originates from an AS >>other than the immediate peer of a BGP speaker that receives the >>UPDATE. The security requirements defined for a peering session >>(above) cannot establish the integrity and authenticity of much of >>the content of an UPDATE, since those requirements address only >>immediate, pairwise integrity and authenticity security features. >>BGP specifies how each AS along the path is supposed to process the >>data it receives to produce any UPDATEs that are emitted as a >>result of receiving an UPDATE. Thus another aspect of securing >>UPDATE-based (vs. locally configured) inputs is to allow a BGP >>speaker to determine if the content of an UPDATE is "valid" as >>defined by the BGP processing specifications. > >>This is a challenging requirement because BGP allows each AS along >>a path considerable discretion in processing a received UPDATE. >>However, there are many aspects of processing that are verifiable, >>at least in principle. > >> - The last AS in the path is the origin AS, and it should be >>possible to verify the authorization of the AS in question to >>originate the prefixes in the UPDATE. > >I think this should actually be the first AS in the update, but >different people use different terms for this. It depends on whether >the last person puts the last as in the path, or the last person >puts the first as in the path. I have to admit that I get confused about first vs. last here! Whatever folks says is right is fine with me, so long as we are consistent :-). > >> - The AS path contained in the UPDATE nominally indicates the >>path traveled by the UPDATE. Note that the use of aggregation by >>ASes may cause the AS path to omit some ASes via which the UPDATE >>was propagated, so one has to exercise care in evaluating this >>aspect of UPDATE validity. However, one can verify some aspect of >>path validity, e.g., no AS should appear in a path unless a speaker >>from the AS in question emitted the UPDATE (or an UPDATE from which >>this UPDATE is derived). Also, the order of the ASes in the path >>should reflect the order that UPDATEs traversed these ASes, etc. >>Since UPDATEs represent realtime inputs to the route calculation >>process it is desirable that verification of UPDATE validity be >>based on realtime data. > >And this is where I'll disagree. The worry isn't over the validity >of the information in a specific update, in terms of "has it been >altered," but rather the validity of what's in the update verses >what the real world looks like. In other words, it's not that >someone has replaced "these" bits with "those" bits, it just matters >if the replacement will cause invalid routing decisions to be made. I guess if I were Bill (Clinton or Gates) I would say it depends on what you mean by "invalid." If a speaker (or an on-the-wire attacker) changes bits in a fashion not consistent with the Update processing algorithm, then the result is inaccurate, relative to what the spec says should happen. Presumably we want to allow speakers to detect misbehavior if it would result in misrouting, right? I think you are suggesting that we don't need to detect misbehavior so long as the results of the misbehavior are "valid." Well, that may be true, but if you want to assert this, you have to demonstrate that an alternative security model is equivalent to what one would get if one adopted the simple model that BGP calls for. The phrase "what the real world looks like" is a bit imprecise. Form a routing perspective, one might nee to know the local policy data for every AS, and the current up/down status for all links, to know "what the real world looks like"" in evaluating an Update. That's seems like a lot to ask. BGP just says that Updates are processed in a way that takes into account local policies and current link status. Thus if we can verify that an Update is valid in the normal BGP processing sense, we don't have to address the issue of explicitly publishing local policy info or the practical impossibility of distributing link status securely in real time via another mechanism. >It's hard to think of metaphors for this, but I would say it's >similar to making certain the plastic card containing your credit >card numbers looks the same as the plastic card the credit card >company issued you. That's not a valuable piece of validity in the >credit card world--we're more worried about the authenticity of the >information the card contains, than the authenticity of the card >itself. An interesting metaphor. Note that if someone makes a copy of the data on the card and uses it to make another card (or to make a telephone, mail order or Internet purchase), and the person doing so is not the authorized card holder, we consider this to be fraud. It is not good enough to represent the data on the card accurately. So, I think that you don't want to use this analogy! >Again, I don't care if it's the original update, only that the >information in the update represents the real world. When I'm trying >to decide if an update carries valid information or not, I don't >care where it came from, I care about whether the information it >carries reflects the real world. In other words, if someone hands me >a BGP update, I don't want to trust Jack more than I trust Jill, >just because Jack is Jack. I want to be able to evaluate Jack's and >Jill's information based on reality. I disagree, and your metaphor above gives a good example of why. >I have a two pointed challenges for you: > >-- First, prove BGP cares that the path contained in an update is >the path the update actually took. It's well known that the update >path is manipulated for many legitimate reasons today. I have assumed that we want to generate requirements based on what BGP says is correct operation. I believe that BGP specifies the circumstances under which a speaker is to emit an Update, either as a side effect of processing a inbound Update or due to detection of loss of connectivity. That suggests that our requirements should try to capture this notion. If, as you suggest, we do not verify that an Update has traversed the path indicated by the path attribute (modulo aggregation) then BGP is susceptible to attacks that advertise bogus path. What you seem to be arguing is that if a speaker advertises a path that is not currently being advertised by the preceding ASes list in the path, but one that could legitimately be advertised based on local policy configurations in those ASes, then that is OK. I challenge you to show me where the BGP spec includes this notion! BGP makes provision to use both static data and dynamic data as inputs to the routing algorithm. If dynamic data were not needed, then we would not need to bother with Updates; we could just all the topology and policy info into each speaker and be done. But, we know that this sort of configuration is not sufficient for many ASes, and that the dynamic data about what paths are currently being advertised IS important. >-- Second, find a requirement to actually back up your assertion >that this is important. The only point where what you're discussing >here matters is in non-repudiation, not in update validity. See >above on the concept of what's in the update verses the actual >update. first, the term non-repudiation is not really applicable here. The security features we want are multicast receiver integrity and authentication. But, as for the why we need to pay attention to how we got an Update, I think my analysis above addresses that question. >I don't see any reason to include language of this type--pushing >concepts into BGP that don't exist in the protocol itself, and >pushing the focus onto a subsidiary point, while ignoring the larger >point. As expected, we disagree. I think what I have said is directly derived from the description of BGP processing. In contrast, what you are advocating is a wording that seems to be designed to accommodate soBGP's notion of validity based on statically configured policy data. >>2. The local policy data used by a speaker is configured by >>managers for the AS to which the speaker belongs, as noted above. >>Some of this data represents purely local information for which the >>AS is authoritative, e.g., agreements to forward transit traffic >>based on contractual arrangements. For such data, only >>locally-applied security procedures can be employed to help ensure >>accuracy. However, other data may be gleaned from authoritative >>sources and thus an architecture for BGP security should establish >>mechanisms to facilitate secure distribution of this data. >> >>Security for this data implies that each AS can identify the source >>of the data, determine that the data has not been modified en >>route, and be able to determine whether the source is authoritative >>for the data in question. Since there is no requirement that this >>data be acquired directly from each source (BGP does not specify >>how the data is acquired and it is common for such data to be >>distributed via repositories operated by third parties), >>connectionless integrity and data origin authentication, are the >>appropriate security requirements. Note that since this data is >>fairly static, verification of its accuracy can be based on >>similarly static measures without significant loss of security >>functionality. > >I don't know that I understand these two paragraphs at all, really >(?). Are you saying that each AS should have a way to propogate >policy to all other AS' without embedding that information in BGP? >It seems to me that this should be down in the requirements >sections, if we're going to add this sort of requirement, rather >than in the intro? The means by which we address this issue need not be in the intro. But I do think the intro needs to explicitly recognize the fact that BGP relies on both dynamic data and static data as inputs to the algorithm. Thus we have to pay attention to integrity, authenticity, and authorization for the static data, as well as the dynamic data. I though you were suggesting that we pay attention to this issue earlier, when you emphasized the need for a "systems approach" to BGP security. I was trying to accommodate this concern you raised, in a fashion that is still grounded in the BGP spec, even though the means by which the data is made available to AS managers is outside the spec and does not involve the border gateway protocol per se. Steve --============_-1107862318==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Thoughts on BGP Security Req's Draft (I)
At 8:27 PM -0500 12/27/04, Russ White wrote:
BGP is described in [BGP] as a routing protocol. Each pair of BGP speakers exchanges information about reachable destinations (address prefixes) in an internetwork through a peering session. Once this information has been exchanged, each BGP speaker locally determines a loop free path to each reachable destination, based on local policy, policy indicators

<what is a "policy indicator?" is this term used in the BGP RFC?

This isn't used in the BGP drafts, but it's easier to come up with some term than to try and add each individual thing a BGP speaker may make a decision on, such as the MED, various communities, etc. Note communities and extended communities, often used to express policy, are not covered in the base BGP draft, so there's no need to be concerned with these concepts there.

Well, if they are no to be included, we just need a concise definition of what you do want to include, and an example for clarity.


(or policies) <what policies are carried in UPDATEs? are you referring to community value attributes? if so, it would be better to use that term, and give examples that illustrate how some of these values act as policy info.>

I think it might be better to add a definition to define some local term, within the draft, to mean communities+meds+any future things someone might dream up. It would make the document more easily readable, probably (?).
A principle goal for BGP security is to ensure that BGP speakers can execute the BGP route selection algorithm using inputs that are accurate.

I wouldn't phrase it this way. BGP primarily wants to find loop free paths through an internetwork, not execture an algorithm. It executes an algorithm in order to find loop free paths, but the algorithm isn't the focus of the protocol, the final result--loop free paths--is.

I agree that the ultimate goal is to become aware of paths, but since we agree that the PBGP specs  says that the means by which the paths are computed is via the algorithm defined in the spec, it seems appropriate to emphasize that aspect.


These inputs come from two sources, as indicated above: UPDATEs received via peering sessions and local policy data introduced by the managers of the AS to which each speaker belongs. This suggests that security requirements for BGP should address the integrity and authenticity of both sources of inputs. Note that the two data sources have different characteristics in terms of the dynamics of the data, i.e., data in UPDATEs is presumed to be

1. A BGP speaker operates on the assumption that the peering session between it and another BGP speaker is secure, specifically:
        - the peer is the one identified in a configuration database
    - that all traffic received via the peering session originates from the peer, has not been modified en route, and is "fresh."

Using common security terminology, a BGP speaker requires peer-entity authentication and connection-oriented integrity for the session.

<note that the wording immediately above does not mandate use of cryptography, but rather establishes requirements, consistent with the focus of this document on requirements, vs. solution mechanisms.>

This sounds fine to me....

OK.

Much of the data contained in an UPDATE often originates from an AS other than the immediate peer of a BGP speaker that receives the UPDATE. The security requirements defined for a peering session (above) cannot establish the integrity and authenticity of much of the content of an UPDATE, since those requirements address only immediate, pairwise integrity and authenticity security features. BGP specifies how each AS along the path is supposed to process the data it receives to produce any UPDATEs that are emitted as a result of receiving an UPDATE. Thus another aspect of securing UPDATE-based (vs. locally configured) inputs is to allow a BGP speaker to determine if the content of an UPDATE is "valid" as defined by the BGP processing specifications.

This is a challenging requirement because BGP allows each AS along a path considerable discretion in processing a received UPDATE. However, there are many aspects of processing that are verifiable, at least in principle.

   - The last AS in the path is the origin AS, and it should be possible to verify the authorization of the AS in question to originate the prefixes in the UPDATE.

I think this should actually be the first AS in the update, but different people use different terms for this. It depends on whether the last person puts the last as in the path, or the last person puts the first as in the path.

I have to admit that I get confused about first vs. last here! Whatever folks says is right is fine with me, so long as we are consistent :-).


   - The AS path contained in the UPDATE nominally indicates the path traveled by the UPDATE. Note that the use of aggregation by ASes may cause the AS path to omit some ASes via which the UPDATE was propagated, so one has to exercise care in evaluating this aspect of UPDATE validity. However, one can verify some aspect of path validity, e.g., no AS should appear in a path unless a speaker from the AS in question emitted the UPDATE (or an UPDATE from which this UPDATE is derived). Also, the order of the ASes in the path should reflect the order that UPDATEs traversed these ASes, etc. Since UPDATEs represent realtime inputs to the route calculation process it is desirable that verification of UPDATE validity be based on realtime data.

And this is where I'll disagree. The worry isn't over the validity of the information in a specific update, in terms of "has it been altered," but rather the validity of what's in the update verses what the real world looks like. In other words, it's not that someone has replaced "these" bits with "those" bits, it just matters if the replacement will cause invalid routing decisions to be made.

I guess if I were Bill (Clinton or Gates) I would say it depends on what you mean by "invalid." If a speaker (or an on-the-wire attacker) changes bits in a fashion not consistent with the Update processing algorithm, then the result is inaccurate, relative to what the spec says should happen.  Presumably we want to allow speakers to detect misbehavior if it would result in misrouting, right? I think you are suggesting that we don't need to detect misbehavior so long as the results of the misbehavior are "valid." Well, that may be true, but if you want to assert this, you have to demonstrate that an alternative security model is equivalent to what one would get if one adopted the simple model that BGP calls for.

The phrase "what the real world looks like" is a bit imprecise. Form a routing perspective, one might nee to know the local policy data for every AS, and the current up/down status for all links, to know "what the real world looks like"" in evaluating an Update. That's seems like a lot to ask. BGP just says that Updates are processed in a way that takes into account local policies and current link status. Thus if we can verify that an Update is valid in the normal BGP processing sense, we don't have to address the issue of explicitly publishing local policy info or the practical impossibility of distributing link status securely in real time via another mechanism.


It's hard to think of metaphors for this, but I would say it's similar to making certain the plastic card containing your credit card numbers looks the same as the plastic card the credit card company issued you. That's not a valuable piece of validity in the credit card world--we're more worried about the authenticity of the information the card contains, than the authenticity of the card itself.

An interesting metaphor.  Note that if someone makes a copy of the data on the card and uses it to make another card (or to make a telephone, mail order or Internet purchase), and the person doing so is not the authorized card holder, we consider this to be fraud. It is not good enough to represent the data on the card accurately. So, I think that you don't want to use this analogy!

Again, I don't care if it's the original update, only that the information in the update represents the real world. When I'm trying to decide if an update carries valid information or not, I don't care where it came from, I care about whether the information it carries reflects the real world. In other words, if someone hands me a BGP update, I don't want to trust Jack more than I trust Jill, just because Jack is Jack. I want to be able to evaluate Jack's and Jill's information based on reality.

I disagree, and your metaphor above gives a good example of why.

I have a two pointed challenges for you:

-- First, prove BGP cares that the path contained in an update is the path the update actually took. It's well known that the update path is manipulated for many legitimate reasons today.

I have assumed that we want to generate requirements based on what BGP says is correct operation. I believe that BGP specifies the circumstances under which a speaker is to emit an Update, either as a side effect of processing a inbound Update or due to detection of loss of connectivity. That suggests that our requirements should try to capture this notion.

If, as you suggest, we do not verify that an Update has traversed the path indicated by the path attribute (modulo aggregation) then BGP is susceptible to attacks that advertise bogus path.  What you seem to be arguing is that if a speaker advertises a path that is not currently being advertised by the preceding ASes list in the path, but one that could legitimately be advertised based on local policy configurations in those ASes, then that is OK.

I challenge you to show me where the BGP spec includes this notion!

BGP makes provision to use both static data and dynamic data as inputs to the routing algorithm. If dynamic data were not needed, then we would not need to bother with Updates; we could just all the topology and policy info into each speaker and be done.  But, we know that this sort of configuration is not sufficient for many ASes, and that the dynamic data about what paths are currently being advertised IS important.

-- Second, find a requirement to actually back up your assertion that this is important. The only point where what you're discussing here matters is in non-repudiation, not in update validity. See above on the concept of what's in the update verses the actual update.

first, the term non-repudiation is not really applicable here. The security features we want are multicast receiver integrity and authentication. But, as for the why we need to pay attention to how we got an Update, I think my analysis above addresses that question.

I don't see any reason to include language of this type--pushing concepts into BGP that don't exist in the protocol itself, and pushing the focus onto a subsidiary point, while ignoring the larger point.

As expected, we disagree. I think what I have said is directly derived from the description of BGP processing. In contrast, what you are advocating is a wording that seems to be designed to accommodate soBGP's notion of validity based on statically configured policy data.

2. The local policy data used by a speaker is configured by managers for the AS to which the speaker belongs, as noted above. Some of this data represents purely local information for which the AS is authoritative, e.g., agreements to forward transit traffic based on contractual arrangements. For such data, only locally-applied security procedures can be employed to help ensure accuracy. However, other data may be gleaned from authoritative sources and thus an architecture for BGP security should establish mechanisms to facilitate secure distribution of this data.

Security for this data implies that each AS can identify the source of the data, determine that the data has not been modified en route, and be able to determine whether the source is authoritative for the data in question. Since there is no requirement that this data be acquired directly from each source (BGP does not specify how the data is acquired and it is common for such data to be distributed via repositories operated by third parties), connectionless integrity and data origin authentication, are the appropriate security requirements. Note that since this data is fairly static, verification of its accuracy can be based on similarly static measures without significant loss of security functionality.

I don't know that I understand these two paragraphs at all, really (?). Are you saying that each AS should have a way to propogate policy to all other AS' without embedding that information in BGP? It seems to me that this should be down in the requirements sections, if we're going to add this sort of requirement, rather than in the intro?

The means by which we address this issue need not be in the intro. But I do think the intro needs to explicitly recognize the fact that BGP relies on both dynamic data and static data as inputs to the algorithm. Thus we have to pay attention to integrity, authenticity, and authorization for the static data, as well as the dynamic data.

I though you were suggesting that we pay attention to this issue earlier, when you emphasized the need for a "systems approach" to BGP security. I was trying to accommodate this concern you raised, in a fashion that is still grounded in the BGP spec, even though the means by which the data is made available to AS managers is outside the spec and does not involve the border gateway protocol per se.

Steve
--============_-1107862318==_ma============-- --===============0323618831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0323618831==-- From rpsec-bounces@ietf.org Tue Dec 28 16:47:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05182 for ; Tue, 28 Dec 2004 16:47:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPML-0008OJ-2n for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 16:58:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjP0i-0005wo-SN; Tue, 28 Dec 2004 16:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOjy-0001lD-2h for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:18:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29541 for ; Tue, 28 Dec 2004 16:18:47 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjOux-0006Mg-Ed for rpsec@ietf.org; Tue, 28 Dec 2004 16:30:11 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Dec 2004 16:28:43 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-350.cisco.com [10.82.217.96]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBSLIPn9008008; Tue, 28 Dec 2004 16:18:26 -0500 (EST) Date: Tue, 28 Dec 2004 16:17:46 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 >> A---B---C---D >> >> Suppose A sends an update to B, and this update finally gets to D through >> some process. Now, there are two questions we can ask about this update: >> >> -- Did the update actually traverse the path A/B/C/D? >> >> -- Does the path A/B/C/D actually exist? >> >> I think these are two fundamentally different questions--one is a question >> about non-repudiation, the other about the validity of the information >> contained in the update. I don't know that we should assume answering the >> first question always answers the second question, and even if we did, I >> don't think such an assumption should be buried in the document. > > As I noted elsewhere, NR is not the right security term here, but I > understand the question you are raising. I think the answer is that we do > care about how the Update got to D, at least to some extent. > > There are lots of inter-As links in the Internet, but each AS decides > what traffic is allowed to traverse which links, in a local sense. BGP is > the way that ASes tell one another the subset of path info that they want > to advertise, and for what traffic (based on destination address prefix > matching rules) vs. the much larger set of paths (sequences of links) > that exist, or even paths that exist but are restricted to other sets of > NLRI. > > This says that even if we receive an Update that represents a path that > exists, that does not necessarily imply that the route represented by the > Update has been authorized by the ASes along the path. Moreover, there is > an issue of timeliness, i.e., do these ASes currently authorize > advertisement of this route? You can't know this from the update, anyway, as is shown in draft-white-pathconsiderations, the latest version of which is here: http://www.riw.us/temp/draft-white-pathconsiderations-05.txt Basically, you're assuming that if I receive an update, I'm somehow "authorized" to use the path contained in the update to forward traffic. That plainly isn't true, for two reasons: -- An update contains a block of addresses which may be advertised by someone other than the owner of the block of addresses, and outside the owner's control. -- The traffic may not flow along the AS Path contained in the update, so the concept of being "authorized to use a path" is not applicable in the case of BGP. Now, you'll say this doesn't imply traffic flow, but clearly the paragraph above _does_ imply traffic flow, and policy, rather than securing the routing information in the proper sense. > I'm not saying that one cannot find other ways to verify that all of the > ASes along the path authorize propagation of the route in an Update. But, > I am saying that the simplest model is the one that the BGP spec defines. > if we try to develop another model that promises to yield the same > answer, we will have a much harder job, since we will bneed to > demonstrate that the results are equivalent in all cases. BGP doesn't have the concept you're talking about. The problem should be split into two pieces, at least, and possibly three or four: -- Does the path exist? -- Was the update actually originated by/forwarded along this path (which only applies to some form of non-repudiation, and nothing else)? -- Am I authorized to use this path (outside the set of questions answerable within BGP today)? -- Am I authorized to advertise this route to my peer (covered by many various mechanisms within BGP today, and coverable using many mechanisms within various possible security systems)? Trying to munge all of this into a single requirement simply muddies the problem, and takes away the designer's ability to address them in various ways. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 16:48:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05371 for ; Tue, 28 Dec 2004 16:48:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPNd-0008Qv-Ff for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 16:59:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjP1D-0006tB-AW; Tue, 28 Dec 2004 16:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOqA-0006Ei-7f for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:25:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01211 for ; Tue, 28 Dec 2004 16:25:11 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjP14-0006uk-Ja for rpsec@ietf.org; Tue, 28 Dec 2004 16:36:35 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBSLOPjh016074; Tue, 28 Dec 2004 16:24:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Dec 2004 14:27:17 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Req's Draft, Section 6 (III) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1105357094==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a --===============1105357094== Content-Type: multipart/alternative; boundary="============_-1107853432==_ma============" --============_-1107853432==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" More proposed text revisions and some questions. Same conventions as before re use of bold vs. plain text and use of angle brackets I suspect the first part will trigger our usual debate. Steve ---- 6. Update Verification Update verification refers to the ability of a receiver to determine that a received Update is accurate, in terms of the identities of the ASes in the path attribute, the NLRI contained in the Update, and any other attributes used as inputs for route computation. Update verification entails several subsidiary security requirements that derive from the characteristics a receiver assumes is true of an Update in a non-hostile environment: - the AS listed as the origin originated the Update, and the NLRI in the Update is "owned' by this AS. (need to modify this to take into account address aggregation) - Each AS that appears in the path processed the Update and forwarded the Update to the next AS in the path (modulo any ASes removed from the path due to aggregation). - If a no_export community attribute was included in the Update by an AS along the path, the attribute has not been removed to enable forwarding beyond what was intended by the AS than inserted it. These requirements arise from an analysis of the BGP Update processing algorithm, plus analysis of extensions to BGP defined in later RFCs, specifically re community attribute processing. They allow a speaker receiving an Update to detect unauthorized modification of an Update or generation of a bogus Update. In turn, this can help identify attackers and parties at fault for route table disruption it is important to track and log prefix origination information along with associated security information. Any security system SHOULD provide a method to allow the receiver of an Update to verify the characteristics listed above. 7. Logging Requirements for Security Security systems often primarily rely on preventative measures to detect and reject corrupted data and to enforce access controls. However, it's also important for network operators to be able to track normal BGP operation, and to facilitate recognition of abnormal behavior when it occurs. Towards this end, standardized logging mechanisms SHOULD be proposed for BGP in conjunction with, or in parallel to, any proposed security mechanisms. The data generated by logging at a speaker may be very large depending on the granularity of the data recorded, the number of peers, the rate at which Updates are received, and the routing policies in place. As such, efficient data structures and storage mechanisms MUST be developed to allow for an effective means of reproducing incidents and outages. Path and NLRI attributes MUST be logged using a standard format. The format must be scalable with the amount of data logged and the frequency of log generation. The frequency of log generation SHOULD be controllable by the operator. The logging mechanisms for the tracked information MUST be standardized across all platforms. Logging ability both on and off line is considered highly desirable. --============_-1107853432==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] BGP Req's Draft, Section 6 (III)
More proposed text revisions and some questions. Same conventions as before re use of bold vs. plain text and use of angle brackets

I suspect the first part will trigger our usual debate.

Steve

----
6. Update Verification

Update verification refers to the ability of a receiver to determine that a received Update is accurate, in terms of the identities of the ASes in the path attribute, the NLRI contained in the Update, and any other attributes used as inputs for route computation. Update verification entails several subsidiary security requirements that derive from the characteristics a receiver assumes is true of an Update in a non-hostile environment:
-  the AS listed as the origin originated the Update, and the NLRI in the Update is "owned' by this AS. (need to modify this to take into account address aggregation)
-    Each AS that appears in the path processed the Update and forwarded the Update to the next AS in the path (modulo any ASes removed from the path due to aggregation).
-  If a no_export community attribute was included in the Update by an AS along the path, the attribute has not been removed to enable forwarding beyond what was intended by the AS than inserted it.

These requirements arise from an analysis of the BGP Update processing algorithm, plus analysis of extensions to BGP defined in later RFCs, specifically re community attribute processing. They allow a speaker receiving an Update to detect unauthorized modification of an Update or generation of a bogus Update.  In turn, this can help identify attackers and parties at fault for route table disruption it is important to track and log prefix origination information along with associated security information.

<non-repudiation is not the appropriate security term here. What we are talking about is data origin authentication and connectionless integrity, for staged, multicast communication.>

   Any security system SHOULD provide a method to allow the receiver of an Update to verify the characteristics listed above.

7. Logging Requirements for Security

   Security systems often primarily rely on preventative measures to detect and reject corrupted data and to enforce access controls. However, it's also important for network operators to be able to track normal BGP operation, and to facilitate recognition of abnormal behavior when it occurs. Towards this end, standardized logging mechanisms SHOULD be proposed for BGP in conjunction with, or in parallel to, any proposed security mechanisms.

   The data generated by logging at a speaker may be very large depending on the granularity of the data recorded, the number of peers, the rate at which Updates are received, and the routing policies in place.  As such, efficient data structures and storage mechanisms MUST be developed to allow for an effective  means of reproducing incidents and outages.

<how does the number of routing policies affect the logging data volume? Also, the last sentence seems very detailed and not necessarily appropriate for a requirements document.>

   Path and NLRI attributes MUST be logged using a standard format.  The format must be scalable with the amount of data logged and the frequency of log generation.  The frequency of log generation SHOULD be controllable by the operator.  The logging mechanisms for the tracked information MUST be standardized across all platforms. Logging ability both on and off line is considered highly desirable.

<what does the last sentence mean? Also, "highly desirable" isn't a good phrase for a requirements document.>
--============_-1107853432==_ma============-- --===============1105357094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1105357094==-- From rpsec-bounces@ietf.org Tue Dec 28 16:49:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05429 for ; Tue, 28 Dec 2004 16:49:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPOM-0008TB-HG for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 17:00:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjP1E-0006uI-1f; Tue, 28 Dec 2004 16:36:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOqD-0006FB-GC for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:25:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01217 for ; Tue, 28 Dec 2004 16:25:14 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjP14-0006uj-J7 for rpsec@ietf.org; Tue, 28 Dec 2004 16:36:38 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBSLOPjj016074; Tue, 28 Dec 2004 16:24:29 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Dec 2004 16:24:17 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Draft: Section 2 (II) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0167771061==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 --===============0167771061== Content-Type: multipart/alternative; boundary="============_-1107853429==_ma============" --============_-1107853429==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" More comments and edits, with the usual conventions. Now that I have gone through Russ's comments on the new document, I'll go back to look at the document itself. Sorry for doing this out of order. Steve ------ 2. Deployment Requirements We have determined, through discussion with several large internetwork operators and equipment vendors, that some attributes of BGP are critical to the operation of the Internet and internetworks using BGP to provide routing information. Each section below discusses one of these attributes in detail. 2.2. Incremental Deployment I think there are multiple requirements here that aren't called out in the text very well, and one I'd like to see added, if possible. Something like this: o The public Internet not be able to deploy a newly secured BGP protocol via a "flag day," i.e., not all ASes will transiton to a secured version of BGP simultaneously. and will be unable to dictate a partitioning of large networks by network operators. Because of this, there are several features that any proposed BGP security architecture MUST incorporate: o BGP speakers that implement BGP security features MUST be able to continue to interact with speakers that do not implement the features. Thus they MUST support transmitting, receiving, and acting on both secured and unsecured routing information. o The security system MUST use backward compatible in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible fashion. < the bullet above seems to anticipate the bullet you added below. I question both, not just from the perspective of the technical ability to engineer a solution that meets the requirement, but from the management perspective. The security community has a fair amount of experience in the security arena that shows that folks are very bad at managing security-relevant configuration data. We see this al the time in enterprise contexts, e.g., in terms of an inability of local security managers to secure servers, desktops, laptops, etc. That is one reason why firewalls are so popular, i.e., the provide a simpler, centralized management capability, even though we also see a general inability to manage large firewall rule lists. So, I think it is a bad idea to require that incremental deployment be transitive. My guess is that operators can manage the notion of which neighbors have deployed a security system, just as they do today for the TCP/MD5 checksum. But, to extend this ASes that are not neighbors is asking too much from a management standpoint.> The one I'd like to see added here is this: o In an environment where secure and nonsecured routing information is transmitted, there MUST be some mechanism for a receiver to determine if the originator, or any intervening autonomous system, intended the information to be secured. --============_-1107853429==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] BGP Security Requirements Draft: Section 2 (II
More comments and edits, with the usual conventions.

Now that I have gone through Russ's comments on the new document, I'll go back to look at the document itself.  Sorry for doing this out of order.

Steve
------


2. Deployment Requirements

We have determined, through discussion with several large internetwork operators and equipment vendors, that some attributes of BGP are critical to the operation of the Internet and internetworks using BGP to provide routing information. Each section below discusses one of these attributes in detail.

<the justification provided here is not compelling, as worded. There is no indication whether the operators you spoke with represent the views of most ISPs around the world, just Tier 1 providers in the U.S. or worldwide, etc.>

2.2. Incremental Deployment

I think there are multiple requirements here that aren't called out in the text very well, and one I'd like to see added, if
possible. Something like this:

o The public Internet not be able to deploy a newly secured BGP protocol via a "flag day," i.e., not all ASes will  transiton to a secured version of BGP simultaneously. and will be unable to dictate a partitioning of large networks by network operators.

<the second part of the sentence seemed to be addressing a second order effect of a possible deployment. Is the intent to say that a solution MUST allow incremental deployment on an intra-AS basis, as well as on an inter-AS basis? If so, say it that way. The we can argue over whether this is a reasonable demand :>

Because of this, there are several features that any proposed BGP security architecture MUST incorporate:

o BGP speakers that implement BGP security features MUST be able to continue to interact with speakers that do not implement the features. Thus they MUST support transmitting, receiving, and acting on both secured and unsecured routing information.

<I deleted the next bullet because it was redundant relative to the one above.>

o The security system MUST use backward compatible in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible fashion.

< the bullet above seems to anticipate the bullet you added below. I question both, not just from the perspective of the technical ability to engineer a solution that meets the requirement, but from the management perspective. The security community has a fair amount of experience in the security arena that shows that folks are very bad at managing security-relevant configuration data. We see this al the time in enterprise contexts, e.g., in terms of an inability of local security managers to secure servers, desktops, laptops, etc. That is one reason why firewalls are so popular, i.e., the provide a simpler, centralized management capability, even though we also see a general inability to manage large firewall rule lists. So, I think it is a bad idea to require that incremental deployment be transitive. My guess is that operators can manage the notion of which neighbors have deployed a security system, just as they do today for the TCP/MD5 checksum. But, to extend this ASes that are not neighbors is asking too much from a management standpoint.>

The one I'd like to see added here is this:

o In an environment where secure and nonsecured routing information is transmitted, there MUST be some mechanism for a receiver to determine if the originator, or any intervening autonomous system, intended the information to be secured.

<for the reasons cited above, I would strongly recommend against adding this.>
--============_-1107853429==_ma============-- --===============0167771061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0167771061==-- From rpsec-bounces@ietf.org Tue Dec 28 16:54:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05883 for ; Tue, 28 Dec 2004 16:54:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPTO-0000D1-QC for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 17:05:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPDs-0002pA-Uu; Tue, 28 Dec 2004 16:49:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjP1w-0007Ih-Pe for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:37:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04235 for ; Tue, 28 Dec 2004 16:37:22 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPCw-00082Y-7d for rpsec@ietf.org; Tue, 28 Dec 2004 16:48:46 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 Dec 2004 16:36:54 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-350.cisco.com [10.82.217.96]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBSLaooa011713; Tue, 28 Dec 2004 16:36:50 -0500 (EST) Date: Tue, 28 Dec 2004 16:36:11 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac >> -- First, prove BGP cares that the path contained in an update is the path >> the update actually took. It's well known that the update path is >> manipulated for many legitimate reasons today. > > I have assumed that we want to generate requirements based on what BGP > says is correct operation. I believe that BGP specifies the circumstances > under which a speaker is to emit an Update, either as a side effect of > processing a inbound Update or due to detection of loss of connectivity. > That suggests that our requirements should try to capture this notion. > > If, as you suggest, we do not verify that an Update has traversed the > path indicated by the path attribute (modulo aggregation) then BGP is > susceptible to attacks that advertise bogus path. What you seem to be > arguing is that if a speaker advertises a path that is not currently > being advertised by the preceding ASes list in the path, but one that > could legitimately be advertised based on local policy configurations in > those ASes, then that is OK. > > I challenge you to show me where the BGP spec includes this notion! We are clearly talking past each other. You are saying: "This is the way BGP works, what BGP assumes." But, you're pushing into BGP the concept of "authorization," which is a matter of policy, and isn't part of BGP. Beyond this, you say "modulo aggregation." That's a hole in the scheme large enough to drive a truck through, honestly. Yes, I am implying that if a speaker advertises a route that doesn't exist, for policy reasons, it is "okay." For instance, a rather mild example is as path prepend. This clearly creates a path that does not exist within the update, and it is "okay." Another for instance--placing a third party AS in the AS set when I advertise updates to a peer, to block those routes from being readvertised through BGP's loop detection mechanism. Again, there is a path that doesn't exist in the update, and it's used on a periodic basis in the real world. Even the case of aggregation proves the point--the path in the aggregated route does not exist, for at least some of the reachable destinations within the aggregate. For instance, 10.1.0.0/16 may be advertised with a path of {1, 2}, but in reality, the path to 10.1.1.0/24 is {1, 2, 3}. Thus, 10.1.1.0/24 is not reachable through the path {1, 2}, and yet BGP lives with this, somehow. So, yet another case in common use where the as path doesn't match the real as path used to reach the destinations within the update. >> I don't see any reason to include language of this type--pushing concepts >> into BGP that don't exist in the protocol itself, and pushing the focus >> onto a subsidiary point, while ignoring the larger point. > > As expected, we disagree. I think what I have said is directly derived > from the description of BGP processing. In contrast, what you are > advocating is a wording that seems to be designed to accommodate soBGP's > notion of validity based on statically configured policy data. Can you show me the point in the BGP drafts that describe this as the only way a BGP update can be processed? When I examine the definition of the AS Path, I find this: "AS_PATH is a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple ." I don't see anything in there about: "the AS Path MUST represent the autonomous systems through which this update has passed." Can you find the language to support your assertion? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 16:57:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06009 for ; Tue, 28 Dec 2004 16:57:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPWO-0000HV-AM for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 17:08:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPES-00031l-Ni; Tue, 28 Dec 2004 16:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjP4S-0007kT-KC for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:40:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04424 for ; Tue, 28 Dec 2004 16:39:57 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPFS-000859-6u for rpsec@ietf.org; Tue, 28 Dec 2004 16:51:22 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 Dec 2004 16:39:30 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-350.cisco.com [10.82.217.96]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBSLdRoa012751; Tue, 28 Dec 2004 16:39:27 -0500 (EST) Date: Tue, 28 Dec 2004 16:38:48 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] BGP Req's Draft, Section 6 (III) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > 6. Update Verification > > Update verification refers to the ability of a receiver to determine that a > received Update is accurate, in terms of the identities of the ASes in the > path attribute, the NLRI contained in the Update, and any other attributes > used as inputs for route computation. Update verification entails several > subsidiary security requirements that derive from the characteristics a > receiver assumes is true of an Update in a non-hostile environment: > - the AS listed as the origin originated the Update, and the NLRI in > the Update is "owned' by this AS. (need to modify this to take into account > address aggregation) With aggregation, this sort of verification simply isn't possible. Aggregation is the exception that proves the entire concept wrong, IMHO. > - Each AS that appears in the path processed the Update and forwarded > the Update to the next AS in the path (modulo any ASes removed from the path > due to aggregation). You can't prove this, so it's impossible to make it a requirement. > - If a no_export community attribute was included in the Update by an > AS along the path, the attribute has not been removed to enable forwarding > beyond what was intended by the AS than inserted it. I don't see how you can prove this one.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 16:59:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06160 for ; Tue, 28 Dec 2004 16:59:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPYH-0000LS-ST for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 17:10:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPGt-0003aM-44; Tue, 28 Dec 2004 16:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjP8V-0000ra-Vb for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:44:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04724 for ; Tue, 28 Dec 2004 16:44:09 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPJV-0008CU-D7 for rpsec@ietf.org; Tue, 28 Dec 2004 16:55:33 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Dec 2004 16:53:56 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-350.cisco.com [10.82.217.96]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBSLhcoa014839; Tue, 28 Dec 2004 16:43:38 -0500 (EST) Date: Tue, 28 Dec 2004 16:42:59 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Draft: Section 2 (II) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a > We have determined, through discussion with several large internetwork > operators and equipment vendors, that some attributes of BGP are critical > to the operation of the Internet and internetworks using BGP to provide > routing information. Each section below discusses one of these attributes > in detail. > > no indication whether the operators you spoke with represent the views of > most ISPs around the world, just Tier 1 providers in the U.S. or > worldwide, etc.> These appear to be self-evident, to me.... > o The security system MUST use backward compatible in the message formatting, > transmission, and processing of routing information carried through a mixed > security environment. Message formatting in a fully secured environment MAY > be handled in a non-backward compatible fashion. > > < the bullet above seems to anticipate the bullet you added below. I > question both, not just from the perspective of the technical ability to > engineer a solution that meets the requirement, but from the management > perspective. The security community has a fair amount of experience in > the security arena that shows that folks are very bad at managing > security-relevant configuration data. We see this al the time in > enterprise contexts, e.g., in terms of an inability of local security > managers to secure servers, desktops, laptops, etc. That is one reason > why firewalls are so popular, i.e., the provide a simpler, centralized > management capability, even though we also see a general inability to > manage large firewall rule lists. So, I think it is a bad idea to require > that incremental deployment be transitive. My guess is that operators can > manage the notion of which neighbors have deployed a security system, > just as they do today for the TCP/MD5 checksum. But, to extend this ASes > that are not neighbors is asking too much from a management standpoint.> > > The one I'd like to see added here is this: > > o In an environment where secure and nonsecured routing information is > transmitted, there MUST be some mechanism for a receiver to determine if the > originator, or any intervening autonomous system, intended the information to > be secured. > > this.> I don't see how you can, realistically, not require transitive incremental deployment in any security system to be deployed. Anything currently being deployed in BGP requires transitive incremental deployment. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 17:15:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07815 for ; Tue, 28 Dec 2004 17:15:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPny-0000nj-Hd for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 17:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPOO-0006KW-FL; Tue, 28 Dec 2004 17:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPKY-0004b8-20 for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 16:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05970 for ; Tue, 28 Dec 2004 16:56:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjPVX-0000GL-Oz for rpsec@ietf.org; Tue, 28 Dec 2004 17:08:00 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Dec 2004 17:06:22 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-350.cisco.com [10.82.217.96]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBSLu4oa018279; Tue, 28 Dec 2004 16:56:04 -0500 (EST) Date: Tue, 28 Dec 2004 16:55:23 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > As expected, we disagree. I think what I have said is directly derived > from the description of BGP processing. In contrast, what you are > advocating is a wording that seems to be designed to accommodate soBGP's > notion of validity based on statically configured policy data. And actually, I would point out something here: -- You are implying in the paragraph above that you would prefer to see a set of requirements that will not accomidate anything except S-BGP. -- The wording I've suggested will allow soBGP, S-BGP, IRV, and SPV to meet them, I think. I don't think I'm trying to sway the process in any direction, I'm trying to get at the real requirements, and break them down into their component parts, so I can understand them, and help others understand them. I'm not working from "this is the best set of requirements for soBGP," I'm working from: "What is it we can really do and what are our materials at hand?" It's not helpful to make your only requirement: "To secure BGP as BGP is described in the BGP drafts." That leaves out two rather large pieces of the puzzle--how BGP is implemented, and how BGP is actually used. I don't think we should leave those concepts out of the mix. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 17:43:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09804 for ; Tue, 28 Dec 2004 17:43:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQEg-0001Wx-Ae for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 17:54:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjQ08-0005YN-7Y; Tue, 28 Dec 2004 17:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPqO-0003lE-3A for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 17:29:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09039 for ; Tue, 28 Dec 2004 17:29:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQ1N-0001CA-Ux for rpsec@ietf.org; Tue, 28 Dec 2004 17:40:54 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBSMSljh018256; Tue, 28 Dec 2004 17:28:49 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Dec 2004 16:52:07 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f At 4:17 PM -0500 12/28/04, Russ White wrote: >>>A---B---C---D >>> >>>Suppose A sends an update to B, and this update finally gets to D >>>through some process. Now, there are two questions we can ask >>>about this update: >>> >>>-- Did the update actually traverse the path A/B/C/D? >>> >>>-- Does the path A/B/C/D actually exist? >>> >>>I think these are two fundamentally different questions--one is a >>>question about non-repudiation, the other about the validity of >>>the information contained in the update. I don't know that we >>>should assume answering the first question always answers the >>>second question, and even if we did, I don't think such an >>>assumption should be buried in the document. >> >>As I noted elsewhere, NR is not the right security term here, but I >>understand the question you are raising. I think the answer is that >>we do care about how the Update got to D, at least to some extent. >> >>There are lots of inter-As links in the Internet, but each AS >>decides what traffic is allowed to traverse which links, in a local >>sense. BGP is the way that ASes tell one another the subset of path >>info that they want to advertise, and for what traffic (based on >>destination address prefix matching rules) vs. the much larger set >>of paths (sequences of links) that exist, or even paths that exist >>but are restricted to other sets of NLRI. >> >>This says that even if we receive an Update that represents a path >>that exists, that does not necessarily imply that the route >>represented by the Update has been authorized by the ASes along the >>path. Moreover, there is an issue of timeliness, i.e., do these >>ASes currently authorize advertisement of this route? > >You can't know this from the update, anyway, as is shown in >draft-white-pathconsiderations, the latest version of which is here: > >http://www.riw.us/temp/draft-white-pathconsiderations-05.txt Thanks for the pointer. >Basically, you're assuming that if I receive an update, I'm somehow >"authorized" to use the path contained in the update to forward >traffic. That plainly isn't true, for two reasons: If AS 1 advertises a route to AS 2, I interpret that as an authorization for AS 2 to send traffic for the indicated prefix(es) to AS 1. Do you disagree? If so, then what do you maintain is the reason that AS 1 advertises a route to AS 2? >-- An update contains a block of addresses which may be advertised >by someone other than the owner of the block of addresses, and >outside the owner's control. Do you mean to say that correct BGP behavior allows an a speaker to originate a prefix when the AS in which the speaker operates is not the owner of the prefix nor has the owner authorized the advertisement in any fashion? Or do you mean to say that correct BGP behavior allows any AS to add arbitrary prefixes to an Update? >-- The traffic may not flow along the AS Path contained in the >update, so the concept of being "authorized to use a path" is not >applicable in the case of BGP. I think we all understand that there is a difference between forwarding and routing and thus propagation of a route does not ensure that traffic will flow over that route. However, the purpose of advertising a route to a neighbor is to make the neighbor aware that the advertiser is willing to accept traffic for the indicated prefixes, and that if such traffic is sent to the advertiser, then the traffic will be forwarded to the the indicated origin AS. That's what I believe is true, and your comment above in now way relates to the notion of >Now, you'll say this doesn't imply traffic flow, but clearly the >paragraph above _does_ imply traffic flow, and policy, rather than >securing the routing information in the proper sense. I have no idea what the sentence above means. >>I'm not saying that one cannot find other ways to verify that all >>of the ASes along the path authorize propagation of the route in an >>Update. But, I am saying that the simplest model is the one that >>the BGP spec defines. if we try to develop another model that >>promises to yield the same answer, we will have a much harder job, >>since we will bneed to demonstrate that the results are equivalent >>in all cases. > >BGP doesn't have the concept you're talking about. The problem >should be split into two pieces, at least, and possibly three or >four: > >-- Does the path exist? You still have not answered the question of what you mean by a path "existing." If you mean there are communication links between ASes, then say so. If you mean that there is local policy in each along the path that states that traffic for an indicated prefix will be forwarded to the origin AS if received from the indicated neighbor, say so. If you mean something else, say so. >-- Was the update actually originated by/forwarded along this path > (which only applies to some form of non-repudiation, and nothing else)? As I have said several times, apparently to no avail, this is not NR. But yes, I agree that this is a separable question from the bullet immediately above. >-- Am I authorized to use this path (outside the set of questions > answerable within BGP today)? I don't know what you are trying to say here. >-- Am I authorized to advertise this route to my peer (covered by many > various mechanisms within BGP today, and coverable using many > mechanisms within various possible security systems)? yes, an important part of routing. >Trying to munge all of this into a single requirement simply muddies >the problem, and takes away the designer's ability to address them >in various ways. the issue is not whether one can identify these as distinct questions that can be asked about a path or a route. The question we are addressing is what does BGP say about paths and routes, does IT ask these questions, and does it make the distinctions you have made above, when the BGP route computation algorithm is executed? It has been suggested that maybe we should not just try to secure BGP as it exists, but rather consider what changes could be made to BGP to make it better, and then secure the result. That might be a good suggestion, but it is not consistent with the WG charter, or with the description of the requirements document that we are working on now. That's why I note that the questions we need to ask must be framed in the context of the protocol we have and how it is defined to work. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Dec 28 18:25:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13567 for ; Tue, 28 Dec 2004 18:25:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQu3-0002XC-AS for rpsec-web-archive@ietf.org; Tue, 28 Dec 2004 18:37:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjQgn-0006rU-Cq; Tue, 28 Dec 2004 18:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjQcj-0005Me-TM for rpsec@megatron.ietf.org; Tue, 28 Dec 2004 18:19:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13139 for ; Tue, 28 Dec 2004 18:19:26 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQnj-0002Ne-Ug for rpsec@ietf.org; Tue, 28 Dec 2004 18:30:52 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Dec 2004 15:25:37 -0800 Received: from russpc.Whitehouse.intra (rtp-vpn3-149.cisco.com [10.82.216.149]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBSNIplP015196; Tue, 28 Dec 2004 15:18:52 -0800 (PST) Date: Tue, 28 Dec 2004 18:18:07 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b >> Basically, you're assuming that if I receive an update, I'm somehow >> "authorized" to use the path contained in the update to forward traffic. >> That plainly isn't true, for two reasons: > > If AS 1 advertises a route to AS 2, I interpret that as an authorization > for AS 2 to send traffic for the indicated prefix(es) to AS 1. Do you > disagree? If so, then what do you maintain is the reason that AS 1 > advertises a route to AS 2? See the second example, section 2.3, in the draft I pointed out above. This is clearly not true, because of the ambiguities in address ownership and aggregation. > Do you mean to say that correct BGP behavior allows an a speaker to > originate a prefix when the AS in which the speaker operates is not the > owner of the prefix nor has the owner authorized the advertisement in any > fashion? Can you explain what you mean by "owner" here? The AS authorized to advertise the prefix, or the AS authorized to advertise a superset of that same address space (the aggregate)? If I "own" 10.1.0.0/16, and I assign 10.1.1.0/24 to some other AS, may I still advertise 10.1.0.0/16? Or, must I break up the /16, and advertise 254 /24's, now that I've given one of the address blocks within the /16 away? If you think about the answers to these questions, you'll see why you cannot make the assumption you're making above. > I think we all understand that there is a difference between forwarding > and routing and thus propagation of a route does not ensure that traffic > will flow over that route. However, the purpose of advertising a route to > a neighbor is to make the neighbor aware that the advertiser is willing > to accept traffic for the indicated prefixes, and that if such traffic is > sent to the advertiser, then the traffic will be forwarded to the the > indicated origin AS. That's what I believe is true, and your comment > above in now way relates to the notion of That's specifically what's not true in a real routing system. Again, if I advertise 10.1.0.0/16 with a path of {1, 2}, I'm implying that traffic destined to 10.1.1.1 will "terminate" in AS 2. In fact, it may terminate three or four or more AS hops away, there's no way to tell at all where that traffic is going to terminate. The advertisement 10.1.0.0/16 {1, 2} actually implies AS 1 has a path to 10.1.0.0/16 it learned from AS 2. It does not imply that AS 1 will use this path to forward traffic, nor does it imply that AS 2 has agreed to transit traffic to every possible destination within 10.1.0.0/16. > You still have not answered the question of what you mean by a path > "existing." If you mean there are communication links between ASes, then > say so. If you mean that there is local policy in each along the path > that states that traffic for an indicated prefix will be forwarded to the > origin AS if received from the indicated neighbor, say so. If you mean > something else, say so. I mean a logical path exists that corresponds to the as path listed in the update. You cannot prove or imply policy along that path. >> -- Was the update actually originated by/forwarded along this path >> (which only applies to some form of non-repudiation, and nothing else)? > > As I have said several times, apparently to no avail, this is not NR. But > yes, I agree that this is a separable question from the bullet > immediately above. Which is why I said "something like non-repudiation," since I don't know of a better term to use in this context. But, I think we understand what we are talking about, even if I'm using the wrong term to describe it. :-) >> -- Am I authorized to use this path (outside the set of questions >> answerable within BGP today)? > > I don't know what you are trying to say here. Exactly what it asks. Given the update 10.1.0.0/16 {1, 2}, am I authorized to transmit traffic to the advertising peer (presumably in AS 1) towards the destination 10.1.1.1? I contend you simply cannot know the answer to that question. Given that same update, can I know that traffic will follow the AS Path in the update to reach 10.1.1.1? I cannot know the answer to that question, either. >> Trying to munge all of this into a single requirement simply muddies the >> problem, and takes away the designer's ability to address them in >> various ways. > > the issue is not whether one can identify these as distinct questions > that can be asked about a path or a route. The question we are addressing > is what does BGP say about paths and routes, does IT ask these questions, > and does it make the distinctions you have made above, when the BGP route > computation algorithm is executed? Then you would restrict the available solutions to only those that secure BGP as a bag of bits, rather than asking what it is that BGP is trying to express, and securing the database as a database. Again, I think the correct questions we should ask when writing the requirements are: -- Can I prove a path exists? -- Can I prove I'm authorized to use the path? (This question, in a sense, is a superset of the question: does every AS along the path have policies set so they will pass traffic I forward along this path to every possible destination within in the address block carried in the update). -- Can I prove traffic I forward along this path will actually use it? If I can't prove one of these questions is answerable, then it makes no sense to build a requirement for a given security system to prove them, right? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 07:28:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03747 for ; Wed, 29 Dec 2004 07:28:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjd7g-00057l-1Q for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 07:40:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjcqB-0000ea-GN; Wed, 29 Dec 2004 07:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjcpD-0000C0-Sg for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 07:21:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03259 for ; Wed, 29 Dec 2004 07:21:10 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjd0A-0004wX-Bj for rpsec@ietf.org; Wed, 29 Dec 2004 07:32:41 -0500 Received: from [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e] (alumange.muada.com [IPv6:3ffe:2500:310:3:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iBTCKUW2035397 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Dec 2004 13:20:31 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0E247C8A-5994-11D9-BFE9-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] BGP Security Requirements Document Date: Wed, 29 Dec 2004 13:20:41 +0100 To: Stephen Kent X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Steve, On 28-dec-04, at 17:54, Stephen Kent wrote: >> However, you pose a very interesting question. It sure looks like a >> lot of people are assuming the following addressing hierarchy: >> ICANN -> RIRs -> origin AS > Not sure exactly what you are referring to here. Russ is concerned with the situation where it's like: ICANN -> RIRs -> ISP -> origin AS If this is just the allocation chain, that's not a problem, but if the ISP also sources an aggregate that covers the prefix sourced by "origin AS" things get complicated. > In the papers we've written on BGP security, we do describe an address > allocation hierarchy that is rooted at ICANN and that goes through > RIRs to ISPs (or subscribers), etc. We also note that some > subscribers get allocations directly from an RIR. Do you think that > this is an inaccurate model for allocation? Not necessarily "inaccurate", but things can be a bit more complex in the real world. The only thing we know for sure is that there is always ICANN/IANA at one end and the origin AS at the other end. There is a RIR involved most of the time. Then there are NIR (national internet registries, mostly in the APNIC region) and LIRs (=== ISPs) which are both optional. There is also a distinction between the address holder (not owner, as addresses can't be owned as per RIR policy) and the origin AS. For instance, an organization with portable address space may have it announced by the ISP du jour, or the address holder can lend the address space to another organization that then announces it without actually transferring the address space. >> All of this begs the question: if we're going to rebuild so many >> parts of BGP, wouldn't it make more sense to start with a clean >> slate? It would be great if we could separate the authenticity and >> authorization issues from the reachability issues. This would >> increase performance and decrease complexity. > I'm not sure what you mean by this last paragraph. When we approached > BGP security we did so cognizant of the limitations of the extant > protocol. We started from the premise of what a speaker assumes is > true when it gets an Update, and then worked from that basis to > determine what the security requirements were, and then proposed > mechanisms to satisfy those requirements. In other words, you added jet engines to the pig. :-) > Anothr way of saying this, that I think we should articulate in the > document (if there is agreement) is that main purpose of BGP security > should be to enable speakers to verify Updates, because speakers make > routing (reachability) decisions based on a combination of dynamic > info from Updates and static config data. That suggests a two-pronged > approach, one that provides a speaker with data to verify the dynamic > aspects of an Update, and one that supports distribution of (static) > data to support verification of the less dynamic aspects of an Update. The way I see it, there are four topologies, each a subset of the previous one: - the logical topology determined by the way BGP speakers are interconnected - the topology that's allowed by policy - the topology for which authorization can be verified successfully - the actually reachable topology I would be much happier if we had mechanisms other than the update message to build topology maps for the first three. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 10:46:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18970 for ; Wed, 29 Dec 2004 10:46:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgD1-0001qn-Cv for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 10:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjg02-000251-8y; Wed, 29 Dec 2004 10:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjfs1-0000OZ-9V for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 10:36:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18040 for ; Wed, 29 Dec 2004 10:36:14 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjg3A-0001aZ-1E for rpsec@ietf.org; Wed, 29 Dec 2004 10:47:48 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBTFZcjl013232; Wed, 29 Dec 2004 10:35:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 29 Dec 2004 10:17:23 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 At 4:55 PM -0500 12/28/04, Russ White wrote: >>As expected, we disagree. I think what I have said is directly >>derived from the description of BGP processing. In contrast, what >>you are advocating is a wording that seems to be designed to >>accommodate soBGP's notion of validity based on statically >>configured policy data. > >And actually, I would point out something here: > >-- You are implying in the paragraph above that you would prefer to >see a set of requirements that will not accomidate anything except >S-BGP. That's your interpretation of my comments, which leaves a lot to be desired in terms of accuracy. >-- The wording I've suggested will allow soBGP, S-BGP, IRV, and SPV >to meet them, I think. In contrast, what I see in your wording is explicitly designed to accommodate only soBGP! >I don't think I'm trying to sway the process in any direction, I'm >trying to get at the real requirements, and break them down into >their component parts, so I can understand them, and help others >understand them. I'm not working from "this is the best set of >requirements for soBGP," I'm working from: "What is it we can really >do and what are our materials at hand?" From my perspective, this is not evident in your choice of words in proposed text. You continually create terms that are thinly veiled references to the soBGP notion of a database that contains all "valid" routes or all paths that "exist", and say that this should be the criteria by which we judge whether an Update is valid. There are no notions of this sort in BGP, only in soBGP. >It's not helpful to make your only requirement: "To secure BGP as >BGP is described in the BGP drafts." That leaves out two rather >large pieces of the puzzle--how BGP is implemented, and how BGP is >actually used. I don't think we should leave those concepts out of >the mix. > If BGP is implemented in a fashion that is not consistent with the RFCs, then the implementations are not conformant, and the IESG should not have approved BGP4 as a full standard. So I'm sure you don't mean to imply that, do you Russ? When you suggest that we have to accommodate how BGP is "actually" used, we may be heading down a slippery slope, where abuses of the protocol, that create security problems, are codified as features, making it impossible to adopt engineering solutions to counter attacks that take advantage of such features. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 10:47:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19156 for ; Wed, 29 Dec 2004 10:47:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgET-0001tK-DC for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 10:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjg03-000256-6L; Wed, 29 Dec 2004 10:44:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjfs1-0000Oa-9U for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 10:36:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18038 for ; Wed, 29 Dec 2004 10:36:14 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjg39-0001aX-Qh for rpsec@ietf.org; Wed, 29 Dec 2004 10:47:48 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBTFZcjj013232; Wed, 29 Dec 2004 10:35:41 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 29 Dec 2004 10:07:12 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Draft: Section 2 (II) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 At 4:42 PM -0500 12/28/04, Russ White wrote: >>We have determined, through discussion with several large >>internetwork operators and equipment vendors, that some attributes >>of BGP are critical to the operation of the Internet and >>internetworks using BGP to provide routing information. Each >>section below discusses one of these attributes in detail. >> >>>There is no indication whether the operators you spoke with >>represent the views of most ISPs around the world, just Tier 1 >>providers in the U.S. or worldwide, etc.> > >These appear to be self-evident, to me.... if it's self evident, then what is the answer? I made it a multiple choice question, so it's not that hard :-). > >>o The security system MUST use backward compatible in the message >>formatting, transmission, and processing of routing information >>carried through a mixed security environment. Message formatting in >>a fully secured environment MAY be handled in a non-backward >>compatible fashion. >> >>< the bullet above seems to anticipate the bullet you added below. >>I question both, not just from the perspective of the technical >>ability to engineer a solution that meets the requirement, but from >>the management perspective. The security community has a fair >>amount of experience in the security arena that shows that folks >>are very bad at managing security-relevant configuration data. We >>see this al the time in enterprise contexts, e.g., in terms of an >>inability of local security managers to secure servers, desktops, >>laptops, etc. That is one reason why firewalls are so popular, >>i.e., the provide a simpler, centralized management capability, >>even though we also see a general inability to manage large >>firewall rule lists. So, I think it is a bad idea to require that >>incremental deployment be transitive. My guess is that operators >>can manage the notion of which neighbors have deployed a security >>system, just as they do today for the TCP/MD5 checksum. But, to >>extend this ASes that are not neighbors is asking too much from a >>management standpoint.> >> >>The one I'd like to see added here is this: >> >>o In an environment where secure and nonsecured routing information >>is transmitted, there MUST be some mechanism for a receiver to >>determine if the originator, or any intervening autonomous system, >>intended the information to be secured. >> >>>adding this.> > >I don't see how you can, realistically, not require transitive >incremental deployment in any security system to be deployed. >Anything currently being deployed in BGP requires transitive >incremental deployment. Maybe I don't understand what you mean by "transitive incremental deployment." What I said was that it makes sense to deploy BGP security in adjacent ASes, incrementally, which seems to be what is done today for other, new BGP features. Requiring that two non-adjacent ASes that have deployed BGP security features be able to take advantage of these features imposes a significant management burden that will likely lead to management-induced security problems. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 10:58:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19776 for ; Wed, 29 Dec 2004 10:58:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgOL-00028k-BF for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 11:09:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjg04-00025B-IE; Wed, 29 Dec 2004 10:44:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjfsC-0000Od-Nb for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 10:36:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18050 for ; Wed, 29 Dec 2004 10:36:26 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjg3L-0001aT-P9 for rpsec@ietf.org; Wed, 29 Dec 2004 10:48:00 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBTFZcjf013232; Wed, 29 Dec 2004 10:35:38 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 29 Dec 2004 09:47:26 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 At 4:36 PM -0500 12/28/04, Russ White wrote: >>>-- First, prove BGP cares that the path contained in an update is >>>the path the update actually took. It's well known that the update >>>path is manipulated for many legitimate reasons today. >> >>I have assumed that we want to generate requirements based on what >>BGP says is correct operation. I believe that BGP specifies the >>circumstances under which a speaker is to emit an Update, either as >>a side effect of processing a inbound Update or due to detection of >>loss of connectivity. That suggests that our requirements should >>try to capture this notion. >> >>If, as you suggest, we do not verify that an Update has traversed >>the path indicated by the path attribute (modulo aggregation) then >>BGP is susceptible to attacks that advertise bogus path. What you >>seem to be arguing is that if a speaker advertises a path that is >>not currently being advertised by the preceding ASes list in the >>path, but one that could legitimately be advertised based on local >>policy configurations in those ASes, then that is OK. >> >>I challenge you to show me where the BGP spec includes this notion! > >We are clearly talking past each other. You are saying: "This is the >way BGP works, what BGP assumes." But, you're pushing into BGP the >concept of "authorization," which is a matter of policy, and isn't >part of BGP. Beyond this, you say "modulo aggregation." That's a >hole in the scheme large enough to drive a truck through, honestly. BGP is a policy-driven system, Russ. The whole point of local policy databases is to enable an AS to impose its local policies on the route determination process, to down select from all the paths that physically exist, to the subset that each AS wants to advertise to other ASes. I'm sorry that you have an aversion to the word 'authorization" but it is implicit in the design of BGP. I say "modulo aggregation" not because I think we can ignore aggregation, but because it is easier to make concise statements about correct operation if one first omits aggregation. We certainly need to include it in the requirements and in solutions, but it's good practice to deal with the common, simple cases first, the move on to the harder ones. >Yes, I am implying that if a speaker advertises a route that doesn't >exist, for policy reasons, it is "okay." For instance, a rather mild >example is as path prepend. This clearly creates a path that does >not exist within the update, and it is "okay." Another for >instance--placing a third party AS in the AS set when I advertise >updates to a peer, to block those routes from being readvertised >through BGP's loop detection mechanism. Again, there is a path that >doesn't exist in the update, and it's used on a periodic basis in >the real world. When an AS adds itself into a path multiple times, that is not a violation of the simple rule I was trying to express, since the AS in question is one through which the Update did travel. It does seem to violate your characterization of BGP looking to find "loop free" paths, as a literal interpretation of the multiple instances of the AS in the path makes it a loop! I have more trouble with your second example. Just because people exploit this aspect of the BGP algorithm to achieve a goal, does not make it valid. after all, spammers also use the lack of security in BGP to steal unused address blocks for brief periods and that meets their "operational requirements" but I hope we don't plan to make this a requirement. >Even the case of aggregation proves the point--the path in the >aggregated route does not exist, for at least some of the reachable >destinations within the aggregate. For instance, 10.1.0.0/16 may be >advertised with a path of {1, 2}, but in reality, the path to >10.1.1.0/24 is {1, 2, 3}. Thus, 10.1.1.0/24 is not reachable through >the path {1, 2}, and yet BGP lives with this, somehow. So, yet >another case in common use where the as path doesn't match the real >as path used to reach the destinations within the update. There is no question that, when legitimate aggregation occurs, the path contained in the Update no longer contains all of the ASes that were present prior to aggregation. So, yes, it is accurate to say that the path seen by ASes past the aggregation point omits some of the ASes that were in the path prior to aggregation. But your claim that this proves your point that the aggregated path does not exist, is not true. > >>>I don't see any reason to include language of this type--pushing >>>concepts into BGP that don't exist in the protocol itself, and >>>pushing the focus onto a subsidiary point, while ignoring the >>>larger point. >> >>As expected, we disagree. I think what I have said is directly >>derived from the description of BGP processing. In contrast, what >>you are advocating is a wording that seems to be designed to >>accommodate soBGP's notion of validity based on statically >>configured policy data. > >Can you show me the point in the BGP drafts that describe this as >the only way a BGP update can be processed? When I examine the >definition of the AS Path, I find this: > >"AS_PATH is a well-known mandatory attribute that is composed of a >sequence of AS path segments. Each AS path segment is represented by >a triple value>." > >I don't see anything in there about: "the AS Path MUST represent the >autonomous systems through which this update has passed." Can you >find the language to support your assertion? Look beyond the definition of the path attribute, to the definition of Update processing and route computation. That defines how Updates pass through ASes, and thus, transitively. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 11:07:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20331 for ; Wed, 29 Dec 2004 11:07:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgXS-0002LB-4C for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 11:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjgIS-0005om-F1; Wed, 29 Dec 2004 11:03:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjg8i-0003Ti-Al for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 10:53:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19435 for ; Wed, 29 Dec 2004 10:53:30 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgJq-000217-KR for rpsec@ietf.org; Wed, 29 Dec 2004 11:05:03 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Dec 2004 10:53:01 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-396.cisco.com [10.82.217.142]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBTFqvMF021961; Wed, 29 Dec 2004 10:52:58 -0500 (EST) Date: Wed, 29 Dec 2004 10:52:18 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c >> We are clearly talking past each other. You are saying: "This is the way >> BGP works, what BGP assumes." But, you're pushing into BGP the concept >> of "authorization," which is a matter of policy, and isn't part of BGP. >> Beyond this, you say "modulo aggregation." That's a hole in the scheme >> large enough to drive a truck through, honestly. > > BGP is a policy-driven system, Russ. The whole point of local policy > databases is to enable an AS to impose its local policies on the route > determination process, to down select from all the paths that physically > exist, to the subset that each AS wants to advertise to other ASes. I'm > sorry that you have an aversion to the word 'authorization" but it is > implicit in the design of BGP. Again, we are clearly talking past each other. You're trying to secure the BGP update as a bag of bits. I'm saying to look beyond that bag of bits, and see what's in there. It doesn't matter if I've securely transmitted a bag of bits from point a to point b, with all the things in that bag intact. BGP doesn't operate that way. BGP operates on routing information. Secure the routing information, not the process used to transmit the routing information. > I say "modulo aggregation" not because I think we can ignore aggregation, > but because it is easier to make concise statements about correct > operation if one first omits aggregation. We certainly need to include it > in the requirements and in solutions, but it's good practice to deal with > the common, simple cases first, the move on to the harder ones. Aggregation is the common case. Aggregation is more common than non-aggregation in the real world. You're subsituting "common" for "simple." Yes, it's simpler to secure BGP without aggregation, but if aggregation then proves the mechanism you've used to secure BGP untrue, or makes certain claims non-provable, then you need to start with aggregation, and work from there. > There is no question that, when legitimate aggregation occurs, the path > contained in the Update no longer contains all of the ASes that were > present prior to aggregation. So, yes, it is accurate to say that the > path seen by ASes past the aggregation point omits some of the ASes that > were in the path prior to aggregation. But your claim that this proves > your point that the aggregated path does not exist, is not true. *sigh* Steve, when I send routing information, I'm not sending an update. I'm sending a prefix and a set of attributes. BGP will unbundle these, and send them, in a possibly different form, to a set of peers. You're applying security to the wrong part of the process. I don't see any way to solve this argument. You will always treat BGP as a bag of bits, and I will always look beyond the bag of bits at how routing works, in the real world. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 11:08:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20379 for ; Wed, 29 Dec 2004 11:08:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgXx-0002Lu-OL for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 11:19:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjgIq-0005xY-6D; Wed, 29 Dec 2004 11:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjgF8-00043K-HI for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 11:00:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19922 for ; Wed, 29 Dec 2004 11:00:08 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjgQG-0002Ab-PO for rpsec@ietf.org; Wed, 29 Dec 2004 11:11:42 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 29 Dec 2004 10:59:38 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-396.cisco.com [10.82.217.142]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBTFxZVB009402; Wed, 29 Dec 2004 10:59:36 -0500 (EST) Date: Wed, 29 Dec 2004 10:58:56 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 >> -- The wording I've suggested will allow soBGP, S-BGP, IRV, and SPV to >> meet them, I think. > > In contrast, what I see in your wording is explicitly designed to > accommodate only soBGP! In other words, you believe that S-BGP doesn't prove the things I've suggested as requirements? What I believe is this: The requirements, as I've suggested them, and as the current draft reads, can be met by S-BGP, IRV, SPV, and, by chance, soBGP, as well. You're claim is that you can get "more security" than what's in the current draft, and in my wording. My counter to this is your claim for "more security" falls apart when you consider the way routing really works, including aggregation. Your counter claim is that aggregation doesn't matter--secure the process, not the data, because, magically, securing the process always secures the data. I know which I prefer--secure the data, not the process. Secure the data with the reality of aggregation in mind, with the way the protocol is implemented and deployed as fundamental assumptions. The wordings I've suggested allow any security system proposed to claim "more security in specific case x," and it also leaves the community free to evaluate that claim of "more security" in light of the real world. I believe this is an acceptable compromise position, in the long run, and the only way these drafts will move forward. Would you like to move forward, or stay in the same argument for the rest of forever? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Dec 29 15:36:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08940 for ; Wed, 29 Dec 2004 15:36:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjkjk-000886-Em for rpsec-web-archive@ietf.org; Wed, 29 Dec 2004 15:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjkUN-0004zw-3A; Wed, 29 Dec 2004 15:32:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjkSv-00042A-Ls for rpsec@megatron.ietf.org; Wed, 29 Dec 2004 15:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08625 for ; Wed, 29 Dec 2004 15:30:39 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjke7-00080k-7g for rpsec@ietf.org; Wed, 29 Dec 2004 15:42:15 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBTKU2jf025332; Wed, 29 Dec 2004 15:30:04 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0E247C8A-5994-11D9-BFE9-000A95CD987A@muada.com> References: <0E247C8A-5994-11D9-BFE9-000A95CD987A@muada.com> Date: Wed, 29 Dec 2004 14:02:32 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a At 1:20 PM +0100 12/29/04, Iljitsch van Beijnum wrote: >Steve, > >On 28-dec-04, at 17:54, Stephen Kent wrote: > >>>However, you pose a very interesting question. It sure looks like >>>a lot of people are assuming the following addressing hierarchy: > >>>ICANN -> RIRs -> origin AS > >>Not sure exactly what you are referring to here. > >Russ is concerned with the situation where it's like: > >ICANN -> RIRs -> ISP -> origin AS > >If this is just the allocation chain, that's not a problem, but if >the ISP also sources an aggregate that covers the prefix sourced by >"origin AS" things get complicated. In the papers we have published, it is always described just as an allocation chain, and thus a suitable basis for a PKI. >>In the papers we've written on BGP security, we do describe an >>address allocation hierarchy that is rooted at ICANN and that goes >>through RIRs to ISPs (or subscribers), etc. We also note that some >>subscribers get allocations directly from an RIR. Do you think that >>this is an inaccurate model for allocation? > >Not necessarily "inaccurate", but things can be a bit more complex >in the real world. The only thing we know for sure is that there is >always ICANN/IANA at one end and the origin AS at the other end. >There is a RIR involved most of the time. Then there are NIR >(national internet registries, mostly in the APNIC region) and LIRs >(=== ISPs) which are both optional. There is also a distinction >between the address holder (not owner, as addresses can't be owned >as per RIR policy) and the origin AS. For instance, an organization >with portable address space may have it announced by the ISP du >jour, or the address holder can lend the address space to another >organization that then announces it without actually transferring >the address space. Yes, I omitted the NIRs and LIRs for simplicity, but they are easy to accommodate in a PKI that parallels the allocation chain. And yes, I tend to use "owner" too loosely; "holder" is the more appropriate term. We recognize the fact the address holder may not be the origin AS, and thus needs to explicitly authorize some AS to originate the address prefix he holds. in the S-BGP work there is no notion of the name of the address prefix holder, only the fact that someone to whom an RIR/NIR/LIR/ISP allocated a prefix has signed an attestation for some time interval identifying an AS to advertise the prefix. So even the lending of addresses is accommodated. > >>>All of this begs the question: if we're going to rebuild so many >>>parts of BGP, wouldn't it make more sense to start with a clean >>>slate? It would be great if we could separate the authenticity and >>>authorization issues from the reachability issues. This would >>>increase performance and decrease complexity. > >>I'm not sure what you mean by this last paragraph. When we >>approached BGP security we did so cognizant of the limitations of >>the extant protocol. We started from the premise of what a speaker >>assumes is true when it gets an Update, and then worked from that >>basis to determine what the security requirements were, and then >>proposed mechanisms to satisfy those requirements. > >In other words, you added jet engines to the pig. :-) yes, but they're really cool engines :-) >>Anothr way of saying this, that I think we should articulate in the >>document (if there is agreement) is that main purpose of BGP >>security should be to enable speakers to verify Updates, because >>speakers make routing (reachability) decisions based on a >>combination of dynamic info from Updates and static config data. >>That suggests a two-pronged approach, one that provides a speaker >>with data to verify the dynamic aspects of an Update, and one that >>supports distribution of (static) data to support verification of >>the less dynamic aspects of an Update. > >The way I see it, there are four topologies, each a subset of the >previous one: > >- the logical topology determined by the way BGP speakers are interconnected >- the topology that's allowed by policy >- the topology for which authorization can be verified successfully >- the actually reachable topology > >I would be much happier if we had mechanisms other than the update >message to build topology maps for the first three. Our goal in S-BGP was to create an infrastructure and mechanism that would allow #3 to match #4, in realtime. Building maps for the first three is tough, especially since I have bee told that many ISPs do not wish to divulge local policy info that is needed to represent #2. Also it seems likely that topology maps are not a good way to represent the dynamic status implied by #4. If we use anything other than Updates to convey data for #4, then there will always be sync problems. But yes, I agree, that, from a technical perspective, one could create maps for #2, and try to create a security infrastructure to transform this into #3. What you would have then is a bound on the extent to which an AS compromise or configuration errors would be tolerated by other ASes participating in the security scheme. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec