Re: nLayer IP transit
On Fri, Aug 02, 2013 at 07:11:34AM +1000, Mark Tees wrote: Thanks for the replies. I think I saw somewhere around the Cloudflare outage post someone mentioning that since the person at Juniper that was responsible for Flowspec left it all went down hill. I take it then Flowspec is still used internally then? I am still wondering if its best to avoid Flowspec and roll your own firewall rules applied via Netconf for transit interfaces to achieve the same sort of functionality. It's a lot less likely to go south if you control the routes that go into the system. That said, it still breaks some things just by having it enabled (like NSR, though I suppose one could argue that NSR breaks itself :P), so you might be better served with a netconf distribution of rules if you want to avoid those potential issues. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: nLayer IP transit
On (2013-08-01 10:00 +1000), Mark Tees wrote: I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Anyone planning to do this might want to be aware that the validation process of flowspec does not limit actions. In practice this means, if you do run flowspec to your customers, your customers likely can inject traffic to arbitrary VRFs. I feel RFC should have explicitly stated valid actions for validation process, which operator MAY change, and any other action MUST cause validation process to fail. -- ++ytti
Re: nLayer IP transit
On Thu, Aug 01, 2013 at 09:13:59AM +0300, Saku Ytti wrote: On (2013-08-01 10:00 +1000), Mark Tees wrote: I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Anyone planning to do this might want to be aware that the validation process of flowspec does not limit actions. In practice this means, if you do run flowspec to your customers, your customers likely can inject traffic to arbitrary VRFs. You can match flow actions by extended communities and not accept actions you do not like. For example, to permit only discard action you can match community flow_discard members traffic-rate:*:0; Or am I missing something ? I feel RFC should have explicitly stated valid actions for validation process, which operator MAY change, and any other action MUST cause validation process to fail. -- ++ytti -- In theory, there is no difference between theory and practice. But, in practice, there is.
Re: nLayer IP transit
On (2013-08-01 11:35 +0400), Alexandre Snarskii wrote: You can match flow actions by extended communities and not accept actions you do not like. For example, to permit only discard action you can match community flow_discard members traffic-rate:*:0; Or am I missing something ? No you're not missing anything. This is what I implied with 'likely', I feel validation check should guarantee eBGP safety as most operators won't deploy additional security via manual config, because issue isn't mentioned in RFC or vendor docs. -- ++ytti
Re: nLayer IP transit
On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: Howdy listers, I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? We were forced to stop offering flowspec connections to customers, after we started experiencing a rash of issues with it. Among other things, we found ways for flowspec generated rules to easily cause non line-rate performance on Juniper MX boxes, and we had a couple of incidents where customer generated routes were able to cause cascading failure behaviors like crashing the firewall compiler processes across the entire network. I previously mentioned some of this here: http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html There have also been a few other high profile outages caused by bugs in the Juniper implementation, for example: https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 As a concept I still very much like Flowspec, and wish we could continue to offer it to customers, but as with any new routing protocol there are significant risks of network-wide impact if the implementation is not stable. IMHO Juniper has done a horrible job of maintaining support for Flowspec in recent years, and has effectively abandoned doing the proper testing and support necessary to run it in production. Until that changes, or until some other major router vendors pick it up and do better with it, I don't expect to see any major changes in this position any time soon. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: nLayer IP transit
Thanks for the replies. I think I saw somewhere around the Cloudflare outage post someone mentioning that since the person at Juniper that was responsible for Flowspec left it all went down hill. I take it then Flowspec is still used internally then? I am still wondering if its best to avoid Flowspec and roll your own firewall rules applied via Netconf for transit interfaces to achieve the same sort of functionality. On 02/08/2013, at 3:30 AM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: Howdy listers, I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? We were forced to stop offering flowspec connections to customers, after we started experiencing a rash of issues with it. Among other things, we found ways for flowspec generated rules to easily cause non line-rate performance on Juniper MX boxes, and we had a couple of incidents where customer generated routes were able to cause cascading failure behaviors like crashing the firewall compiler processes across the entire network. I previously mentioned some of this here: http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html There have also been a few other high profile outages caused by bugs in the Juniper implementation, for example: https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 As a concept I still very much like Flowspec, and wish we could continue to offer it to customers, but as with any new routing protocol there are significant risks of network-wide impact if the implementation is not stable. IMHO Juniper has done a horrible job of maintaining support for Flowspec in recent years, and has effectively abandoned doing the proper testing and support necessary to run it in production. Until that changes, or until some other major router vendors pick it up and do better with it, I don't expect to see any major changes in this position any time soon. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
nLayer IP transit
Howdy listers, I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Thanks, -- Regards, Mark
Re: nLayer IP transit
On Jul 31, 2013, at 20:00 , Mark Tees markt...@gmail.com wrote: I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Not any more. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
