Building Trust Improving Technical Security Strengthening the Internet

NDSS 2020: The Best in Security Research – For the Good of the Internet

On 23 February, the 27th consecutive Network and Distributed System Security Symposium (NDSS) kicks off in San Diego, CA. NDSS is a premier academic research conference addressing a wide range of topics on network and system security. It’s an incubator for new, innovative ideas and research on the security and privacy of the Internet.

NDSS 2020 (23-26 February) will be one of the biggest NDSS symposium yet, featuring 88 peer-reviewed academic papers, 34 posters, 5 workshops, and 2 keynotes on vital and timely topics. Here are some of the highlights.


This year’s program officially starts with five workshops on Sunday, 23 February. NDSS workshops are organized around a single topic and provide an opportunity for greater dialogue between researchers and practitioners in the area.

The QUIC Privacy and Security (QUIPS) Workshop focuses on QUIC security and privacy analysis efforts. The IETF QUIC protocol is a modern UDP-based, stream-multiplexing, encrypted transport protocol. Inspired by prior art, QUIC’s packet and header encryption removes cleartext information from the network while simultaneously mitigating ossification of version-specific protocol behavior. The goal of the QUIPS workshop is to bring formal analysis results to the IETF working group and developer communities in order to build confidence in and improve QUIC before its widespread deployment.

The Workshop on Measurements, Attacks and Defenses for the Web (MADWeb) returns this year after making its debut in 2019. The web connects billions of devices, running numerous types of clients, and serves billions of users every day. To cope with such a widespread adoption, the web constantly changes. This is evident by some browsers that have a release cycle of just six weeks. These rapid changes are not always studied from a security perspective, resulting in new attack vectors that were never observed before. MADWeb is looking to connect researchers working at the intersection of browser evolution and web security. The goal is to bring together a community to discuss the rapid changes to browsers from a security perspective, the security implications of current web technologies, and how we can make browsers in the future more secure without hindering the evolution of the web.

The Learning from Authoritative Security Experiment Results (LASER) Workshop focuses on learning from and improving cybersecurity experimental results. The workshop strives to provide a highly interactive, collegial environment for discussing and learning from experimental methodologies, execution, and results. Ultimately, the workshop seeks to foster a dramatic change in the experimental paradigm for cybersecurity research, improving the overall quality and reporting of practiced science. As such, it will be structured as a true “workshop” in the sense that it will focus on discussions and interactions around the topic of experimental methodologies, execution, and results with the goal of encouraging improvements in experimental science in cybersecurity research. Authors will lead the group in a discussion of the experimental aspects of their respective efforts.

The Binary Analysis Research (BAR) Workshop returns for its third year at NDSS. Binary analysis refers to the process where humans and automated systems examine underlying code in software to discover, exploit, and defend against vulnerabilities. With the enormous and ever-increasing amount of software in the world today, formalized and automated methods of analysis are vital to improving security. This workshop will emphasize the importance of releasing and sharing artifacts that can be used to reproduce results in papers and can be used as a basis for further research and development.

The Workshop on Decentralized IoT Systems and Security (DISS) is also in its third year. The seemingly endless potential of the Internet of Things (IoT) is somewhat tempered by the ongoing concern over the ever-increasing risk that these devices pose to the Internet. The ultimate success of IoT depends on solving the underlying security and privacy challenges. Following the spirit of NDSS, the goal of this workshop is to bring together researchers and practitioners to analyze and discuss decentralized security in the IoT.


There will be two keynotes this year: Paul Forney, Chief Security Architect at Schneider Electric, on Monday, and Dr. Sharon Goldberg, Associate Professor in the Computer Science Department at Boston University and CEO/Co-Founder of Arwen, on Tuesday.

Paul Forney will discuss “Overcoming the ‘Evil Twins’ Attack: Lessons Learned from the Industrial Battlefield.” He asks the important question: “What could happen during a simultaneous attack of the industrial safety controllers (SIS) and Industrial Control Systems (ICS) of a critical infrastructure system?” Paul will discuss the technical lessons that can be learned from this sort of attack and how to best architect, protect, and contextualize a better future.

Dr. Sharon Goldberg will present “A Few Adventures in Technology Transfer.” This talk will discuss her adventures in technology transfer and in particular address two key metrics – ease of integration and precise specification.

NDSS 2020 Papers

The star and indeed the core of NDSS 2020 is the final set of peer-reviewed academic papers to be presented and published. This year there are 88 peer-reviewed papers organized into 19 sessions, representing less than 20% of the original submissions. This year there were over 500 submissions during both a summer and a fall submission period. A program committee of 97 experts assisted by 133 external reviewers worked to select and shepherd the accepted papers to this result. Topics cover a wide range including authentication, cryptography, censorship, network security, privacy, IoT, and mobile and web security. Papers, slides, and videos of all the talks will eventually be available on the NDSS 2020 programme page. The detailed agenda is already there!

Finally, NDSS 2020 also includes an energetic Poster Session and Reception featuring 34 posters of recently published or newly-emerging research. Attendees can vote for their favorites with special prizes being awarded in different categories.

