On Thu, 6 Mar 2008, Curtis Villamizar wrote:
> > In message <[EMAIL PROTECTED]> > Sandra Murphy writes: >> >> [---8<---snip---] >> << snip >> > > Sandy, > > Would you please enumerate those things that the IRR model does not > support after reading RFC2725 and RFC2769. > > Note that RFC2769 has not been implemented but would provide the > missing functionality (ability to authenticate information held in > other registries). It also provides efficient replication of > databases so anyone can have a local copy of any database of interest > to improve query time. > > I am not advocating going in that direction, simply pointing out that > SIDR to a large extent reinvents the wheel. If anything I think SIDR > not implementing the full RPSL semantics is deficient. > > Curtis > I commented last July on the security model (RPSS) used in RIPE http://www.ietf.org/mail-archive/web/sidr/current/msg00207.html To expand a bit. The model in RPSS has a similar basis as the model used in the RPKI, namely that delegation of a prefix requires authority over a covering prefix - that comes from the inetnum authorization requirement. The RPSS model also insists that the prefix holder is the one who authorizes origination of routes to that prefix. The RPSS model goes further to insist that authorization to originate routes (actually, to create a route object for a prefix) must also be granted by the AS mentioned. In that the authorization model in RPSS is different than the RPKI model. That makes revoking authorization different as well. To delte a route object in RPSS, you need the authorization of both the prefix holder and the AS. (This could cause difficulties if some prefix holder changes providers and wishes to remove the route object, if its former provider is not interested in OK the route object deletion.) RFC2769 addresses the problem (I think) of invalidating inetnums that are derived from an inetnet that gets deleted. (If that is what is meant as "repeating authorization checks".) It seems to me that there is no way to bound the number of database objects that are potentially effected by one object deletion. But the biggest difference is in the trust model. RPSS assumes that the IRR has a way to authenticate the principles - the maintainers. A particular object might have multiple maintainers (of various types) and each can have more than one way to be authenticated. The maintainers authenticate in some way to the IRR and the IRR stores the data. Those referring to the data must have some way to retrieve the data from the IRR that is itself secure. But even with a secure retrieval, the data retrieved carries no hint of the authentication with which it was transmitted to the IRR. You don't know which maintainer placed the info there and you don't know what authentication mechanism was used in accepting the data. No one can authenticate the data except the IRR, and no one can know what assurance to place in the data, aside from a blind "I trust my IRR". There are also issues of staleness of data, as there is no mechanism to state and enforce a validity period. (From reports, stale IRR data played a part in the spread of bogus info in the Con Ed incident last year.) An IRR might go to using the strongest authentication possible, and to accepting signed data and storing the signature. And publishing the certs it assigned to users. That would go pretty far to giving the same assurance of the RPKI. But that's kind of what I meant about adopting the same mechanisms as the RPKI, and therefore the cost --Sandy. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
