Hi Sandra, Thanks again for the information in both the mails. I got to read the differences between the RIR and the IRR. I also agree to the fact that in case we have some mechanism which can verify all the attributes of a route, then such a certificate which does this would be helpful, and then the infrastructure you talk about would be helpful too.
I understand the fact that we are talking about a NLRI and the AS element in the AS_PATH. I still look very interestingly at differences we have between AS_SEQUENCE and AS_SET (if we are to verify an update more than one hop away which element in the AS-SET to verify it against - not much difference though if we have only one AS number in the AS_PATH). The only point I want to add to the discussion is because we have to verify the Origin only in the first hop peer, we do not need a global database (as I mentioned we are not saving against malicious attacks in any case). Thanks, Vishwas On Thu, Feb 28, 2008 at 10:13 AM, Sandra Murphy <[EMAIL PROTECTED]> wrote: > > On Thu, 28 Feb 2008, Vishwas Manral wrote: > > > Hi Sandra, > > > > > After reading a bit through what Pekka/ Danny/ Joe Abely said away in > > which we could update the filters between peers automatically(only > > relating to routes originated by the peer), from the RIR, we may > > achieve the very same functionality. > > > > Generating filters from IRR (not RIR, a point it took me a while to learn) > data is indeed similar, with the following differences: > > (a) Security (authenticity, integrity and authorization) of IRR data > varies widely among IRR's. And there are quite a few IRRs. > > (b) Even those IRRs associated with RIRs can protect authn/int/authr of > only that data that comes from their own members. > > (c) RIPE uses the strongest security model among the many IRRs, but their > system relies on protection of the communication with the user (and the > protection varies from user to user) and the protection of communication > to the person accessing the data. The protection is not stored with the > data, so the reader must rely on the IRR to get it right. I don't think > the reader can tell what protection was used to put the data in there, so > there's no way for the reader to judge the assurance in the data. > > (d) This is not a mechanism that could extent to protection of the other > BGP features that you have mentioned. So if/when we decide to work on > those features, we'd have to start over with the system we are building > now anyway. > > --Sandy > > > > _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