All of this fabulous content takes a huge effort by a large group of people. Special note should be given to the Program Committee along with the Organizing Committee. This is teamwork and collaboration in action!

NDSS is where the next generation of security research starts, and for more than 20 years, the Internet Society has been a proud partner in hosting this event. Nearly 450 security experts will gather this coming week in San Diego to collaborate and engage in research discussion to help advance network and system security – all for the benefit of better security and a strong Internet.

Follow along via our social media channels – Twitter, Facebook, and LinkedIn, or search/post using #NDSS20.

See you in San Diego!

Improving Technical Security Internet Exchange Points (IXPs) Mutually Agreed Norms for Routing Security (MANRS)

Securing the Internet: Introducing Oracle Internet Intelligence IXP Filter Check

Oracle is an Organization Member of the Internet Society. We welcome this guest post announcing a new tool that complements our work to improve the security of the Internet’s routing infrastructure.

We are proud to announce the launch of the IXP Filter Check, which is designed to improve Internet routing security by monitoring route filtering at Internet Exchange Points (IXPs). Here we describe the origin of this project, how it works, and what it hopes to achieve.


Last year, Oracle started partnering with the Internet Society to explore ways to make the Internet safer and more secure for our enterprise customers and users. Businesses – banks, insurance companies, pharmaceutical firms – as well as non-profit organizations and governments continue to turn to Internet-facing assets as key components of their critical infrastructure. Market research firm IDC estimates that 55.9 billion devices will be online by 2025. We believe it is incumbent upon us, as trusted partners and suppliers, to help make the global Internet as safe as possible.

Securing trust-based Internet routing is one such security challenge. Despite decades of research and engineering on the topic, securing Internet routing remains a notoriously difficult task. The challenge is evidenced by the fact that nearly every month there is another major story of a disruptive BGP routing incident.

Routing mistakes will inevitably occur as long as people configure routers. Our best hope at containing these incidents is deploying layers of route filtering at key junctions of the Internet. Those junctions fall into two categories: network operators and IXPs.

With respect to network operators, large telecoms have begun announcing their plans to implement the Resource Public Key Infrastructure (RPKI), which is very encouraging. As for IXPs, there is an active movement within the IXP community to filter routes exchanged at route servers based on RPKI and other best practices. With its announcement of its IXP program last year, the MANRS Initiative broadened the scope of its secure routing initiative beyond network operators.

Filtering at Route Servers

Implementing route filtering at IXPs offers the opportunity to make real progress in the improvement of Internet routing hygiene. IXPs serve a vital role in the infrastructure of the Internet by facilitating thousands of connections between the networks of telecoms, content providers, and other major businesses.

However, the implementation of route filtering can be complicated and to date there has been no way to independently and programmatically verify whether an IXP was appropriately filtering its routes. Using data graciously published by Packet Clearinghouse (PCH) and data processing supported by Oracle Cloud Infrastructure, the Oracle Internet Intelligence team developed IXP Filter Check to analyze route filtering at nearly 200 IXPs around the world.

By monitoring the routes passed by route servers at these IXPs, and identifying those routes that should have been filtered, IXP Filter Check identifies gaps in route filtering and aims to assist in technical compliance of MANRS IXP requirements.

In the course its development, IXP Filter Check has identified major filtering misconfigurations at three IXPs including a month-long RPKI filter outage at one of the world’s largest IXPs. By detecting these problems, IXP Filter Check enabled cooperating route server administrators to fix their route filtering and also validated the need for third party technical review of route server filtering.

What is IXP Filter Check?

Essentially, IXP Filter Check is a table of metrics observed in BGP messages collected by PCH at various IXPs in the previous day. The table (see below) reports the unique number of prefix/origin pairs, messages that were RPKI invalid, or those lacking a route object (IRR registration) at the time of collection, as well as prefixes and ASNs that are either bogons or on Spamhaus droplists.

Note that acting on Spamhaus droplists is not a MANRS IXP requirement, but after last year’s experience of removing Bitcanal from IXPs, we felt it was important to include reports of questionable routing to the IXPs.

One can click on an IXP to see the individual prefixes being reported as potentially problematic. In that view, one can expand each prefix to reveal recent raw BGP messages which include timestamp and BGP community information as depicted below:

Finally, one can click on either the RPKI or IRR assessment (“INVALID_ASN” or “VALID” in the example above) to be taken to an external source to verify the claim.


The IXP program is an important component of the MANRS initiative that strives to prevent Internet disruptions caused by adverse routing incidents. It is no longer an unthinkable goal for all Tier 1 carriers and major IXPs to drop invalid RPKI messages.

Moreover, if your organization hasn’t created Route Origin Authorizations (ROAs) for its routes, please consider doing so. This will help enable RPKI filtering to prevent routes from being affected during a routing mishap. Find your regional RIR (listed below) and follow their instructions for creating ROAs.

Oracle is committed to helping make the Internet safer and more secure for enterprises and global users and we are proud to contribute this tool to assist IXPs in improving routing security. We thank PCH and the Internet Society for being strong partners in these efforts.

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

Network Operators in Latin America and the Caribbean Take Steps to Strengthen Routing Security

