Re: Lazy Engineers and Viable Excuses
--On Tuesday, August 26, 2003 9:35 AM -0400 Leo Bicknell [EMAIL PROTECTED] wrote: Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system I wish this was true but it is not!!! In particular I call your attention to Qwest. Their customer in LA with AS29809 was announcing ip block 138.252.0.0/16, which is hijacked ip block, see details at http://www.completewhois.com/hijacked/files/138.252.0.0.txt It took us a little time to find out who to report it to because amount of abuse was small and all traceroutes were faked, here is part of it as it was several days ago: 8 204.255.169.138 (204.255.169.138) 33.299 ms 28.885 ms 30.188 ms 9 bur-core-01.inet.qwest.net (205.171.13.9) 35.992 ms 28.280 ms 10 bux-edge-01.inet.qwest.net (205.171.13.174) 32.468 ms 30.766 ms 11 tbr1-p012201.la2ca.ip.att.net (12.123.28.130) 40.104 ms -- Faked here 12 gbr4-p20.sffca.ip.att.net (12.122.2.69) 51.680 ms 52.195 ms 50.259 13 gbr6-p70.sffca.ip.att.net (12.122.5.153) 62.751 ms 61.256 ms 14 ar2-p3110.sfcca.ip.att.net (12.123.195.81) 71.827 ms 71.376 ms 15 12.119.200.38 (12.119.200.38) 83.024 ms 82.612 ms 82.004 ms 16 203.148.164.170 (203.148.164.170) 89.747 ms 92.942 ms 87.614 ms 17 203.148.164.228 (203.148.164.228) 103.087 ms 99.536 ms 99.910 ms 18 svoa-bkk.a-net.net.th (203.148.200.145) 1104.594 ms 1098.491 ms 19 138.252.0.1 (138.252.0.1) 33.634 ms 33.220 ms 32.514 ms And that is when sh ip bgp was showing: 8001 7911 209 29809 6395 1239 209 29809 5650 1239 209 29809 From above everything starting with 11 was faked and once this was realized Qwest security was notified and they even said the ip block will be filtered and indeed it was for 1 day!!! But appearently they just started advertising smaller 138.252.0.0/21 ip block from exactly same Qwest POP in Burbank, CA but with new faked traceroute: traceroute to 138.252.0.10 (138.252.0.10), 30 hops max, 38 byte packets ... 5 qwest.sjc03.atlas.psi.net (154.54.10.154) 1.988 ms 1.264 ms 1.243 ms 6 svl-core-01.inet.qwest.net (20r.171.214.41) 2.526 ms 2.229 ms 2.383 ms 7 sbur-core-02.inet.qwest.net (205.171.5.217) 9.491 ms 9.519 ms 9.494 ms 8 bux-edge-01.inet.qwest.net (205.171.13.178) 9.514 ms 9.860 ms 9.467 ms 9 * * * 10 obl-rou-1003.NL.eurorings.net (134.222.229.238) 22.436 ms 18.489 ms 11 ffm-s1-rou-1002.DE.eurorings.net (134.222.230.30) 40.087 ms 47.130 12 ksrh-s1-rou-1071.DE.eurorings.net (134.222.227.86) 39.634 ms 38.361 13 ksrh-s1-rou-1072.DE.eurorings.net (134.222.227.74) 40.083 ms 42.067 14 r1-ka.strato.cust.eurorings.net (134.222.102.18) 39.853 ms 39.022 ms 15 81.169.144.22 (81.169.144.22) 39.770 ms 43.874 ms 39.956 ms 16 81.169.144.38 (81.169.144.38) 60.088 ms 59.179 ms 60.091 ms 17 lb1.webmailer.de (192.67.198.246) 70.123 ms 76.9934ms 69.991 ms router#sh ip bgp 138.252.0.1 BGP routing table entry for 138.252.0.0/21, version 10503636 Paths: (2 available, best #1, not advertised outside local AS) 16631 174 209 29809 216.151.223.17 (metric 65) from 216.151.223.17 Origin IGP, metric 100, localpref 100, weight 500, valid, internal, best Community: 16631:1000 local-AS 6347 701 209 29809 209.144.160.89 from 209.144.160.89 (209.83.159.23) Origin IGP, localpref 100, weight 10, valid, external Community: 6347:1023 6347:5000 6347:5001 local-AS I'm pretty sure Qwest is doing something wrong by allowing such an open BGP annoncements from their customers without checking what they would be announcing. Instead of putting filters as allow all and then adding filtering only 138.252.0.0/16 when they were contacted, they instead should have filtered all announcement except for specific ones customer asked and was authorized. And I do hope there is somebody from Qwest here who can deal with this issue and educate on proper filtering whoever is responsible for their bgp router in Burbank. Also as for this particular case, I'll strongly advise to just filter AS29809 entirely, I have serious doubts about whoever controls this asn and have done the research on it (see above referenced file) and it appears the addresses at ARIN are all wrong (I have some doubts about Trimeda being located on the grounds of Mormon Temple for example...) and has been recently changed from completely different set of addresses and besides it would have been enough that AS29809 only advertises this particular hijacked ip block (and nothing else!) and they on purpose fake traceroute to their AS to move blame away from themselve. Just a shame that not everyone filters their customers. And although it has been a while, I know I've seen a route-leak from 6461 at AMS-IX. (Probably last year sometime) Indeed it really is a shame, especially when its large players like Qwest who do not filter their customers, how can you expect it from smaller European
Re: Lazy Engineers and Viable Excuses
--On Tuesday, August 26, 2003 9:35 AM -0400 Leo Bicknell [EMAIL PROTECTED] wrote: Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system they get depeered and become someone's customer aggressively filtered. The large ISP's then trust each other to do that aggressive filtering. So be careful if you advocate filtering. The IRR, with everyone doing an update for every customer worldwide does not scale, but depeering all the smaller peers and letting a few big guys sort it out does. I don't think that's the result most people pushing filtering want. If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of oops, our customer announced everything to us and we leaked it. Filtering peers is not the way to go. Filtering customers and trusting peers to do the same is. (Whether that trust explictly mentioned in a peering agreement or whatever). Just a shame that not everyone filters their customers. And although it has been a while, I know I've seen a route-leak from 6461 at AMS-IX. (Probably last year sometime)
Re: Lazy Engineers and Viable Excuses
In a message written on Wed, Aug 27, 2003 at 12:15:18AM -0400, John Payne wrote: If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of oops, our customer announced everything to us and we leaked it. Because European naps have more smaller and clueless players. I know more than a few people (because they ask for peering) who have an IRR entry that is 1 prefix for the ISP, and 1 prefix for their only BGP customer. It should be of no surprise they get that customer configured wrong. It should also be of no surprise that most of the real ISP's would never consider peering with those types of networks. Of course, those small and clueless players exist elsewhere, but in general you don't see them connected to exchange points in other parts of the world. Filtering peers is not the way to go. Filtering customers and trusting peers to do the same is. (Whether that trust explictly mentioned in a peering agreement or whatever). You're right, but you missed a part of that solution. ISP's should filter customers, and trust peers to do the same. That also means they need to qualify their peers in some way to insure they aren't peering with someone who doesn't understand that. Just a shame that not everyone filters their customers. And although it has been a while, I know I've seen a route-leak from 6461 at AMS-IX. (Probably last year sometime) 6461 filters all customers by prefix list. Note too, filtering customers does not eliminate route leaks, it just removes the most obvious and often cause. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
--On Wednesday, August 27, 2003 9:36 AM -0400 Leo Bicknell [EMAIL PROTECTED] wrote: In a message written on Wed, Aug 27, 2003 at 12:15:18AM -0400, John Payne wrote: If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of oops, our customer announced everything to us and we leaked it. Because European naps have more smaller and clueless players. I know more than a few people (because they ask for peering) who have an IRR entry that is 1 prefix for the ISP, and 1 prefix for their only BGP customer. It should be of no surprise they get that customer configured wrong. It should also be of no surprise that most of the real ISP's would never consider peering with those types of networks. CAIS (or whatever they're called today - BtNAccess/PCCW) is a small and clueless player? Then why is 6461 peering with 3491? (yeah, that was a customer route leak in July. I tend to just delete such emails, but I'd be surprised if there weren't more in August from ISPs that don't fit into small and clueless) Not everyone filters their customers, and saying that everyone that counts does doesn't make it so. 6461 filters all customers by prefix list. Note too, filtering customers does not eliminate route leaks, it just removes the most obvious and often cause. Really? So how was I able to advertise a new netblock to one of your customers just now and see 6461 their AS my AS on route-views.oregon-ix.net within 2 minutes and without telling a soul what I was doing? You must have some pretty broad prefix lists. (And no, it doesn't make me happy that I was able to do this... there are 2 places that are missing filters in that path). At least I *think* that they are your customer, if not, then you're leaking routes to Sprint and opentransit and telia amongst other places.
Re: Lazy Engineers and Viable Excuses
--On Wednesday, August 27, 2003 9:36 AM -0400 Leo Bicknell [EMAIL PROTECTED] wrote: In a message written on Wed, Aug 27, 2003 at 12:15:18AM -0400, John Payne wrote: If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of oops, our customer announced everything to us and we leaked it. Because European naps have more smaller and clueless players. I know more than a few people (because they ask for peering) who have an IRR entry that is 1 prefix for the ISP, and 1 prefix for their only BGP customer. It should be of no surprise they get that customer configured wrong. It should also be of no surprise that most of the real ISP's would never consider peering with those types of networks. CAIS (or whatever they're called today - BtNAccess/PCCW) is a small and clueless player? Then why is 6461 peering with 3491? (yeah, that was a customer route leak in July. I tend to just delete such emails, but I'd be surprised if there weren't more in August from ISPs that don't fit into small and clueless) there have been leaks by some large networks tier1 if you like you dont know what caused the route leaks tho.. eg modifying cisco route-maps and filters by deleting and re-adding opens a small window of opportunity in which a lot of announcements get through, if your CLI pauses during this window or something causes you to be disconnected its instant route leak i quote the above as i know of more than one occasion where this has occured to bad consequences you can think of others eg the filter building script has a bug in it etc etc better to try and fail than to not try at all imho Not everyone filters their customers, and saying that everyone that counts does doesn't make it so. 6461 filters all customers by prefix list. Note too, filtering customers does not eliminate route leaks, it just removes the most obvious and often cause. Really? So how was I able to advertise a new netblock to one of your customers just now and see 6461 their AS my AS on route-views.oregon-ix.net within 2 minutes and without telling a soul what good question, however as an ex-customer I know MFN do filter.. perhaps you're announcing that many that your being filtered on as-path of prefix count? try announcing something naughty and see if it goes thro eg rfc1918 or the block with windowsupdate on .. that should increase your traffic volume ;p Steve
Re: Lazy Engineers and Viable Excuses
Hey, You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. I don't consider this as lazy. I'd rather consider it as efficiency. Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. IRR is great, and it should be used to maximum extent as possible. I've seen people filtering accordingly to IRR properly, and also seen people creating their own manageable applications that work beatifully on *nix boxes. Announcing filtering list over BGP inside an AS would be efficient management to an extent however... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: Again... If folks were to implement explicit prefix filtering *everywhere* it wouldn't be necessary to filter only bogons and other miscellany explicitly. Something of this sort would only lower the lazy bar (is it possible?) for the clueless and/or lazy (those which Rob's list currently accommodates, which is better than nothing, BUT.. -- no offense Rob, I'm pretty sure our beliefs are aligned here :-). If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits. Is it really that hard? -danny
Re: Lazy Engineers and Viable Excuses
On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe
Re: [Re: Lazy Engineers and Viable Excuses]
Joe Abley [EMAIL PROTECTED] wrote: [cut] .. if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. not perfect, you would still need to filter at the customer ingress, making sure that they weren't spoofing a 'properly registered route object' that wasn't part of the aup that they had signedthey did sign an aup right??? The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. trivial yes, but it would be nice if there was at least a minimal effort to filter unregistered route objects, especially on transit from certain regions of the worldwe can deal with the registration issue separately. /joshua Joe Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
Re: Lazy Engineers and Viable Excuses
On Mon, Aug 25, 2003 at 07:41:34PM -0400, Joe Abley wrote: On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe, You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I think the key here is that filtering is a good thing(tm). People who are not using it as their baseline (with their own custom additions for their own AS based policy decisions of course) are asking for trouble. Hardly a month (or even a week) goes by where I don't see that one of our peers has attempted to leak the routing table to us. max-prefix and peer filtering help mitigate the risks to our network. If you don't trust other IRRs, run your own where you do have a stricter trust model via pgp/gpg. these are both tools that can be used in conjunction with each other and should be. Effort put into the automation of these will pay for itself. Customers will be able to update route objects via the web or via email. Reduced support costs in handling and authenticating requests manually, as well as the ability to audit these either realtime or in a delayed fashion. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Lazy Engineers and Viable Excuses
On Monday, August 25, 2003, at 07:32 PM, Jared Mauch wrote: You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I fully agree with the cart/horse chicken/egg analogy. If SPs began employing IRRs more fully and more work went into commercialization of IRR infrastructure and tools (and perhaps some RIR feedback loop were created) they'd improve. Instead, folks are running about designing new protocols far more complex than BGP already is, that *still* require some authority. When in reality, 99% of the vulnerabilities could have been solved with what was in place 10 years ago. Folks are striving for perfect security, which is fine, but they've ignored the reasons why we don't even have crappy security. -danny
Re: Lazy Engineers and Viable Excuses
At 02:32 26/08/2003, Jared Mauch wrote: On Mon, Aug 25, 2003 at 07:41:34PM -0400, Joe Abley wrote: On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe, You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I think the key here is that filtering is a good thing(tm). People who are not using it as their baseline (with their own custom additions for their own AS based policy decisions of course) are asking for trouble. Hardly a month (or even a week) goes by where I don't see that one of our peers has attempted to leak the routing table to us. max-prefix and peer filtering help mitigate the risks to our network. If you don't trust other IRRs, run your own where you do have a stricter trust model via pgp/gpg. these are both tools that can be used in conjunction with each other and should be. Effort put into the automation of these will pay for itself. Customers will be able to update route objects via the web or via email. Reduced support costs in handling and authenticating requests manually, as well as the ability to audit these either realtime or in a delayed fashion. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Lazy Engineers and Viable Excuses
Joe wrote: Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. There is this widely percieved notion that the IRR is a single, unadministered database. This is incorrect. The Source: field tells the whole story - there are multiple databases, with varying degrees of trust-worthiness, varying content, and varying uses. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. The IRR is the correct tool; what is missing is a little application of the available capabilities of the tool. Here's an example: You have a lot of address space to manage. Some BGP customers, some not. Some worthy of trust, some not. So, you operate your *own* routing registry, and tell the world about it. But, you, and only you, have update access. You mirror the routing registries of only the customers you trust. Your peers operate likewise. Your filter-building accesses the rr's of your peers, either directly, or via a reasonably well-located and well-trusted mirror. Or better yet, you mirror (possibly privately) them, yourself. Any problems with the content of any RR, you know who to contact (and blame). You also now have a mechanism to persuade your peers with, which is the peering agreement you both signed. Update it to include this, if you need to. No cruft, secure enough, no bogons, scalable. Technology that is already well understood, and for which tools have been built. Clear chain of trust, and straightforward means to sever problem servers. I don't see where (other than perhaps attitudes and erroneous assumptions) the problem is. And running a route-registry is *really* no more difficult than querying one, in most cases less so. Certainly less effort than even a small name server serving authoritative data... -- Brian Dickson Email: [EMAIL PROTECTED] http://www.cineclix.comTel : +1 604 688 2339
Re: Lazy Engineers and Viable Excuses
On dinsdag, aug 26, 2003, at 00:22 Europe/Amsterdam, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Is it really that hard? Well, I don't think it's particularly easy. Generating the filters isn't the hard part, but getting them inside routers has always been quite a challenge. But that should be better than it used to be now. By the way, you don't mention filtering based on routing registry information in your book. (I do mention it in mine but don't explain how to do it as I have never done it myself.)
Re: Lazy Engineers and Viable Excuses
On Monday, 25 August 2003, at 21:32PM, Jared Mauch wrote: You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I'm not suggesting that the IRR is not useful. I'm saying that it's important to appreciate what it is good for, and what it is not good for. For example, it would be unfortunate if an ISP used the IRR to build prefix filters for customers as a replacement for a manual scheme in which updates were scrutinised for legitimacy, without an understanding of the implications of the decision. Joe
Re: Lazy Engineers and Viable Excuses
On Mon, 25 Aug 2003, Joe Abley wrote: On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Maybe, however you can fix that.. RIPE for example uses hierarchical authorisation so you cant add a route on a block you are not allocated, the broken part here is that the non-European IRRs are not run by the registry and therefore accept anything.. Steve
RE: Lazy Engineers and Viable Excuses
If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits. Is it really that hard? I can see not filtering peers if the hardware can't handle it, but there doesn't appear to be such a good excuse for not edge filtering. If Barry Green is listening out there, I'd be interested to hear how successful he and his team have been at convincing ISPs to do this. I know he's been on his ISP Security Best Practices world tour for quite a while now, and am curious if he's found it more difficult to get edge filtering implemented vs. other security measures (and if so, why) or if it's just security in general that's difficult to get ISPs to do. Also, are recommendations given for how edge filters should be maintained? This was discussed here a short while ago but I don't think a broad consensus was reached. The mere existence of the filters is nice to prevent AS7007-like incidents but does little to prevent other bad things such as address hijacking if the customer (or someone posing as the customer?) can call the ISP and get holes punched in a filter for address blocks that he/she has no business announcing. It seems that a common practice amongst ISPs who do filter on the edge is to blindly punch holes in these filters when asked without somehow validating the request. Does this negate a significant portion of the advantages gained by edge filtering or are we primarily concerned with accidental/malicious route table leaking at this point? -Terry
Re: Lazy Engineers and Viable Excuses
In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard? Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. The fundamental problem with the IRR Everywhere notion is simple. If everyone filtered everyone, then, drum roll please: Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure. Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes pruned near the edge of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good. While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve. In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote: The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics https://stats.linx.net/cgi-pub/combined?log=combined.bits show about 23 Gig of traffic moves through there on a daily basis. That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined. Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would only serve to drive more medium sized player away from exchange points and to private interconnects with only the largest players. Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system they get depeered and become someone's customer aggressively filtered. The large ISP's then trust each other to do that aggressive filtering. So be careful if you advocate filtering. The IRR, with everyone doing an update for every customer worldwide does not scale, but depeering all the smaller peers and letting a few big guys sort it out does. I don't think that's the result most people pushing filtering want. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, 26 Aug 2003 09:35:57 EDT, Leo Bicknell [EMAIL PROTECTED] said: the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). The first few sites to get allocations from 69/8 would consider it an improvement. pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 09:35:57AM -0400, Leo Bicknell wrote: In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard? Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? http://infopage.cary.cw.net/Routing_Registry/mainpage.html http://info.us.bb.verio.net/routing.html#VRR http://www.irr.net/docs/list.html#LEVEL3 http://www.irr.net/docs/list.html#FGC (you need to replace gctr.net with gblx.net) I'm not able to give you the skitter related metric for the core of the internet as i'm getting connref from http://as-rank.caida.org/cgi-bin/main.pl but please do review it and comb the rest of the list at irr.net to get an idea of how much of the internet actually is doing this and then think about if you're in the majority or the minority. The fundamental problem with the IRR Everywhere notion is simple. If everyone filtered everyone, then, drum roll please: Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure. Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes pruned near the edge of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good. If you misuse the IRR data as you state here, yeah, your network will break. Same thing will happen if you do other bad things in configuring your network policy. This is why network operations are not for those armchair geeks, you can easily cause significant unexpected problems as it relates to this. While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve. Yeah, but that's not what we're attempting to discuss here, we're asking what hurdles (that are not self-errected due to improper policy decisions) that honestly are preventing you from deploying irr type filtering. (or that's what I think danny was trying to ask yesterday) In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote: The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics https://stats.linx.net/cgi-pub/combined?log=combined.bits show about 23 Gig of traffic moves through there on a daily basis. That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined. Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would
Re: Lazy Engineers and Viable Excuses
In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) My rant is on peer-to-peer filtering. Customers should always be filtered by every ISP. Period. ISP's should automate that as much as possible for their customers, and using the IRR is a fine solution. Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? It's a bad thing because it doesn't scale. It's not a matter of before or not, it's that there is a linear relationship between the size of the internet and the processing needed to be done by each ISP. That doesn't scale. Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. No, you couldn't. Please go back and take routing 101 again. Internet routing is asymetrical, the source of the packet has nothing to do with where the return route points in the core. If it were that simple we could just use Unicast RPF on all peering links and spoofing would be a thing of the past. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) I'd have to imagine all those proxy registered routes for sprint prefixes that you see in the LEVEL3 rr are used for something other than consuming disk space. My rant is on peer-to-peer filtering. Customers should always be filtered by every ISP. Period. ISP's should automate that as much as possible for their customers, and using the IRR is a fine solution. Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? It's a bad thing because it doesn't scale. It's not a matter of before or not, it's that there is a linear relationship between the size of the internet and the processing needed to be done by each ISP. That doesn't scale. Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. No, you couldn't. Please go back and take routing 101 again. Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. Internet routing is asymetrical, the source of the packet has nothing to do with where the return route points in the core. If it were that simple we could just use Unicast RPF on all peering links and spoofing would be a thing of the past. Actually, it sounds like you're not that clued on how Juniper handles unicast-rpf at all (for example). It allows you to do unicast-rpf on a per-interface basis for all routes that you receive regardless of if they're installed for forwarding. this means that people could use this and set the necessary community so it doesn't leave the peer router (no-export + no-advertise), or prepended so much it's not used and use that to perform filtering. If best-path for returning the packet is not across the link, it will still not drop this. This is a nice feature on the part of Juniper. http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-interfaces/html/interfaces-family-config17.html#1029493 I suggest you (and others) take a look at these features and use them where possible to mitigate spoofed DoS attacks from your network. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Lazy Engineers and Viable Excuses
In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, 26 Aug 2003, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] Hmm this isnt a real world scenario tho.. if you multihome there should be BGP on both paths.. In the example above Sprint arent accepting or sourcing a route so there is no issue on routes being passed into Sprint or UUNET and we're talking here about spoofing of routes not packets Steve
Re: Lazy Engineers and Viable Excuses
On Tuesday, August 26, 2003, at 11:13 AM, Stephen J. Wilcox wrote: On Tue, 26 Aug 2003, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] Hmm this isnt a real world scenario tho.. if you multihome there should be BGP on both paths.. In the example above Sprint arent accepting or sourcing a route so there is no issue on routes being passed into Sprint or UUNET and we're talking here about spoofing of routes not packets In a real world scenario, I bumped into Verio's RPF peer filters yesterday. Due to the large outage at 200 paul, the /19 that one of my /24's is out of went away. Obviously due to prefix filtering policies, verio didn't have my /24. I had several people complain who were multihomed, and did have the /24 from their other carrier(s). Unfortunately, my best path to these customers was via verio, who's rpf promptly blocked my return traffic :( Steve -- Matt Levine [EMAIL PROTECTED] The Trouble with doing anything right the first time is that nobody appreciates how difficult it was. -BIX
Re: Lazy Engineers and Viable Excuses
On dinsdag, aug 26, 2003, at 17:03 Europe/Amsterdam, Leo Bicknell wrote: Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? You're not saying anything about outgoing route advertisements here so these questions are unanswerable. My position is that if you want to use certain source addresses, you should announce and register the route that goes with those addresses. Expecting the whole world to forego uRPF just because that makes your life easier isn't realistic. However, maybe we're spending too much effort on the whole source address spoofing issue, as stopping this doesn't really solve the core problem, which is how to shut up undesired incoming traffic. Looking up the unspoofed source address in a registry and then email or phone the listed contact isn't exactly a sure fire way to do this. mime-attachment Why???
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 11:29:17AM -0400, Matt Levine wrote: In a real world scenario, I bumped into Verio's RPF peer filters yesterday. Due to the large outage at 200 paul, the /19 that one of my /24's is out of went away. Obviously due to prefix filtering policies, verio didn't have my /24. I had several people complain who were multihomed, and did have the /24 from their other carrier(s). Unfortunately, my best path to these customers was via verio, who's rpf promptly blocked my return traffic :( Speaking about this specific issue, since there was no return path in our RIB/FIB, we dropped the packets, yes. If you were annoucing the /19 or something that fit our filtering policy (in your alternate locations) you would not have had issues. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Lazy Engineers and Viable Excuses
During my tenure at a medium-sized ISP, I found that one of the more painful experiences was trying to assist small or first-time BGP customers in setting themselves up in the IRR and registering their routes. While I would take issue with some posters' comments that maintaining edge filters does not scale, I would certainly support the statement that providing IRR 101 tutorials definitely doesn't scale. For smaller sites, I feel that explicit permit prefix filters are the way to go. At the same time a filter is updated, if the customer was assigned space from one of our blocks, off go both a SWIP and a proxy IRR object. If the space is PA space from another provider, we'd submit a route object after verifying the assignment. In the case of PI space, we *might* take the trouble to give the IRR 101 training if the customer seemed trainable. Somewhere in the growth curve along which a customer increases in both size and credibility, I think there is a case for migrating them from prefix filtering to as-path filtering with a prefix limit. While not preventing any possibility of an illegitimate announcement, it does prevent a 7007 type incident along with scalability.
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) Global Crossing doesn't use the IRR to filter their BGP speaking customers, every prefix-list update gets touched by a human. While their response time is good, and they're generally friendly people, they do have a tendancy to prove that they are human by forgetting or typoing a random route with nearly every other update. When you start getting into the hundreds of routes, personally I will go through the trouble to maintain IRR entries any day vs letting humans break stuff. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Lazy Engineers and Viable Excuses
* Richard A Steenbergen said: On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) Global Crossing doesn't use the IRR to filter their BGP speaking customers, every prefix-list update gets touched by a human. While their response time is good, and they're generally friendly people, they do have a tendancy to prove that they are human by forgetting or typoing a random route with nearly every other update. When you start getting into the hundreds of routes, personally I will go through the trouble to maintain IRR entries any day vs letting humans break stuff. As is usual with most things, it's not black and white. It's a sticky position that some major providers find themselves in. A lot of customers do not maintain their IRR objects or even have them at all. The traction would have to come from the provider themselves in a lot of cases, but then customers are apt to complain when a major provider registers 'their' routes on an IRR ... kinda like a dog peeing on a hydrant, some customers tend to think registration means a kind of ownership claim. -Steve
Re: Lazy Engineers and Viable Excuses
At 19:08 -0400 8/25/03, Haesu wrote: Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available. (Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: Lazy Engineers and Viable Excuses
That is true, although distributed route-servers that serve specific region may be easier dealing with emergencies (i.e. local POP(s) having emergency situation etc) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Aug 26, 2003 at 12:36:09PM -0400, Edward Lewis wrote: At 19:08 -0400 8/25/03, Haesu wrote: Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available. (Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: Lazy Engineers and Viable Excuses
Somewhere in the growth curve along which a customer increases in both size and credibility, I think there is a case for migrating them from prefix filtering to as-path filtering with a prefix limit. While not preventing any possibility of an illegitimate announcement, it does prevent a 7007 type incident along with scalability. a.k.a. the need for some type of automated filtering that scales -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Lazy Engineers and Viable Excuses
Again... If folks were to implement explicit prefix filtering *everywhere* it wouldn't be necessary to filter only bogons and other miscellany explicitly. Something of this sort would only lower the lazy bar (is it possible?) for the clueless and/or lazy (those which Rob's list currently accommodates, which is better than nothing, BUT.. -- no offense Rob, I'm pretty sure our beliefs are aligned here :-). If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits. Is it really that hard? -danny
Re: Lazy Engineers and Viable Excuses
Hi, NANOGers. ] If folks were to implement explicit prefix filtering ] *everywhere* it wouldn't be necessary to filter only ] bogons and other miscellany explicitly. Agreed! Simple edge filters make this problem go away. While I and the rest of Team Cymru are happy to provide this service, we will gladly find other things to do if folks ubiquitously employ edge prefix filters. :) We attempt to convey this sort of thing in our templates. If folks need assistance building their filters, feel free to ping on us. We charge only the occasional cup of coffee. :) http://www.cymru.com/Documents/secure-bgp-template.html http://www.qorbit.net/documents/junos-bgp-appnote.htm ] ...no offense Rob, I'm pretty sure our beliefs are aligned here :-). None taken, I completely agree. Thanks, Rob, not just the bogon guy. :) -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
