Categories
Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

Developing Good BGP Neighbour Relationships @ APRICOT 2019

Routing Security is featuring heavily on the APRICOT 2019 programme, which is being held on 23-28 February 2019 in Daejeon, South Korea. This helps build on the MANRS initiative being supported by the Internet Society,

On Wednesday, 27 February (09.30-13.00 UTC+9) there will be a Routing Security session that will discuss the latest problems, developments, and how routing security measures can be implemented. Speakers include Job Snijders (NTT) who’ll be discussing changes to BGP in the coming 18 months; Töma Gavrichenkov (Qrator Labs) on how BGP hijacks can be used to compromise the digital certificates used to secure online transactions; and from Anurag Bhatia (Hurricane Electric) who’ll analyse the top misused ASNs.

During the second part of the session, Tashi Puntsho (APNIC) will cover the practical issues and implications of deploying your own RPKI Certificate Authority; Tim Bruijnzeels (NLnet Labs) will discuss the use of route servers at Internet Exchange Points; whilst Ed Lewis (ICANN) will discuss the issues with using the RIR Whois databases.

Following on from this, our colleague Andrei Robachevsky will be raising awareness of the MANRS Initiative during the FIRST Technical Colloquium (16.30-18.00 UTC+9).

FIRST is the global organisation of Computer Security and Incident Teams (CSIRTs) which are often in the front line when network security incidents occur, but are also involved in implementing preventative measures and capacity building. MANRS therefore considers CSIRTs to be important partners in improving the security and resilience of the global routing system, as well as providing input and feedback on the MANRS Observatory that is being developed to provide analysis of the state of the security and resilience of the routing system.

The Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) is the largest international Internet conference in the region, drawing network engineers, operators, researchers, service providers, users and policy communities from over 50 countries to teach, present, and develop relationships. Other Asia-Pacific networking organisations also use the opportunity to meet, in order to share knowledge required to operate the Internet.

If you’re interested in attending then it’s still possible to register at https://2019.apricot.net/register/register/

Alternatively, if you’re unable to make it in person, then the sessions can be followed via webcast.

Further Information

Categories
Deploy360 Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

Even Better MANRS During August

We already discussed the MANRS activities during SANOG 32 where we organised a Network Security Workshop and signed an MoU with the ISP Association of Bangladesh (ISPAB), but the Internet Society was also involved with three other events during the month of August. This included the Symposium on Internet Routing Security and RPKI, VNIX-NOG 2018 and the inaugural INNOG 1.

Symposium on Internet Routing Security and RPKI

ZDNS along with CNCERT organised a symposium on 17th August at Crowne Plaza Beijing to discuss routing security issues and how RPKI can help address this problem. There were many prominent participants representing local, regional and international entities including Baidu, Tencent, Alibaba, Huawei, ZTE, the Chinese Academy of Sciences, APNIC, ICANN, along with the Internet Society.

Dr Stephen Kent (BBN) was the keynote speaker, having played an important role in the SIDR (Secure Internet Domain Routing) Working Group at the IETF (Internet Engineering Task Force) and also co-authored many RFCs (Request for Comments) on RPKI. He discussed the ideas behind RPKI and Route Origin Authorization/Validation.

George Michaelson (APNIC) who along with his colleague Geoff Huston co-authored RFC 6483 – Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) – followed this with a presentation on the status of RPKI deployment in the region with specific focus on China. CNNIC, the National Internet Registry (NIR) of China, only started offering ROA services in November 2017, so there is currently limited uptake, which is why the symposium is hoping to raise awareness of the importance of implementing RPKI.

I then outlined some of practical issues that network operators need to consider when deploying Route Origin Validation, as well as highlighting how the issues related to unallocated IPv4/v6 address space (aka Bogons) can be addressed.

VNIX-NOG 2018

The VNIX Network Operators Group Conference (VNIX-NOG) was held on 24 August 2018 in Danang City, Vietnam. This annual event is organised by the Vietnam Internet Network Information Centre (VNNIC), a National Internet Registry, and has become an important focus for local community to improve understanding and knowledge, and offers a platform to discuss information security issues relevant to Vietnam.

