Please find the rough notes that I took during this BOF attached
Nigel
Cross registry authentication BOF
Why do we need cross registry auth?
Currently alien autnum objects are created in order to authorise
route-object creation
Where inetnum is in RIR A and autnum is in RIR B this gets awkward.
Cross authentication would allow us to regularise this and get rid of a
lot of superfluous objects
It was questioned whether the RIPE database was the only one that
requires dual authorisation.
Four Possible directions
Flatten the mntner namespace
- Extend RPSL to allow foreigh references
- Define a new protocol to provide a quorum between registries
to find out where maintainer objects live
Objections are that we currently don't have a flat namespace
and will end up having to remove duplicate maintainers.
There are 939 colliding maintainer objects across the
registries checked which will have to be de-duplicated.
Points were raised about legacy space and here there is
different policy in the different RiRs which complicates things.
Use RPKI signatures
Another possibility is to use a RPKI signature to authenticate
the creation of a cross registry route object rather than using a maintainer
object.
Note that the latest version of the RPKI validator can export
ROAs in route object format which might help. Thoughts on this would be
welcomed.
Signed objects also have a definite lifetime which means that
there is an automatic garbage collection.
The point was raised that the validation is done at creation so
there is no automatic cleanup of route objects. This was refuted as when a
signed object is removed, all related objects are removed.
The point was raised that RPKI solves all the problems and why
were we looking further.
It was pointed out that RPKI doesn't solve the whole routing
problem. If the end goal is secure routing then we need BGP-SEC. This has been
bubbling around for 20 years or more and isn't going to be solved anytime soon.
However we probably don't want to solve the whole routing problem but the
origination problem, and there ROAs have a chance.
Ruediger wanted to say something nice about Alex but couldn't
remember what due to stack overflow.
The one thing that RPKI offers is the guarantee that statements
made about the ownership of a resource are correct.
Relax authorisation constraints
Technically the requirement to have authentication of both
autnum and inetnum object maintainers could be relaxed and only authentication
by the inetnum owner required. This would reduce the complexity considerably.
This is probably the simpler approach but will bypass the
autnum holders.
APNIC are seeing large number of final /8 intenums as few
customers have their own autnum. Creation of route objects is creating a heavy
load on their help desk. So there is some merit in this approach.
However there is a substantial amount of garbage in the system
which needs cleaning up and this proposal would make it worse. Much garbage
results from proxy registrations.
Fully define Autnum and Route objects in RDAP
Define POST for RDAP for creating route objects
- Route objects live in the RIR-of-the-prefix
- POST to RIR-of-the-AS
- Use redicts to RIR-of-the-prefix with RIR signed
tokens to authenticate one client with both RIRs
Use RDAP bootstrap for POST destination
This would involve an extension to RDAP
Authentication varies according to RIR.
This allows dual route authorisation for all RIRs. It also
allows each RIR to decide what authorisation is required according to regional
preference.
Comments
RPSL data and RPKI data from the RIPE database is often in conflict.
Should the RIPE NCC be doing something to resolve this conflict (Martin Levy)?
Feedback
Gert: option C is rejected by the community for various (possibly
bogus) reasons. However there was a feeling in the room that these reasons were
definitely bogus due to the ability to create alien autnum objects.
Eric Bais: Option A has the option to creat federations? Can we explore
that as it is a very elegant way to proceed with multiple registries?
Gert: make the namespace hierachical? But this will break RPSL parsing
(JS). However there are ways to encode things to bypass this.
Andrew Newton: Why can't we use the existing source identifier in the
maintainer name? This is enforced in the ARIN database but not in the others.
If we are going to fiddle around with RPSL then why not just throw it out and
start from scratch?
Option D has considerable attraction for automation as using an API-key
for authentication makes things easier.
It was noted that if you can trust the RIR then this is probably enough
for everyday use in building routing filters.
RPKI is supposed to hold much of the relevant information we need (RV).
Why not use it rather than developing a new method? Changing the operating
position for a network is not a decision to be taken lightly and this may delay
implementation for methods other than those based on RPKI.
Another operator commented that the easiest approach would be Option D.
It was noted that whatever approach we use must cater for small
companies as well as large ones capable of building their own toolsets.
There was some argument over whether source validation (using RPKI) is
sufficient or whether BGP-SEC is required. It is possible to build blacklists
from RPKI which gives more functionality than is currently available.
There seems to be no agreement except on the fact that the current
system needs improvement.
