ARIN RPKI TAL deployment issues

Tue Sep 25 17:30:05 UTC 2018

Dear NANOG,

I'd like to draw attention to a very concerning development: it appears
that the ARIN TAL is not as widely deployed as other RPKI TALs (such as
RIPE or APNIC's TAL). This means that ARIN members are needlessly put at
higher risk.

Ben Cartwright-Cox performed RPKI research a few weeks ago where he
compared the (un)reachability of RPKI Invalid announcements using ARIN,
RPKI, APNIC and JPNIC space. The full write-up is available here:

    https://blog.benjojo.co.uk/post/are-bgps-security-features-working-yet-rpki

I quote Ben's assessment:

    """Using the data, we can also see that the providers that have not
    downloaded the ARIN TAL. Either because they were not aware that
    they needed to, or could not agree to the agreement they have with
    it.

    This is frustrating to watch. Since it means that ROA signing ARIN
    prefixes will be less secure than ROA signing others, until these
    restrictions are abolished. Even after that it will have a long term
    knock on effect as software updates take a long time to propagate to
    end networks."""

In other words, when creating RPKI ROAs for your resources, ARIN members
are getting *LESS* in return compared to say RIPE members.

As ARIN member I'd hope and expect the ARIN organisation to go above and
beyond to distribute their RPKI TAL as widely as possible. (Think:
proactively submitting the ARIN TAL to relevant open source projects,
making the TAL available for download without restrictions or
limitations). 

At the NANOG 74 meeting David Whisnick will talk about legal barriers to
RPKI adoption and he'll offer suggestions for reform. I think Ben's
observation that the ARIN TAL is less widely deployed is a direct result
from the legal barriers that David identified.

    https://pc.nanog.org/static/published/meetings//NANOG74/daily/day_2.html#talk_1767

I fear that if no action is taken (e.g. when none of the RPKI Cache
Validators can include the ARIN TAL in their software distribution [1]),
we'll continue to see the gap between ARIN and the other RIRs widen.
Software developers have indicated that the RPA is problematic and
prevents BGP implementations from shipping "secure by default" software:
https://lists.arin.net/pipermail/arin-consult/2018-April/001087.html

When ARIN members create ROAs, I assume those members would also like
networks *outside* the ARIN region to honor those ROAs and help prevent
propagation of incorrect BGP announcements. The ARIN member and the
operator of the foreign network may not even have any languages in
common! I fear that limited deployment of the ARIN TAL is detrimental to
the business interests of resource holders in the ARIN region.

Kind regards,

Job

[1]: https://github.com/NLnetLabs/routinator/commit/b1e70746bb3768554fa439c5ced4e8b8484eeb00