2019 has been a very good year for the Internet in Latin America and the Caribbean. In May, during the 31st meeting of LACNIC, several operators pledged to take steps to make routing security, and the Internet itself, stronger. They joined the MANRS initiative, which includes four simple and concrete steps to improve the Internet’s security and reliability. In August, NIC Mexico convened the second meeting of network operators in the country, during which routing security stood out as one of the main issues on the agenda.

The Internet Society also made progress on collaboration with National Research and Education Networks (NRENs) and higher education institutions. During the TICAL 2019 meeting, we offered a workshop on MANRS in collaboration with RedClara, LACNIC, the University of Guadalajara, ANUIES, and the Autonomous University of Yucatán. This workshop was part of a series of virtual sessions started in April, which ended on October 2 during the ANUIES-TIC meeting with a long-term practical workshop.

As we head to the final stretch of the year, the 32nd meeting of LACNIC will be a new opportunity to work with network operators to improve the security of the Internet. From Panama we will advise anyone interested in implementing the four actions of MANRS and offer advice to make the most of the recently launched MANRS Observatory.

As neighbors in this worldwide network called the Internet, we must work together to make it as strong and resilient as we can.

Building Trust Encryption Improving Technical Security Internet of Things (IoT) Mutually Agreed Norms for Routing Security (MANRS) Privacy Security

Celebrating National Cybersecurity Awareness Month

Every October, we mark National Cybersecurity Awareness Month. From the U.S. Department of Homeland Security website, “Held every October, National Cybersecurity Awareness Month (NCSAM) is a collaborative effort between government and industry to raise awareness about the importance of cybersecurity and to ensure that all Americans have the resources they need to be safer and more secure online.”

We believe in an Internet that is open, globally connected, secure, and trustworthy. Our work includes improving the security posture of producers of Internet of Things (IoT) devices, ensuring encryption is available for everyone and is deployed as the default, working on time security, routing security through the MANRS initiative, and fostering collaborative security.

The Online Trust Alliance’s IoT Trust Framework identifies the core requirements manufacturers, service providers, distributors/purchasers, and policymakers need to understand, assess, and embrace for effective security and privacy as part of the Internet of Things. Also check out our Get IoT Smart pages for get more consumer-friendly advice on IoT devices.

Much of OTA’s work culminates in the Online Trust Audit & Honor Roll, which recognizes excellence in online consumer protection, data security, and responsible privacy practices. Since that report’s release in April 2019, we’ve done a couple of “deep dives” into specific sectors, including Healthcare and Banks, with more sectors on the way. We’ve also done a deep dive specifically into privacy statements, finding that most organizations do not comply with existing global privacy regulations and are not ready for additional regulations going into effect in 2020.

In addition, our Cyber Incident & Breach Trends Report analyzes events to extract key learnings and provide guidance to help organizations of all sizes raise the bar on trust through enhanced data protection and increased defense against evolving threats.

Check out our Best Practices to learn more, and make October the month you work to improve your organization’s overall cybersecurity stance!

Improving Technical Security

The Role of South Asia’s NOGs in Community Building

At the recently concluded 34th South Asia Network Operators Group (SANOG 34), it was interesting not only to hear about the evolution of digital infrastructure, technology, and the economy in South Asia, including the opportunities it presents to network operators, but also to hear how community-led national Network Operating Groups (NOGs) in South Asia are working to build technical community knowledge, capacity, and engagement in their respective economies.

SANOG, which was set up as a sub-regional, community-led initiative in 2003, has played a significant role in bringing operators from the region together for knowledge sharing and cooperation. It is a biannual event, rotated among economies for maximum reach and participation.

While the NOGs of developed economies in the Asia Pacific began forming in the late 1990s, the NOGs in South Asia are quite recent: Bangladesh (bdNOG) and Bhutan (btNOG) were set up in 2014; Nepal (npNOG) in 2016; Sri Lanka (LKNOG) in 2017; and India (INNOG) in 2017.

The objectives of these NOGs are to encourage knowledge sharing within their respective economies and discuss global and regional technical developments, while addressing local requirements and issues. This, in turn, helps members of the operator community acquire the necessary skills to equip them for the present and the future. NOG meetings also provide a common ground for networking among participants, which helps in the exchange of ideas and thoughts. While most of the NOGs in South Asia have an annual event, it is only bdNOG that is held twice a year. The NOG meetings are normally rotated across cities in order to cater to more people.

While most NOGs organize both workshops and conferences during their events, depending on the requirement of the region and availability of trainers, the number of conference and workshop days at a NOG meeting vary: bdNOG has a half-day conference and four days of workshops; INNOG has a one-day conference and three days of workshops; npNOG has a half-day conference and three days of workshops; and LKNOG has a one-day conference and a one-day workshop.

Topics for discussion and training are normally decided based on global and regional trends, keeping domestic requirements in mind. IPv6, IXPs, MPLS, DNS, routing security, network monitoring and management, and SDN are some of the workshop topics you can expect to find at a NOG meeting in South Asia.

Most NOG meetings are paid entry events, with an average of around 150 participants attending.