The theme of this year’s event was Routing Security, and Srinivas Chendi (APNIC) provided some background on RPKI, whilst Hiroki Kawabata (JPNIC) shared JPNIC’s experience of deploying RPKI for.

I then presented the ‘Routing Security landscape‘ that highlights the issues of BGP hijacks and leaks and how it would be beneficial for ISPs to join MANRS initiative. Very interestingly, not a single service provider in Vietnam advertises any IPv4/v6 Bogon.

INNOG 1

The ISP Association of India (ISPAI) organised the inaugural Indian NOG (INNOG) in the capital city of New Delhi. The event comprised three days of workshops (27-29 August 2018) and a one-day conference (30 August).

The Internet Society supported the Network Security workshop with our community trainers Moinur Rehman and Anirban Data, and turned to be fully booked. Our colleague Subhashish Panigrahi presented the MANRS initiative and highlighted the routing issues impacting Indian ISPs and enterprises, as well as the simple steps can be taken to address the problems.

Following this on 3 September 2018, the Internet Society signed a MoU with the ISP Association of India (ISPAI) in order to promote the MANRS principles and encourage member ISPs to sign-up as MANRS participants. The MoU was signed by Rajnesh Singh (ISOC Regional Bureau Director for the Asia-Pacific region) and Rajesh Chhariya (President ISPAI) and will give a great boost to improving the routing security situation in India.

AusNOG 2018

I also participated in AusNOG 2018, the Australian Network Operators’ Group, on 30-31 August 2018 in Sydney, Australia. A number of interesting announcements were made here, which will be the subject of a separate forthcoming blog.

Further Information

Categories
Mutually Agreed Norms for Routing Security (MANRS)

SANOG 32 – Another Success Story for MANRS

The SANOG 32 meeting was held on 2-10 August 2018 in Dhaka, Bangladesh, which marked fifteen amazing years of collaboration between network operators in the South Asia region. The Internet Society is proud to support the SANOG fellowship programme that provides opportunities for network engineers from countries in the region to attend, as well as organising the Network Security workshop during the event.

SANOG 32 also saw another MANRS milestone reached when the ISP Association of Bangladesh (ISPAB) signed a Memorandum of Understanding (MoU) with the Internet Society. ISPAB is a membership-based, not-for-profit organization that provides a forum for Bangladeshi ISPs to discuss technology, policy, regulatory and commercial issues and find collective solutions.

In accordance with the MoU, both ISPAB and ISOC will work together to promote and support MANRS, to encourage network operators in Bangladesh to join the initiative. There are currently only two MANRS participants in the country, so being able to increase engagement with the networking community is a welcome development.

Dr Philip Smith (NSRC and Chair of SANOG Programme Committee) also provided a MANRS update during the conference session.

The Network Security workshop attracted 40 participants and was lead by MANRS founding member Matsuzaki Yoshinobu (IIJ) and Champika Wijayatunga (ICANN), with local support provided by Moinur Rehman and Anirban Data. This featured a hands-on lab where participants learned about the four MANRS action – namely Prefix Filtering, Anti-Spoofing, Coordination and Global Validation. APNIC staff also demonstrated how to update Whois information through MyAPNIC, how to create route/route6 objects, as well as how to create Route of Origin Authorisations (ROAs) for the Internet number resources (IP addresses and AS numbers) under their management. These steps are important in achieving two of the MANRS actions – Coordination and Global Validation.

The South Asian Network Operators Group (SANOG) was started in 2003 to bring together engineers and industry experts from network operators for the purpose of knowledge sharing as well as co-operation among all the relevant stakeholders in the South Asian region which covers Afghanistan, Bangladesh, Bhutan, India, Maldives, Nepal, Pakistan and Sri-Lanka. The SANOG meeting incorporates workshops and tutorials in conjunction with the conference, and people from the community are invited to contribute as workshop instructors or share their experiences through tutorial or conference presentations. Many network operators in the region are in the nascent stage of development, such helps  valuable.

