On Mon, Sep 21, 2009 at 2:19 PM, Andrei Robachevsky <[email protected]> wrote: > 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.
not 'require' but 'make provisions for' ... which I think is more a router-os/router-policy-engine implementation (and customers asking for this knob, akin to 'accept-own-as'). -chris > >> -- 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 > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
