From iesg-secretary at ietf.org Sun Nov 3 16:06:40 2002 From: iesg-secretary at ietf.org (The IESG) Date: Sun, 03 Nov 2002 11:06:40 -0500 Subject: Last Call: NOPEER community for BGP route scope control to BCP Message-ID: <200211031606.LAA09183@ietf.org> The IESG has received a request from the Prefix Taxonomy Ongoing Measurement & Inter Network Experiment Working Group to consider NOPEER community for BGP route scope control as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2002-11-17. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ptomaine-nopeer-00.txt From woody at pch.net Sun Nov 3 18:57:29 2002 From: woody at pch.net (Bill Woodcock) Date: Sun, 3 Nov 2002 10:57:29 -0800 (PST) Subject: Last Call: NOPEER community for BGP route scope control to BCP In-Reply-To: <200211031606.LAA09183@ietf.org> Message-ID: > The IESG has received a request from the Prefix Taxonomy Ongoing > Measurement & Inter Network Experiment Working Group to consider NOPEER > community for BGP route scope control > as a BCP. > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. I would like to express my support for moving this draft forward to BCP. -Bill Woodcock From jfletcher at proficient.net Thu Nov 7 18:13:03 2002 From: jfletcher at proficient.net (Justin Fletcher) Date: 07 Nov 2002 10:13:03 -0800 Subject: Last Call: NOPEER community for BGP route scope control to BCP In-Reply-To: <1079106364.20021104000240@psg.com> References: <1079106364.20021104000240@psg.com> Message-ID: <1036692784.2228.123.camel@riga> > The IESG has received a request from the Prefix Taxonomy Ongoing > Measurement & Inter Network Experiment Working Group to consider NOPEER > community for BGP route scope control > as a BCP. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg at ietf.org or ietf at ietf.org mailing lists by 2002-11-17. I believe this should be considered as an experimental rather than a BCP. It does not document current practice and requires implementation by router vendors before it can be adopted into practice. Other issues: The community field should be previously assigned by IANA and defined in the document. There's a large motivation section, but no implementation section (what do I do with NOPEER if receive it?) The paragraph This approach allows an originator of a prefix to attach a commonly defined policy to a route prefix, indicate that a route should be re-advertised conditionally, based on the characteristics of the inter-AS connection. does not define the conditions under which a route should be re-advertised. Without such, I don't see a difference between NOPEER and NO-ADVERTISE. There should at least be references to RFC1771 and RFC1997. I'd like a clear definition of "bilateral inter-AS peering" early in the document. Best, Justin Fletcher Proficient Networks, Inc. From pekkas at netcore.fi Thu Nov 7 19:46:40 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 7 Nov 2002 21:46:40 +0200 (EET) Subject: Last Call: NOPEER community for BGP route scope control to BCP In-Reply-To: <1036692784.2228.123.camel@riga> Message-ID: On 7 Nov 2002, Justin Fletcher wrote: > > The IESG has received a request from the Prefix Taxonomy Ongoing > > Measurement & Inter Network Experiment Working Group to consider NOPEER > > community for BGP route scope control > > as a BCP. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg at ietf.org or ietf at ietf.org mailing lists by 2002-11-17. > > I believe this should be considered as an experimental rather than a > BCP. It does not document current practice and requires implementation > by router vendors before it can be adopted into practice. Actually, I don't think this requires _anything_ from router vendors. Taking this into use is, of course, a bit easier if there's something in the routers, but I believe the "promise" of the mechanism is just to specify how to use a new well-known community. Well, seeing that there are different assumptions on this, I believe text should be clarified a bit (one way or the other). > Other issues: > > The community field should be previously assigned by IANA and defined in > the document. > > There's a large motivation section, but no implementation > section (what do I do with NOPEER if receive it?) Do you think example route-map statements are necessary? > The paragraph > > This approach allows an originator of a prefix to attach a commonly > defined policy to a route prefix, indicate that a route should be > re-advertised conditionally, based on the characteristics of the > inter-AS connection. > > does not define the conditions under which a route should be > re-advertised. Without such, I don't see a difference between > NOPEER and NO-ADVERTISE. A route-map is quite an explicit condition. > There should at least be references to RFC1771 and RFC1997. Agreed. > I'd like a clear definition of "bilateral inter-AS peering" > early in the document. Agreed. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From iesg-secretary at ietf.org Thu Nov 7 20:11:40 2002 From: iesg-secretary at ietf.org (The IESG) Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: Note Well Statement Message-ID: <200211072011.PAA08965@ietf.org> >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From curtis at fictitious.org Thu Nov 7 22:59:14 2002 From: curtis at fictitious.org (Curtis Villamizar) Date: Thu, 07 Nov 2002 17:59:14 -0500 Subject: Last Call: NOPEER community for BGP route scope control to BCP In-Reply-To: Your message of "07 Nov 2002 10:13:03 PST." <1036692784.2228.123.camel@riga> Message-ID: <200211072259.RAA25608@workhorse.fictitious.org> In message <1036692784.2228.123.camel at riga>, Justin Fletcher writes: > > The IESG has received a request from the Prefix Taxonomy Ongoing > > Measurement & Inter Network Experiment Working Group to consider NOPEER > > community for BGP route scope control > > as a BCP. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg at ietf.org or ietf at ietf.org mailing lists by 2002-11-17. > > I believe this should be considered as an experimental rather than a > BCP. It does not document current practice and requires implementation > by router vendors before it can be adopted into practice. > > Other issues: > > The community field should be previously assigned by IANA and defined in > the document. > > There's a large motivation section, but no implementation > section (what do I do with NOPEER if receive it?) The ISP configures policy (a single statement) based on the NOPEER BGP community. What the policy does is not sufficiently specified. > The paragraph > > This approach allows an originator of a prefix to attach a commonly > defined policy to a route prefix, indicate that a route should be > re-advertised conditionally, based on the characteristics of the > inter-AS connection. > > does not define the conditions under which a route should be > re-advertised. Without such, I don't see a difference between > NOPEER and NO-ADVERTISE. The semantics are not defined. A customer sends NO-ADVERTISE. A peer sends NOPEER. I would imagine that a customer sending NOPEER would go out of the immediate AS (NOPEER and current AS as the only AS in the path is exported) but no further. If this is what is intended the draft doesn't say so. > There should at least be references to RFC1771 and RFC1997. > > I'd like a clear definition of "bilateral inter-AS peering" > early in the document. > > Best, > Justin Fletcher > Proficient Networks, Inc. I agree with your comments regarding inadequate specification of implementation. This draft has a good motivation but semantics need to be clearly defined. It is also not a BCP since it is not a current practice (unless Geoff is already doing this with his peers, which I doubt). Curtis From jfletcher at proficient.net Fri Nov 8 22:54:04 2002 From: jfletcher at proficient.net (Justin Fletcher) Date: 08 Nov 2002 14:54:04 -0800 Subject: Last Call: NOPEER community for BGP route scope control to BCP In-Reply-To: References: Message-ID: <1036796044.2228.194.camel@riga> > > > > There's a large motivation section, but no implementation > > section (what do I do with NOPEER if receive it?) > > Do you think example route-map statements are necessary? I believe examples of how this would be applied and what the affect on advertisements would be very helpful; I'd suggest they be as generic as possible rather than a vendor-specific implementation. Justin Fletcher Proficient Networks, Inc. From jabley at automagic.org Tue Nov 12 23:36:10 2002 From: jabley at automagic.org (Joe Abley) Date: Tue, 12 Nov 2002 18:36:10 -0500 Subject: Last Call: NOPEER community for BGP route scope control to BCP In-Reply-To: <1036796044.2228.194.camel@riga> Message-ID: <85E2652E-F697-11D6-9B14-00039312C852@automagic.org> On Friday, Nov 8, 2002, at 17:54 Canada/Eastern, Justin Fletcher wrote: >>> >>> There's a large motivation section, but no implementation >>> section (what do I do with NOPEER if receive it?) >> >> Do you think example route-map statements are necessary? > > I believe examples of how this would be applied and what the affect > on advertisements would be very helpful; I'd suggest they be as generic > as possible rather than a vendor-specific implementation. There is a standards-track way to represent such policy in the form of RPSL, although it's debatable whether that would be more useful to operators than (say) a sample IOS config and a sample JUNOS config. From randy at psg.com Thu Nov 14 20:48:24 2002 From: randy at psg.com (Randy Bush) Date: Thu, 14 Nov 2002 12:48:24 -0800 Subject: draft-ietf-ptomaine-nopeer-00.txt Message-ID: on todday's iesg call, a number of folk were concerned about the issues raised in smb's comment below. i think it is a legitimate issue. randy --- From: "Steven M. Bellovin" The Security Considerations section is a bit scary. It says, in effect, "this makes an existing attack worse". Do we really want that? Absent something like sbgp, one defense is monitoring AS paths to important destinations -- this can, to some extent, prevent such monitoring. In a separate vein, routing games are useful adjuncts to eavesdropping and MITM attacks (if no crypto us used), not just DoS attacks. That should be clarified. From gih at telstra.net Fri Nov 15 03:44:14 2002 From: gih at telstra.net (Geoff Huston) Date: Fri, 15 Nov 2002 14:44:14 +1100 Subject: draft-ietf-ptomaine-nopeer-00.txt In-Reply-To: Message-ID: <5.1.0.14.2.20021115143819.02106d20@kahuna.telstra.net> At 12:48 PM 11/14/2002 -0800, Randy Bush wrote: >on todday's iesg call, a number of folk were concerned about the >issues raised in smb's comment below. i think it is a legitimate >issue. > >randy > >--- > >From: "Steven M. Bellovin" > >The Security Considerations section is a bit scary. It says, in >effect, "this makes an existing attack worse". Do we really want that? >Absent something like sbgp, one defense is monitoring AS paths to >important destinations -- this can, to some extent, prevent such >monitoring. > >In a separate vein, routing games are useful adjuncts to eavesdropping >and MITM attacks (if no crypto us used), not just DoS attacks. That >should be clarified. Randy had already forwarded this comment to me a few days ago, and my response at the time went along the following lines: Obviously I'd be interested in comments from the WG on wording that can be used in the Security Considerations section that would address Steve's concerns. Geoff --- My original response Not quite - it says "adoption of use of this attribute can allow yet another form of attack within BGP." In terms of truth in advertising, yes, I believe that this statement is an accurate portrayal of the situation. The next question was "Do we really want that?" And the ideal response is that no, what we would all want us a more secure form of operating inter-domain routing that allows others to identify and discard attempts to inject false information. There are way too many games that can be played in BGP to create all kinds of havoc, and I'm sure that I can dream up only a small proportion of the attack vulnerabilities in the eBGP space, and that the true extent of our vulnerabilities in this area is a sobering thought. NOPEER is a very small and very modest contribution to the BGP environment and its motive is to allow operators some additional capability to limit the propagation of Traffic-Engineering-motivated small prefix advertisements into the broader eBGP world. The intent is to assist in limiting massive growth rates in the eBGP space as a palliative measure to assist in scaling. The downside is that BGP has no clean way to verify and validate the information that is being exchanged acorss any arbitrary eBGP session, and any mechanism to allow an originator to scope the extent of a route advertisement allows an attacker to scope the extent of an attack vector. Now that's a pretty large problem with BGP and this draft does not pretend that the problem does not exist, nor does it pretend that this particular attribute assists with BGP verification and validity. I believe that there is a very real operations / routing / security issue with BGP as practised today. To what extent we want to focus effort on this to the exclusion of all other inter-domain routing activities is an open question. Adding more knobs and whistles to BGP while we are still pondering what is required in the security and integrity may not be wise. Just a few thoughts in any case From mknopper at cisco.com Fri Nov 15 06:35:31 2002 From: mknopper at cisco.com (Mark Knopper) Date: Fri, 15 Nov 2002 01:35:31 -0500 Subject: ptomaine wg agenda for Atlanta Message-ID: Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) TUESDAY, Nov. 19 at 1545-1645 ======================================= CO-CHAIRS: Sean Doran Mark Knopper PROPOSED AGENDA: 0. Agenda bashing and administrivia 1. WG documents - 15 mins a. draft-ietf-ptomaine-nopeer-00.txt (Geoff) b. draft-ietf-ptomaine-bgp-redistribution-01.txt (Andrew Lange) c. bounded longest match draft - (Russ White) 2. WG charter (5 mins) 3. Cengiz talk (London Internet Exchange - data analysis) - 20 mins 4. Geoff talk - CIDR report www.cidr-report.org - 20 mins From randy at psg.com Fri Nov 15 21:35:44 2002 From: randy at psg.com (Randy Bush) Date: Fri, 15 Nov 2002 16:35:44 -0500 Subject: Comments References: Message-ID: > As far as the IANA Considerations section, shouldn't it say > something more like the following: > > 4. IANA considerations > > This document defines new BGP well-known transitive community > field in section xxxx. IANA is requested to register XXXX > upon publication of this document. > > ....or something like that. > > I can't really tell which registry this should go in, the name > of the field should be included in the IANA Considerations section, > etc. i think you are correct randy From andrewl at xix-w.bengi.exodus.net Mon Nov 18 22:29:52 2002 From: andrewl at xix-w.bengi.exodus.net (andrewl at xix-w.bengi.exodus.net) Date: Mon, 18 Nov 2002 14:29:52 -0800 Subject: ptomaine wg agenda for Atlanta In-Reply-To: ; from mknopper@cisco.com on Fri, Nov 15, 2002 at 01:35:31AM -0500 References: Message-ID: <20021118142952.A18524@demiurge.exodus.net> > Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) > > TUESDAY, Nov. 19 at 1545-1645 > ======================================= > > CO-CHAIRS: Sean Doran > Mark Knopper > > PROPOSED AGENDA: > > 0. Agenda bashing and administrivia > > 1. WG documents - 15 mins > a. draft-ietf-ptomaine-nopeer-00.txt (Geoff) > b. draft-ietf-ptomaine-bgp-redistribution-01.txt (Andrew Lange) Since I, unfortunately, will not be in Atlanta for this meeting, I'll give my update to the list. During the Yokohama meeting we discussed the possibility that the current idr extended communities draft might undergo alterations before it is standardized. In the idr meeting, I outlined a proposal for an new, more flexible and extensible community type. My proposal received a good response, however, we decided that since current extended communities are well deployed in RFC2547 BGP VPN's that replacing them would be impractical. Instead, the new community propsal will be written up as a seperate draft documenting third-generation communities. This draft will be forthcomming. Since extended communties will likely be advanced in one form or another to RFC at some point there doesn't seem to be any reason to hold up discussion of the redist draft pending idr work. We should continue our discussion of the technical and practical merits of the redist draft. Andrew From lear at cisco.com Wed Nov 20 18:45:16 2002 From: lear at cisco.com (Eliot Lear) Date: Wed, 20 Nov 2002 10:45:16 -0800 Subject: draft-ietf-ptomaine-nopeer-00 Message-ID: <3DDBD83C.7090002@cisco.com> My question from the BoF. Is *anyone* planning to deploy this? Thanks, Eliot From ttauber at genuity.net Wed Nov 20 19:31:43 2002 From: ttauber at genuity.net (Tony Tauber) Date: Wed, 20 Nov 2002 14:31:43 -0500 (EST) Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: <3DDBD83C.7090002@cisco.com> Message-ID: On Wed, 20 Nov 2002, Eliot Lear wrote: > My question from the BoF. Is *anyone* planning to deploy this? So, would it count if someone were already to have a community (or two) that customers can use to control the redist. of their prefixes, but it's not the well-known one? Tony From jhaas at nexthop.com Wed Nov 20 20:07:08 2002 From: jhaas at nexthop.com (Jeffrey Haas) Date: Wed, 20 Nov 2002 15:07:08 -0500 Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: ; from ttauber@genuity.net on Wed, Nov 20, 2002 at 02:31:43PM -0500 References: <3DDBD83C.7090002@cisco.com> Message-ID: <20021120150708.B29057@nexthop.com> On Wed, Nov 20, 2002 at 02:31:43PM -0500, Tony Tauber wrote: > So, would it count if someone were already to have a community (or > two) that customers can use to control the redist. of their prefixes, > but it's not the well-known one? The problem with those is that this is meant to be far more transitive than other internal communities. I would suspect that this may reach 2-3 as hops away from the person who attaches the community while current globally well known ones, such as NO_EXPORT, etc. only go as far as the first AS. > Tony -- Jeff Haas NextHop Technologies From vijay at umbc.edu Wed Nov 20 22:01:58 2002 From: vijay at umbc.edu (Vijay Gill) Date: Wed, 20 Nov 2002 17:01:58 -0500 Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: <3DDBD83C.7090002@cisco.com> Message-ID: On Wed, 20 Nov 2002, Eliot Lear wrote: > My question from the BoF. Is *anyone* planning to deploy this? > Not AOL /vijay From gih at telstra.net Wed Nov 20 22:23:49 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 21 Nov 2002 09:23:49 +1100 Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: References: <3DDBD83C.7090002@cisco.com> Message-ID: <5.1.0.14.2.20021121092011.02018658@localhost> At 05:01 PM 11/20/2002 -0500, Vijay Gill wrote: >On Wed, 20 Nov 2002, Eliot Lear wrote: > > > My question from the BoF. Is *anyone* planning to deploy this? > > sorry, not empowered to answer definitively on behalf of my employer. otoh, in a competitive upstream market where providing various forms of control mechanisms to customers to allow the customer to engineer various forms of policy-based solutions, then it is conceivable that support of such a routing option is not inconsistent with such a general objective. Geoff Huston From lear at cisco.com Thu Nov 21 05:04:49 2002 From: lear at cisco.com (Eliot Lear) Date: Wed, 20 Nov 2002 21:04:49 -0800 Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: <5.1.0.14.2.20021121092011.02018658@localhost> References: <3DDBD83C.7090002@cisco.com> <5.1.0.14.2.20021121092011.02018658@localhost> Message-ID: <3DDC6971.9090109@cisco.com> Geoff Huston wrote: > otoh, in a competitive upstream market where providing various forms of > control mechanisms to customers to allow the customer to > engineer various forms of policy-based solutions, then it is conceivable > that support of such a routing option is not inconsistent with such > a general objective. While I appreciate your response, Geoff, (even if I don't completely understand it), let me clarify my question. In order to label NOPEER a Best Current Practice it would seem appropriate (a) that it be Best and (b) that it be a current practice. Best is, of course, subject to debate. However, "current practice" would indicate that people had either implemented it or will do so in the future. Eliot From crimson at gweep.net Thu Nov 21 22:59:17 2002 From: crimson at gweep.net (Joe Provo) Date: Thu, 21 Nov 2002 17:59:17 -0500 Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: <20021120150708.B29057@nexthop.com> References: <3DDBD83C.7090002@cisco.com> <20021120150708.B29057@nexthop.com> Message-ID: <20021121225917.GA18219@gweep.net> On Wed, Nov 20, 2002 at 03:07:08PM -0500, Jeffrey Haas wrote: > On Wed, Nov 20, 2002 at 02:31:43PM -0500, Tony Tauber wrote: > > So, would it count if someone were already to have a community (or > > two) that customers can use to control the redist. of their prefixes, > > but it's not the well-known one? > > The problem with those is that this is meant to be far more transitive > than other internal communities. I would suspect that this may > reach 2-3 as hops away from the person who attaches the community > while current globally well known ones, such as NO_EXPORT, etc. > only go as far as the first AS. Transitive comunities do exist in multi-AS providers' environments (701 customers can influence route policy at edges of 702, etc). Considering the number of "make me prepend at my edge", "send to customers only", "send to customers but not tagged as your customer", etc communities that are deployed in provider-specific manners, end users are counting up as-paths, making policy configurations and tweaks per-provider. Certainly the ability to smooth out the per-provider configurations can only help reduce complexity and therefore reduce the oft-cited operator-induced errors? Does that make it "best current"? I don't know - I stayed out of arguments of that lingo when 1597 and 1627 begat 1918. The only "current" I can think of off the top is 70x example; I know Level3 had communities that were transitive between their ASNs as well, but they no longer run multi-ASN. Does this translate to people operating at a distance through peers? I don't know, but there are networks who do handle MEDs and deaggregates with peers on an as-agreed basis. Would that be considered prior art for operating at a distance through peers? Cheers, Joe -- crimson at sidehack.gweep.net * jprovo at gnu.ai.mit.edu * jzp at rsuc.gweep.net RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From kurtis at kurtis.pp.se Sat Nov 23 18:30:59 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sat, 23 Nov 2002 19:30:59 +0100 Subject: draft-ietf-ptomaine-nopeer-00 In-Reply-To: <20021121225917.GA18219@gweep.net> Message-ID: > Does that make it "best current"? I don't know - I stayed out of > arguments of that lingo when 1597 and 1627 begat 1918. The only > "current" I can think of off the top is 70x example; I know Level3 > had communities that were transitive between their ASNs as well, but > they no longer run multi-ASN. > KPNQwest was also using transitive communities for our network. Each country had it's own AS with various communities defined. This was transited over our backbone AS. Best regards, - kurtis -