We can look to the larger and more established NOGs in the Asia Pacific region for inspiration for what we want our South Asian NOG meetings to become. Holding hackathons and expanding the topics of discussion to more cutting-edge topics like next-generation data centre architecture and segment routing are just two ideas. Some very large NOGs are even able to run meetings without registration fees, attracting large numbers of attendees.

To encourage participation, NOGs such as LKNOG, btNOG, and bdNOG have provided fellowships. As women and youth are still less represented in such meetings, diversity initiatives have been taken by NOGs in the sub-region, including providing fellowships for women and young students in btNOG, organizing a networking panel for women, to promote women in tech at LKNOG, and so on.

While most of the NOGs aspire to increase their participation further and provide fellowships to deserving candidates, they face issues such as the uncertainty or inadequacy of sponsorships and unavailability of trainers (especially local). NOGs in South Asia can be particularly hindered by these issues.

Despite the odds, however, the NOGs are finding innovative ways to encourage more participation and help build a community of  trained and knowledgeable network operators, who are connected and can support one another when required.

This article reprinted with permission by the Asia Pacific Network Information Centre (APNIC), the Regional Internet Registry for the Asia-Pacific region.

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

Network Operators in Mexico Strengthen Their Collaboration

Collaboration is a basic element for Internet development. Without it, connections among networks would be non-existent and the Internet wouldn’t have its global reach. Without it, the Internet wouldn’t exist as we know it. Fortunately, there are many groups that use collaboration and other elements of the Internet networking model.

On August 14, NIC Mexico convened the second meeting of network operators in the country. After a first successful meeting held in 2018, this year’s event exceeded the expectations of the organizers. Edmundo Cázarez, Internet Resource Manager at NIC Mexico, said the organization placed greater emphasis on promoting the meeting among network operators, which led to increased participation.

MEXNOG, as the group of operators is also known, has capitalized on the enthusiasm of the participants through their meetings, but also through a mailing list. In the style of other Internet development groups, the mailing list has served as a meeting point and as a space for exchanging information and best practices among participants.

Therefore, the next step for the group is to strengthen participation in this space, as Edmundo points out: “We want the mailing list to be the contact point of the group. It has been used to consult topics of different kinds, but we hope it will increase participation. Currently, communication among network operators already exists in other ways, but the ideal is to be taken to the list.”

This year’s meeting program was formed taking into account the suggestions of the local community. The topics had a strong emphasis on strengthening routing security. From the Internet Society, Christian O’Flaherty, Senior Development Manager for Latin America and the Caribbean, contributed with a presentation about the MANRS Observatory, which had been presented globally the day before the meeting.

At the close of the event, Ernesto Bojórquez, Commercial Director of NIC Mexico and Chairperson of the LACTLD Board of Directors, highlighted the role that network operators play in the development of the Internet. In addition, he invited attendees to point out in their agendas that the group’s third meeting is already dated: August 14, 2020.

Join MANRS and help strengthen Internet routing security!

Improving Technical Security

Second Meeting of the Indian Network Operators’ Group Concludes Successfully

The Indian Network Operators’ Group (INNOG) organized their second meeting ( INNOG 2) in New Delhi on 1-4 July. The event, comprised of a conference and three workshops, was attended by more than 170 local and international participants. The event was supported by ISPAI, APNIC, NIXI, Internet Society, Tata Communications, Telestra, Spectra, Amazon Web Service, Software Technology Parks of India, and COAI. The Internet Society India Delhi Chapter also supported the event.

The conference held on 1 July was inaugurated by Arnold Nipper of DE-CiX, David Huberman of ICANN, Rajesh Chharia of ISPAI, Ramesh Chandra of Reliance JIO, Shailesh Gupta of Tata Communications, and Srinivas Chendi and Anurag Bhatia of Hurricane Electric. The conference sessions covered a variety of topics including root service, routing security, FreeBSD, leveraging IPv6 for explosive growth, and the ecosystem of IXPs. David Huberman of ICANN shared latest updates on DNS and highlighted the Open Forum in which participants can network and exchange ideas.

Subsequently, from 2-4 July, three workshops were held to address the ongoing challenges faced by Indian Internet services providers. The three workshops were on IPv6 deployment, IXP deployment, and the multiprotocol label switching (MPLS) routing technique.

The workshop on IPv6 deployment had 40 participants involved in Internet technology standards, local and national network infrastructure deployment, and network operations attending the lectures and hands-on lab modules that provided step-by-step guides.

The workshop on IXP deployment was also comprised of lectures and hands-on lab work to build the OSPF/ISIS and BGP skills required for network operators to participate at an IXP.

The workshop on MPLS included participants involved in building or operating a wide-area TCP/IP-based Internet service provider or metro service provider. The workshop covered the basic functionalities and features of MPLS, using MPLS to create virtual private networks, traffic engineering, building a large enterprise network over MPLS cloud, MPLS security and troubleshooting MPLS

About INNOG: INNOG provides service and content providers with a venue to share and learn from each other, thereby fostering greater collaborations at the working level. INNOG is not-for-profit and organization-neutral. It is loosely structured and is run by volunteers. If you would like to contribute by speaking or organizing future INNOG meetings, reach out.R

