RE: Filter on IXP
- the IXP participants keep their IRRDB information fully up-to-date Geez anything else but the fully up-to-date IRRDB please. That just won't fly. That's why I said that an up to date IRRDB would have been a nice side effect of IXP filtering. - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Yes this is a valid point I think the technicalities of how to implement this kind of filtering at the IXP equipment is out of scope for this discussion. Anyways I believe IXPs should not be responsible for this mess and that BCP38 should be implemented by the participants of an IXP. As Saku Ytti mentioned several times Tier2 ISPs are in the best position for a successful BCP38 filtering at their network boundaries. adam -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Sunday, March 02, 2014 2:01 PM To: Vitkovský Adam; Jérôme Nicolle; nanog@nanog.org Subject: Re: Filter on IXP On 02/03/2014 12:45, Vitkovský Adam wrote: On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. And that's a really nice side effect. and it only works for leaf networks. The moment your ixp supports larger networks, it will break things horribly. It also assumes that: - all your IXP members use route servers (not generally true) - the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true) - the IXP port ASICs can handle large L2 access lists (not generally true) - there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain) - there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement) - the IXP participants keep their IRRDB information fully up-to-date (not generally true) - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Last but not least: - there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case) There are many places where automated RPF makes a lot of sense. An IXP is not one of them. Nick
RE: Filter on IXP
On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. And that's a really nice side effect. However in case of transit providers the problem is that RaDB /RIPE lists what prefixes you are allowed to advertise. But that does not necessarily fully match with what source IPs can leave your network. I mean ISP-A can have a customer that uses PA range of other ISP-B and only has a static route towards ISP-A for some TE purposes. I'm not well versed with RIPE myself so I'm not sure whether there's a way to handle this situation. adam -Original Message- From: Jérôme Nicolle [mailto:jer...@ceriz.fr] Sent: Friday, February 28, 2014 6:03 PM To: Nick Hilliard; nanog@nanog.org Subject: Re: Filter on IXP Le 28/02/2014 17:52, Nick Hilliard a écrit : this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. It could break if filters are based on announced prefixes. That's preciselly why uRPF is often useless. On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter on IXP
On 02/03/2014 12:45, Vitkovský Adam wrote: On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. And that's a really nice side effect. and it only works for leaf networks. The moment your ixp supports larger networks, it will break things horribly. It also assumes that: - all your IXP members use route servers (not generally true) - the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true) - the IXP port ASICs can handle large L2 access lists (not generally true) - there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain) - there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement) - the IXP participants keep their IRRDB information fully up-to-date (not generally true) - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Last but not least: - there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case) There are many places where automated RPF makes a lot of sense. An IXP is not one of them. Nick
Re: Filter on IXP
On Sun, Mar 2, 2014 at 4:00 AM, Nick Hilliard n...@foobar.org wrote: There are many places where automated RPF makes a lot of sense. An IXP is not one of them. That make sense. Everyone is rightly resistant to automated filtering. But could we automate getting the word out instead? Can obvious BCP38 cluelessness be measured? Maybe as a ratio of advertised to unadvertised egressing ASes, etc. ? If so, then if your downstream/peer is even *partially* BCP38, give them a pass. They are at least somewhat aware of the problem. Otherwise: - Visually red-flag their BCP38 stats/percentage in RADb; - Send them an automatic email once a week; - Let upstreams *optionally* not automatically update their routes via RADb until they call to ask why; etc. Can we combat the awareness problem in bulk -- without *filtering* in bulk? Royce
Re: Filter on IXP
Hi Chris, Le 23/02/2014 01:43, Chris Laffin a écrit : It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. Wasting ASIC ressources on IXP's dataplanes is a wet-dream for anyone willing to kill the network. IXP's neutrality is a key factor to maintain reasonable interconnexion density. Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. By the way, would anyone know how to generate OpenFlow messages to push such filters to member ports ? Would there be any smat way to do that on non-OpenFlow enabled dataplanes (C6k...) ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter on IXP
- Original Message - From: Jérôme Nicolle jer...@ceriz.fr Le 23/02/2014 01:43, Chris Laffin a écrit : It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. Wasting ASIC ressources on IXP's dataplanes is a wet-dream for anyone willing to kill the network. IXP's neutrality is a key factor to maintain reasonable interconnexion density. Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. Interesting. Are you doing this? Planning it? Or at least researching how well it would work? A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. Don't they do this already? If you get something practical implemented on this topic, we'd be more than pleased to see it show up on bcp38.info; exchange points are the one major construct I hadn't included there, cause I didn't think it was actually practical to do it there. But then, I don't run one. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Filter on IXP
It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. while i agree that this is an extremely stupid idea, clearly you have not been reading this list for very long randy
Re: Filter on IXP
Le 28/02/2014 17:00, Jay Ashworth a écrit : From: Jérôme Nicolle jer...@ceriz.fr Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. Interesting. Are you doing this? Planning it? Or at least researching how well it would work? Juste seriously considering it on TOUIX. I'd propose it to Lyonix and France-IX too. A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. Don't they do this already? Not to my knowledge. Some members are only announcing regional prefixes on smaller IXs. They could however exchange trafic originaing from any region of their networks. Best would be to differentiate announced prefixes from legitimately announcable prefixes, as registered to RIPEdb (as far as we're concerned). In a more global perspective, the extended best-practice could be to set ACLs as we generate prefix-lists, route-maps and route-filters for BGP downlinks and PNIs too. If you get something practical implemented on this topic, we'd be more than pleased to see it show up on bcp38.info; exchange points are the one major construct I hadn't included there, cause I didn't think it was actually practical to do it there. But then, I don't run one. I think the idea worth investigating, but I run a very small IXP and will most certainly be unable to fully investigate every potential side-effects on my own. I'll be reaching out to bigger ones in my next email. -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter on IXP
Hi Randy, Le 28/02/2014 17:15, Randy Bush a écrit : clearly you have not been reading this list for very long Well... Busted. All things considered, there surelly has been more stupid proposals. -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter on IXP
On 28/02/2014 15:42, Jérôme Nicolle wrote: Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. Nick
Re: Filter on IXP
On Feb 28, 2014, at 11:52 , Nick Hilliard n...@foobar.org wrote: On 28/02/2014 15:42, Jérôme Nicolle wrote: Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. Or to anyone who doesn't announce their full downstream table to the route servers. Or to people who don't use route servers. Or to someone who does traffic engineering. Or -- TTFN, patrick
Re: Filter on IXP
Le 28/02/2014 17:52, Nick Hilliard a écrit : this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. It could break if filters are based on announced prefixes. That's preciselly why uRPF is often useless. On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. -- Jérôme Nicolle +33 6 19 31 27 14
