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

[Ben Maddison]

Hi Frank,

On 06/09, Frank Habicht wrote:

> Hi Job,

> 

I realise that your response was directed at Job, but I'll respond
anyway...


> [co-author writing]

> 

> On 08/06/2021 17:36, Job Snijders via RPD wrote:

> > At the moment of writing, the AFRINIC Trust Anchor has excellent

> > standing in the global community. If AFRINIC starts publishing RPKI

> > ROAs for Unallocated or Unassigned space, unfortunately, I'll have to

> > consider the AFRINIC RPKI Trust Anchor to be UNFIT FOR RELYING.

> 

> I believe the current Trust Anchor will not be touched.

> A new one will be created.

> Why would your opinion about the current TA change?

> It is acceptable that you will consider the new TA unfit.

> I would think the first one could still be fine for you.

> 

The draft policy *does not* mandate that a separate TA be used.
I have previously suggested that this should be mandated in the policy,
but this was not done.

As long as the draft merely says that a different TA *could* be used,
defences in this vein are bogus.


> > Implementation of this proposal will put years of AFRINIC's work and

> > investment in RPKI at risk, ... a pretty crazy situation! :-(

> > 

> > Danger to AFRINIC members

> > =========================

> > 

> > If this policy proposal is implemented, the ultimate consequences is

> > that certain types of disputes between members and AFRINIC will result

> > in severe connectivity problems for the member. Some members might

> > think, "that will never happen to me, I always pay my bills on time!"

> 

> I have the tendency to look for root-causes.

> Why would the "certain types of disputes" come into existence...?

> Can it be avoided?  ;-)

> 

No, it is not possible to eliminate the potential for conflict between
resource holders and AFRINIC.

Some scenarios that I can anticipate:

- Sanctions actions
- Ex-parte injunctions
- Banking/payment clearance disruptions
- Bona fide disputes arising from the RSA
- Bona fide disputes arising from the CPM
- Administrative error

... and probably many more that I have not thought of.

This policy elevates each one from an administrative inconvenience to a
DOS at the scale of (potentially) millions of Internet users.


> > But we cannot know the future! If five years from now there is a banking

> > issue between AFRINIC's bank and a member's bank (for example, because

> > of sanctions, war conflict, or any other issue)

> 

> I understand AfriNIC staff do contact members before any

> de-registration. I know first-hand that they also contact upstream

> providers.

> In terms of time-line, I also believe (i guess staff can confirm) that

> de-registrations done in February 2021 were for members where fees are

> not paid for 2020. Did the members have 11 months? or 12 months to sort

> this out?

> 

> I know of two (EU-PI) members in this-here country whose inetnums were

> removed and following that it was just a matter of ongoing RIPE-NONAUTH

> cleanup for them to have zero route objects and "impact".

> So somebody had to talk sense into these resource members. This won't

> change.

> 

You are describing the "ordinary" process.

There are plenty of possible scenarios (as I have tried to illustrate)
where the "ordinary" process would not be followed.


> > - the member suddenly

> 

> i object to 'suddenly'.

> 

From the perspective of the impacted member (and even more so, their
users) this could be very sudden in some of the above scenarios.


> > might find themselves in a situation where not only the AFRINIC

> > registration of IP addresses falters (a serious problem), but

> > additionally the member's internet connectivity is forcefully taken

> > offline (an even bigger problem!). This seems disproportional.

> 

> There are those in the world who advertise "fail fast and hard" [1]

> 

You are misusing the above principal.

It is often beneficial to "surface" failures so that they can be
attended to, and then fixed, rather than allowing them to go undetected
and un-addressed resulting in a gradual service deterioration.

That is not a reason to introduce a new failure mode, which is what this
policy does.


> Also: above is the case if _all_ of the upstreams of the member actively

> choose the AS0-TAL, and don't implement any manual overrides/workarounds

> for the customer.

> 

Again, the policy *does not* mandate the use of a separate TA. This
point is bogus.

Additionally, the failure domain is not determined solely by the use (or
not) of the null-ROAs by the member's upstreams. Each RP-network
validates RPKI data separately and enforces the result at their own
borders.
Thus a "manual override" would be required by *every* relying party on
the Internet. That is not a practical suggestion.


> > ASPECT #2: Any mistake AFRINIC makes in the AS0 publication will result

> > in significant problems for third parties.

> 

> those that actively choose the AS0-TAL.

> 

Again, the policy *does not* mandate the use of a separate TA. This
point is bogus.


> > (Possibly outside AFRINIC

> > region) What if a typo is made?

> 

> one would expect a lot of automation.

> 

Automation is simply a means of making typos at scale.


> > The wrong prefix added to the AS0 block

> > list? Why would we voluntarily increase our global risk?

> 

> I think this is not an argument against _having_ the 2nd TAL.

> I think it's against _using_ it.

> Some operators might weigh and see more benefits than cost+risk.

> 

