On Thu, 28 Feb 2008, Vishwas Manral 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).
You are right that we have not considered how you validate an AS_PATH where the origination is an AS_SET. That has been looked at before, and it is complicated and the possibilities of providing some protection aren't good, even on the theoretical level. Keep in mind that the number of BGP Updates that contain AS_SET anywhere in the AS_PATH are a tiny, tiny, percentage (one figure I saw recently was 10K out of a base of 91M updates - .01%). As a wg, we decided not to work on this right now. > > 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). As long as *every* first hop peer does the appropriate strong verification, you would be good. But this system allows ASs beyond the first hop to verify the origination of the route. So, for example, UUNET could have verified the announcements it saw from PCCW even if PCCW did no check and propogated the bogus announcement. (As "Origin" is a BGP attribute with a different semantics, perhaps we should avoid using that term in this context to avoid confusion.) And, finally, yes we *are* protecting against malicious attacks (as well as accidental attacks) on those features we *are* intending to protect. No, we are not protecting against malicious attacks (or accidental attacks) on features we are *not* intending to protect. The difference is not malicious vs accidental, the difference is scope of protection. You think we haven't gone far enough, I'm saying what we're building is the basis for any further protection. --Sandy _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
