[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

[Ben Maddison]

Hi Owen,

On 02/12, Owen DeLong wrote:

> > 

> > This is true for the following reasons:

> > - Non-RIR managed IRR databases exist that allow the creation of

> >  route(6) objects that are not covered by an RIR allocation

> > - Many networks do not filter by prefix based on IRR data at all

> > - Those that do generally do not filter their transits by prefix

> > - Transit-free networks generally do not filter their peers (or at least

> >  their transit-free peers) by prefix

> > 

> > Thus, today, a de-registration probably results in a partial outage that

> > can be worked-around, rather than a near-total outage that cannot.

> > This is either a feature or a bug in the policy, depending on your point

> > of view regarding a specific de-registration case!

> 

> The TL;DR of this boils down to “With great power comes great responsibility”.

> 

> The reality is that working around an errant AS0 ROA wouldn’t be any more

> difficult than working around an errant IRR entry. It involves a policy

> change on the afflicted routers which is relatively simple to achieve.

> 

The above is incorrect, because the semantics of ROAs and route(6)
objects are not the same (despite having a similar structure):
- A ROA (or rather a set of ROAs that all cover a given prefix) say: if
  the observed origin does not match (one of) the authorised origin(s),
  the route is *invalid* (which in most deployed policy results in a
  discard); while
- A route(6) object says "this combination of prefix/origin" is OK. It
  does not say *anything* about any other combination of prefix/origin.

Thus:
    route6: 2001:db8:f00::/48
    origin: AS65000

Does not impact the handling of an announcement (2001:db:f00::/48 //
AS65001) in any way.

Creating an AS0 ROA (for a prefix not covered by other ROAs) is not like
creating a route(6) object with 'origin: AS0'.
It is much more like *deleting* all existing route(6) objects for the
prefix *from all IRR databases*. This is not something that an RIR can
do today.

Even that IRR analogy goes only so far, since transit-free operators do
not typically filter each other by prefix from the IRR, and neither does
any sane operator filter its transits by prefix from the IRR.
RPKI ROV discard-invalid policies, on the other hand, are generally
applied on those adjacencies, so the creation of an AS0 ROA would have a
substantially greater impact across the DFZ.


> In fact, in large provider networks, it might be easier to work around the

> AS0 ROA because most of the routers feed from a local cache where the errant

> ROA could be cache-poisoned until it was resolved through the RIR.

> 

That is also false.

The construction used to define local policy exceptions to RPKI data is
called SLURM, defined in RFC8416.
It is not possible to express in SLURM the policy "ignore AS0 ROAs for
prefix P, only if issued by the RIR, rather than the LIR".
This is the case even if the RIR uses a separate TA, since "matching" on
a TA is not supported in SLURM.

The operator would have to choose from:
1.  Opt-out altogether from using the "AS0" TA;
2.  Use SLURM to filter out all AS0 ROAs for some set of prefixes (at
    the risk of ignoring LIR-issued ROAs for things like IXP prefixes); or
3.  Define the policy exception locally on the router(s) - assuming it's
    even expressible in the vendor DSL.

On the other hand, in IRR-land, the equivalent operation is *not*
filtering out a route(6) object. It is re-creating a route(6) in either
a locally administered IRR database or via whatever tool translates IRR
data into route policy constructs.
In any moderately well designed tool-set, this case is trivial.
However, even if it were not (to reiterate): *no RIR today has the ability
to delete route(6) objects across the IRR system*.


> > I would suggest the following modifications, in order to alleviate some

> > of the risks inherent in the current draft:

> > 1.  The automatic creation of AS0 ROAs should be limited to space that

> >    has never been allocated by an RIR or part of a legacy allocation.

> 

> I could live with this, though I think it unnecessary. It doesn’t need to be

> policy, it’s an operational matter for staff to consider in implementation.

> 

I do not agree that this is an operational matter. All of my suggestions
were aimed at the premise that the downside of having end-users impacted
in the case of a disputed re-claim is far larger than the upside of
having full AS0 coverage of bogon address space.
The above suggestion aims to ensure that AFRINIC does not create ROAs
for any previously issued space, since it may still be routed somewhere,
causing unexpected outages for end-users.
Perhaps some due-diligence can be performed that would permit creation
on a case by case basis, but the departure point should be to err on the
side of not switching peoples connectivity off.


> > 2.  AFRINIC should require the explicit consent of the previous holder

> >    to issue AS0 ROAs in respect of re-claimed, returned, etc, space.

> 

> I disagree here. This would essentially allow someone who obtained space, never

> paid their fees and never complied with policy to continue using the space

> ad infinitum because they refuse to grant permission to the RIR to issue the

> AS0 ROA. Instead, I suggest a process whereby the RIR is not allowed to issue

> a ROA for 90 days after reclaiming space and upon appeal of the reclamation

> within that 90 days, AS0 ROAs cannot be issued until the appeal is finalized.

> The appeal should be finalized within an additional 90 days.

> 

I could live with some version of that.
The case I would be anxious to cover is where the re-claim is the result
of some legal process that the registrar is gagged from disclosing.
For the above to work, the appeal process would need to be sufficiently
transparent that other operators have the opportunity to create policy
exceptions *within* the 90 days if they deem it necessary.


> > 3.  Any ROAs issued under this policy should be issued and published in

> >    a way that makes it operationally easy for an relying party to

> >    ignore them (probably by issuing under a separate TA)

> 

> That’s already in the latest version of the policy proposal.

> 

I'm glad to hear that. It was a mere suggestion to staff in the version
I reviewed a while back.

There is an additional observation that I think is important here, and
which I haven't seen anyone point out during this debate:

Issuing AS0 ROAs for unallocated space will help to prevent squatting on
that space while it is still un-allocated.
It *does nothing* to ensure that the space can be *re-allocated* more
easily. Here is why:

Suppose member X (AS65000) has 2001:db8:f00::/48 and 2001:db8:baa::/48
from the RIR.
The RPKI member CA cert will contain resources:
    AS65000
    2001:db8:f00::/48
    2001:db8:baa::/48
And at time t0, X issues ROAs:
    2001:db8:f00::/48 asID:65000
    2001:db8:baa::/48 asID:65000

Some dispute at time t1 results in 2001:db8:f00::/48 being re-claimed.
The RIR will revoke the previous CA cert, and issue a new one (possibly
over the same keypair to avoid breakage), containing resources:
    AS65000
    2001:db8:baa::/48

This will result in the validation of the ROA for 2001:db8:f00::/48
in the RPKI failing, and being ignored by validators.

Today, the RIR does nothing beyond this (in the RPKI).
In that case an announcement in BGP for 2001:db8:f00::/48 origin AS65000
would be ROV-unknown. It would likely be accepted ~everywhere.
With this policy, the RIR would issue a new ROA:
    2001:db8:f00::/48 asID:0
The presence of this ROA would make the above BGP announcement
ROV-invalid. It would likely it dropped ~everywhere.

At time t2, the RIR re-allocates 2001:db8:foo::/48 to member Y, who also
has AS65001.
Member Y issues ROA:
    2001:db8:baa::/48 asID:65001

Now (regardless of whether the AS0 ROA was ever created, or whether it
is still there), the presence of the AS65001 ROA means that the above
announcement is ROV-invalid. Period. Nothing whatever to do with this
policy at all.

The only difference that this policy makes is:
1.  The ROV status of the announcement during the time interval t1 to t2
    (i.e. while it's a bogon); and
2.  The ROV status of the announcement following t2 *if* Y fails to
    create a ROA for their newly issued space.
    There are no sound engineering reasons that I am aware of for failing to
    create a ROA for newly received space (please say if you can think of
    any!). So this point can safely be ignored.

Thus this policy makes:
- it harder to squat on un-allocated space. This is a good thing. But
  not a very important thing.
- it easier for recipients of recycled space to fail to create ROAs.
  This is, in my opinion, a bad thing.

Sorry for the long email ;-)

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210213/a33fad7c/attachment.sig>