upstream support for flowspec

Mailman List Mirror (Read Only)
1

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

2

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

3

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?)

4

Envoyé de mon iPhone

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.

5

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

6

Saku Ytti <saku@ytti.fi> writes:

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

7

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 <corbe@corbe.net> writes:

8

Ha, I wish all customers would buy in full line rate commits! :slight_smile:

- Job

9

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

10

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.

11

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.