[DBWG] route-object auto-created from a ROA

Fri Nov 23 07:08:26 UTC 2018

Hi all,

Apologies for being late to this conversation.

I have no general objection to the idea generating route[6] objects from ROAs *in general*, but there are operational consequences that need thinking about.
There seem to be two models under discussion here:
1) A tighly coupled method where a route[6] object is auto generated at the same time that a ROA is created, and can't be modified/deleted other than by revocation of the associated ROA; or
2) A loosely coupled method where the UI hints the user that they may want to create equivalent route[6] objects when creating ROAs if "matching" objects can't be located.

Option 2 sounds to me like a good way to increase the cruft present in the database, and I'm against that option. So I'll focus on option 1:

Issue 1 - read-only:
The created route[6] objects should be read-only via the normal IRR interaction channels (to prevent them getting out-of-sync with their ROA counterparts).
The two ways that I can see of doing that are:
a) a special maintainer object, that will have mnt-by on all created objects. The downside to this is that it violates the authorisation model in use for "normal" objects.
b) a separate database with a separate source name, which is read-only for all operations other than the ROA-route[6] hook that we're discussing. This is my preference, for the reasons below.

Issue 2 - source:
Many users of the IRR (us included, and I know of several others) use knowledge of the authorisation semantics of a database in their resolution logic (e.g. preferring RIR databases with strict authorisation semantics). This is typically implemented by matching on the source attribute.
Therefore, I would suggest that using a separate database source name (e.g. AFRINIC-RPKI?) for the created objects.
This would have consequences for those who either mirror the database (they will need a separate nrtm session for the new source, at least in irrd v3) or set their sources list explicitly when querying. Recent experience from the ripe-nonauth change tells us that this is a non-trivial issue. However, unlike ripe-nonauth change, we are talking here about only *new* data, and this won't break existing usage of existing data.

Issue 3 - grandfathering/opt out:
How do we deal with existing ROAs?
- If we grandfather them in (by creating the missing route[6] objects), we are making a change that the original creator did not authorise at creation, and couldn't be reasonably be expected to have anticipated.
- If we don't, then the set of route[6] objects will never be complete (with respect to the set of ROAs). The same is true if we provide an opt-out of this mechanism. I don't have an issue with this approach, but it should be properly documented that the RPSL version of the data is probably incomplete.

Issue 4 - maxlength:
Should not be used by *most* operators in general. See [1]. It is even more of an issue here. Because there is no matching route[6] object attribute, there is no good way of performing this mapping. As far as I can see, there are the following options:
a) ignore maxlength, and create the route[6] object only for the covering prefix in the ROA.
a*) as above, but put "remarks: ROA maxlength: x" (or similar) in the route[6] object.
b) create an object for every covered prefix. No no no no no. My filters are plenty long already, thanks. Not to mention that f00::/32-/64 will run the whois server out of memory very easily.
c) do nothing in respect of ROAs with maxlength set (to something longer).
My personal vote is a*. I am not against c. I am strongly against b.
I would be interested to hear other peoples views here.

Happy to have off-list arguments if people prefer ;-).

Cheers,

Ben Maddison

[1] https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-01

Director
Workonline Communications (Pty) Ltd

Office:      +27 (0) 21 200 9000
Mobile:      +27 (0) 82 415 5545
Email:       benm at workonline.africa

________________________________________
From: Sylvain BAYA <abscoco at gmail.com>
Sent: 10 October 2018 15:37:28
To: dbwg at afrinic.net
Subject: [DBWG]  route-object auto-created from a ROA

Hi @ll,

Le mer. 10 oct. 2018 7:33 AM, Amreesh Phokeer <amreesh at afrinic.net<mailto:amreesh at afrinic.net>> a écrit :
Hi Avinash,

Thanks for starting this discussion. We had an internal discussion about which way (IRR->ROAs or ROAs -> IRR) would be best.

IMO, creating route objects from the current MyAFRINIC ROA interface doesn’t seem to be practical, as a ROA can contain several prefixes (v4 and/or v6) + max length. We can have a section on MyAFRINIC where the user can manage all IRR objects related to the resources the member holds. During creation of a route(6) object, if the member’s RPKI engine is activated, an option to create a ROA appears, the user ticks the “Create ROA” checkbox and both route objects and the ROAs are generated. Similarly, when a route object is deleted, the equivalent ROA is revoked.

Caveats to be dealt with:
- ROAs have additional information such as start and end dates and max length, route objects have prefix-length only.
- ROAs cannot be modified, they can only be revoked
- Route objects do not have max-length i.e. the max-length in the ROA should be set equal to the prefix-length to match the route object

Thoughts?

This article [1] would, perhaps, be of interest.

Amresh, can we also have a similar OT&E (Operational Test & Evaluation) [2] environment in our context ?

I suggest you to implement your idea in a test environment then allow users to try it and propose changes|ameliorations until we reach the next 'release'...
__
[1]: https://teamarin.net/2017/10/31/implementing-rpki-its-easier-than-you-think/
[2]: https://www.arin.net/resources/ote.html

Regards,
--sb.

--
Amreesh

> [...]

--

Regards,
Sylvain B.
http://www.chretiennement.org<http://www.chretiennement.org/>
__
Website : https://www.cmnog.cm<https://www.cmnog.cm/>
Wiki : https://www.cmnog.cm/dokuwiki
Surveys : https://survey.cmnog.cm<https://survey.cmnog.cm/>
Subscribe to Mailing List : https://lists.cmnog.cm/mailman/listinfo/cmnog/
Mailing List's Archives : https://lists.cmnog.cm/pipermail/cmnog/
Last Event's Feed : https://twitter.com/hashtag/cmNOGlab3
https://twitter.com/cmN0G
https://facebook.com/cmNOG
https://twitter.com/hashtag/REBOOTcmNOG
https://twitter.com/hashtag/cmNOG
https://cmnog.wordpress.com/