Samuel Weiler wrote on 21-09-2009 20:03: > On Thu, 17 Sep 2009, Sandra Murphy wrote: > >> I recognize that there is an fear that this system somehow puts ISPs >> under someone's control. I would answer that there is not any more >> control than is already the case. > > David Conrad already responded to this, pointing out the technical > possibilities. > > I think it's also instructive to look back at the message that started > this thread (also from David Conrad), which astutely observes: > > "... their parents, grandparents, great-grandparents, etc. in the trust > hierarchy potentially could, by intent, whim, or error, instantly and > completely remove their ability to send/receive Internet traffic[1]? > ... > [1] Note that the actual accuracy of this statement is not particularly > relevant since there will be folks who will spin the capabilities of the > system in this way." > > However the system IS used, I'm sympathetic to David's concern that the > potential for control could be a barrier to deployment. Which leaves us > with the question of how to design a system that is resistant to capture > and control. Or perhaps, as Jeff Schiller proposed, build something > that doesn't change the current balance of power. > > What would we need to do differently in the RPKI design to prevent > capture and control? >
I think, nothing. The RPKI attests to Internet resource holdings, nothing more. The worst thing that can happen is when we cannot trust uniqueness of address allocation. To mitigate concerns regarding capture and control we need to shift decision making to the ISP level as much as possible, to their routing policy definitions. In other words, require a fallback to insecure routing, rather than dropping the RPKI-invalid announcement off altogether. > -- Sam Andrei > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