Join the thousands of Internet Society members working to build an Internet for everyone, everywhere!

Image courtesy of APNIC.

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

MANRS Observatory: Monitoring the State of Internet Routing Security

Routing security is vital to the future and stability of the Internet, but it’s under constant threat. Which is why we’ve launched a free online tool so that network operators can see how they’re doing, and what they can improve, while anyone can see the health of the Internet at a glance. The MANRS Observatory measures networks’ adherence to MANRS – their “MANRS readiness” – a key indicator of the state of routing security and resiliency of the Internet.

Here’s what the MANRS Observatory is in a nutshell:

  • Performance Barometer: MANRS participants can easily monitor how well they adhere to the requirements of this initiative and make any necessary adjustments to their security controls.
  • Business Development: Participants can see how they and their peers are performing. They can leverage the MANRS Observatory to determine whether potential partners’ security practices are up to par.
  • Government: Policymakers can better understand the state of routing security and resilience and help improve it by calling for MANRS best practices.
  • Social Responsibility: MANRS implementation is simple, voluntary, and non-disruptive. The Observatory can help participants ensure they and their peers are keeping their networks secure, which helps improve routing security of the Internet as a whole.

The Observatory has two views: public, open to everyone, and private, available to MANRS participants. The public view user can look at the routing security metrics and statistics on a global, regional, and economic level, while MANRS participants can see performance of individual networks (of more than 64,000!) and even drill down to a detailed monthly incident report for the networks they operate.

  • The public view is aimed at anyone interested in routing security. Users can see the status at a glance for every country on an interactive global map and drill down into data for a chosen country.
  • The private view is intended for network operators. It lets them measure their MANRS readiness and quickly identify problematic areas to help them improve the security of their networks. It also adds an element of accountability where networks can see how well others are keeping their side of the street clean, which helps improve routing security of the Internet as a whole.

The metrics and statistics to measure MANRS readiness are calculated by tracking the number of incidents and networks involved, their anti-spoofing capabilities, and completeness of routing information in public repositories, such as IRRs and RPKI. This data is gathered from trusted third-party sources. (For more information on how MANRS readiness is measured, read “Measurement Framework.”) The Observatory was developed jointly with the MANRS community but still has to pass the test of real-life usage and validation by MANRS participants.

One of the main objectives of the Observatory was to report on cases of MANRS non-compliance, and it provides reliable information on that. But measuring network security from the outside is difficult, and even with highly-reputed data sources there are sometimes false positives or false negatives (an incident that went unnoticed by the data collection systems). To put it into context, in 2018 alone, there were more than 12,000 routing outages or attacks, such as hijacking, leaks, and spoofing. We’re working with our partners to continuously improve the quality of incident data.

While MANRS is seeing steady adoption – worldwide, there are now over 200 network operators and more than 30 IXPs supporting our initiative – we need more networks to implement the actions and more customers to demand routing security best practices. The more organizations applying MANRS actions, the fewer security and related incidents happening, the more secure and resilient the Internet!

Explore the MANRS Observatory.

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

The Internet Is Your Oyster: MANRS at International Telecoms Week

What do oysters, clams, and mussels have in common with network operators? Hint: it’s not just that they are both in Atlanta this week, either in exhibits in the Georgia Aquarium or for the 2019 International Telecoms Week.

It’s that both bivalves and network operators play an incredibly important role for their ecosystems: they filter the bad stuff out and leave things a lot cleaner.

As water quality is vital to life in the ocean, the global routing system is vital to the smooth functioning of the Internet. The routing system’s decentralized structure, made up of thousands of independent networks tied together through business decisions and trusted relationships, provides flexibility, scalability, and overall durability.

However, despite its strengths, thousands of routing incidents occur every year. Some of these can be pretty scary, with route hijacks sending government traffic through the networks of foreign adversaries; route leaks slowing parts of the global Internet to a crawl; or hackers using spoofed traffic to take down websites in distributed denial of service (DDoS) attacks.

Network operators can help mitigate these problems by using stronger filtering policies to block spoofed traffic coming from their networks (helping guard against DDoS attacks) and filter route announcements from neighboring networks to separate the real announcements from the bogus (helping guard against routing incidents). They can help filter out the pollutants of the routing system.

Yet, both network operators and bivalves suffer from serious image problems.

Sure we all know mussels as the things that look like shells and taste great when cooked with butter and white wine, but did we know they are also one of our best allies in cleaning the oceans? And who knew that network operators do so much to ensure the smooth function of the Internet?

Bivalves are incentivized to clean the ocean as a part of getting food – so they will always do it. Network operators, as businesses, also need incentives to do the right things on routing security. Unfortunately, while the solutions to routing security are known, a lack of incentives, particularly the difficulty of credibly signaling one’s routing security to customers or peers, holds back their implementation.

The Mutually Agree Norms for Routing Security (MANRS) is trying to change that.

As a visible, measurable, and actionable set of principles, network operators who join MANRS can show their customers, peers, and governments that they are doing their part to improve routing security online. And, with the forthcoming MANRS Observatory and Dashboard, people everywhere will be able to see the quantitative difference that MANRS members have vs. non-members in implementing routing security best practices.

