[db-wg] Temporary origins

At RIPE70, in the DB Workgroup and the Cross Region BoF, there was some 
discussion of authority to originate a route.  There was indication of 
one major operator's intent to look to the RIPE IRR for validation of 
OriginAS.
In addition to Cross Regional concerns about the correctness and 
authority to originate, there was also a need to support temporary 
redirection (change of originAS) mentioned.
Temporary redirection is often accomplished by BGP announcement.

There was some discussion of the ownership of address-blocks by an AS.
RPKI has answered these in ways that are not universally adopted, but do 
place the authority to originate (ROA) in the responsibility of the 
"prefix holder" (4), not an AS with which it might normally be 
associated.
rfc 2725 also says, in section 9.4 route objects:
"There is a legitimate reason to be in more than one origin AS."

I propose that we aim to validate that the IRR database model is 
consistent with the RPKI model in requiring the authority of the 
maintainer of the inetnum to originate a route.
However RIPE current documentation opposes this, "authorisation for 
creation of route(6) objects can and must be provided by both the 
address space holder and the holder of the AS number" (5) .

We need to allow for more than one AS to be authorised to announce an 
origin for a prefix, even though we expect only one originator to 
announce normally.  Multiple Origin AS (MOAS) conflicts occur today and 
do not appear to cause problems in their own right, as discussed in 
reference (1).  Indeed the motivation for this discussion was to create 
policy for selecting routes in MOAS cases.


I would like to propose for discussion that a basic set of objectives 
might be:

1.  An inetnum is globally unique and has a maintainer that is at least 
unique to each RIR  (perhaps legacy address space may show different 
maintainers in different RIRs);
that maintainer has the responsibility to identify which ASNs are 
entitled to announce an origin for that inetnum,
and to register allowed ASNs in the IRR of that RIR.
In this way the authentication of the person and their right to make 
changes stays within the one RIR.
It is of no significance whether the ASNs identified are registered in 
the same RIR, or not.

2.  Clarification, if necessary, that more than one route object for a 
subnet is permitted, where each RO has a different originAS.  I have 
found no prohibition of multiple route objects for the same subnet.  If 
one exists we should review its merit.

2.  Each RIR should feed up its IRR to a global 'read-only' IRR.  
Alternatively each RIR should provide its IRR to all other RIR so that 
each may maintain an independent global view.
Data structures may also need to be adjusted to accommodate more than 
one authorised originator.

3.  The routing announcements actually made by an AS are the 
responsibility of the AS-maintainer, and that AS-maintainer should be 
accountable in cases where the AS announces origin for a subnet for 
which the AS does not have the authority. If this is useful.

Notes:
a.  More than one route object record with different originAS may be 
appropriate:
-    where there is multi-homing without BGP or
-    where organisations make use of BGP redirection for temporary 
third-party services, like DDoS mitigation

b. rfc 1930 (BCP-6)  section 7 says:
"Generally, a prefix can should belong to only one AS".
The first word indicates that there should be allowance for exceptions.  
The rfc was written at a time when the relationship between AS number 
and IP block was much more stable than it is today.

c. There seems to me to be some ambiguity about route objects and 
Origin.  rfc 2725, section 9.4 route objects (3) says:
"There is a legitimate reason to be in more than one origin AS."

But route objects have only one origin field.  If multiple route objects 
pointing to exactly the same subnet are allowed then who has the 
authority to create route objects?
I suggest that the authority should reside with the inetnum maintainer.  
This makes the origin part of a route object rather than an attribute of 
inetnum.
d. An alternative, might be to require (best practice) that temporary 
route announcements should prepend the ASN of the owner's AS.  But this 
has an impact on the effectiveness of the announcement in the case of 
hop-count tie-breaks.

References:
(1) http://www.cs.colostate.edu/~massey/pubs/conf/massey_imw01.pdf
An Analysis of BGP Multiple Origin AS (MOAS) Conflicts {Xiaoliang Zhao, 
Dan Pei, Lan Wang, Dan Massey, Allison Mankin, S. Felix Wu,Lixia Zhang}

(2) https://tools.ietf.org/html/rfc1930
BCP-6

(3) https://tools.ietf.org/html/rfc2725#page-12

(4) http://www.potaroo.net/ispcol/2011-07/bgpsec.html {Bush & Huston}

(5) 
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.78/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object

________________________



Steve Nash CEng MIET

Consulting Engineer

Arbor Networks

office +44 118 967 4917

mobile +44 772 029 1359

http://www.arbornetworks.com/

________________________





-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20150623/bf5354ee/attachment.html>