(coffee != sleep) & (!coffee == sleep) donald.sm...@qwest.com gcia
> -----Original Message----- > From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On > Behalf Of Jeffrey I. Schiller > Sent: Tuesday, September 22, 2009 8:53 AM > To: Curtis Villamizar > Cc: sidr@ietf.org > Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) > > On Tue, Sep 22, 2009 at 12:09:50AM -0400, Curtis Villamizar wrote: > > Interesting idea. But if this is a free for all, I can just declare > > to the world that I have rights to 18/8? Or maybe just the subnet > > that includes ns.mit.edu. And then I announce it and everyone > > believes it. > > Well first you would have to convince a CA for RPKI that you are in > fact the legitimate holder of 18/8. Given that the CA's should check > the WHOIS data for 18/8, they should see that you are not MIT and not > issue the cert. > > Now there is always the possibility that someone will make a mistake > and issue the certificate anyway. This is but one reason why > revocation is important, so we can correct such mistakes when they > happen. If a particular CA seems to be making many mistakes, then > maybe it has its certificate revoked and we move on (better hope the > trust anchors behave!). > > > I think that is the problem we are trying to solve. > Without some form > > of authoritative hierarchy we haven't solved anything. > > > > One possibility is that providers can pick who they trust. If a RIR > > causes trouble maybe they get dropped by some providers with an > > alternate considered authoritative. This could make peer pressure a > > factor, or it could fragment the web of trust and limit acceptance. Don't we all end up having to trust the same set of RIRs? We have to trust more then just the one we choose to sign the certs. We have to trust the set that other ISPs trust too or not accept their certs unless I am missing something here. > > This is risky (and will happen). The way to avoid problem here is to > have a good set of trust anchors up front, complete with multiple > sources of certificates for each situation. In this fashion if one CA > doesn't issue a certificate, another can. > > At this end of the day, the more I think about this the more I am > beginning to believe that it is the providers (aka ISP's) who should > run the CA's (or an organization chartered by them). For at the end of > the day, it is the providers and their customers who are the stake > holders in this game. > > From an IETF perspective, if we want RPKI to be deployed, it is the > providers that have to be sold... and selling a system that causes > them to lose control (even to a small degree) of a service which is > essential to their core business, will be a difficult sell. Difficult to sell is putting it mildly. Most ISPs don't run CAs today nor do they have the infrastructure to do so. Neither will they want to turn over any aspect of routing control to a 3rd party. > > -Jeff > > -- > ============================================================== > ========== > Jeffrey I. Schiller > MIT Network Manager > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue Room W92-190 > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > j...@mit.edu > ============================================================== > ========== > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr