Feedback Requested: Routing Resilience Manifesto

Colleagues,

A small group of network operators has been working on defining a
minimal, but feasible package of recommended measures that, if deployed
on a wide scale, could result in visible improvements to the security
and resilience of the global routing system.

Many operators are ahead of the curve and already implement much more
than the proposed recommendations. But we believe that gathering support
for these relatively small steps could pave the road to more significant
actions on a global scale.

We called this set of recommendations a Routing Resilience Manifesto �
you can find a draft document here: https://www.routingmanifesto.org/.

This initial version of the Manifesto was drafted by a small group, but
we need a wider community review, your feedback, and, ultimately, your
support to make this initiative fly. It was already presented at several
venues, like RIPE and NANOG, and now we open it for a more detailed
review. Please note that this is very much a work in progress.

Please review the document and provide your feedback and text
suggestions online or via routingmanifesto@isoc.org by 31 August 2014.

Regards,

Andrei Robachevsky
Internet Society

Howdy,

First recommendation: ditch the word "manifesto." Manifesto is loaded
with so many negative connotations that using it in a document
intended to be taken seriously by professionals is unwise...
particularly if those professionals will have to beg money from CEOs
to implement any of the proposals.

While less catchy, something along the lines of "Minimum Professional
Routing Standards for Lawfully Operated Networks" is more apt to
secure the needed cooperation, funding and vendor support.

Seriously, manifesto? What's next, some routing unabombers? Oh wait, I
guess we already have those, don't we?

Regards,
Bill Herrin

On the other hand, people will notice & read a Œmanifesto¹. The industry
has preached things like BCP38 for many years with not great progress...

Seriously. And it is actually a deeper wound than that.

The whole document (or as much of it as I was willing to read, anyway) is worded like it had been copied out of the Ernesto Guevara Handbook.

Howdy,

Best practices just means you're not quite the best -- often a worthy
trade for controlling cost, particularly if your customers won't
notice. Besides, it's best -current- practices which means it'll
probably change tomorrow and you won't have to do all that hard work
after all. And if not tomorrow then surely the next day.

People will notice you streaking across a football field. They won't
pay the slightest attention to what you have to say but they sure will
notice you. Shall we organize a naked routing run?

Regards,
Bill Herrin

No, but how else do you suggest we work to address these problems? There are
side-effects of every tradeoff, including today NTP is unusable on some networks
due to lack of BCP-38. Is the internet to be eventually defined as a few
select ports and protocol numbers?

While a naked run isn't my first choice, I am interested in practical solutions
and responses. I've privately and publicly documented some of my challenges
securing my networks with BCP-38. While perhaps not obviously related there
is also the issue of BGP filtering and other things that create a nexus of
interrelated items.

How can we build a culture of cooperation around these topics to raise the bar?

It isn't the most chronic or sexy thing to address, but the bar still needs
to be raised before it becomes the latest in a list of things we all knew about
and took no action on.

- Jared

I am no longer active in the field, but back in the day, the ways of successfully selling stuff to management involved some mix of:

It will improve sales.
It will reduce costs.
It will allow you to do something you want to do.
It will keep you out of court and jail.

No variation "It is the right thing to do" ever worked unless management thought of it.

Hi Jared,

Have you ever known any problem to be solved with stronger awareness
of the rules of whack-a-mole?

The first level of the problem is technical: there's no efficient
protocol for propagating knowledge about acceptable sources from each
link from router to router and not nearly enough TCAM in shipping
models to implement such a protocol if it existed. Every current
anti-spoofing approach either involves slow and mistake-prone manual
effort or is tied to trivial single-homed routing cases so often
implemented by inept junior staff at third-tier networks.

The second level of the problem is financial -- some customers will
pay you to avoid being victims of the problem but none will pay you to
avoid being facilitators. Protocols, software and TCAMs are expensive.
Far more expensive than the abject lack of penalties, lawsuits,
shutdowns and public shaming which result from the discovery of leaky
origins.

Regards,
Bill Herrin

Ew. That's a mental image I didn't need. Pass me the mind bleach.

No, but how else do you suggest we work to address these problems?
While a naked run isn't my first choice, I am interested in practical solutions
and responses. I've privately and publicly documented some of my challenges
securing my networks with BCP-38. While perhaps not obviously related there
is also the issue of BGP filtering and other things that create a nexus of
interrelated items.

Hi Jared,

Have you ever known any problem to be solved with stronger awareness
of the rules of whack-a-mole?

The first level of the problem is technical: there's no efficient
protocol for propagating knowledge about acceptable sources from each
link from router to router and not nearly enough TCAM in shipping
models to implement such a protocol if it existed. Every current
anti-spoofing approach either involves slow and mistake-prone manual
effort or is tied to trivial single-homed routing cases so often
implemented by inept junior staff at third-tier networks.