Special thanks to Sumon Ahmed Sabir (SANOG Founding member and Core Com)Gazi Zehadul Kabir (SANOG Chair), Rashed Amin (Vice President ISPAB), Md.Emdadul Hoque (Secretary General ISPAB) and Simon Sohel Baroi (SANOG PC Chair) for the great support.

Its great to see MANRS getting support in the Asia Pacific region. If you are running a network infrastructure then be part of the solution and help protect the core. Join MANRS.

Categories
Building Trust Events Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Open Internet Standards Securing Border Gateway Protocol (BGP) Technology

Routing Security BoF – APRICOT 2018

On Sunday, 25 February, the first day of APRICOT 2018, a “Routing Security BoF” (birds of a feather: An informal discussion group) was organized to address the ever-growing routing related incidents happening on daily basis. We have discussed routing security in general within the Asia Pacific region but there was a need to have a platform for open and candid discussion among the network operator community to find a possible way forward, where operators can share their approach in securing their own infrastructure and keeping the internet routing table clean as well.

A quick introduction was provided by the moderator (Aftab Siddiqui) on why it is important to have this BoF. Here are the introductory slides:

The first technical community presenter was Yoshinobu Matsuzaki (Maz) from Internet Initiative Japan (IIJ), the first ISP in Japan started in 1992. IIJ is one of the few ISPs in the region implementing prefix filtering, source address validation for their end customers, and making sure that all their routing information is reflecting the current status in the peeringdb for AS2497. IIJ was the first Asia Pacific ISP to join MANRS (Mutually Agreed Norms for Routing Security), a global initiative, supported by the Internet Society, to work with operators, enterprises, and policymakers to implement crucial fixes needed to eliminate the most common routing threats.

The rest of the BoF was based on a panel discussion, with panelists representing some of the top global CDNs (Content Delivery Networks) along with the technical lead of the MANRS initiative from the Internet Society.

The discussion started with the following questions:

Q1. You just heard from one of the largest ISP in the region (IIJ) and, being one of the biggest CDN providers globally, what measures do you take to ensure that you are keeping the internet routing table clean?

A1 (summary). CDNs mostly rely on the peering fabrics and they do put filters in place to safeguard their infrastructure and also don’t usually pollute the global routing table. They can’t control any peer network and hence cannot avoid any accidental/intentional prefix hijack. To safeguard against such incidents, all CDNs actively monitor the global routing table to quickly fix incidents and reduce the outage or impact.

Q2. There are ISPs that implement routing security and there those who don’t. Do you have the same peering policies for both? Do you enforce any policy to make sure that your peering partners are doing the right things?

A2 (summary). It is not possible for CDNs to create different peering policies on the basis of network reputation, but they do make sure that they have good visibility of the network in order to find the problem as early as possible. Also, it is hard for CDNs to de-peer in case of an incident because there are commercial interests in place as well. The counter argument from Andrei (ISOC) was: CDNs can’t apply different policies to networks/peers on the basis of reputation because it is realistically difficult to differentiate the bad from the majority of good peers. This is where MANRS can provide a platform to show if a network is accidentally/intentionally polluting the internet routing table.

Q3. Do you see any benefit of RPKI and BGPSEC to secure internet routing in the future?

A3 (summary). It was clear from the discussion that BGPSEC is too new to have any constructive discussion; there are many changes required in the protocol and even after that it is optional for a peer to use BGPSEC. However, RPKI can play some role in the future but at the moment no CDN is actively pursuing RPKI as a solution. The topic of RPKI resulted in some interesting debate between Geoff Huston and panelists.

At the end of the panel discussion we asked four questions through an interactive poll and the results were very interesting and encouraging.

Around 62 members of the community participated in this poll, which clearly shows that the vast majority of them consider routing security a problem we need to address. While some are not clear if there was an impact on internet services because of routing security incidents (lack of data), it was very clear that networks don’t follow guidelines to implement routing security because there is no incentive for them to do so. At the end the clear winner was MANRS, as most respondents believe that only a community-driven initiative such as MANRS can convince the network operators to implement routing security. (Here’s how to join MANRS.)

