[sidr] defending at layer seven against layer nine attacks

[Randy Bush <[e-mail]>]

yesterday, a few friends asked

   if someone files in court against your customer and gets a
   judgment telling the rir to revoke your bgp-speaking customer's
   certs and roas[0], what the heck happens to your responsibility
   and/or sla to your customer?  what can you do to keep them
   flying?

i believe this is a legitimate concern.  one classic example is a
russian isp being attacked by a dutch court.  of course it could be
a canadian being attacked by a virginia court.

note that, traditionally, the sla describes a level of service
between you and your customer, and its all best effort to the rest
of the intertubes.

first, the rirs, no matter how well-meaning, can do nothing to
help, any thought thereof is a joke.  they will not stand up to
court orders and people with guns, end of story.  and the same goes
for well-intentioned schemes where arin backs up ripe's members'
rpki data.  american (dns) registries have already been used,
through us courts, to attack overseas sites.

but, note that the decisions routers make are not burned in.  by
design, they are local policy configured by the operator.  rpki-
based origin validation merely marks a received bgp announcement as
valid, notfound, or invalid.  it is up to operator-configured
policy to decide how to treat the received announcement based on
the validity marking and anything else the operator chooses.

so we will use local knowledge of who your customers are to make a
local policy decision that you're going to route them no matter
what some third party says about them.

let's assume you have a prefix filter list for my customer's
prefixes (the customer themself, not their bgp speaking customer
cone).  you do have prefix lists for your customers, don't you [1]?

so, your programatically generated template for a customer peering
could be something such as the following pretty strict policy:

    if p in custs-pfxs
       community add ExportToPeersCustsAndUpstreams
       if p is marked valid
          set local-pref 120
       elif p is marked notfound
          set local-pref 100
       elif p is marked invalid  # layer nine attack
          set local-pref 120	 # maintain g-r fantasy

an even more paranoid approach might begin

    if p in custs-pfxs
       if p comes from or through an as not my customer's
          drop it on the floor
       ...

as you surely have customer specific prefix filters in place, you
do not risk allowing in invalid attacks sourced by your customer.

that this is all supported in the design and in current code from
J&C is not an accident.  but beware of occasional vendor do-gooder
knobs which default to applying policy for you.

also check out draft-ietf-sidr-ltamgmt.  it explains how to use the
rpki tools and tool-sets (i.e. nothing new needed) to have your own
view of the world, overriding the iana/rir-based rpki data.  this
view could include copies of your customers' rpki data.

it would also be really helpful to have a seventh registry of good
reputation situated in a much less vulnerable jurisdiction, e.g.
iceland.  we could all use the ltamgt hack to use them as a safety
net.

otoh, i would also hope that the goons at layers 8-10 would realize
that a lot of attacks against the rpki would jeopardize everyone's,
including their own, routing security as folk will start to shy
away from using it.

---

[0] - or forces the rir to create a roa for as 0

[1] - you can always construct one from the rpki data, all the roas
      with the customer's as.  if they did not register, then all
      this makes no difference, their prefixes are always notfound.