[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

[Ben Maddison]

Hi Jaco,

On 07/23, Jaco Kroon wrote:
> Hi Owen,
> 
> Using 154.73.32.0/22 as example, please clarify how the effect would be
> any different if this object would suddenly disappear off of the whois
> database?
> 
> route:          154.73.32.0/22
> descr:          ROUTE-ULS1
> origin:         AS327767
> mnt-by:         ULTIMATELINUX-MNT
> source:         AFRINIC # Filtered
> 
I realise that you directed your question to Owen, but I'll take the
liberty to respond instead.

There are fundamental differences between the semantics of route(6)
objects vs. the semantics of ROAs, and between the RPKI system and IRR
system.

Consequently, there are substantial differences in practical impact.
Some of these are as follows:

1.  The IRR system is a set of independent databases, with independent
    object namespaces. Which databases are usable in practise is
    determined only by the set of operators that mirror/query them when
    generating filters.

    It does not matter, in general, whether a route object for
    154.73.32.0/22 is published in the AFRINIC IRR or in another,
    non-RIR managed database such as RADB, NTTCOM, ALTDB, etc.

    The RPKI on the other hand is strictly (at least by design)
    hierarchical. A ROA covering 154.73.32.0/22 can *only* be validly
    signed by the AFRINIC CA.

    Thus, an operator loosing access to, and having their objects
    deleted from, an RIR-managed IRR database has alternative
    publication options. The same is not true in the case of ROA
    publication.

2.  Network operators typically re-build filters from IRR on a
    relatively long, fixed schedule. Typically this is 24 hours,
    although variation exists.

    Conversely, ROAs wind up in the policy information bases of routers
    as soon as permitted by the timers configured in the publication
    pipeline and RP software involved. From my experience, this seems to
    translate into a propagation delay of 10-60 mins in most cases.

    As a result, the operator has around 2 orders of magnitude less time
    to respond to the publication of an adverse ROA than they would to
    the deletion of a route(6) object, before the problem deteriorates
    into an outage.

3.  A route(6) object in the IRR *only* makes a positive assertion. The
    example you provided says that a route for 154.73.32.0/22 and origin
    AS327767 may exist. It doesn't say anything at all about any route
    with either a different prefix, length or origin.

    A ROA, however, makes both positive *and* negative assertions. 
    A ROA:
        { prefix: 154.73.32.0/22, asID: 327767 }
    Says that a route for a prefix covered by 154.73.32.0/22 that has
    either: a) a length > 22; or b) an origin other than AS327767, is
    invalid.

    A consequence of this distinction is that IRR-based prefix filters
    are only useful when applied to sessions with customers or
    moderately sized peers. Operators don't filter their transits in
    this way, and transit-free networks don't filter one-another in this
    way.

    An ROV Invalid, on the other hand, should not show up in the DFZ at
    all, and filters to discard them are (correctly) applied on *all*
    eBGP sessions at the AS border.

In practise, in the current example, the combination of the above 3
differences mean that:

Scenario A:
    The example route object is deleted, and ULTIMATELINUX-MNT is
    prevented from accessing the AFRINIC IRR database.

    The operator will need to create replacement objects in some other
    IRR database, such that these are visible to at least one of AS2914,
    AS3356, AS5511, AS174 or AS6939. This probably involves nothing more
    than creating an new maintainer on one of the non-RIR operated IRR
    databases.

    In the extreme and unlikely case where this is not achievable, the
    operator would need to convince at least one of their transits to
    configure a manual exception, and to request the same from one of
    their transits in turn. This would represent intervention by at
    minimum two operators. In all cases, the request would originate
    from a paying customer.

    The operator will have on average 12 hours to complete this before
    an outage occurs.

Scenario B:
    Same as scenario A + any existing ROAs for 154.73.32.0/22 are
    deleted, and replaced with one having asID: 0.

    The operator will have to perform that mitigations in scenario A.

    Additionally, the operator will have to make contact with *every
    network operator in the world* that is relying on the TA under which
    the new ROA is issued, providing them with sufficient information
    and accompanying documentation to convince them:
    - You are who you say you are;
    - There is a bonafide dispute that warrants taking action to
      override the stated intention of the RIR; and
    - The impact to *their* network is sufficient to warrant taking the
      trouble to deal with.

    The operator will have approximately 10 - 60 mins to complete this
    before an outage occurs.

Whether or not you believe placing operators in this position is
desirable, please can we at least stop pretending that scenario A & B
are even vaguely similar to one-another?

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/20210724/abba0ad6/attachment.sig>