Categories
Deploy360 Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

BGPSec – A reality now

The Secure Inter Domain Routing (SIDR) initiative held its first BoF at IETF 64 back in November 2005, and was established as a Working Group in April 2006. Following the Youtube Hijack incident in 2008, the need to secure BGP became increasingly important and SIDR WG charter explains it well:
The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are:
  • Is an Autonomous System (AS) authorized to originate an IP prefix
  • Is the AS-Path represented in the route the same as the path through which the NLRI traveled.

This last vulnerability was the basis for defining an AS Path validation specification which has become known as BGPsec.

BGPsec attempts to assure a BGP peer that the content of a BGP update it has received, correctly represents the inter-AS propagation path of the update from the point of origination to the receiver of the route.

So far, 39 RFCs have originated from the SIDR WG, with three drafts currently under discussion. Seven RFCs were published last month (September 2017) providing a big boost to the securing routing work:

  • RFC 8205 (was draft-ietf-sidr-bgpsec-protocol) – BGPsec Protocol Specification
  • RFC 8206 (was draft-ietf-sidr-as-migration) – BGPsec Considerations for Autonomous System (AS) Migration
  • RFC 8207 (was draft-ietf-sidr-bgpsec-ops) – BGPsec Operational Considerations
  • RFC 8208 (was draft-ietf-sidr-bgpsec-algs) – BGPsec Algorithms, Key Formats, and Signature Formats
  • RFC 8209 (was draft-ietf-sidr-bgpsec-pki-profiles) – A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
  • RFC 8210 (was draft-ietf-sidr-rpki-rtr-rfc6810-bis) – The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
  • RFC 8211 (was draft-ietf-sidr-adverse-actions) – Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)

RFC 8205 is the BGPSec Protocol Specification that has been published as standard. BGPsec is an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message propagates. BGPsec is implemented via an optional non-transitive BGP path attribute called BGPsec_Path, that carries digital signatures produced by each autonomous system propagating the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route.

BGPsec is intended to be used to supplement BGP Origin Validation [RFC6483][RFC6811], and when used in conjunction with origin validation, it is possible to prevent a wide variety of route hijacking attacks against BGP. It relies on the Resource Public Key Infrastructure (RPKI) certificates that attest the allocation of AS number and IP address resources [RFC6480].

The Resource Public Key Infrastructure (RPKI) system is a way to improve routing security by associating an IP address range with an autonomous system number (ASN) through cryptographic signatures, as described in RFC 6480. RPKI leverages X.509 certificates [RFC 5280] with added extentions for IPv4 and IPv6 prefixes, and AS numbers defined in RFC 3779.

The RIRs [APNIC, ARIN, RIPE NCC, AFRINIC, LACNIC] issue these certificates to resource holders when a resources are requested. Certificates are typically renewed every year and each RIR uses a self-signed root certificate to sign the certificates they issue.

RPKI allows network operators to create cryptographically verifiable statements about the route announcements they authorise to be made with the Autonomous System (AS) numbers an IP address prefixes they hold. These statements are known as Route Origin Authorisations (ROAs), can also be used to determine the maximum length of the prefix that the AS is authorised to advertise.

A record for AS25 and AS42 collected through RIPE NCC RPKI Validator Tool shows the validity of prefixes announced.

In case of BGPSec, the mechanism requires the use of a new BGP attribute and negotiation of a new BGP capability between eBGP peers, so it means little will change over night. An incremental deployment is going to be the way forward, starting with adjacent AS’s offering to speak BGPsec with their eBGP peers.

In a perfect future Internet, interconnected ASes all speaking BGPsec will be able to provide assurance about the correctness of all routes originated and propagated amongst the same interconnected ASes. Therefore the benefits of secure BGP will mostly only be realised when there are fewer non-BGPSec speakers in the routing paths.

