Subject: Re: [Sidr] other means of trusting announcements

From: [email-masked] (Sandy Murphy)
Date: Mon, 9 Jul 2007 16:58:11 -0400 (EDT)

A late reply to Joe's message:

>The RPSL repository operated by the RIPE NCC (the "RIPE database") on  
>behalf of RIPE members (and others) incorporates a feature which I  
>believe is not available in corresponding services offered by other  
>RIRs. The assignment/allocation data from the RIR (in the form of  
>RPSL inetnum, aut-num, etc objects) is linked for the purposes of  
>authentication with routing data (e.g. route, route6, etc objects).
>
>This linkage is provided by RPSS (Routing Policy System Security).  
>RPSS is documented in RFC 2725, but I do not know how accurate that  
>document is with respect to the code which is actually running today  
>in Amsterdam.

I recall asking at the mike in the Oct 06 ARIN meeting about support
for RPSS.  Andrei Robachevsky (RIPE rep there at the time) said that
RIPE fully supports RPSS.  (Ray Plzak said that ARIN did not.)  <ARIN
provides transcripts of its meetings - there's reason to believe this
is an accurate accounting.> I've also been told by people from the
RIPE region that they must adhere to the RPSS rules when registering
objects.  So I believe that the actually running RIPE code is doing
RPSS.

>In broad terms (and apologies to those who know the details of this,  
>and who are now cringing) it is not possible to register a route  
>object in the RIPE database if you are not authorised to manipulate  
>the corresponding (covering) inetnum object.

The actual RPSS rule is that you have to be authorized for the inetnum
for the prefix AND the aut-num for the AS.  This was the RIPE
authorization model that I mentioned in last Nov's sidr meeting.  I
asked if the ROA we produced should do that dual authorization, or
stick with authorization by the prefix holder only.  The comments at
the mike seemed to agree that the authorization by the prefix holder
only was appropriate.

>[The big hole in this trust dynamic is that for addresses assigned by  
>other RIRs, no such linkage exists; in practice anybody can install  
>route objects for addresses they have no business announcing in the  
>RIPE database so long as those route objects don't already exist, and  
>so long as the addresses concerned are not taken from one of the RIPE  
>NCC's pools.]

So RIR-run IRRs have the opportuntity to authenticate registrations
from that RIR's members.  
    Those RIR's who have just one database that holds both resource  
    information and routing policy information (e.g., RIPE) have an  
    easier time of this than those RIR's who have separate the resource  
    database from the routing policy database (e.g., ARIN).

RIR run IRRs can not authenticate registrations from non-members.

non-RIR run IRRs (RADB?) can not directly authenticate anything
registered with them.

Incidentally, from what I've heard and overheard from ARIN staff,
ARIN's IRR will authenticate registrations against the authentication 
in their resource database.  But:
   - the mtn-by in the IRR database side is not always in sync with the
     POC in the resource database side, which can make authentication
     difficult when they do not match
   - they allow but can't authentiate registrations for non-members (see above)
   - they authenticate inetnum and aut-num registrations, but do not
     authenticate route objects.

>The key point is that it is possible to build a prefix filter based  
>on policy expressed in an aut-num or as-set RPSL object using the  
>RIPE database

I thought the RPLS route object was the closest match to the ROA, not
the aut-num/as-set.  Wrong?

There is one other basic difference between the IRR authorization
model and the resource certificates and ROAs we are defining.  The
IRRs use a secure channel model; we use a secure object model.  The
IRR model is that the registry authenticates input to it, stores the
authenticated input, and you get your data (hopefully through a
protected channel) from the IRR.  Getting a copy of the IRR data from
anywhere else gives you no assurance in the data.  In the resource
certificates and ROAs, the objects themselves are protected, so you
can get the objects by any channel (posted somewhere, peer-peer
exchanges, rsynch...) from anywhere and the objects are still
protected.

--Sandy

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Jul 2007 19:20:15 -0400

On 9-Jul-2007, at 16:58, Sandy Murphy wrote:

> RIPE fully supports RPSS.

As a some-time use of the RIPE db, I agree.

> (Ray Plzak said that ARIN did not.)

Similarly, as a some-time user of the ARIN db, I agree with that too.

> the aut-num/as-set.  Wrong?

What usually happens is that for each ISP there is a set of AS  
numbers, the members of which are used to originate routes. One (or  
more) of those ASes will roughly equate to "the ISP". The rest  
probably can be treated as "BGP-speaking customers".

A peer (in the BGP sense, not the economic sense) of that ISP who  
wants to filter prefixes announced from that ISP's routers might ask  
"what's your AS-SET?" and receive the name of an object whose members  
are the ASes mentioned above. The peer can then query the whois  
server and enumerate "all routes with an origin AS that is a member  
of this set".

I think in the context of SIDR, the IRR as a whole (the RPSS- 
supporting minority and the rest) represents a source of possibly- 
feasible routes that a peer AS might want to announce. There are  
other such sources (e.g. mail from customers saying "please announce  
X"). RPSS means the set is more likely to be accurate, but it's still  
no guarantee of anything in practice (and will never be so long as  
there are RPSL repositories run by people who are not RIRs).

However you obtain your list of feasible routes, you still need a  
reliable, automated mechanism for deciding whether a given route is  
actually sensible to accept. It seems to me that most of that would  
be accomplished by the work being discussed here (with the possible  
exception of a convention or protocol to allow ROAs to be retrieved?).

Joe