The document discusses changes to the RIPE IRR database to prevent "foreign objects". Specifically: - As a result of policy discussions over several years, the RIPE NCC will no longer allow APNIC region resources to be included in the RIPE IRR database to prevent hijacking of prefixes. - Existing foreign objects will be maintained separately but new foreign objects will not be permitted. - The changes aim to ensure resources are always controlled by their designated holders and any routing assertions require their explicit consent.

1. 2018#apricot2018 45
Foreign Objects in RIPE IRR
George Michaelson, APNIC

2. 2018#apricot2018 45
“good news, everyone”
2

3. 2018#apricot2018 45
“good news, everyone”
3
No, really.
This is a
good news story.

4. 2018#apricot2018 45 4

5. 2018#apricot2018 45 5

6. 2018#apricot2018 45 6

7. 2018#apricot2018 45
No more foreign objects in RIPE RPSL
• As a result of ongoing policy discussions over several years
the RIPE NCC is closing off a hole which permitted APNIC
region resources to be included in the RIPE RPSL
• This should hopefully prevent some forms of ‘hijack’ of
prefixes because RPSL in RIPE IRR can no longer lift filters
for these prefixes to be origin-AS from the RIPE region ASN
• Existing foreign objects are maintained in a different RPSL
”source” which is now closed.
7

8. 2018#apricot2018 45
Background/History
• May 2015, discussions at the RIPE70 meeting Amsterdam
• 2015-2017 ongoing DB-WG, Routing-WG discussion
• 2017 concrete proposals to deprecate foreign objects
• End 2017, Q1 2018 consensus reached
• Q1 2018 RIPE NCC Technical staff publish work program to
move data, close foreign object admission in source RIPE
8

9. 2018#apricot2018 45
Proposed body of work (WG chairs)
• Remove the ASN authorisation requirement for ROUTE(6) object creation
– Deprecate the "mnt-routes:" attribute in the AUT-NUM object
– Remove the 'pending object creation' functionality for route creation
• Create the source 'RIPE-NONAUTH’
– Move all ROUTE(6) objects relating to non RIPE managed address space to this new
source
• (pending eventual deletion after further discussion)
– Move all non ripe managed AUT-NUM objects to this new source
• (pending eventual deletion after further discussion)
• Adjust the query service relating to serving the RIPE-NONAUTH data
9

10. 2018#apricot2018 45
Proposed body of work (WG chairs)
• Disallow creation of any new AUT-NUM or ROUTE(6) objects in the RIPE Database
for non RIPE managed resources, but allow existing objects to be modified or
deleted
• Remove the "mnt-routes:" attribute from all the placeholder INET(6)NUM objects in
the RIPE Database for non RIPE managed address space
• Delete the MNTNER object with the public password
– ('fixing' any other database objects that may refer to it)
• Update all documentation to reflect the new processes
• Ensure that the inter RIR transfer process for resources moving into the RIPE
managed address space does not allow the transfer of ROUTE(6) objects from
source RIPE-NONAUTH to source RIPE without the agreement of the resource
holder
10

11. 2018#apricot2018 45
Outcome: you control your resources
• Existing data held in the RIPE NCC IRR is moved into a
clearly denoted ‘foreign’ space
– It is probably heading to being removed. You will be informed.
• If your resources need to be routed via an Origin-AS held in
the RIPE-NCC, your inclusion in the decision is now explicit
(but, out-of-band)
• Future routing assertions in IRR/RPSL should always
include your explicit consent.
11

12. #apricot2018
19 – 28 February 2018KATHMANDU, NEPAL
2018
45