Hi Sandra, To further clarify, > 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). This would mean for someone who gets the information from RIPE does not need to necessarily use the mechanism the way it currently stands.
Thanks, Vishwas On Thu, Feb 28, 2008 at 10:56 AM, Vishwas Manral <[EMAIL PROTECTED]> wrote: > 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
