I agree with Tony. No need to overcomplicate a problem. Today, more and more ISP verify routing, using prefixes or (less reliable) AS--es, taking them from different sources. If you be able to add, in small increments, certified information into this routes, OR create external source of such information, and intimidate people to use it, you will make a step toward the goal. _You must not rely_ is really very strong overcomplicating. There is better to build 90% reliable xxx-BGP extension which will work in 1 year, vs. designing theoretically ideal , 100% reliable solution and never be able to deploy it.
(It reminds me SSL certificate problem - yes, you _should_ not rely on self signed certificates and on _in-band_ certificate delivery; anyway, using such certificates and such delivery is 1000 times better vs. using nothing /and danger of such usage is heavily overestimated by Verisign and other _fat certifiers_ sales. The same here - it is better to add any, simple information allowing to certify routes, instead of building the whole new system for this purpose.) ----- Original Message ----- From: "Tony Li" <[EMAIL PROTECTED]> To: "Russ White" <[EMAIL PROTECTED]> Cc: "Geoff Huston" <[EMAIL PROTECTED]>; "Daniel Golding" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, May 23, 2005 10:25 PM Subject: Re: soBGP deployment > > > > -- You must not rely on routing to secure routing. > > > I would like to point out that this goal is unnecesary. > > First, we need to understand that for ANY solution to be deployable, it > must be incrementally deployable. We do not get an Internet-wide flag > day for BGP. The Internet must continue to function, regardless of the > percentage of NLRI that are actually authenticated. For the forseeable > future, we will need to have a path selection policy that rejects any > information that clearly fails authentication, continues to use > unauthenticated prefixes, and prefers authenticated vs. unauthenticated. > > Second, validating a certificate must be doable even if the router is > using unauthenticated prefixes to do so. Remember that the crypto > properties of a certificate must make it unforgeable, and that routers > must have at least one reference point in the web of trust. If the > route to the root of that web is spoofed, then the crypto will not be > able to validate any other certificates in the web, but this is NOT an > authentication failure -- the related NLRI are just unauthenticated, not > unuseable. > > Obviously, authenticating the root certificate NLRI are our top > priority, but the system MUST continue to operate even without this. > This is the only way to truly address the chicken and egg problem. I > think that this also highlights the need for multiple, diversely routed > certificate authorities. > > Tony
