Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA18400 for ; Tue, 8 Feb 2000 13:38:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 031D45DDD8; Tue, 8 Feb 2000 13:38:34 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E75BB5DDD7; Tue, 8 Feb 2000 13:38:33 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 5164E5DDC9 for ; Tue, 8 Feb 2000 13:38:27 -0500 (EST) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA25380; Tue, 8 Feb 2000 10:38:15 -0800 (PST) Message-Id: <200002081838.KAA25380@omega.cisco.com> To: Sandy Murphy Cc: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt In-reply-to: Your message of "Tue, 08 Feb 2000 13:09:11 EST." <200002081809.NAA27060@clipper.gw.tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25376.950035094.1@cisco.com> Date: Tue, 08 Feb 2000 10:38:15 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Sandy, > >I reiterate that if you are going to claim it is > >*just* a protocol analysis, then you need to remove about 80% of the draft > >as it refers to something which is neither part of the protocol nor > > It's an analysis of what's there and the possible enhancements to > the protocol. I wonder if it could help to make progress if you would "unbundle" your Internet Draft into two separate Internet Drafts, the first with the analysis part, and the second with the possible enhancements. Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA18123 for ; Tue, 8 Feb 2000 13:24:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2CFB75DE1E; Tue, 8 Feb 2000 13:23:13 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D5505DE24; Tue, 8 Feb 2000 13:23:06 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 1B15A5DE1E for ; Tue, 8 Feb 2000 13:22:15 -0500 (EST) Received: by sentry; id NAA00823; Tue, 8 Feb 2000 13:23:30 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma000813; Tue, 8 Feb 00 13:23:13 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id NAA27992; Tue, 8 Feb 2000 13:21:53 -0500 (EST) Date: Tue, 8 Feb 2000 13:21:53 -0500 (EST) From: Sandy Murphy Message-Id: <200002081821.NAA27992@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: Secure BGP -- Internet Drafts Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk >That seems unworkable. The NLRI blocks are as large as 500 prefixes. I think you need to talk to the SBGP guys. First, I may have gotten their story wrong. Second, I'm not the person to convince. >When >this occurs, a subset of an NLRI block is propogated further. Yes, and when that happens, all the original signed NLRI blocks must accompany the subsets that are propogated. >> now. If the RIB's get big, is that a problem, or is it only the >> forwarding table size that motivated aggregation? > > >Yes. That is a problem. I'm bowing out of this - I'm not the right person to be expressing an opinion or listening to advice. Again, I think the BBN guys would really want to listen to this sort of info. >> decided upon route before sending an UPDATE to a neighbor or verify just >> whenever you think there's a problem. (That last one is chancy.) > > >The latter allows a bad route to be installed and therefore can divert >traffic. Yes, exactly. That's why I called it "chancy". If you verify only when you think there's a problem (or at some periodicity), then you let problems occur and you fix them later. About the only advantage is that you know where the problem came from. --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA17908 for ; Tue, 8 Feb 2000 13:14:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BE715DDE6; Tue, 8 Feb 2000 13:10:30 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D53635DDEF; Tue, 8 Feb 2000 13:10:29 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id 742D25DDE6 for ; Tue, 8 Feb 2000 13:10:18 -0500 (EST) Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA21767; Tue, 8 Feb 2000 13:10:09 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA01590; Tue, 8 Feb 2000 13:12:10 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200002081812.NAA01590@curtis-lt.avici.com> To: Sandy Murphy Cc: idr@merit.edu Reply-To: curtis@avici.com Subject: Re: protecting BGP routing with filters In-reply-to: Your message of "Mon, 07 Feb 2000 16:45:18 EST." <200002072145.QAA28144@clipper.gw.tislabs.com> Date: Tue, 08 Feb 2000 13:12:10 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <200002072145.QAA28144@clipper.gw.tislabs.com>, Sandy Murphy writes: > I am fundamentally bothered by the claims of prefix and AS_PATH filtering. > The claims that these filters help can only hold if: > > (1) the filters are derived from accurate, complete and timely > topology information > > (2) the filters aren't so inspecific as to be meaningless > > > There are those who claim that (1) can be achieved by reference to the > IRR's. Given time and effort and mandates for allocating addresses, I can > see that completeness might hold true at some point, for network > prefixes. (Any one got any data on how much of the allocated IP > address space is represented in the IRR's?) Timeliness would also be > a matter of careful design and engineering. I don't know about > accuracy - we're relying on the same people to input data who are > presently making mistakes in configuring their routers. > > But the AS_PATH information and the transit policies require that the > AS's publicize information closely related to their private peering > agreements. I have heard from several people who should know that > there is doubt that the AS's would be willing to take that step, > particularly as the participation in the IRR's is presently voluntary. > That means that completeness would be difficult to achieve. > > As for (2), I can see that near the edges of the internet, it might be > possible to have specific filters on incoming routes, because the > operators would have direct knowledge of their customer and the > customer would have very little to say. But if the Internet > connectivity is at all rich, not-tree-like, then at some point away > from the edge, an AS must be able to receive routes to most addresses > and routes to most addresses from most peers. In other words, the > filters wouldn't be able to filter out much of anything. And if the > Internet connectivity is tree-like and not rich so that it stays > possible to know what prefix+path you will get from each peer and to know > from what peer you will get each prefix+path, then the Internet is > inherently fragile. An extremely bad attribute for a Critical > Infrastructure. > > So which is it? > > --Sandy Sandy, The IRR is incomplete. Not all prefixes are available in the IRR. AS adjacnecies are not accurately represented. The deployment of sanity filters varies among providers. Some (including a few major providers) still do not filter route announcements from their direct customers. Some providers filter their own customers and prefer routes (in order of preference) from 1) their direct customers and 2) from providers that are know to filter and/or be more reliable. Some providers take the two steps above and (unless things have changed since I was last in touch with operations) also prefer registered routes from peers over unregistered. This only means that registering a prefix and choosing a provider that does a bit more filtering than less may provide some improvement in reliability. If you pick a provider that does no filtering at all, then a malicious or accidental bad announcement could effectively take out you connectivity. If you pick a provider that does more filtering, your connectivity to others using the same provider and other providers that have effective filters is immune to this sort of problem. Your connectivity to a provider that does no filtering at all can still be effected. Registering prefixes in the IRR may also help depending on who is using it these days. Is this adequate? IMHO - No. In practice, it has proven workable though occasional outage do occur so sites who's business relies heavily or almost entirely on their connectivity (example: AOL) are directly connected to many providers and also take steps to insure that the providers they connect to filter *their* prefixes even if they don't filter in general. Curtis Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA17875 for ; Tue, 8 Feb 2000 13:11:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27C845DDDB; Tue, 8 Feb 2000 13:10:15 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CBD235DDDC; Tue, 8 Feb 2000 13:10:14 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id ED4485DDDB for ; Tue, 8 Feb 2000 13:10:08 -0500 (EST) Received: by sentry; id NAA00530; Tue, 8 Feb 2000 13:11:27 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma000478; Tue, 8 Feb 00 13:10:31 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id NAA27060; Tue, 8 Feb 2000 13:09:11 -0500 (EST) Date: Tue, 8 Feb 2000 13:09:11 -0500 (EST) From: Sandy Murphy Message-Id: <200002081809.NAA27060@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk >I reiterate that if you are going to claim it is >*just* a protocol analysis, then you need to remove about 80% of the draft >as it refers to something which is neither part of the protocol nor It's an analysis of what's there and the possible enhancements to the protocol. >computationally feasible. I dispute that it is not computationally feasible. >why are operational solutions inadmissable Because they do not make the protocol secure, they make the network operation robust. Like "don't use clear text passwords", etc. --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17417 for ; Tue, 8 Feb 2000 12:51:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 612115DD9F; Tue, 8 Feb 2000 12:51:06 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4CC4A5DDC9; Tue, 8 Feb 2000 12:51:06 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id D658C5DD9F for ; Tue, 8 Feb 2000 12:50:59 -0500 (EST) Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id MAA20388; Tue, 8 Feb 2000 12:50:55 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA01549; Tue, 8 Feb 2000 12:52:57 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200002081752.MAA01549@curtis-lt.avici.com> To: Sandy Murphy Cc: idr@merit.edu Reply-To: curtis@avici.com Subject: Re: Secure BGP -- Internet Drafts In-reply-to: Your message of "Mon, 07 Feb 2000 16:00:10 EST." <200002072100.QAA27126@clipper.gw.tislabs.com> Date: Tue, 08 Feb 2000 12:52:57 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <200002072100.QAA27126@clipper.gw.tislabs.com>, Sandy Murphy writes: > >> > The algorithm cost is based on prefixes, if the cost of the computation > >> > based on prefix growth is less than Moore's law, there isn't a problem. > >> > > >> > >> It is actually proportional to the number of prefixes multiplied by the > >> average AS path length as the computations are carried out for each AS in > >> the path. > >> > >> Ben > > >Minor point - Its the number of unique prefix and advertising AS > >advertised to the router via EBGP times the average AS path length. > >... > >The AS path is the same for the whole BGP update, but > >prefixes must be signed individually. > > Overall, I don't know that it makes a difference in the magnitude of > the numbers - but I think SBGP signs the NLRI *block*, not each > individual NLRI. That means that if you choose just one NLRI from a > block to advertise, you have to forward the original NLRI block, too. > (And Charlie and Luis can bash me on the list if I've got this wrong.) > Fewer signatures, more signed data to be passed - my back of the > envelope said that this wins most times unless the NLRI blocks or the > AS_PATHs get big. That seems unworkable. The NLRI blocks are as large as 500 prefixes. BGP implementations currently repack the NLRI each time they are advertised as they currently do not maintain any record of how they were packed on the way in. It is common for another AS Path to provide a better path to a subset of routes (some examples are dual homed customers such as research networks that also have connectivity to a commercial service). When this occurs, a subset of an NLRI block is propogated further. > >Aggregation is problematic since signatures cannot be aggregated. > > Yes, that's true. > > I was listening to Steve Kent talk about SBGP and suddenly realized > one of their points - that the *forwarding* table is not affected by > the signatures that have to be carried. The fact that all the > un-aggregated signatures have to be carried forward past an > aggregation point means that the RIB's will not decrease in size, but > the forwarding table will still decrease and just as much as it does > now. If the RIB's get big, is that a problem, or is it only the > forwarding table size that motivated aggregation? Yes. That is a problem. > >If they are > >kept in deaggregated form, this begs the question as to whether the > >router needs to verify the signatures chains within the aggregate and > >what it does if some are valid but some are not. > > I think that the SBGP guys would say that all the signatures have > to verify - each is attesting to some delegation of authority, so if any > one does not work, you do not have a chain of authority established. > > There's also the point of when you do the verification - verify every > incoming UPDATE before doing the decision procedure or verify the > decided upon route before sending an UPDATE to a neighbor or verify just > whenever you think there's a problem. (That last one is chancy.) The latter allows a bad route to be installed and therefore can divert traffic. > --Sandy Curtis Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17197 for ; Tue, 8 Feb 2000 12:39:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id EDED85DE0A; Tue, 8 Feb 2000 12:37:14 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 261D95DE04; Tue, 8 Feb 2000 12:37:14 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id B88005DE13 for ; Tue, 8 Feb 2000 12:30:31 -0500 (EST) Received: (qmail 17353 invoked from network); 8 Feb 2000 17:31:41 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 8 Feb 2000 17:31:41 -0000 Message-ID: <029701bf7259$f1136860$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Sandy Murphy" , Cc: References: <200002081717.MAA24661@clipper.gw.tislabs.com> Subject: Re: draft-murphy-bgp-secr-03.txt Date: Tue, 8 Feb 2000 09:28:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk Yes, I noticed the brief comments buried in the midst of all the AS path signature discussion. I reiterate that if you are going to claim it is *just* a protocol analysis, then you need to remove about 80% of the draft as it refers to something which is neither part of the protocol nor computationally feasible. If you are going to allow for presentation of "solutions" to protocol weaknesses, such as the numerous mentions of signature schemes, then why are operational solutions inadmissable? Ben > >All the more reason for it to have been mentioned in regards to BGP > >security. > > > > > >Ben > > > >> > Please refer > >> >to RFC2725 and draft-ietf-rps-dist-06.txt. > >> > >> You might want to note that I am an author of rfc2725. > >> > >> --Sandy > >> > > See section 3.6 "Rely on Registries", page 13 and section 4.5 "Rely on > Registries", page 15 and reference [5] to the Routing Policy System Security > draft, page 17. > > --Sandy > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16732 for ; Tue, 8 Feb 2000 12:19:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC64E5DDD1; Tue, 8 Feb 2000 12:18:09 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 74A2D5DDC9; Tue, 8 Feb 2000 12:18:09 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 2C06D5DDD1 for ; Tue, 8 Feb 2000 12:18:03 -0500 (EST) Received: by sentry; id MAA29393; Tue, 8 Feb 2000 12:19:18 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma029384; Tue, 8 Feb 00 12:18:26 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id MAA24661; Tue, 8 Feb 2000 12:17:07 -0500 (EST) Date: Tue, 8 Feb 2000 12:17:07 -0500 (EST) From: Sandy Murphy Message-Id: <200002081717.MAA24661@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk >All the more reason for it to have been mentioned in regards to BGP >security. > > >Ben > >> > Please refer >> >to RFC2725 and draft-ietf-rps-dist-06.txt. >> >> You might want to note that I am an author of rfc2725. >> >> --Sandy >> See section 3.6 "Rely on Registries", page 13 and section 4.5 "Rely on Registries", page 15 and reference [5] to the Routing Policy System Security draft, page 17. --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16449 for ; Tue, 8 Feb 2000 12:08:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE1445DDCC; Tue, 8 Feb 2000 12:07:30 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3FEC65DDC9; Tue, 8 Feb 2000 12:07:30 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 350F95DDD1 for ; Tue, 8 Feb 2000 12:07:16 -0500 (EST) Received: (qmail 17264 invoked from network); 8 Feb 2000 17:08:24 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 8 Feb 2000 17:08:24 -0000 Message-ID: <023f01bf7256$b10964c0$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Sandy Murphy" , , References: <200002081638.LAA22793@clipper.gw.tislabs.com> Subject: Re: draft-murphy-bgp-secr-03.txt Date: Tue, 8 Feb 2000 09:05:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk All the more reason for it to have been mentioned in regards to BGP security. Ben > > Please refer > >to RFC2725 and draft-ietf-rps-dist-06.txt. > > You might want to note that I am an author of rfc2725. > > --Sandy > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15793 for ; Tue, 8 Feb 2000 11:41:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE03B5DDA9; Tue, 8 Feb 2000 11:40:53 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D226D5DDCC; Tue, 8 Feb 2000 11:40:53 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 2FC7B5DDA9 for ; Tue, 8 Feb 2000 11:40:52 -0500 (EST) Received: by sentry; id LAA28638; Tue, 8 Feb 2000 11:42:11 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma028631; Tue, 8 Feb 00 11:41:19 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id LAA22898; Tue, 8 Feb 2000 11:40:00 -0500 (EST) Date: Tue, 8 Feb 2000 11:40:00 -0500 (EST) From: Sandy Murphy Message-Id: <200002081640.LAA22898@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk > Please refer >to RFC2725 and draft-ietf-rps-dist-06.txt. You might want to note that I am an author of rfc2725. --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA03760 for ; Mon, 7 Feb 2000 23:36:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3610F5DD97; Mon, 7 Feb 2000 23:36:24 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 194BC5DD9A; Mon, 7 Feb 2000 23:36:24 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 2DA8B5DD97 for ; Mon, 7 Feb 2000 23:36:22 -0500 (EST) Received: (qmail 15363 invoked from network); 8 Feb 2000 04:37:30 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 8 Feb 2000 04:37:30 -0000 Message-ID: <015a01bf71ed$c8f43a60$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Sandy Murphy" , Cc: References: <200002072039.PAA26458@clipper.gw.tislabs.com> Subject: Re: draft-murphy-bgp-secr-03.txt Date: Mon, 7 Feb 2000 20:34:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk > Let me say first that my purpose in writing this draft was to answer > two questions: > Is BGP a secure protocol? and > What could we do to enhance the protocol to make it secure? Introduction of undeployed and incompletely specified "enhancements" rather than coverage of *existing* mechanisms would seem of limited utility. > This is intended as a record of the knowledge base of the answers to > those two questions, not a suggestion that any of the various > directions be taken. If in future the working group decided to pursue > making BGP secure, this draft would be a starting point for ideas. > If this is the case, then it is essential that deployed security mechanisms be covered. > The operational mechanisms you mention are attempts to compensate for > the vulnerabilities in BGP, not to correct the vulnerabilities. So > they do not belong in an analysis of BGP security. I would think that > they *do* belong in the "Applicability Statement" that is one of the > mandated suite of RFC's that must be written about any protocol. I > expect that the document might say "As shown in the xxx RFC, BGP is > vulnerable in various ways, but the known enhancements to BGP that > would correct those vulnerabilities are expensive. Operators would be > wise to implement some set of the following procedures:" > > I have seen presentations about prefix filtering at NANOG, etc, but I > am not assured that those operational mechanisms are scalable and > effective against deliberate attack through a BGP participant. If > they are not, then I would say that they provide robustness or fault > tolerance or some similar statistical attribute, but not security. > > Furthermore, the prefix filtering does not address at all the problems > that result from falsification of the AS_PATH. A bogus AS_PATH could > overwhelm networks just as easily as a bogus network origination. > Directly generating policy from a secure registry provides for both prefix and AS path filtering. In another e-mail you express concerns regarding the accuracy and timeliness of the information in the registries. Please refer to RFC2725 and draft-ietf-rps-dist-06.txt. If an entity enters inaccurate information for its own prefixes, it only impacts its own reachability. If an entity allows its registry information to become out of date, it only impacts its own reachability. This is exactly the situation desired: the source of policy information is a secure repository and the policy is a direct reflection of that repository. I strongly encourage you to familiarize yourself with all the relevant RFCs, drafts, and common practice before making arbitrary judgements on what can and can't be included in an information draft on the security of BGP. > > >The mechanisms I describe do not belong in the protocol. > > And hence do not belong in a discussion of security enhancements to the > protocol. > > >They are simply > >common practice and common practice is often documented in an RFC other than > >the one describing the original protocol. > > OK - but not in this one. > > >Agreed. This is why I pointed out the numerous *deployed* solutions for the > >problems presented > > I think I disagree that the operational mechanisms should be characterized > as "solutions". > If operational mechanisms can cause the problem to cease to exist, then they would appear to solve the problem. I am open to other definitions of solutions. > >My comment regarding the ORIGIN attribute was that the vulnerability is more > >(however slightly) than what you believed. > > OK, I'll strengthen that part. > > >This is the sort of thing that *should* be discussed in > >a draft regarding security. > > In a draft discussing secure operations, yes, but not in a draft > discussing the protocol's security. Otherwise, all sorts of wisdom > regarding secure operation would need to be included. > If you are going to cover the *actual* weaknesses of the protocol, then do so. However, that means you have eliminated the introduction of *new* protocol mechanisms as they do not address flaws in the *existing* protocol. > About the AS_PATH prepending - both you and Randy say that I must have > misunderstood comments about adding multiple copies of one's AS > number. I really thought that route servers had been brought up as an > example of places where prepending need not occur, but since noone has > spoken up I'll simply take what you and Randy and the spec say as > both gospel and real life. > I encourage you to read RFC1863 as it directly addresses your questions about the behavior of route servers. Ben Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24902 for ; Mon, 7 Feb 2000 16:51:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 456C25DE40; Mon, 7 Feb 2000 16:46:36 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D99D65DDE1; Mon, 7 Feb 2000 16:46:27 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 30B4E5DEB0 for ; Mon, 7 Feb 2000 16:46:04 -0500 (EST) Received: by sentry; id QAA18990; Mon, 7 Feb 2000 16:47:16 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma018986; Mon, 7 Feb 00 16:46:30 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA28144; Mon, 7 Feb 2000 16:45:18 -0500 (EST) Date: Mon, 7 Feb 2000 16:45:18 -0500 (EST) From: Sandy Murphy Message-Id: <200002072145.QAA28144@clipper.gw.tislabs.com> To: idr@merit.edu Subject: protecting BGP routing with filters Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk I am fundamentally bothered by the claims of prefix and AS_PATH filtering. The claims that these filters help can only hold if: (1) the filters are derived from accurate, complete and timely topology information (2) the filters aren't so inspecific as to be meaningless There are those who claim that (1) can be achieved by reference to the IRR's. Given time and effort and mandates for allocating addresses, I can see that completeness might hold true at some point, for network prefixes. (Any one got any data on how much of the allocated IP address space is represented in the IRR's?) Timeliness would also be a matter of careful design and engineering. I don't know about accuracy - we're relying on the same people to input data who are presently making mistakes in configuring their routers. But the AS_PATH information and the transit policies require that the AS's publicize information closely related to their private peering agreements. I have heard from several people who should know that there is doubt that the AS's would be willing to take that step, particularly as the participation in the IRR's is presently voluntary. That means that completeness would be difficult to achieve. As for (2), I can see that near the edges of the internet, it might be possible to have specific filters on incoming routes, because the operators would have direct knowledge of their customer and the customer would have very little to say. But if the Internet connectivity is at all rich, not-tree-like, then at some point away from the edge, an AS must be able to receive routes to most addresses and routes to most addresses from most peers. In other words, the filters wouldn't be able to filter out much of anything. And if the Internet connectivity is tree-like and not rich so that it stays possible to know what prefix+path you will get from each peer and to know from what peer you will get each prefix+path, then the Internet is inherently fragile. An extremely bad attribute for a Critical Infrastructure. So which is it? --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA23869 for ; Mon, 7 Feb 2000 16:03:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id D69645DDB2; Mon, 7 Feb 2000 16:00:58 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C06A65DDC9; Mon, 7 Feb 2000 16:00:58 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 1B8475DDB2 for ; Mon, 7 Feb 2000 16:00:57 -0500 (EST) Received: by sentry; id QAA18525; Mon, 7 Feb 2000 16:02:12 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma018519; Mon, 7 Feb 00 16:01:22 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA27126; Mon, 7 Feb 2000 16:00:10 -0500 (EST) Date: Mon, 7 Feb 2000 16:00:10 -0500 (EST) From: Sandy Murphy Message-Id: <200002072100.QAA27126@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: Secure BGP -- Internet Drafts Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk >> > The algorithm cost is based on prefixes, if the cost of the computation >> > based on prefix growth is less than Moore's law, there isn't a problem. >> > >> >> It is actually proportional to the number of prefixes multiplied by the >> average AS path length as the computations are carried out for each AS in >> the path. >> >> Ben >Minor point - Its the number of unique prefix and advertising AS >advertised to the router via EBGP times the average AS path length. >... >The AS path is the same for the whole BGP update, but >prefixes must be signed individually. Overall, I don't know that it makes a difference in the magnitude of the numbers - but I think SBGP signs the NLRI *block*, not each individual NLRI. That means that if you choose just one NLRI from a block to advertise, you have to forward the original NLRI block, too. (And Charlie and Luis can bash me on the list if I've got this wrong.) Fewer signatures, more signed data to be passed - my back of the envelope said that this wins most times unless the NLRI blocks or the AS_PATHs get big. >Aggregation is problematic since signatures cannot be aggregated. Yes, that's true. I was listening to Steve Kent talk about SBGP and suddenly realized one of their points - that the *forwarding* table is not affected by the signatures that have to be carried. The fact that all the un-aggregated signatures have to be carried forward past an aggregation point means that the RIB's will not decrease in size, but the forwarding table will still decrease and just as much as it does now. If the RIB's get big, is that a problem, or is it only the forwarding table size that motivated aggregation? >If they are >kept in deaggregated form, this begs the question as to whether the >router needs to verify the signatures chains within the aggregate and >what it does if some are valid but some are not. I think that the SBGP guys would say that all the signatures have to verify - each is attesting to some delegation of authority, so if any one does not work, you do not have a chain of authority established. There's also the point of when you do the verification - verify every incoming UPDATE before doing the decision procedure or verify the decided upon route before sending an UPDATE to a neighbor or verify just whenever you think there's a problem. (That last one is chancy.) --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23431 for ; Mon, 7 Feb 2000 15:40:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9252A5DDA7; Mon, 7 Feb 2000 15:40:03 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 644755DDAD; Mon, 7 Feb 2000 15:40:03 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 3003E5DDA7 for ; Mon, 7 Feb 2000 15:39:57 -0500 (EST) Received: by sentry; id PAA18349; Mon, 7 Feb 2000 15:41:12 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma018346; Mon, 7 Feb 00 15:41:07 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id PAA26458; Mon, 7 Feb 2000 15:39:54 -0500 (EST) Date: Mon, 7 Feb 2000 15:39:54 -0500 (EST) From: Sandy Murphy Message-Id: <200002072039.PAA26458@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk [Sorry for the long delay in responding - I've been mostly on travel for the last two weeks (when not snowed in).] Let me say first that my purpose in writing this draft was to answer two questions: Is BGP a secure protocol? and What could we do to enhance the protocol to make it secure? This is intended as a record of the knowledge base of the answers to those two questions, not a suggestion that any of the various directions be taken. If in future the working group decided to pursue making BGP secure, this draft would be a starting point for ideas. Did you miss the fact that this is intended to be an Informational RFC? The operational mechanisms you mention are attempts to compensate for the vulnerabilities in BGP, not to correct the vulnerabilities. So they do not belong in an analysis of BGP security. I would think that they *do* belong in the "Applicability Statement" that is one of the mandated suite of RFC's that must be written about any protocol. I expect that the document might say "As shown in the xxx RFC, BGP is vulnerable in various ways, but the known enhancements to BGP that would correct those vulnerabilities are expensive. Operators would be wise to implement some set of the following procedures:" I have seen presentations about prefix filtering at NANOG, etc, but I am not assured that those operational mechanisms are scalable and effective against deliberate attack through a BGP participant. If they are not, then I would say that they provide robustness or fault tolerance or some similar statistical attribute, but not security. Furthermore, the prefix filtering does not address at all the problems that result from falsification of the AS_PATH. A bogus AS_PATH could overwhelm networks just as easily as a bogus network origination. >The mechanisms I describe do not belong in the protocol. And hence do not belong in a discussion of security enhancements to the protocol. >They are simply >common practice and common practice is often documented in an RFC other than >the one describing the original protocol. OK - but not in this one. >Agreed. This is why I pointed out the numerous *deployed* solutions for the >problems presented I think I disagree that the operational mechanisms should be characterized as "solutions". >My comment regarding the ORIGIN attribute was that the vulnerability is more >(however slightly) than what you believed. OK, I'll strengthen that part. >This is the sort of thing that *should* be discussed in >a draft regarding security. In a draft discussing secure operations, yes, but not in a draft discussing the protocol's security. Otherwise, all sorts of wisdom regarding secure operation would need to be included. About the AS_PATH prepending - both you and Randy say that I must have misunderstood comments about adding multiple copies of one's AS number. I really thought that route servers had been brought up as an example of places where prepending need not occur, but since noone has spoken up I'll simply take what you and Randy and the spec say as both gospel and real life. --Sandy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16082 for ; Fri, 4 Feb 2000 12:59:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 323435DDB0; Fri, 4 Feb 2000 12:58:46 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 088815DDDA; Fri, 4 Feb 2000 12:58:46 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id A48FD5DDB0 for ; Fri, 4 Feb 2000 12:58:08 -0500 (EST) Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id MAA13813; Fri, 4 Feb 2000 12:58:07 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA08835; Fri, 4 Feb 2000 12:58:51 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200002041758.MAA08835@curtis-lt.avici.com> To: Charles Lynn Cc: Benjamin Black , Danny McPherson , IDR@merit.edu Reply-To: curtis@avici.com Subject: Re: S-BGP performance paper - was: Re: Secure BGP -- Internet Drafts In-reply-to: Your message of "Thu, 03 Feb 0100 16:04:12 EST." <20000203210653.5F3965DD8E@segue.merit.edu> Date: Fri, 04 Feb 2000 12:58:50 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <20000203210653.5F3965DD8E@segue.merit.edu>, Charles Lynn writes: > Ben, > > > You reference a paper to be published next month which specifically > > addresses the performance issue. Can this be provided to the group? > > Yes, I now have permission to make the S-BGP NDSS 2000 paper available. > The URL of the paper is > http://www.ir.bbn.com/projects/sbgp/ndss00.S-BGP.ps > There is a link to it from the S-BGP home page > http://www.ir.bbn.com/projects/sbgp > > Comments are welcome, especially on the "underlying statistics" ... > > Danny, > > > I'll gladly provide anyone interested in performing these simulations > > with a perspective of typical number of iBGP/eBGP peers and routes > > your simulations. > > That information would be appreciated. The most quantitative data we > have for peers is from BGP traffic recorded by Merit, but that misses > private peerings and doesn't really have show iBGP sessions. We used > actual eBGP peering sessions with the three ISPs that responded to my > request at the IDR WG session but they might not be diverse enough to > be representative of the whole Internet. > > Suggestions for additional experiments that lead to convincing results > are also welcome. > > Charlie Charlie, Two figures in your paper strike me as significant. In Table 2 you cite: 1,426 updates per day In section 5.6.2 it appears as though the table (not numbered) tells us that using SHA-1 and 1024 bit DSA we'd have: 139.9 CPU minutes/day steady state If that is 2+ CPU hours per 24 hour day per peer providing 1,426 updates per day, what does this mean if either your router has 50 peers or a bad day. Looking at past history at IPMA (http://www.merit.edu/ipma/instability/) we see: the host zounds.merit.edu is incredibly slow ... not responding If it were working I suspect you'd still see peak days were the number of updates were much higher and certainly peak hours where the update rate for the hour exceeded the CPU processing ability for that hour. salamanders are very slow animals ... but I finally got a reply an empty page and nicely formated timeout message ... Craig? Ahba? In practice not all 50 peers will send full routing. These routers have outbound filters that reduce what is sent to a subset fo full routes. People who make routers must build equipment that can withstand worst case scenarios such as some of the peers accidentally dropping their outbound filter policies and leaving the routers that way. We also have to consider what happesn during peaks and creating 15 to 20 minute CPU backlogs would not be acceptable. Therefore, your proposal has limited applicability and may not be at all applicable to use by gateway routers in the Internet at least without a very significant boost in CPU power. Again, I don't think this should prevent publication of your i-d as informational or experimental and maybe you'll even get someone to try the experiment. If it suceeds, then the IDR WG can revisit this. It almost seems like the conclusion of you paper is that without cryptographic hardware the proposal is infeasible or at least impractical. You didn't mention what sort of speedup you could expect relative to the P/Pro-200 that you used. (Clearly you could already get a factor of as much as 2-3 just using a newer processor). If I've misinterpreted your paper, please let me know. Curtis Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA26082 for ; Thu, 3 Feb 2000 16:07:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55D985DD8E; Thu, 3 Feb 2000 16:06:56 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2F1E95DD90; Thu, 3 Feb 2000 16:06:56 -0500 (EST) Received: from CLYNN.BBN.COM (CLynn.BBN.COM [128.89.1.209]) by segue.merit.edu (Postfix) with SMTP id 5F3965DD8E for ; Thu, 3 Feb 2000 16:06:53 -0500 (EST) Date: Thu, 3 Feb 100 16:04:12 EST From: Charles Lynn To: Benjamin Black , Danny McPherson Cc: IDR@merit.edu, CLynn@BBN.COM Subject: S-BGP performance paper - was: Re: Secure BGP -- Internet Drafts Message-Id: <20000203210653.5F3965DD8E@segue.merit.edu> Sender: owner-idr@merit.edu Precedence: bulk Ben, > You reference a paper to be published next month which specifically > addresses the performance issue. Can this be provided to the group? Yes, I now have permission to make the S-BGP NDSS 2000 paper available. The URL of the paper is http://www.ir.bbn.com/projects/sbgp/ndss00.S-BGP.ps There is a link to it from the S-BGP home page http://www.ir.bbn.com/projects/sbgp Comments are welcome, especially on the "underlying statistics" ... Danny, > I'll gladly provide anyone interested in performing these simulations > with a perspective of typical number of iBGP/eBGP peers and routes > your simulations. That information would be appreciated. The most quantitative data we have for peers is from BGP traffic recorded by Merit, but that misses private peerings and doesn't really have show iBGP sessions. We used actual eBGP peering sessions with the three ISPs that responded to my request at the IDR WG session but they might not be diverse enough to be representative of the whole Internet. Suggestions for additional experiments that lead to convincing results are also welcome. Charlie Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA15503 for ; Tue, 1 Feb 2000 22:33:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E0965DDA6; Tue, 1 Feb 2000 22:32:28 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3BF805DDA8; Tue, 1 Feb 2000 22:32:28 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 88BA05DDA6 for ; Tue, 1 Feb 2000 22:32:26 -0500 (EST) Received: (qmail 4458 invoked from network); 2 Feb 2000 03:33:32 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 2 Feb 2000 03:33:32 -0000 Message-ID: <01ed01bf6d2d$93099d60$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Charles Lynn" , "Yakov Rekhter" Cc: References: <20000201220840.DD10F5DDB7@segue.merit.edu> Subject: Re: draft-murphy-bgp-secr-03.txt Date: Tue, 1 Feb 2000 19:28:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk As I outlined in detail in several other posts, this draft offers little in the way of BGP protocol analysis and even less for proposed solutions. I see no reason to accept it as a WG document. Ben > Yakov, > > > I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt > > as an IDR WG document with the ultimate goal of publishing it as > > an Informational RFC. Please comment on this within the next 2 weeks. > > I think that the draft should be accepted as an IDR WG document with > the intent of getting it published in the near term, even if that > means dividing it into separate vulnerability and proposed solution > mechanisms documents. As has been noted on the list, defining a few > terms might make the document useful to a larger community that may > not be familiar with special connotations those terms have in the BGP > context. > > Charlie > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10169 for ; Tue, 1 Feb 2000 17:09:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7813B5DDB7; Tue, 1 Feb 2000 17:08:43 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 37D9F5DDBC; Tue, 1 Feb 2000 17:08:43 -0500 (EST) Received: from CLYNN.BBN.COM (CLynn.BBN.COM [128.89.1.209]) by segue.merit.edu (Postfix) with SMTP id DD10F5DDB7 for ; Tue, 1 Feb 2000 17:08:40 -0500 (EST) Date: Tue, 1 Feb 100 17:06:54 EST From: Charles Lynn To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt Message-Id: <20000201220840.DD10F5DDB7@segue.merit.edu> Sender: owner-idr@merit.edu Precedence: bulk Yakov, > I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt > as an IDR WG document with the ultimate goal of publishing it as > an Informational RFC. Please comment on this within the next 2 weeks. I think that the draft should be accepted as an IDR WG document with the intent of getting it published in the near term, even if that means dividing it into separate vulnerability and proposed solution mechanisms documents. As has been noted on the list, defining a few terms might make the document useful to a larger community that may not be familiar with special connotations those terms have in the BGP context. Charlie