RPKI and origin validation is nearing a point of maturity in terms of understanding the need for it, but there is still a long and winding road ahead to ensure a decent level of RPKI deployments. The RIRs have already launched their RPKI services, and working code for implementing origin validation in BGP has been released by a few vendors (Cisco, Juniper, Quagga), but the Internet community has likely been waiting for the announcement of BGPSec specification.

Now that BGPSec is a reality though, there’s no longer any excuse for network operators to not be signing their resources, and thereby contributing towards a stable, secure and trusted Internet routing system.

Deploy360 also want to help you deploy Secure Routing, so please take a look at our Start Here page to learn more.

 

Categories
Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

Global routing – a kludge or a collaboration phenomenon?

Is it true that the percentage of Internet traffic currently secured by a new system of cryptographic network keys is zero? This was the conclusion of a recent article in The Washington Post.

While the article makes a fair assessment of the security vulnerabilities of the protocol that controls routing in the global Internet, as well as challenges in improving its security, it does not suggest any particular way forward. Although it is not easy, a path forward to a more robust and secure Internet exists, and I’d like to share with you what we think it might look like.

Before I go into it, let’s think of a more fundamental question: How are innovations deployed in the core infrastructure of the Internet? Innovation flourishes at the Internet’s edges—witness the explosion of applications just in the last decade—but how does innovation take hold in between networks, where they are glued together to form the global communication fabric that makes up the Internet?

Well, innovations are not adopted overnight. There is a term, coined out by a sociologist Everett Rogers back in 1962, “diffusion of innovations” that reflects the gradual nature of this process. The process can be faster or slower, and so is the steepness of the known S-curve. But what is at the core of this process is the “interpersonal communication with peers […] necessary to persuade most individuals to adopt a new idea” (Rogers, E. M., and Kincaid,D. L. (1981). Communication Networks:Toward a New Paradigm for Research. New York: Free Press.).

And if it is true for a washing machine or a refrigerator, or a VCR, it is even more true for technologies needed to secure global routing system. Knowing that one’s neighbors are happy with a novel appliance makes one more confident in making a similar purchase, but there is no real interdependency related to the utility of the device.

On the contrary, with the routing security technology one cannot get the benefits of its deployment by doing this alone – one’s network security depends on whether the rest deploys these measures, too. The more networks deploy, the more “return on investments” one gets.

So how can we stimulate this process?

We believe that global adoption of routing security measures can be most effectively “diffused” in local communities, like IXPs, small NOGs, etc., through collaboration, based on common understanding and commitment. One of the examples is the Mutually Agreed Norms for Routing Security (MANRS, aka Routing Resilience manifesto) that I recently wrote about in a blog post.

The foundation of MANRS is made from the existing building blocks and new ones that are being developed – there is an array of solid best practices on additional checks on routing information a network receives from its customers and peers (“filtering” as it is called in the article), based on various repositories, such as address allocation databases, Internet Routing Registries, or Resource Public Key Infrastructure (RPKI) developed by the IETF (see RFC6480). The IETF is also finalizing its security extensions to the BGP called BGPSEC (see draft-ietf-sidr-bgpsec-overview).

I called them “building blocks” and didn’t single any one of them as “the solution”, because there is no “silver bullet”. New unforeseen requirements emerge all the time, especially in the Internet fast pacing world. Any protocol, or technology, need to evolve, and this evolution needs to diffuse. We should also not forget that resiliency of the global routing system is in its collaborative nature that helps resolving routing incidents in reasonable timescales. And we need to improve further on the preventive front to eliminate such incidents altogether.

Open standards development and collaboration are the key ingredients to our common success in this area.

Categories
Building Trust Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Technology

MANRS + IXPs = A MORE Secure Internet Routing System

Internet Exchange Points (IXPs) are a critical community to adopt the MANRS (Mutually Agreed Norms on Routing Security) initiative to make the Internet’s routing infrastructure more secure.  I recently made this point when given an opportunity to present MANRS at the MORE-IP conference organized by one of the leading Internet Exchanges AMS-IX.

Why do I think the IXP community is an important audience?

