[routing-wg] Fwd: [db-wg] Cross registry authentication BOF - rough notes

Hi all,

With many thanks to Nigel Titley for being unceremoniously picked on
to write some notes for yesterday's BoF on cross-registry route object
authentication, here they are.

Discussion is largely going to happen on the db-wg list.

Cheers,
Rob

----- Forwarded message from Nigel Titley <nigel at titley.com> -----

Date: Tue, 12 May 2015 19:35:16 +0200
From: Nigel Titley <nigel at titley.com>
To: Database WG <db-wg at ripe.net>
Subject: [db-wg] Cross registry authentication BOF - rough notes
X-Spam-Score: -0.0 (/)

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.  





----- End forwarded message -----