Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? Adrian
At 09:23 AM 11/9/2006, you wrote:
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days?
We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
On Thursday 09 November 2006 08:26, Robert Boyle wrote:
At 09:23 AM 11/9/2006, you wrote:
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days?
We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details.
-Robert
Believe you are thinking of Team Cmyru at http://www.cymru.com/Bogons/ They support BGP peering I believe. -- Larry Smith SysAd ECSIS.NET sysad@ecsis.net
On Thu, Nov 09, 2006 at 09:26:13AM -0500, Robert Boyle wrote:
At 09:23 AM 11/9/2006, you wrote:
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days?
We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details.
I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged. The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them.... Steve
steve@telecomplete.co.uk writes:
On Thu, Nov 09, 2006 at 09:26:13AM -0500, Robert Boyle wrote:
At 09:23 AM 11/9/2006, you wrote:
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days?
We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details.
I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged.
The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them....
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. ---rob
Robert E. Seastrom wrote:
steve@telecomplete.co.uk writes:
On Thu, Nov 09, 2006 at 09:26:13AM -0500, Robert Boyle wrote:
At 09:23 AM 11/9/2006, you wrote:
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days?
We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details.
I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged.
The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them....
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice. Andrew
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice. Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why
traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list. If this was done through a central repository and updated daily, or required the list to be refreshed periodically otherwise it timed out- fine. The problem is people leave these lists in and forget about them. If you are going to keep on top of them, and make sure to remove them when you leave- then that's great. But if you are going to do it half way- please don't bother. -Don
On Thu, 9 Nov 2006, Donald Stahl wrote:
Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list.
This process can be automated. See my previous post. jms
On Thu, Nov 09, 2006 at 12:13:57PM -0500, Justin M. Streiner wrote:
On Thu, 9 Nov 2006, Donald Stahl wrote:
Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list.
This process can be automated. See my previous post.
automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to Steve
At 06:58 PM 11/9/2006, you wrote:
automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to
Since I am the OP, I never said that filtering bogons was a miracle cure all. If we put static bogon filters on customer routers, I would agree that would be stupid and would cause maintenance and routing problems. As an ISP several assignments from formerly bogon blocks, I agree and understand your point. However, we are religious about updating our bogon filters and we never block legitimate traffic or announcements. Bogon filtering is just one thing among many which I think should be done. Following BCP38 and filtering what comes in from customers and transit/peer connections all help to ensure that you aren't part of the problem to the community or to your own clients. The original poster who I replied to stated that it appeared that some traffic of unknown origin on a private address was being routed across his network between routers and he didn't have any routes for that network in his routing tables. My response was that those announcements and traffic should be filtered at his edge. This turned into a thread about whether filtering was a good thing or not which in my mind is absurd. However, if you run a network and want to accept traffic from bogon and RFC1918 space over your customer, peering, and transit connections then that's your problem. I just choose to not make it mine. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
On Fri, Nov 10, 2006 at 01:25:05AM -0500, Robert Boyle wrote:
At 06:58 PM 11/9/2006, you wrote:
automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to
Since I am the OP, I never said that filtering bogons was a miracle cure all. If we put static bogon filters on customer routers, I would agree that would be stupid and would cause maintenance and routing problems. As an ISP several assignments from formerly bogon blocks, I agree and understand your point. However, we are religious about updating our bogon filters and we never block legitimate traffic or announcements. Bogon filtering is just one thing among many which I think should be done. Following BCP38 and filtering what comes in from customers and transit/peer connections all help to ensure that you aren't part of the problem to the community or to your own clients. The original poster who I replied to stated that it appeared that some traffic of unknown origin on a private address was being routed across his network between routers and he didn't have any routes for that network in his routing tables. My response was that those announcements and traffic should be filtered at his edge. This turned into a thread about whether filtering was a good thing or not which in my mind is absurd. However, if you run a network and want to accept traffic from bogon and RFC1918 space over your customer, peering, and transit connections then that's your problem. I just choose to not make it mine.
We may be talking at cross purposes... BGP filtering using bogon lists affects the routes you receive and hence whether or not you are willing to send traffic TO that space. If you want to not 'accept traffic FROM bogon and RFC1918 space' then you need to apply acls or rpf. My issue with BGP filtering is primarily related to manually built filters, there is evidence that this practice is harmful. Whether automatically built filters is a good idea is up to you, the current feeling seems to be yes altho personally I dont implement it. WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space. I still would advise tho that there is a lot of address space in use but ot announced on the internet, add to that the use of RFC1918 on internal network links and the potential to break things such as pmtu by dropping icmps is real. Steve
WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space.
Your comment implies that ACLs are static and must be configured manually. In this day and age of automated systems, that is no longer true. Anyone who wants to can easily implement dynamic ACLs. They will be slightly less dynamic than a routing protocol, but ACLs do not have to be manually configured and do not have to be static. Of course, on some hardware ACLs have a significant CPU impact, but that is less of a factor than it used to be. --Michael Dillon
On Fri, Nov 10, 2006 at 01:18:02PM +0000, Michael.Dillon@btradianz.com wrote:
WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space.
Your comment implies that ACLs are static and must be configured manually. In this day and age of automated systems, that is no longer true. Anyone who wants to can easily implement dynamic ACLs. They will be slightly less dynamic than a routing protocol, but ACLs do not have to be manually configured and do not have to be static.
Of course, on some hardware ACLs have a significant CPU impact, but that is less of a factor than it used to be.
for the purpose of scope tho we have to imagine this is a large ISP looking at every one of its border links to peers and transits given that, your options for suitable deployments are a lot more limited Steve
<andrew2@one.net> writes:
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice.
On the other hand, compulsive hand washing has never been shown to keep disease away, and may actually cause dry skin and other unintended side effects. ---Rob
Robert E. Seastrom wrote:
<andrew2@one.net> writes:
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice.
On the other hand, compulsive hand washing has never been shown to keep disease away, and may actually cause dry skin and other unintended side effects.
Speaking as someone with a degree in Molecular Biology (gasp!) the dry/damaged skin can actually be a way to increase the susceptibility to bacterium/virons. As for bogon filtering...when there is a perfectly good, perfectly responsible bogon source you can BGP peer with that is rigorous in its maintenance of good data... why fight it? Sanity check their feed, call it a day. Maintaining your own bogon list is a nightmare. Someone (years ago) said... why would I want to pay to move bogon traffic across my network when its only going to get dropped by the next hop anyway -- as a justification for filtering bogons. Deepak
* rs@seastrom.com (Robert E. Seastrom) [Thu 09 Nov 2006, 16:02 CET]: [..]
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
Yeah! This "Principle of minimal privilege" is totally not applicable to real, live networks... -- Niels.
Niels Bakker <niels=nanog@bakker.net> writes:
* rs@seastrom.com (Robert E. Seastrom) [Thu 09 Nov 2006, 16:02 CET]: [..]
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
Yeah! This "Principle of minimal privilege" is totally not applicable to real, live networks...
I'm not sure what principle of minimal privilege has to do with filtering addresses that are known unissued. Seems to me that the principle of minimal privilege would allow connections only from addresses from which you are specifically expecting them, not from "the internet at large minus a few blocks that aren't issued". Particularly in the case of spam abatement, where the vast majority of spam comes from compromised Windows hosts (which are probably *not* residing on unissued space), I can't see the point. We could get into some kind of meta-discussion about DoS attacks and the like, but at that point you probably want your upstream doing the filtering for you before it clogs your links. Bottom line: my gut feeling is that the threat that unissued "bogon" space poses pales in comparison to the Bad Neighborhood that is the Internet. I would welcome a pointer to some kind of actual research that shows this to be incorrect. Of course, bogon filtering is a fine security blanket for those whose scope of knowledge is not sufficient to perform a meaningful threat/risk assessment. As for me, I prefer to rivet horseshoes (open end up, to catch the good luck falling from above) to the cable tray above my racks. Oh yeah, religiously adhering to BCP-38 as well, that brings luck too. ---Rob
The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them....
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
I think there is a terminology problem here. People think that "bogons" means "bogus routes". From that they infer that bogus routes should be filtered and use the Cymru feed because it seems to be a no-brainer. The problem arises because the Cymru feed only contains the low-hanging fruit. It only refers to address ranges that *might* be bogus and which are easy to identify. The problem is that if you pick this fruit, it soon goes rotten and you end up filtering address ranges which are in use and almost certainly not bogus. If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed. But at the present time, such a feed does not exist. Also, I think that anyone contemplating creating a new feed should give some thought to what they are doing. It would be very useful to have a feed or database which can assign various attributes to address ranges. When there is only one possible attribute, bogon, then the meaning of the attribute gets stretched and the feed becomes useless. But if there are many attributes such as UNALLOCATED, UNASSIGNED, DOS-SOURCE, SPAM-SOURCE, RIR-REGISTERED then it starts to look interesting. Some networks might like to filter based on several attributes, others will just filter those with the DOS-SOURCE attribute. Obviously, it would require lots of cooperation for some of these such as UNASSIGNED, but perhaps the Internet needs to move towards more cooperation between network operators. --Michael Dillon
On Fri, 10 Nov 2006, Michael.Dillon@btradianz.com wrote:
If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed.
But at the present time, such a feed does not exist.
http://www.cymru.com/BGP/bogon-rs.html Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ VIKING NORTH UTSIRE: SOUTHERLY VEERING WESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. HIGH. RAIN THEN SHOWERS. MODERATE OR GOOD.
If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed.
But at the present time, such a feed does not exist.
That is not a feed of routes that are known to be bogus. That is a feed of routes that use addresses which have not been allocated by IANA to an RIR. There are many bogus routes that are not included in the Cymru feed. For instance, RIR address ranges that have not yet been allocated ISP address ranges that have not yet been assigned Assigned address ranges that are not announced by the assignee. Address ranges from which a high percentage of the traffic is SPAM, i.e. a network owned by spammers. I am arguing that it is better to start with a database that allows several attributes, both negative and positive, to be associated with address ranges. Then build a feed from that, in fact, allow the user to specify which attributes they want in their feed. One size fits all just doesn't work. --Michael Dillon
On Fri, Nov 10, 2006 at 12:54:28PM +0000, Michael.Dillon@btradianz.com wrote:
The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them....
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
I think there is a terminology problem here. People think that "bogons" means "bogus routes". From that they infer that bogus routes should be filtered and use the Cymru feed because it seems to be a no-brainer.
The problem arises because the Cymru feed only contains the low-hanging fruit. It only refers to address ranges that *might* be bogus and which are easy to identify. The problem is that if you pick this fruit, it soon goes rotten and you end up filtering address ranges which are in use and almost certainly not bogus.
If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed.
But at the present time, such a feed does not exist.
Also, I think that anyone contemplating creating a new feed should give some thought to what they are doing. It would be very useful to have a feed or database which can assign various attributes to address ranges. When there is only one possible attribute, bogon, then the meaning of the attribute gets stretched and the feed becomes useless. But if there are many attributes such as UNALLOCATED, UNASSIGNED, DOS-SOURCE, SPAM-SOURCE, RIR-REGISTERED then it starts to look interesting. Some networks might like to filter based on several attributes, others will just filter those with the DOS-SOURCE attribute.
how about PORN-SOURCE, COMMUNIST-SOURCE, DEMOCRACY-SOURCE, TERRORIST-SOURCE, RIGHT-WING-CHRISTIAN-SOURCE, COURT-ISSUED-LIBEL-CASE-SOURCE be careful before you open such a pandoras box... will this scale? who will want to use it? can it be exploited? what sort of liability do you take on by becoming responsible for policing the Internet? Steve
how about PORN-SOURCE, COMMUNIST-SOURCE, DEMOCRACY-SOURCE, TERRORIST-SOURCE, RIGHT-WING-CHRISTIAN-SOURCE, COURT-ISSUED-LIBEL-CASE-SOURCE
be careful before you open such a pandoras box...
The box was opened a long time ago. In an Internet context, there are many email blacklists which apply various different criteria for inclusion, therefore, they are essentially publishing different attributes. In a social context, freedom of religion is a long-accepted principle and various religions publish lists of literature that is either acceptable or unacceptable. If a network operator finds a business case for supplying service only to right wing organizations and blocking network traffic from communist sources then what is wrong with that? The principle of the Internet is that network operators run private networks and set their own policies independent of regulators and governments.
will this scale?
The fact that the database has multiple attributes to assign to address ranges makes it more likely to scale.
who will want to use it?
People who find some value in dynamically filtering Internet traffic based on a trusted source for filters.
can it be exploited?
Virtually anything can be exploited. Smart network operators do not hardwire their routers to a 3rd-party BGP feed. Instead they pull that feed into their operational support systems where it can raise alarms so that a human being can decide whether to stop or start filtering a particular range. Or else they make some kind of 2-party binding contract with SLAs and penalties such as a transit contract or a peering agreement.
what sort of liability do you take on by becoming responsible for policing the Internet?
Who said anything about policing the Internet? This is all about identifying address ranges who source various kinds of traffic that some network operators do not wish to transit their networks. Every network operator has an AUP for their own customers and peers. This merely extends that to 3rd parties who wish to transit the network. --Michael Dillon
On Thu, 9 Nov 2006, Adrian Chadd wrote:
On Thu, Nov 09, 2006, Robert Boyle wrote:
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days?
You probably want to have a look at http://www.cymru.com/BGP/bogon-rs.html jms
participants (13)
-
Adrian Chadd -
andrew2＠one.net -
Deepak Jain -
Donald Stahl -
Justin M. Streiner -
Larry Smith -
Michael.Dillon＠btradianz.com -
Niels Bakker -
Robert Boyle -
Robert E. Seastrom -
Stephen Wilcox -
steve＠telecomplete.co.uk
-
Tony Finch