Many ISPs publish community lists that go above-and-beyond standard route selection. Is there a standard for this? ie. I want my clients to utilize my s/rtbh setup as they see fit, for themselves. I'd also like my upstreams to do the same if necessary. Is there a consensus on which communities are used for these purposes? If so, which ones? otoh, is there such an engineer/network that has a client that they trust so much that they'd enable them to null a block for you globally, via community list? Steve
I don't know about anyone else, but I use: 9999:9999 for local rtbh 9999:8888 for local + remote rtbh Basically, whether I should blockhole the traffic to a capture box on my network for user analysis -OR- whether I should blackhole within my network AND make a best effort to blackhole within my direct peers as well. Its obviously a sticky case since some of my direct peers don't support blackhole routing. I allow users to signal either case to me and I also offer to inject the routes on their behalf. I didn't have much reason for selecting 9999 other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks. brad On Jul 19, 2010, at 5:52 PM, Steve Bertrand wrote:
Many ISPs publish community lists that go above-and-beyond standard route selection.
Is there a standard for this?
ie. I want my clients to utilize my s/rtbh setup as they see fit, for themselves. I'd also like my upstreams to do the same if necessary.
Is there a consensus on which communities are used for these purposes? If so, which ones?
otoh, is there such an engineer/network that has a client that they trust so much that they'd enable them to null a block for you globally, via community list?
Steve
On (2010-07-19 23:45 -0500), Brad Fleming wrote: Hey,
9999:9999 for local rtbh 9999:8888 for local + remote rtbh
I didn't have much reason for selecting 9999 other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks.
I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS9999 might want to use 9999 to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility. Hopefully future community (*wink*wink*blink*blink* Raszuk) standards will explicitly state that this is faux pas. -- ++ytti
On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote:
On (2010-07-19 23:45 -0500), Brad Fleming wrote:
Hey,
9999:9999 for local rtbh 9999:8888 for local + remote rtbh
I didn't have much reason for selecting 9999 other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks.
I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS9999 might want to use 9999 to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility.
IMO, any reasonable routing policy would reset all BGP communities on ingress (and MEDs for that matter), whether from a customer or peer, as transiting stuff that has varying semantic interpretations, unknown propagation scope, or relying on others to act on non-mandatory not-well-known communities that may not even be propagated in some BGP configurations as a matter of default behavior, is a simple recipe for nondeterministic behavior, more senseless path attribute tuples in the global routing system, resulting in less efficient BGP update packing, and may even result in security issues. And customer ingress policy can always be crafted to accommodate the upstream special handling policies for RFC1998+ functions, as well as source and destination-based RTBH and other capabilities, across one or more ISPs, even if they vary. There have been some spirited discussions on the specification of more well-known communities for functions related to this and other applications in various IETF working groups, from IDR and GROW to OPSEC and L3VPN, for those interested in having a gander... -danny
On Tue, Jul 20, 2010 at 09:34:40AM -0600, Danny McPherson wrote:
On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote:
On (2010-07-19 23:45 -0500), Brad Fleming wrote:
Hey,
9999:9999 for local rtbh 9999:8888 for local + remote rtbh
I didn't have much reason for selecting 9999 other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks.
I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS9999 might want to use 9999 to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility.
IMO, any reasonable routing policy would reset all BGP communities on ingress (and MEDs for that matter), whether from a customer or peer, as transiting stuff that has varying semantic interpretations, unknown propagation scope, or relying on others to act on non-mandatory not-well-known communities that may not even be propagated in some BGP configurations as a matter of default behavior, is a simple recipe for nondeterministic behavior, more senseless path attribute tuples in the global routing system, resulting in less efficient BGP update packing, and may even result in security issues.
We're still seeing buffer overflows, so people obviously fail to generalize about sanitizing input. One would think the need is more obvious for signalling protocols, but expecting people to DTRT often results in disappointment. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
participants (5)
-
Brad Fleming -
Danny McPherson -
Joe Provo -
Saku Ytti -
Steve Bertrand