While MANRS is a truly global collaborative effort, its success very much depends on the sense of ownership, peer pressure and common understanding. These properties are the strongest in relatively small communities united by common operational objectives. The IXP community fits this profile very well.

I was very glad to reconfirm to myself that the AMS-IX community takes security issues seriously. For example, there was a presentation from AMS-IX technical team about their proposed setup for outgoing prefix filtering on AMS-IX route servers. In other words instead of each ISP building their own filters on what routing updates to accept or not from each of their peers, the route server is going to do this for them. There is a possibility for a peer to choose between the traditional IRR or the RPKI repository as a source of information for building filters and select whether prefixes are filtered or only tagged. The more members adopt this setup the less vulnerable the global routing system will become. And given 715 networks peering at AMS-IX this will definitely have an impact.

Another presentation was about the Trusted Networks Initiative – a last resort solution hosted by the Hague Security Delta for DDoS attacks that are too big to handle. This initiative is supported by AMS-IX and is based on peering on a separate private VLAN by a set of “trusted” networks. “Trust” is based on adherence to norms that are similar to MANRS. Moreover, the members list has a separate column indicating their participation in MANRS, although I was a bit surprised to see this box checked only for one network.

I think regardless of the existence of “fire exits” it is important that we work on making the whole building fire-proof, to use an analogy. I see MANRS as a tool for local communities, like the AMS-IX association, to use to create a new, more secure and resilient norm for routing.

P.S. If you are with a network operator, have you signed the MANRS document? If not, why not do so today?


Image credit: Photo of Andrei Robachevsky speaking provided by the MORE-IP conference organizers.

Categories
Improving Technical Security

Initial Routing Resilience Survey Results Show At Least 10% Of Incidents Are Real Threats

Last year in November we launched, in partnership with BGPmon, a new project called Routing Resilience Survey. As I wrote in the blog post “New Internet Society Project Aims to Learn: Is Your Internet Routing Secure and Resilient?”, this effort is based on collecting incident data related to routing resilience from an operator’s point of view. This approach allows us not only to filter out false positives – for instance, legitimate configuration changes – but also to record the impact and the severity of the incident.

Since the beginning of the project four months ago, 25 participants representing more than 300 ASNs joined the effort – providers often take care of their customers’ routing problems and wanted to include those problems in the survey. In total we asked folks to classify almost 500 events, and more than half of them have indeed been classified! And while we hope to collect more data to get a more statistically representative picture of these incidents and their impacts, there is already something to look at.

So I couldn’t resist the temptation to show you some graphs from this presentation of initial results (full presentation embedded below and available on SlideShare).


Routing Resilience: Impact Severity

First of all, let’s look at the number of registered incidents and their impact [slide 9]. Do not be surprised that the timeline starts back in 2011 – for each participant we presented a “historical” overview of significant events, and asked them to classify each. Green is the most prominent color – these are “false positives,” configuration changes, like connecting a new customer. But even with our relatively small set of surveyed networks, one can notice moderate and severe incidents.

If we look at the impact from a slightly different angle [slide 10], we see that “false positives” constitute at least half of all events. Real incidents sum up to 10% of all events. This number may be higher, depending on what is in the “unknown” category – events that have not been classified yet.

Finally, it is interesting to look at how folks became aware of the incidents [slide 11] – a question we asked when classifying an event. “Customer call” is a dominating answer, which indicates that reactive measures prevail over proactive ones.

It is still not too late to join this effort – your contribution will help us better assess the state of security and resilience of the routing system from a risk perspective. In return, you may become more aware yourself how risky the environment is, and after the project is completed, get an individual report where you can see how your risk profile compares to others.

Please send a request for the creation of your account to rrs-admin@isoc.org.

In the request please indicate:

  • your AS number
  • email address for notifications

You may also include AS numbers of your customers for whom you would like to monitor and classify related security incidents.

Hope to see you soon!

Categories
Improving Technical Security

Resilience of the Commons: Addressing Routing Security Challenges

