[ppml] Proposed Policy: Capturing Originations in Templates

[sandy at tislabs.com]

>> The issue is that RRs at least in North America are run separate from
>> registrars and there is no way to be certain that whoever entered
>> something in RR is authorized to have done it.
>> 
>This simply isn't true.  Some of the RRs are run separate from
>registrars, but, there is an ARIN run RR run by ARIN which is the
>only registrar in North America.

ARIN does indeed run an RR.  If you look at www.irr.net you will see
that there are many other RR's in North America, including the very
widely known RADB.  And Verio.  And SAVVIS. 

Coincidentally, I mentioned the authentication problem for route
objects stored in RRs in a presentation in the Lighning talks at NANOG
yesterday.  

RIR run IRRs have internal access to their authentication mechanism
for the prefix holders and can authenticate the route object as being
from the authorized holder.

   Note: the ARIN site says that they will check the email address from
   the sumbitted RR object against the POC in the template for the
   associated address block.  OK, so that's a weak authentication, but at
   least the hook is there for a check.  However, I'm told by an informed
   source that this is done for inetnum and aut-num but not for the route
   objects.

Non-RIR run IRRs would have to find a way to get that authentication
check from the RIR or get it done by the RIR.  When the authentication
check is MAIL-FROM, anyone can do the check.  But... it's MAIL-FROM ;-{

   (I understand that RADB does no checking, anyway.)

RIR run IRRs are in the same position if they are allowing
registration of objects associated with non-member resources.  They
wouldn't be able to do the authorization/authentication checking
themselves; they would have to rely on the remote RIR for that
resource.

--Sandy


P.S. There is an RFC (2725) that defines a security model for who
should be allowed to register types of RR objects. For route objects
it say they should be registered by the person/org allocated the
prefix. {Truth in Advertising: I am listed as an author.  Truth in
Reality: Curtis Villamizar *is* the author; I contributed little.}

Actually, RFC2725 says a route object should be authenticated from
both the prefix holder *and* the AS holder - and I think RIPE does
this.  But then RIPE holds both the allocation data and the registry
data, so they can.