nLayer IP transit

Mailman List Mirror (Read Only)
1

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,

2

Not any more.

3

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.

4

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

5

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.

6

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.

7

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.

8

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.