Why do some innovations take off like wildfire, while others take ages to reach widespread deployment? What makes for a successful protocol? How can we detect a protocol failure ahead of time and correct course? Recently I attended an Internet Architecture Board-hosted workshop on Internet Technology Adoption and Transition (ITAT) that aimed to address these questions.

The workshop stimulated interesting discussions, helping us better understand the enablers of and inhibitors to technology adoption and, since it focused on IETF protocols, what makes for a successful protocol.

The IAB has discussed this before. In fact, in 2008 the IAB published RFC 5218, entitled “What Makes for a Successful Protocol?” Without providing a recipe for a successful protocol or technology, it looked at various factors that “contribute to or hinder a protocol’s success.” It found that for a protocol to be successful, it should:

  • Meet a real need
  • Have open code and specification availability
  • Have open maintenance processes
  • Have good technical design (though for initial success it seems to have minimal impact compared with other factors)

The IAB also found that a successful protocol can be deployed incrementally, meaning that early adopters gain some benefit even if others do not support the protocol. Indeed, ability to use and benefit from a technology independently of other actors makes the deployment strategy clearer and simpler.

But what happens when a protocol’s benefits begin to unfold only when their penetration is substantial, like IPv6 or DNSSEC? Early adopters incur costs and gain little until the number of users reaches a tipping point. It doesn’t make sense to join a social network if only a couple of strangers are on it, or deploy DNSSEC if only a few others have adopted it. Protocols and solutions for securing the global routing system are among this group of collective action problems, too.

Everett M. Rogers, a prolific scholar of communication and social change, once noted, “diffusion is essentially a social process. While the mass media often create awareness-knowledge of an innovation, interpersonal communication with peers is necessary to persuade most individuals to adopt a new idea.”

At the ITAT workshop we presented an approach to tackle these issues based on our work with network operators. Similar to Rogers, our approach is based on the understanding that technology building blocks and solutions are an important aspect, but people are what ultimately hold the Internet together. In our new paper, “Resilience of the Commons: Routing Security,” we argue that to achieve a positive outcome, we must:

  • Build consensus around an understanding of the problem space
  • Share an understanding of the potential offered by different solutions
  • Create a culture of collective responsibility based on an understanding of collective and individual benefits
  • Focus on a positive end goal

We also see improving routing security and resilience as a social process. That is why our efforts in the area of routing security are focused on the people that run the networks and make the global infrastructure resilient. One recent example of such an effort is the Routing Resilience Survey aimed at involving operators in collecting factual data about routing incidents and their impacts. (You can still join the project!)

Security of the global routing infrastructure is to some extent no one’s concern and everyone’s concern at the same time. How can we stimulate improvements in this area – an area where traditional market forces, the main drivers of the Internet’s development, do not work, where regulation may not be effective, where one’s actions may benefit competitors more than one’s own customers?

Technology building blocks and solutions are an important aspect, but Internet development has been based on the voluntary cooperation and collaboration of the peopleinvolved. We believe that is still one of the essential factors of the Internet’s prosperity.

Security and Resilience: Can We Make a Difference?

Probably everyone would agree that security and resilience of the global routing system is an essential element of a well-functioning Internet.

Vulnerabilities of the system are well known and have manifested themselves many times – be it a prefix hijack, like the YouTube incident, or China’s deflection of the Internet traffic for significant amount of networks.

Threats are also real and present, take for instance possibilities of hijacking and impersonating DNS infrastructure, like the case this year with Spamhaus, or so-called route leaks that happen frequently, according to a presentation by Jared Mauch at NANOG41, and potentially allow MITM attacks for a wide variety of traffic paths. The impact can be significant and, since such incidents affect the foundation of the Internet, may have cascading effects.

Not that operators are not aware or do not care – on the contrary, many network operators take routing security very seriously. And there are ways to make the system more secure and resilient – from good old best practices to new technologies like RPKI. And still, there is much room for improvement.

The tricky thing here is that often good netizenship doesn't have an immediate business case, although many would probably agree that it benefits an organization in the long run. The issue of so-called externality, which disconnects costs from benefits, is one of the stumbling blocks for wide deployment of routing security solutions.

