upstream support for flowspec
I was perusing RFC5575 after reading a presentation that ALU did (presumably during some previous NANOG conference). Reference: https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Is there anything in the air about widening the adoption base? Cisco? Brocade? And once that happens, what are the chances of services providers adopting this for their customers to make use of on as wide of a scale as (for example) blackhole community strings. I'd certainly *love* to have a way to mitigate an attack that doesn't involve me sacrificing one service on my network to save the rest. Best, Daniel
Re: upstream support for flowspec
On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe co...@corbe.net wrote: Is there anything in the air about widening the adoption base? Cisco? Brocade? I've seen some suggesting that increased support, but even at Juniper, actions seem to speak larger than words. There seems to be very little interest for awhile now. However, I do know of some providers who use it, largely internal only. We also have tried a community flow-spec service, and more recently have been prototyping a community RTBH server with flow-spec capability (ping me off list if you want to hear more or see me at NANOG 62). A few people have recently told me they would like our community RTBH service via flow-spec instead of just BGP next hop, but really only one seemed seriously intent on configuring it day one. John
Re: upstream support for flowspec
On Thu, Sep 18, 2014 at 1:53 PM, Daniel Corbe co...@corbe.net wrote: And once that happens, what are the chances of services providers adopting this for their customers to make use of on as wide of a scale as (for example) blackhole community strings. I'd certainly *love* to have a way to mitigate an attack that doesn't involve me sacrificing one service on my network to save the rest. there are providers (verizon business, att, sprint, ntt at least) that provide mitigation via bgp update... which is equivalent to the blackhole community stuff, why not investigate those options? (or if you had, what was lacking?)
Re: upstream support for flowspec
Envoyé de mon iPhone Le 18 sept. 2014 à 19:53, Daniel Corbe co...@corbe.net a écrit : I was perusing RFC5575 after reading a presentation that ALU did (presumably during some previous NANOG conference). Reference: https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Is there anything in the air about widening the adoption base? Cisco? Brocade? Hi, I've submitted a request through my Brocade SE to support this, but it seems they are not interested about it. They claim their strategy is to achieve the same using SDN capabilities via OPENFLOW support. In the mean time, we are sitting ducks with our traditional technics. I read in an old NANOG thread (IIRC) that cisco was about to support this really soon on IOS-XR, but I am not 100% sur. Best regards. And once that happens, what are the chances of services providers adopting this for their customers to make use of on as wide of a scale as (for example) blackhole community strings. I'd certainly *love* to have a way to mitigate an attack that doesn't involve me sacrificing one service on my network to save the rest. Best, Daniel
Re: upstream support for flowspec
On (2014-09-18 13:53 -0400), Daniel Corbe wrote: Hi Daniel, This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic b) operator may get more traffic, as attack does not yield desired outcome And when we look at the feature technically a) junos does not allow setting flowspec on in FW filters and then apply FW filter where you wish to do it, it's automatically turned on for all traffic transiting box. This may be undesirable. b) by default junos accepts all flowspec actions, such as diverting traffic to new IP or new VRF. This may cause undesirable security issues. c) added feature == added complexity == reduced availability -- ++ytti
Re: upstream support for flowspec
Saku Ytti s...@ytti.fi writes: On (2014-09-18 13:53 -0400), Daniel Corbe wrote: Hi Daniel, This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. b) operator may get more traffic, as attack does not yield desired outcome Not necessarily true. If I can identify and push malicious traffic towards your edge, then you can do the same towards your peers. If I can ask you to filter by source, can you turn around and do so by source *AND* destination? You know what I'm announcing, so it seems like this ought to be possible. Short of that, it would require us to be in a trust relationship and I can see how that would be problematic. If we circle back around to paying a premium for the service, then I'm going to expect you to absorb the attack on my behalf. And when we look at the feature technically a) junos does not allow setting flowspec on in FW filters and then apply FW filter where you wish to do it, it's automatically turned on for all traffic transiting box. This may be undesirable. b) by default junos accepts all flowspec actions, such as diverting traffic to new IP or new VRF. This may cause undesirable security issues. c) added feature == added complexity == reduced availability -Daniel
Re: upstream support for flowspec
Also, if I'm buying full line rate commit from you then you're not actually losing any money on the deal whether or not you route me the traffic. -Daniel Daniel Corbe co...@corbe.net writes: Saku Ytti s...@ytti.fi writes: On (2014-09-18 13:53 -0400), Daniel Corbe wrote: Hi Daniel, This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. b) operator may get more traffic, as attack does not yield desired outcome Not necessarily true. If I can identify and push malicious traffic towards your edge, then you can do the same towards your peers. If I can ask you to filter by source, can you turn around and do so by source *AND* destination? You know what I'm announcing, so it seems like this ought to be possible. Short of that, it would require us to be in a trust relationship and I can see how that would be problematic. If we circle back around to paying a premium for the service, then I'm going to expect you to absorb the attack on my behalf. And when we look at the feature technically a) junos does not allow setting flowspec on in FW filters and then apply FW filter where you wish to do it, it's automatically turned on for all traffic transiting box. This may be undesirable. b) by default junos accepts all flowspec actions, such as diverting traffic to new IP or new VRF. This may cause undesirable security issues. c) added feature == added complexity == reduced availability -Daniel
Re: upstream support for flowspec
On Thu, Sep 18, 2014 at 03:15:41PM -0400, Daniel Corbe wrote: Also, if I'm buying full line rate commit from you then you're not actually losing any money on the deal whether or not you route me the traffic. Ha, I wish all customers would buy in full line rate commits! :-) - Job
Re: upstream support for flowspec
On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. Would you be willing to pay for the traffic _not_ delivered to you because of customer-pushed ACLs? If so, that would take the argument away because we filter we can't bill. Would you be willing to pay a premium to be able to do so? Is it worth a premium to insert ACLs in real time in the upstream's network or is a 2 hour delay acceptable? what about 5 minute delay? Aside from practical issues with flowspec as Ytti mentioned already, I don't think the market has yet figured out how stuff like this should work and become cost-effective. Kind regards, Job
Re: upstream support for flowspec
On 9/18/14 1:19 PM, Job Snijders wrote: On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. Would you be willing to pay for the traffic _not_ delivered to you because of customer-pushed ACLs? If so, that would take the argument away because we filter we can't bill. Would you be willing to pay a premium to be able to do so? Is it worth a premium to insert ACLs in real time in the upstream's network or is a 2 hour delay acceptable? what about 5 minute delay? It's not really a question we have to ask. Managed firewall services have way higher margins then pure IP transit. By extension dropping packets can be substantially more profitable especially on a per packet or byte basis then delivering them. Not everyone wants that service however. Aside from practical issues with flowspec as Ytti mentioned already, I don't think the market has yet figured out how stuff like this should work and become cost-effective. Ah cost effective is a consideration, yeah that is a bit of a bummer. Kind regards, Job signature.asc Description: OpenPGP digital signature
Re: upstream support for flowspec
On 9/18/14 11:06 AM, John Kristoff wrote: On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe co...@corbe.net wrote: Is there anything in the air about widening the adoption base? Cisco? Brocade? I've seen some suggesting that increased support, but even at Juniper, actions seem to speak larger than words. There seems to be very little interest for awhile now. However, I do know of some providers who use it, largely internal only. afaik from some previous experience it was hard to know a-priori which flow-spec route insertion was going to cause aberrant performance on the juniper platforms we were using. That's kinda ok if you use them since at least you can be aware of and revert that if it proves to be a problem. but it's kind of handing your customer a loaded gun. We also have tried a community flow-spec service, and more recently have been prototyping a community RTBH server with flow-spec capability (ping me off list if you want to hear more or see me at NANOG 62). A few people have recently told me they would like our community RTBH service via flow-spec instead of just BGP next hop, but really only one seemed seriously intent on configuring it day one. John signature.asc Description: OpenPGP digital signature