I can't solve the inept staff problem either, this is a problem of people
being paid to do something they're unqualified to do. They can muddle through
it to a workable solution and folks say "great, it's fixed don't touch it"
and move on. As a community we need to find these cases and educate those
which haven't learned that proxy-arp, ip redirects (and ipv6 redirects) are
bad and cause more damage than good. Perhaps this "manifesto" is the
wrong way, but it's at least an attempt to enumerate some set of them
and make it public to educate folks. I'd love to see all the members
of this list be able to take one item and strive for it this year as a
goal.

The second level of the problem is financial -- some customers will
pay you to avoid being victims of the problem but none will pay you to
avoid being facilitators. Protocols, software and TCAMs are expensive.
Far more expensive than the abject lack of penalties, lawsuits,
shutdowns and public shaming which result from the discovery of leaky
origins.

Sure. I have been trying to avoid mentioning this, but there's at least one
case this week where someone substituted their own moral standing in place
of a party they feel wasn't doing the right thing. The fate of that
event is still not determined. (I'm not trying to fork the discussion to
be related, but it's certainly a threat that I'm paying close attention to).

  - Jared

For $dayjob, automation (marketing term: SDN) has let us attain all of the above, including the ability to roll out fixes promptly and predictably.

How we can encourage other actors to raise the bar is what I'm hoping occurs. Similar to Gert and his "Have you turned on IPv6 on something today" quote, did you contribute to the stability and security of the internet today? Sometimes it's tiny incremental work, but over time it's additive to make things better. Toyota has a concept of continual improvement in their processes, how can we improve?

- Jared

Hi Jared,

Ask folks in the IRTF to hash out architectures for efficiently
propagating permitted source information. The manual processes we have
today don't cut it. Ask folks in the IETF and build a protocol or two
around those architectures. And lobby lawmakers about the vast
economic and national security implications of the corporate blind-eye
to criminal behavior that the protocol solves. Not necessarily in that
order.

Banks with controls inadequate to obstruct money laundering face
severe consequences. So do owners of swimming pools who make no effort
to prevent child drownings. The former is criminal while the latter
facilitates a huge torts under the attractive nuisance doctrine. Why
should network operators with inadequate controls to obstruct source
address fraud get a completely free pass? Surely the impact has become
sufficiently severe!

Alternately, it will be my pleasure to cheer everyone on as they
achieve ever higher scores at whack-a-mole. With only the occasional
snark. I promise.

Regards,
Bill Herrin

Things like DNSBLs could be used to encourage correct behavior.

Why is your network performance shit? Because you allow your customers to spew sewage and you ended up on a blacklist, everyone now puts all your traffic in scavenger queue.

-Dan

Well, that was easy.
Already have 1 and 2 squared away.
Only challenging one left is #3.
Is the INOC-DBA project still around? Would
love to sign up for that and be able to check off
#3 as well.

Once that's done, all that's left is the naked routing
run. With the way temperatures have been, I'm
all in favour of that--pick a date, let's make it happen!

Matt

Yep. We had a bit of a dry spell on funding for it for a while, but we have someone starting full-time on it again in mid-August, and we’ve had some very good volunteers that have tided us over during the times when we didn’t have funded staff for it. And Cisco have, of course, been very generous with continuous support since INOC-DBA was rolled out in 2001. We’re in the process of a web-site overhaul that will include a new INOC-DBA configuration portal, and we’re currently testing out the new DX650 phones. I’m anticipating that a fair bit of the last few years’ development work will actually get rolled out in production over the course of the next year; there was quite a bit backed up behind the lack of full-time staff.

                                -Bill

About #3... I had a little discussion on abuse-wg@RIPE a while ago about keeping records up to date and relevant. See below.

Nobody at RIPE cares much at the moment (to actually pick up this subject). Maybe they need a push with a TerexRH400.

David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)
---------------------------------------------------------ctrl-v--------------------------------------------
Hi Frederik,

Who has an interest in a clean database? The sloppy Org or Ripe? The answer is Ripe, therefore it should also spend energy [via Ripe Ncc] in (making sure that Orgs are) keeping it clean.

Kids do not grow up themselves, it requires an active process. Organisations are not much different.

David

-----Oorspronkelijk bericht-----

You get a lot of network and DNS types and maybe 1% of them will be
concerned with the mechanics of abuse prevention - that's the other
group down the hall, and "they are not the internet police". Ah well
.. maybe that's better than hamfisted lanham act takedowns of whitehat
dynamic dns providers - but those are two extremes.

--srs

About #3... I had a little discussion on abuse-wg@RIPE a while ago
about keeping records up to date and relevant. See below.

Nobody at RIPE cares much at the moment (to actually pick up this
subject). Maybe they need a push with a TerexRH400.

You get a lot of network and DNS types and maybe 1% of them will be
concerned with the mechanics of abuse prevention - that's the other
group down the hall, and "they are not the internet police".

Which, I maintain, is why the "manifesto" needs to be recast for Management, because it is Management that is supposed to define mission goals and job assignments, which might very well involve operation as network police for the local piece of The Internet (which does in fact extend to the end devices in your shop).

   Ah