And this is also true for other aspects of the Internet security and resilience:

  • No one organization can resolve this issue by itself; the level of security and resilience of other players matters.
  • Not only the protection of organization's own assets and infrastructure, but management of risks that an organization (by its action or inaction) itself presents to the Internet ecosystem becomes equally important.
  • Proper mitigation of many of these risks requires collective action.

In the paper "Understanding Security and Resilience of the Internet” that we published recently we claim that collaboration is an essential component of effective security. "Ultimately, it is people that hold the Internet together. The Internet’s development has been based on voluntary cooperation and collaboration and we believe that is still one of the essential factors for its prosperity and potential."

Throughout the Internet history, collaboration among participants and shared responsibility for its smooth operation has been one of the pillars for its tremendous growth and success, as well as for its security and resilience. Technology alone is not enough, and fostering this shared responsibility seems to be as important.

So what if industry leaders come together and state their commitment to routing security and resilience of the Internet as a whole by taking certain actions, implementing specific best practices, etc.? What if we capture this collaborative spirit of the Internet in a document that can provide guidance to network operators in addressing issues of security and resilience of the global Internet routing system as well as document commitment of the industry leaders to this practice? And if we start small, can we grow this list of signed up networks and create a critical mass?

Can we collectively make a difference?

P.S. Stay tuned for a future post with some specific suggestions we have for action…

Categories
Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

Observations from the Routing Resiliency Measurements Workshop

On many occasions when I talk to network operators about routing security a question of risk comes up.

Quite a few well-known and analyzed incidents, like the YouTube prefix hijack or the China Telecom traffic detour, clearly demonstrate vulnerabilities in the routing system that can be exploited and that present a real threat. But while everyone agrees there are vulnerabilities, the real questions are (1) What are the frequency and probability of security incidents, and (2) What are their operational and economic ramifications?

Not answering these questions means ignoring or accepting the risks by default – and that is the dominant trend among ISPs. Having no answers is also an indication of low operator awareness and, subsequently, lack of motivation to do something about it.

A better grasp of what’s happening in Internet routing would inform operators’ decisions regarding proactive and reactive measures they can deploy to mitigate risk.

To address this issue, the Internet Society organized a routing resiliency measurements workshop on 2-3 November 2012, inviting researchers and operators to share their experience and data and try to find answers to several important questions:

  1. What level of attack has there been in the past – to what extent do security incidents happen, but go unnoticed, or get dealt with inside a single network, possibly introducing collateral damage?
  2. Are the number and impact of service disruptions and malicious activity stable, increasing, or decreasing?
  3. Can we understand why, and track it collectively?

The workshop was divided into three main sections:

  • Measurement methodology and frameworks: We looked at different methodologies, their limitations, and available data sets used for the analysis of suspicious events related to inter-domain routing in the Internet.
  • Research analysis and operational data: Participants presented and discussed analysis of data related to routing resilience coming from both researchers and operational experience.
  • Metrics and long-term monitoring: This discussion focused on which metrics could be a useful representation of routing resiliency in the Internet, both to inform operators’ actions and facilitate a long-term monitoring and trend analysis.

We just published a report on the workshop that documents main points of discussions, main conclusions, and forward-looking suggestions.

One of the conclusions was that not knowing the operator’s real routing policy makes it difficult to separate legitimate changes from attacks. Several approaches presented at the workshop allow the number of false positives to be minimized, but do not provide an answer to how much goes under the radar.

We also observed that many operators do not specifically track routing security incidents, making it difficult to collect sensible operational statistics. This is a missing piece that could facilitate risk assessment and measure the effectiveness of mitigation techniques.

Lack of well-defined and actionable metrics and common vocabulary are two of the main limitations for consistent long-term monitoring and trend analysis. It is difficult to say how the system evolves, or whether it is getting better or worse.

Did the workshop have answers to all of these difficult issues? Well, no, but it provided a good starting point for moving forward based on a common understanding of the challenge.