That is approximately the same argument that the NRA uses to justify the
sale of automatic weapons in the US.

The authors and proponents of this policy have consistently failed to
provide examples of actual operational problems that this policy would
solve, whilst many examples of potential harm have been provided.


> > The proposal

> > authors will blow off these concerns as 'surely AFRINIC will never make

> > a mistake', ... but that simply is not how things work.

> 

> I wrote "This chance is not exactly zero. As with any other change

> anywhere." on this list about 51h ago. So: no. I still believe we live

> in the same reality.

> 

I agree that the *probability* of adverse impact is relatively low.

However, the degree of harm that may be caused in that event may be
extremely large.

We have to weigh both when evaluating the risk introduced by this
policy.

In this case The additional risk dramatically outweighs the benefits.


> 

> > In the current RPKI service model, most problems can only be caused by

> > AFRINIC members themselves, and only related to their own prefixes. It

> > is a Good Thing [tm] when people can only negatively impact themselves.

> 

> I absolutely agree. Also well put.

> 

> > However, in the proposed model a whole new level of mistakes become

> > possible!

> 

> Yes. agreed.

> But we have to note that this is for network operators to decide on

> whether they want to use the *optional* new TAL with new-shiny "includes

> AS0" features.

> 

Again, the policy *does not* mandate the use of a separate TA. This
point is bogus.

If the authors would like to continue relying on this argument, please
request that the last-call be ended, and ship a new version of the
proposal, with the separate TA as a mandatory requirement.


> 

> > Lessons from the RIPE Region

> > ============================

> > 

> > ...

> > 

> > RIPE NCC is subject to EU Regulations and Sanctions. Iranian and Syrian

> > internet participants would have been at risk of losing internet

> > connectivity (on top of an already challenging and devastating

> > situation) if the idea of AS0 TALs was implemented.

> 

> That risk is serious and I should think carefully and twice before using

> the RIPE AS0-TAL. Thanks for warning me and thanks for giving me the

> choice. Oh. not?


Why would we ask AFRINIC to spend valuable time and energy manufacturing
a dangerous foot-gun, which even the designers would "think [...] twice
before using"?

Don't you have a list of things that would actually be useful? I do!


> 

> > This shows that the

> > idea of AS0 policies is at odds with the Internet's architecture.

> 

> At this moment I don't see the big difference to a Team-Cymru bogon feed

> via bgp. The cymru feed having the extra minus of involving an extra

> external party.

> 

Depending on how that service is used, the effects may be very similar.

But the mere existence of a similar service is not an argument for
re-creating it. If anything, it makes the proposal redundant.


> > https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html

> 

> It's sad that RIPE NCC and members have to worry about sanctions.

> I have no idea how (better or worse?) that would be different in

> Mauritius. And well, i don't know where that leaves scope of this list.

> 

We have previously been advised by AFRINIC staff that treaties between
the EU and Mauritius required the implementation of GDPR.

I imagine the position regarding EU-imposed sanctions would be similar.

Perhaps we could hear from the lawyers in the WG on this point?


> > Even if this policy proposal is implemented under a distinct TAL, there

> > will be some networks somewhere that misunderstand the risks and

> > consequences of 'AS0 TAL', and subsequently end up losing connectivity

> > towards some Internet destinations for no good reason. 

> 

> Reminds me how i advised someone to not enable validation....

> 

> > Another aspect: almost no operators are using the APNIC/LACNIC AS 0 TAL!

> > It appears many people recognize that it brings additional risk, for no

> > reward. Success stories of the AS0 TAL in LACNIC and APNIC do not exist.

> 

> It's new and optional.

> 

> > Conclusion

> > ==========

> > 

> > RPKI has been designed to be used as optional security feature to help

> > grow the Internet, not as a 'punishment' or 'censorship' tool.

> 

> ehm: that's also not the intention here.

> And in my opinion AfriNIC is not allowed to use RPKI in that way.

> 

Whether it is the intention is besides the point.

The best way to ensure a tool is not abused is not to create it.
Once it exists the potential for abuse exists, regardless of anyone's
intentions.

In my view, the most important thing to recognize is that a third party
may *force* AFRINIC to abuse it.


> > To

> > reclaim unassigned space, AFRINIC can continue to work with global

> > carriers on a case-by-case basis. The 'problem' this proposal 'solves'

> > is NOT proportional to the risks the proposal introduces.

> 

> I could name you a carrier that's validating and advertising space from

> the de-registered customer ("bogon AS"). Did they have a talk to their

> customer to get reinstated at AfriNIC? Would AfriNIC staff confirm that

> they contacted that upstream?

> 

The key word in Job's statement is "proportional".

Bogons are annoying, and can be used to hide abusive activities.

However, they can be dealt with through other means, and do not cause
outages on the scale of millions of users.

The medicine we produce should be no more poisonous than the disease.

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/20210609/c3abeb05/attachment-0001.sig>