These days, people tend to like the humble oyster or mussel. Sure they look like rocks and live in the mud, but they play an important part in making their ecosystem safer for everything else in it.

Network operators have an opportunity to demonstrate their leadership in improving the security of the global routing system.

Come see our booth this week at ITW to learn more about MANRS and how joining could help your business.

Join MANRS and take simple, concrete steps to improve Internet security and reliability!

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

Improving Routing Security: Microsoft Joins MANRS

In November, a routing incident in Nigeria caused Internet traffic to be rerouted through Russia and China. It lasted for just over an hour, but during that time, it significantly affected some cloud and search services globally, including Spotify and Google’s Search. It was one of more than 10,000 incidents, such as route hijacking and leaks, that occurred in 2018. Past events have led to large-scale Denial of Service attacks, stolen data, and financial losses.

The global routing system is the backbone of the Internet. It determines how everything – from email messages to videoconferences to website content – moves from network to network. The November event, caused by a configuration mistake with a small ISP in Nigeria, shows that routing incidents can have significant global effects – impacting the security of the Internet itself.

A number of network operators around the world – including Oracle, GÉANT, and Comcast – have joined MANRS to address these types of routing threats. The Mutually Agreed Norms for Routing Security (MANRS) initiative, supported by the Internet Society, does this through technical and collaborative action across the Internet. Those who join agree to take meaningful action to keep the Internet safe for everyone – by taking four concrete steps to improve routing resiliency.

We are pleased to announce that Microsoft is one of the latest to join the MANRS initiative – working with other industry giants to improve routing security globally. They join a community of security-minded organizations committed to making the global routing infrastructure – and the Internet itself – more robust and secure.

“Microsoft has long been committed to increasing cybersecurity online. We are therefore excited to be joining the MANRS community in addressing the very real challenges related to routing security, which impact businesses and consumers on a daily basis. In addition to having implemented the existing MANRS framework in our operations, we are also partnering with Internet Society, the Cybersecurity Tech Accord, and others to examine how actors beyond network operators and IXPs can effectively contribute to routing security,” said Yousef Khalidi, Corporate Vice President, Azure Networking.

Collaboration and shared responsibility are key to the success of MANRS. So far 152 network operators and 32 IXPs have signed on. By joining, these companies are working hard to secure the fabric of the Internet.

Routing security is vital to the future and stability of the Internet. We’re thrilled that Microsoft has joined MANRS, and we hope that they will lead the way for other network operators around the world.

About Internet Society Building Trust Community Networks Growing the Internet Improving Technical Security Internet Governance Internet of Things (IoT) Mutually Agreed Norms for Routing Security (MANRS) Public Policy Security Shaping the Internet's Future

Working Together the Internet Way to Build Success in North America

One of the most common lines you’ll hear in the virtual halls of the Internet Society is that the Internet’s success is due to its open, distributed, and global nature.

Think about it. A network of voluntarily-connected networks changed the course of history in a matter of decades because people agreed to work and innovate together. It’s a deeply profound source of inspiration about the power of humankind.

It practically begs the question: can we replicate even a portion of its success by embodying the “the Internet way” of working in North America?

The answer is yes.

As part of this, one thing is strikingly clear. Chapters and partners are the lifeblood of the organization. They are critical to working more closely with communities at the front lines of our work.

The Internet’s own globally-operable infrastructure proves the infinite potential of what can happen when people work together. In the same way, we will come together as a diverse community to help define future priorities.

We’ve already seen successes in the North American region that show how closer collaboration with Chapters and partners can help us reach new levels of success.

Enhancing IoT Security

Canada is changing how countries around the world think about securing our connected future.  Last year, the Internet Society launched and led the Canadian Multistakeholder Process oversight committee to secure Internet of Things (IoT) in Canada.

Throughout this project, the Canadian chapter helped plan meetings and enlist a dedicated group of partners, stakeholders, and youth participants to develop recommendations for an IoT policy to ensure security is ingrained in Canadian innovation. The Quebec chapter also organized a focus group on IoT during an Internet Engineering Task Force meeting in Montreal last year.  Even our U.S. Chapters and organization members are supporting the cause. For instance, the Internet Society’s New York Chapter hosted a session on how to make trustworthy IoT last October.

Thanks to this collaboration, countries and policymakers around the world are being inspired by our work. While the final recommendations aren’t expected until April 2019 (Canadians can comment on the draft here), we’re already helping countries like Senegal, France, and others to adopt similar regulatory approaches to build a future we can trust.

Indigenous Connectivity

Connecting the world is critical and we won’t rest until everyone who wants to be connected has the option to do so. Thanks to a dedicated group of individuals, communities, and local Chapters like New Mexico, we’ve made great headway to inspire solutions to close the digital divide in Indigenous communities throughout North America.

We’ve already held two successful Indigenous Connectivity Summits (ICS) to explore the potential of community networks to empower communities to connect to fast, affordable, and reliable Internet on their own terms. The ICS has also inspired plans to create a new Chapter focused on Indigenous connectivity.

