On Nov 26, 2013, at 4:24 PM, Geoff Huston <[email protected]> wrote: > > I reviewed the mailing lists of all three WGs from November last year, when > this came up. > and I was searching for a proposed methodology of defining requirements, > proposing mechanisms > and standardising one of more candidate technologies relating to the issue of > path > control of the propagation of BGP announcements in order to allow BGP speakers > to detect unintended announcements. My search of the list archives was > unsuccessful. > > As I seem to be the only one interested in an answer, I give up. > > geoff > > > (Of course the net value of the entire effort in "securing" a routing > protocol that still cannot > discriminate between intended routing announcements and all forms of routing > lies is in > itself another interesting question, but maybe that's best answered by those > folk who will, > or will not, turn on this particular set of routing control knobs in their > routers.)
Indeed… I’d like to solve the routing security problem and at least get back to where we were circa ’95 (see the IRR policy considerations draft). The routing security issue IMO is ultimately a routing policy issue (coincidentally, as is the inter-domain anti-spoofing problem). The reason people don’t do these things is because they didn’t have some form of resource certification to manage staleness/integrity/automated configuration/etc, etc.. As Russ points out we tried to address this in SIDR and it wasn’t in their carefully crafted charter. BGPSEC work ignores the policy aspects, tightly couples resource certification with inter-domain routing, and slams RPKI directly into the routers and routing system, introducing considerable new external dependencies and overhead and little capability for autonomy and “buffers", and IMO, will be “challenging” to in the real world. I’ve burned enough cycles trying to be productive there, all to no avail. I do believe that eventually, the only way a global resource certification infrastructure will be fully employed is if it’s only loosely coupled to the routing system. I would like to see the IETF address the routing system security issues in a manner more cognizant of operational, business, and geopolitical realities, but have found immense cycles ineffective at influencing a carefully pre-plotted course, and until something changes significantly I know of at least one operator that will focus elsewhere with other mechanisms and our resources. -danny
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
