Incrementally deployable secure Internet routing: operator survey

Dear Nanog,

Knowing how challenging it is to apply new technologies to current networks, in a collaboration between ETH, Princeton University, and University of Virginia, we constructed a system that provides security benefits for current Internet users while requiring minimal changes to networks. Our design can be built on top of the existing Internet to prevent routing attacks that can compromise availability and cause detrimental impacts on critical infrastructure – even given a low adoption rate. This provides benefits over other proposed approaches such as RPKI that only protects a route’s origin first AS, or BGPsec that requires widespread adoption and significant infrastructure upgrades.

Our architecture, called Secure Backbone AS (SBAS), allows clients to benefit from emerging secure routing deployments like SCION by tunneling into a secure infrastructure. SBAS provides substantial routing security improvements when retrofitted to the current Internet. It also provides benefits even to non-participating networks and endpoints when communicating with an SBAS-protected entity.

Our ultimate aim is to develop and deploy SBAS beyond an experimental scope. We have designed a survey to capture the impressions of the network operator community on the feasibility and viability of our design. The survey is anonymous and takes about 10 minutes to complete, including watching a brief 3-minute introductory video.

We thank you for helping inform our further work on this project. We will be happy to share the results with the community.

With kind regards
Prateek Mittal, Adrian Perrig, Yixin Sun

Matt Harris​

Infrastructure Lead



Looking for help?


Email Support

We build customized end‑to‑end technology solutions powered by NetFire Cloud.


//Speaking as RTGWG co-chair

As commutated to SCION proponents before, a detailed presentation at IETF RTGWG would be a good starting point.
Please consider doing so at the upcoming IETF113.
The best way is to subscribe to rtgwg mailing list and respond to chairs email request for presentations, perhaps you’d also want to respond to comments/questions after tthe presentation, being subscribed would facilitate that.
Usually we’d prefer a draft to allow for a presentation, however, for the intro (unless you would actually go ahead and write an architecture draft), we’d be ok with just a presentation.

Please let me know if you have got any questions.



Hi all,

other proposed approaches such as RPKI that only protects a route’s origin first AS, or BGPsec that requires widespread adoption and significant infrastructure upgrades.

For both RPKI-based BGP Route Origin Validation and RPKI-based BGPsec - that meme “widespread adoption is a prerequisite to benefit” is somewhat annoying in getting widespread adoption going. Plz Stop It! :slight_smile:

In my opinion, global scale BGP routing security does not depend on concepts like “herd immunity”. Rather, I would frame “BGP routing security” as a problem requiring selfish acts, not collective action. The benefits become immediately available to you and your EBGP peer (who agreed to participate in the effort). Commercial incentives align with upgrading (both transport capacity and security) one peer at a time.

All of RPKI ROV, BGPsec, ASPA/peerlock, and even older plain-text stuff like “IRR” are incrementally deployable technologies; because how else would one ever get anything deployed in fast-and-wide growing multiple-operator networks such as the Internet? Nothing happens at the same time. But when it happens, it progresses at the pace of decades, at times so slow one might think the paint isn’t drying on the wall.

BGP sessions “worth protecting” usually are the revenue generating/cost reduction sessions, and as such usually are assigned highest LOCAL_PREF. I think this property has interesting implications on how routing security features become available and are demanded from others throughout the ecosystem. For most networks at the edge, the private peering sessions also are the BGP sessions with the least BGP state on either side, compared to say upstream.

The “significant upgrades” aspect is just part of the job and happen no matter what. Every network replaces all their kit at some point in time; but sometimes it takes as long as ten to fifteen years! The good news is that every replacement also comes with improved cryptographic op accelerators in the CPU and more memory; and it all seems to be converging towards commonly available general purpose computing systems on which people can run any BGP stack they want.

I’m bullish on BGP routing security tech already specified and published through the IETF process :slight_smile:

Kind regards,


the way i think of it is that

    rpki-based rov is a thousand points of light, each independently
    having a specified security property.

    rpki-based bgpsec forms islands of varied sizes, each island having
    a specified security property (quite different from that of rov).
    islands may merge to form larger islands.