You can read about last year’s event held in Canada’s Artic community of Inuvik, NT in Empowerment Through Connectivity.  We’re already looking forward to the third Summit in Hawaii this November, and not just for the change in weather. Stay tuned here for more details on ICS!

Promoting a Healthy Internet for Everyone

When it comes to advocacy, we have a lot of ground to cover as a global organization. There is a wide range of issues critical to ensuring an open Internet for all, and Chapters and partners are crucial to speaking with a stronger regional voice.

Just last month, Konstantinos Komaitis led a speaking series on regulation in the United States and Canada to bring attention to our Chatham House call for papers on consolidation. Thanks to help of the Washington DC and Canada Chapters to organize these events, our “regulation on the road” tour brought attention to the unintended consequences of regulation in key newsworthy moments, such as securing Canada’s federal election.

One of the successes that inspired our collaborative efforts was supporting DC Chapter Executive Director Dustin Phillips’ Internet community road trip last year. His collaboration with the San Franscisco-Bay Area chapter and other partners to promote the importance of getting involved in Internet Governance helped bring some powerful doers and shakers to the ecosystem.

This year, we’ll be advocating for security standards like MANRS. We’ll also continue to collaborate on even more events, educational resources, and webinars to amplify what we do, why it matters, and how it’s important to the future of the Internet.

Moving Forward Together

When it comes to making a difference, the Internet has already taught us that we’re stronger together than we are apart.

By integrating “the Internet way” of working with Chapters and partners based on our shared goals and values, the Internet Society can take greater strides to making the Internet a better and more inclusive place for everyone.

Based on our early successes, we’re more confident than ever that collaboration will take us to new levels of success.

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

Internet Resilience Discussions at IETF 104

Let’s look at what’s happening in the Internet Engineering Task Force (IETF) and the upcoming IETF 104 meeting in the area of Internet infrastructure resilience. As usual, my focus here is primarily on the routing and forwarding planes, and specifically routing security and unwanted traffic of Distributed Denial of Service Attacks (DDoS) attacks. There’s interesting and important work underway at the IETF that can help addressing problems in both areas.

This time there are a lot of new ideas, especially of an operational nature, that people bring to the IETF in the form of Internet Drafts that aim to improve the security and resilience of the Internet infrastructure. So I’d like to introduce some of them to you, but keep in mind that an Internet Draft (I-D) does not necessarily indicate IETF endorsement. It also does not constitute a standard and may even not result in any work at the IETF.

So let’s look at what’s happening in BGP land.

Can BGP Communities be harmful? 

In the recent paper “BGP Communities: Even more Worms in the Routing Can“, the authors demonstrated that Border Gateway Protocol (BGP) communities can be exploited by remote parties to influence routing in unintended ways. Due in part to their ill-defined semantics, BGP communities are often propagated far further than a single routing hop, even though their intended scope is typically limited to nearby ASes. As a consequence, remote adversaries can use BGP communities to trigger remote blackholing, steer traffic, and manipulate routes even without prefix hijacking.

The problem of ill-defined semantics is aggravated by the fact that BGP communities, and especially well-known communities, are manipulated inconsistently by current router implementations. There are differences in the outcome of the “set” directive in several popular BGP implementations. For example, in Juniper Network’s Junos OS, “community set” removes all received communities, well-known or otherwise, whilst in Cisco Systems’ IOS XR “set community” removes all received communities except a few.

An I-D “Well-Known Community Policy Behavior” describes the current behavioural differences in order to “assist operators in generating consistent community-manipulation policies in a multi-vendor environment, and to prevent the introduction of additional divergence in implementations.”

The document also urges network operators never to rely on any implicit understanding of a neighbor ASN’s BGP community handling.  For instance, “before announcing prefixes with NO_EXPORT or any other community to a neighbor ASN, the operator should confirm with that neighbor how the community will be treated.”

BGP Large Communities in the IXP environment

Some networks peer at multiple IXPs in order to improve redundancy and geographical optimization.  It is also common that, in the case of using a Route Server (RS) to implement multilateral peering relationships, Large Communities are used to instruct the RS on how to handle an announcement (e.g. not to advertise to a particular ASN), or to send additional information to the peer, e.g. the status of the validation.

The I-D “BGP Large Communities applications for IXP Route Servers” attempts to document commonly used Large Communities to facilitate consistency of use across multiple IXPs.

Building a more robust routing policy with maximum prefix limits

Has your network experienced a situation where a peer suddenly floods your border router with many more routes than expected, sometimes causing resource exhaustion and other troubles? 

The I-D “BGP Maximum Prefix Limits” describes mechanisms to reduce the negative impact of these types of misconfigurations. Instead of a general limit on the number of prefixes received from a BGP neighbour, as defined in the BGP specification, it proposes a more granular scheme with three control points to mitigate the impact:

  • Pre-Policy Inbound Maximum Prefix Limits – when the limit is checked before any policy is applied (e.g. filtering). These limits are particularly useful to help dampen the effects of full table route leaks and memory exhaustion when the implementation stores rejected routes.
  • Post-Policy Inbound Maximum Prefix Limits – checked after the import policy is applied. They are useful to help prevent FIB exhaustion and prevent accidental BGP session teardown due to prefixes not accepted by policy anyway.
  • Outbound Maximum Prefix Limits – trigger termination of a BGP session with a neighbor when the number of address prefixes to be advertised to that neighbor exceeds a locally configured upper limit. These limits are useful to help dampen the negative effects of a misconfiguration in local policy.  In many cases, it would be more desirable to tear down a BGP session rather than flooding the neighbors with misconfigured announcements.

These recommendations are distilled from a broader framework, presented by Job Snijders at the RIPE 77 meeting last year.

Leveraging RPKI for proven operational practices

A common best practice to ensure that one’s customers only announce their own networks and the networks of their customers, is to build prefix filters. 

In the case there are only direct customer relationships (i.e. the network operator’s customers are ‘stub networks’), the task is relatively easy. One needs to collect prefixes, legitimately originated by these networks, and this is most commonly done by using an IRR of choice and collecting corresponding “route” objects. But with the proliferation of RPKI, it can become a more robust alternative, providing a cryptographically verifiable ROA object that serves a similar purpose.

If you are a bigger network and some of your customers also provide transit services for smaller networks, the task is more difficult. How to determine who are the customers of your customers and so on? 

To help with this task, there is a special IRR object – “as-set”. This object is a list of ASNs or other “as-sets” that defines the customer cone of a particular AS.

However, when it comes to RPKI, there is no way for an operator to assert the routes for its customer networks, making it difficult to use the information carried by RPKI to create meaningful prefix filters without relying on RPSL “as-sets”.

The I-D “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” attempts to fix that problem by introducing a new attestation object called an AS-Cone.  An AS-Cone is a digitally signed object with the goal of enabling operators to define a set of customers that can be found as “right adjacencies” or transit customer networks, facilitating the construction of prefix filters for a given ASN, thus making routing more secure.

By leveraging RPKI, AS-Cone also addresses two fundamental problems with the RPSL “as-set”. The same AS-SET name can exist in multiple IRRs, and a relying party does not necessarily know which “as-set” belongs to which ASN, and which as-set to use. 

Improving AS-PATH validation

The Border Gateway Protocol (BGP) was designed with no mechanisms to validate BGP attributes. The ability to manipulate one of them – AS_PATH – creates one of the most serious vulnerabilities of the Internet routing system. BGPsec was therefore designed to solve the problem of AS_PATH correctness.  

But according to the authors of a new I-D “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization” even leaving aside the complexity, its backward support for ‘insecure’ BGP allows an attacker to mount a downgrade attack to nullify all the work of AS_PATH signing. 

The authors suggest a more pragmatic approach that can help leveraging the benefits of RPKI without the need for the ubiquitous deployment of BGPsec. The idea is that any AS can declare its upstream providers and peers – the networks that can propagate its prefix announcements. The more networks that do that, the more chances to detect misconfigurations whether malicious or not.

The draft defines the semantics of Autonomous System Provider Authorization (ASPA) objects that should become part of RPKI. ASPAs are digitally signed objects that bind in a selected AFI Provider AS number to a Customer AS number (in terms of BGP announcements not business), and are signed by the holder of the Customer AS. An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements onward, e.g. to the Provider’s upstream providers or peers.

Mitigating DDoS attacks

DDoS attacks are a persistent and growing threat on the Internet.  As they evolve rapidly in the terms of volume and sophistication, a more efficient cooperation between the victims and parties that can help mitigate such attacks is required. The ability to quickly and precisely respond to a attack when it begins, and communicate precise information to a mitigation service provider is crucial.

Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS) Working Group busy. The aim of DOTS is to develop a standards based approach for the real-time signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. Specifications outlining the requirements, architecture and the use cases for DOTs are maturing, and there is a hackathon planned at IETF104 to conduct further interoperability testing of DOTS protocols.

Another interesting case getting more importance, especially with the advent of consumer IoT devices, is mitigation of outbound DDoS attacks originating in a home network. The I-D “Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home” proposes a solution to these cases by proposing a DOTS signal channel Call Home extension that enables the DOTS server to initiate a secure connection to the DOTS client. The DOTS client then conveys the attack traffic information to the DOTS server. 

In a typical deployment scenario, the DOTS server is enabled on a CPE, whilst a client resides in an ISP network. In this case the DOTS server in the home network initiates the Call Home during peace time, and subsequently the DOTS client in the ISP environment can initiate a mitigation request whenever the ISP detects there is an attack from a compromised device in the DOTS server’s domain. Subsequently, the DOTS server would use the DDoS attack traffic information to identify the compromised device in its domain launching the DDoS attack, notify the network administrator, and take appropriate mitigation action such as quarantining the compromised device or block its traffic to the attack target until the mitigation request is withdrawn.

The meeting in Prague is certainly going to be interesting regarding Internet infrastructure security and resilience, and will hopefully have a positive impact in this area.

Relevant Working Groups at IETF 104

SIDROPS (SIDR Operations) WG
GROW (Global Routing Operations) WG
IDR (Inter-Domain Routing) WG
DOTS (DDoS Open Threat Signaling) WG