Categories
Mutually Agreed Norms for Routing Security (MANRS) Strengthening the Internet

New Category of CDNs and Cloud Providers Join MANRS to Improve Routing Security

Today, we’re proud to announce the new MANRS Content Delivery Network (CDN) and Cloud Programme. This new program broadens support for the primary objective of MANRS – to implement crucial fixes needed to eliminate the most common threats to the Internet’s routing system.

The founding participants are: Akamai, Amazon Web Services, Azion, Cloudflare, Facebook, Google, Microsoft, and Netflix.

Now, let’s back up and explain how we got here.

What Is MANRS?

Mutually Agreed Norms for Routing Security (MANRS) is a global initiative, supported by the Internet Society, that requires collaboration among participants and shared responsibility for the global Internet routing system. It’s a community of security-minded organizations committed to making routing infrastructure more robust and secure.

Originally designed by and for network operators, the initiative has already been extended once to address the unique needs and concerns of Internet Exchange Points. These two facets of MANRS complement each other – the first secures customer-provider interconnections, while the second creates a safe public peering environment.

How Do CDNs and Cloud Providers Help?

CDNs are a geographically distributed group of servers that work together to provide fast delivery of Internet content across the globe, and today the majority of web traffic is served through CDNs. Cloud providers offer network services, infrastructure, and/or applications in the “cloud” by hosting them in data centers, often distributed around the world, and providing access via the Internet or private interconnections.

CDNs and cloud providers help companies serve their content and online services to end users by delivering it in a distributed manner and from locations closer to them. For instance, when you visit a website, its content is often fetched from a closest location and not from the website owner’s infrastructure, which could be much farther away and, as a result, much slower.

The two typically peer – exchange traffic directly – with thousands of other networks so that data can flow more efficiently, making them large hubs of the Internet interconnection infrastructure. Peering with CDNs and cloud providers can drastically improve performance of network services they host, so there is a clear benefit to interconnect with these networks.

While CDN and Cloud are basically edge networks, their impact on routing security can be significant. Several known incidents showed that an edge network, even a small one, can cause havoc on the Internet by leaking routes. MANRS helps by requiring egress routing controls, so networks can prevent such incidents from happening. Secondly, leveraging CDNs’ and cloud providers’ peering power can have significant positive spillover effect on the routing hygiene of networks they peer with. In other words, if CDNs and cloud providers do their part to improve routing security and demand better practices from their customers, their customers will in turn step up their efforts, and together the Internet will be better and safer for all of us.

That is why in late 2018 the MANRS community formed a task force with representatives from Akamai, Azion, Cloudflare, Comcast, Facebook, Google, Microsoft, Nexica, Oracle, Telefonica, Redder, TORIX, and Verisign committed to developing a set of actions CDNs and cloud providers should take to improve routing security. The outcome of that task force’s work led to the creation of this new MANRS program.

What Do CDNs and Cloud Providers Need to Do?

The MANRS Content Delivery Network (CDN) and Cloud Programme lists six actions, of which five are mandatory to implement:

  1. Prevent propagation of incorrect routing information
  2. Prevent traffic of illegitimate source IP addresses
  3. Facilitate global operational communication and coordination
  4. Facilitate validation of routing information on a global scale 
  5. Encourage MANRS adoption
  6. Provide monitoring and debugging tools to peering partners (optional)

Program participation provides an opportunity to demonstrate attention to the security and sustainability of the Internet ecosystem and, therefore, dedication to providing high-quality services.

How Do I Sign Up?

Any CDN or cloud provider that takes at least the five required actions above is welcome to join us. Besides enjoying improved security posture, MANRS participants also show their commitment to the sustainability and resilience of the Internet ecosystem by:

  • Creating a secure network peering environment, preventing potential attacks at their border
  • Encouraging better routing hygiene from your peering partners
  • Signaling your organization’s security-forward posture
  • Demonstrating responsible routing behavior
  • Improving operational efficiency for peering interconnections, minimizing incidents and providing more granular insight for troubleshooting

Why Is Routing Security Important?

The Internet routing system’s resilience and security is a collective responsibility. No single entity can solve BGP vulnerabilities, and yet without additional controls any network can wreak havoc on the system.

BGP – the protocol used to exchange reachability information between networks and build a “roadmap” of the Internet – does not have built-in validation mechanisms. Without additional controls, routing information is accepted as is, including falsifications and mistakes. When that happens, the roadmap is distorted and traffic follows undesired paths, gets intercepted, or gets blackholed altogether.

Those additional controls have been known for decades and they, if implemented widely, will prevent most routing incidents from happening. MANRS actions encourage any network running BGP to implement well-established, low-risk, low-cost industry best practices and technological solutions that can address the most common threats.

Why Should I Care?

There are numerous examples of the impact of routing incidents, either malicious attacks or configuration mistakes. Route leaks, mentioned above, resulted in several hours outages spread globally. Routing system vulnerabilities can also be exploited to hijack and impersonate important Internet services, like DNS or websites, leading to money and reputation loss.

Let’s Work Together

It is only through collective action and a shared sense of responsibility that we can address problems like BGP leaks, hijacks, DDoS attacks, and IP address spoofing that have real-world consequences for millions of people. We must work together to build a more resilient and secure Internet infrastructure.

This new Content Delivery Network (CDN) and Cloud Programme opens a new chapter in MANRS, further extending its community and bringing us closer to a secure and resilient global routing system – the foundation of the Internet. Please join us.

Read the fact sheet to learn more about this new program.

Categories
Mutually Agreed Norms for Routing Security (MANRS) Strengthening the Internet

You Asked and We Listened: New Features in the MANRS Observatory

Collaboration and shared responsibility are two pillars of the Mutually Agreed Norms for Routing Security (MANRS) initiative, which we support so that there is a baseline of routing security for network operators around the world.

The same values apply to running the MANRS Observatory, an online tool we launched in August that lets users track the state of Internet routing security and network operators their “MANRS-readiness.” Aggregating data from trusted sources, it relies on the community with a shared goal to protect the core of the Internet.

Since we rolled out the tool, many of you have shared that you would like to see updates to make it more informative, intuitive, and easy to use. We take your comments seriously, and we are delighted to introduce some of the new features to you.

We’ve made several improvements to the user interface, including:

  • Improved Search. The search network now displays the name of a network as you type an ASN. This feature is only available to MANRS participants; public access does not provide data for individual networks.
  • Report Sharing. Individual network reports that provide detailed information about potential incidents and cases of non-conformance can now be easily shared with colleagues across the company, for example at a NOC. Metrics and corresponding detailed data can now be exported as separate reports in JSON format. Also, any part of the report can be shared by using a link with a stable URL.
A screenshot of a cell phone

Description automatically generated
Figure 1: Data related to individual metrics are now easy to download or share
  • Simpler Metrics. We consolidated some data related to metrics indicating “bogon” announcements. The reports are now less “chatty” and easier to read.
  • Historical Charts. When more than one network is selected, the history charts are shown as a stacked diagram, showing the distribution of “ready,” “aspiring,” and “lagging” networks as well as the average readiness index for the group.
Figure 2: Historical trends are now presented as stacked diagrams, showing the distribution of different readiness levels in the group, as well as the average score
  • New Data Source. We added new contact information to make the corresponding metric (M8) consistent with the MANRS requirement. Now, next to RIRs’ WHOIS databases, PeeringDB is also queried.
  • Custom Network Groups. Participants and partners can now create custom network groups of ASNs they are interested in monitoring. This does not change access permissions; users still only have access to detailed reports for the ASNs they operate, but groups provide an easy overview, otherwise accomplished by manually adding ASNs through the search function. Several use cases were considered, including: a transit provider monitoring its customer cone, a CSIRT monitoring MANRS conformance of its constituency, or a government monitoring networks of its agencies.
Figure 3: Users can create custom groups, for instance the networks belonging to their customer cone, to monitor conformance

Partner Access, More Granular Data, and an Enhanced Acceptable Use Policy

We have been getting requests from organizations and individuals working together with MANRS to promote this initiative and routing security. They see the MANRS Observatory as a useful tool to support their work. To enable their access to more granular data, we revised the Observatory’s Terms and Conditions, which now clarify an acceptable use policy. In particular, it says that use of any information derived from the Observatory is only permitted “for purposes of promoting routing security or MANRS, such as presentations, technical workshops and tutorials,” and that it can only be shared in “de-identified form.” Partners can still only access overall readiness scores – access to detailed reports remains open only to the operators of respective networks. To apply for partner access, fill out this form.

Aspiring MANRS Networks

Another potentially useful feature that we’ve started testing is a so-called “aspirant” account. When a network applies to MANRS, during the audit process we often share data related to potential areas of improvements that we get from the MANRS Observatory. The aspirant account allows the network engineer to log in and explore all the data related to their network available in the Observatory, fixing any shortcomings they find. That should help streamline the audit process and improve the quality of applying networks.

Your Feedback

Routing security problems cannot be solved by any single entity. It requires collective action, like MANRS. That is why we appreciate the feedback you have given us, so that the Observatory can be more useful to the community. That in turn will help all of us make the Internet more secure.

If you are using this tool, please let us know what you think about these features. If you have suggestions on how to improve the tool further – please let us know, too!  Email us at manrs@isoc.org.


Image by Volodymyr Hryshchenko via Unsplash

Categories
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.

Categories
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
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-sidrops
Charter: https://datatracker.ietf.org/wg/sidrops/charter/
GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-grow
Charter: https://datatracker.ietf.org/wg/grow/charter/
IDR (Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-idr
Charter: https://datatracker.ietf.org/wg/idr/charter/
DOTS (DDoS Open Threat Signaling) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-dots
Charter: https://datatracker.ietf.org/wg/dots/charter/
Categories
Building Trust Events IETF Improving Technical Security Open Internet Standards

Rough Guide to IETF 102: Internet Infrastructure Resilience

As usual, in this post I’ll focus on important work the IETF is doing that helps improve the security and resilience of the Internet infrastructure.

At IETF 102 there are a lot of new ideas being brought to the community in the form of Internet Drafts aimed at improving the security and resilience of the Internet infrastructure, and I’d like to introduce some of them to you. But keep in mind – an Internet Draft does not indicate IETF endorsement, is not a standard, and may not result in any further work at the IETF.

So, let us look at what is happening in the domain of BGP, the routing protocol that connects the Internet.

Route leaks

There has been slow progress in the work on mitigating route leaks in the IDR Working Group (WG). One of the reasons for the slowness was that the group was considering two proposals addressing the route leak problem and both are IDR WG documents:  “Methods for Detection and Mitigation of BGP Route Leaks”, and “Route Leak Prevention using Roles in Update and Open Messages”. Plus, there is a third submission “Route Leak Detection and Filtering using Roles in Update and Open Messages” that also provides a solution in this area.

Fortunately, it seems that the relationship between all three is clearer now. Preventing route leaks locally by the potential culprit is described in draft-ietf-idr-bgp-open-policy. It also defines roles that can be useful in other solutions. draft-ietf-idr-route-leak-detection-mitigation now incorporates some ideas from draft-ymbk-idr-bgp-eotr-policy and is focused on detection and mitigation of the leaks upstream, more than one hop away from the culprit. In other words, the group is now working on two complementary and not conflicting solutions. Hopefully that will help with finalizing them soon.

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 fact, this should become a norm for every network, as defined in Action 1 of MANRS.

In the case where there are only direct customer relationships (i.e. the network’s customers are all “stub networks”), the task is relatively easy – one needs to collect the list of prefixes legitimately originated by these customer networks. This is most commonly done by using an IRR and collecting corresponding “route” objects, but with the proliferation of RPKI this can become a more robust process using cryptographically verifiable ROA objects that serve 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 does one determine who are the customers of one’s 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 a 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 Internet Draft “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” tries 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 considered transit customer networks, thereby facilitating the construction of prefix filters for a given ASN and 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,
  • a relying party does not know which “as-set” belongs to which ASN, and which as-set to use.

Validating AS-PATH without BGPsec

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 more serious vulnerabilities of the Internet routing system. BGPsec was designed to solve the problem of AS_PATH correctness.

But according to the authors of a new Internet Draft, “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization“, even leaving aside its complexity, its backward compatibility with ‘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 do that – the more chances to detect misconfigurations (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 a 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, e.g. to the Provider’s upstream providers or peers.

Using blockchain to secure IP addresses allocation, delegation and bindings

While RPKI technology offers the significant benefits of cryptographically secured authentication and authorisation of ownership of Internet number resources (IP address blocks and AS numbers), aligned with the distribution hierarchy of Internet number resources, it has also raised some concerns. The concerns are mostly related to centralization of routing authority and creating single points of failure, or even kill switches, represented by the  RIRs and IANA.

A technology that can facilitate building cryptographically strong and credible ledgers, without relying on a hierarchical system, is blockchain. Can it be applied in this case?

The Internet Draft, “An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings“, looks at how blockchain technology can be used to secure the allocation, delegation, and binding to topological information of the IP address space.  The main outcomes of the analysis are that blockchain is suitable in environments with multiple distrusting parties and that Proof of Stake is a potential candidate for a consensus algorithm.

However, several questions remain open, such as the balance of power between providers and customers, enforcement of RIR policies, incentives for adoption or deployment cost.

As you can see, the meeting in Montreal is certainly going to be full of interesting discussions in the area of Internet infrastructure resilience, and will hopefully lead to some important work, specifications and improvements to the fabric of the network that we all depend on for so much.

Related Working Groups at IETF 102

SIDROPS (SIDR Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/

GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Building Trust Improving Technical Security Internet of Things (IoT) Open Internet Standards Technology

The Internet of Things as an Attack Tool

Akamai has published its Q4 2016 State of the Internet/Security report As always, an interesting read and an opportunity to look at trends in attacks.

Not all trends are up and to the right. As the report states, Q4 2016 was “the third consecutive quarter where we noticed a decrease in the number of attack triggers”. Still, “the overall 2016 attack count was up 4% as compared to 2015”. Also, the volume and number of “mega-attacks” is on the rise.

And of course, there was the Mirai malware recruiting poorly secured devices connected to the Internet. The Mirai-based botnet produced the largest-ever DDoS attacks, with volume peaking at 623 Gbps. That drew a lot of media attention to the dark side of the Internet of Things (IoT), calling for action before it is too late.

Let us look at a few trends playing out in this area.

First, the IoT. Lacking an agreed definition, there is a tendency to call anything connected to the internet, except conventional computers, an IoT device. Not trying to craft yet another definition, an important question is what makes these new types of connected devices different from the ones that were connected in the past? In the context of DDoS attacks I can only think of the three:

Increased number. Twenty years ago, a household would have a home router and one or two computers connected. Then the smartphone revolution came and significantly more devices were added: gaming consoles, smartphones and tablets. Now with the ability to easily connect anything there is a potential that the number of connected things per household, but also in other areas, such as industrial systems and “smart” environments, will increase in orders of magnitude. And since any device is potentially vulnerable, that increases opportunities for an attacker.

Limited user interaction. Smart objects are designed to operate autonomously, in the background, without requiring user intervention and offering a limited user interface (if there is one at all). That means that the user won’t administer the device – install updates, monitor its performance, scan for malware and clean it up. But quite frankly, this does not happen much with computers and smartphones either. The difference is that in the latter area the industry has matured and consolidated, realizing the need and offering proven security solutions without relying on a user.

Constrained. On one hand, that means that implementing security functions is more difficult, but on the other – malware has to deal with the same constraints. As recent attacks showed in the context of a DDoS, we should be more afraid of unconstrained devices such as home routers and set top boxes. Such devices have presented a threat since 2003, when a software flaw in Netgear cable modems cased a DDoS attack on the University of Wisconsin, USA. Also, many of these unconstrained devices are always on – another useful feature for a bot.

Increasing complexity, expanding code base, larger attack surfaces as new users and devices are connected to the Internet, less reliance on the user as the Internet has become a commodity – these are general trends related to growth and development, not just an IoT revolution.

The report seems to confirm this: “While there were plenty of IoT-fuelled DDoS attacks in the fourth quarter, none of the fourth quarter’s attacks over 300 Gbps were IoT-based. The Attack Spotlight looks at the botnet that generated the top 3 largest DDoS attacks and delves more deeply into the largest attack this quarter, a 517 Gbps attack with signatures from the Spike DDoS toolkit.”

Another interesting trend highlighted in the report is related to competition for resources: “Our examination of the use of ntp reflection as an attack amplifier last quarter suggests that new attack types peak shortly after they appear. But as these attacks gain in popularity, competition for the resources needed to make them begins. While the number of attacks goes up, the size of individual attacks is pushed down, as there are fewer resources available for each of the botnets.”

What does this mean?

I think that if we talk about DDoS attacks and botnets we must build on more than two decades of experience dealing with this phenomenon. So far three strategies have been applied with relative success:

1. Making the edge more secure

The frightening trend here is that many device manufacturers put features and price on top, and security at the bottom of their priority list. That also includes absence of a software or firmware update mechanism. This creates a long-lasting vulnerability at the edges.

A positive trend here is that the standards development and open source communities are putting a lot of efforts into designing building blocks and ready-to-use solutions in this area. Last year the IAB organised a workshop, “ Internet of Things (IoT) Software Update (IoTSU)”, where participants discussed the software/firmware update mechanisms. A BoF to further work in this area is scheduled for the IETF 98 meeting in Chicago from March 26-31: “A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) BoF”. Significant efforts are being put into building IoT frameworks, some of which are open source, like AllJoyn by the Open Connectivity Foundation (OCF), and some of which are closed, such as HomeKit by Apple.

2. Detection and disinfection

A good example here is the ” Anti-Bot Code of Conduct for Internet Service Providers” outlining five areas where ISPs can take action and help reduce end-user bots. These are: Education, Detection, Notification, Remediation, and Collaboration.

Users can also take responsibility and keep their home networks clean. This is more and more in their own interest – from performance degradation to privacy and even physical threats as the IoT penetrates our material life. Developments like SENSE from F-Secure can provide households with necessary tools.

3. Mitigation

Botnets usually rely on so-called Command & Control (C&C) servers to get instructions for their operation. Disabling the C&C server effectively means disabling the botnet. For example, this approach was successfully applied in mitigating the Conficker botnet.

Interestingly, there is no (at least not that I have found) mention of this approach when addressing the Mirai botnets. Given that the source code has been released, tracing and taking down C&C servers should be easier.

Does the IoT change this?

The emergence of the IoT makes addressing the issue more challenging, but so is the growth of the Internet in terms of bandwidth and number of connected users. That makes it more important to re-inforce and foster the approaches that worked.

It is true that the IoT brings new challenges and threats, and at different scale. Imagine cars colliding without reason, or smart cities getting the time of day wrong, or power plants misreading parameters of the reactor. What could make these nightmares materialize themselves are vulnerabilities of the components, not only devices, but also communication links and protocols, software, apps, etc. And the question is – how do we secure these systems? A common approach is based on holistic risk assessment. But this is a topic for another post.

So, does the IoT bring a radical change to the DDoS attack landscape? If it does, which of the current approaches in addressing botnet issues and DDoS mitigation work and which do not? What new approaches are required? We welcome your thoughts, opinions and ideas here in the comments.

Categories
Building Trust IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 97: Internet Infrastructure Resilience

Let’s look at what’s happening in the IETF and the upcoming IETF 97 meeting in the area of Internet infrastructure resilience. My focus in this Rough Guide to IETF 97 post is primarily on the routing and forwarding planes and specifically routing security and unwanted traffic of DDoS attacks. There is interesting and important work underway at the IETF that can help address problems in both areas.

The Secure Inter-Domain Routing (SIDR, http://datatracker.ietf.org/wg/sidr/) WG has made a significant contribution to the area of routing security by developing the RPKI system and security extensions to BGP – BGPSEC. Its work is almost done, with the core specifications being either approved as IETF standards, or waiting in the IESG queue for approval.

Now the real focus is on the deployment of these technologies and related to this maintenance of the corresponding standards. This deployment must be properly handled to avoid the division of the Internet into separate networks.

A newly chartered SIDR Operations Working Group (sidrops) is aimed at developing guidelines for the operation of SIDR-aware networks, and providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks.

From the charter (https://datatracker.ietf.org/wg/sidrops/charter/): “In the space of sidrops, the term operators will encompass a range of operational experience: CA Operators, Regional/National and Local Internet Registries, Relying Party software developers as well as the research/measurement community all have relevant operational experience or insight that this working group will consider in its work. The sidrops working group is focused on deployment and operational issues and experiences with SIDR technologies that are part of the global routing system, as well as the repositories and CA systems that form part of the SIDR architecture.”

The expectation is that the working group if formed will meet first at IETF 98. The proposed charter includes work items which are already underway.

In the area of route leaks there are still two proposals. One is an IDR WG document,“Methods for Detection and Mitigation of BGP Route Leaks”, where the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC. Another is an independent submission “Route Leak Detection and Filtering using Roles in Update and Open messages”. This proposal enhances the BGP Open message to establish an agreement of the (peer, customer, provider, internal) relationship of two BGP neighboring speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks.

There was no discussion of either approach on the mailing list, but a new version of “Route Leak Detection and Filtering using Roles in Update and Open messages” is on the agenda of the IDR WG meeting in Seoul.

Related to the forwarding plane and DDoS specifically, a few meetings ago a draft “BLACKHOLE BGP Community for Blackholing” was introduced initially to document a well-known community used for triggering blackholing at IXPs, similar to what DE-CIX is doing (https://www.de-cix.net/products-services/de-cix-frankfurt/blackholing). Several concerns about the risk of abusing IXPs as a “filtering sink of the internet,” for example by law enforcement, were raised that led to a more general document describing use of this attribute for just networks. The document was adopted by the GROW WG and is recently published as an informational RFC (https://datatracker.ietf.org/doc/rfc7999).

Also in the same problem area a DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG is making good progress. The goal of the group is to develop a communications protocol intended to facilitate the programmatic, coordinated mitigation of such attacks via a standards-based mechanism. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries.

The agenda of the WG meeting at IETF 97 contains discussion of use cases, requirements draft, architecture of the system, data and information model, including the telemetry specification.

I hope this work will lead to an effective solution for this huge problem of the Internet and facilitate necessary cooperation across network administrative domains.

Related Working Groups at IETF 97

SIDR (Secure Inter-Domain Routing) WG
Thursday, 17 November, 15:20-17:50, Studio 2
Agenda: https://datatracker.ietf.org/meeting/97/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations) WG
Wednesday, 16 November, 11:10-12:10, Grand Ballroom 2
Agenda: https://datatracker.ietf.org/meeting/97/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Tuesday, 15 November, 15:50-18:20, Grand Ballroom 3
Agenda: https://datatracker.ietf.org/meeting/97/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Friday, 18 November, 09:30-11:30, Park Ballroom 1
Agenda: https://datatracker.ietf.org/meeting/97/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

There’s a lot going on in Seoul, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see https://dev.internetsociety.org/tag/ietf97/.

Categories
Building Trust IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 95: Internet Infrastructure Resilience

This issue of the ISOC Rough Guide to IETF 95 includes not only issues related to the control plane (routing), but also to the data forwarding plane – specifically DDoS attacks. There is interesting and important work underway at IETF 95 in Buenos Aires next week that can help addressing problems in both areas.

The Secure Inter-Domain Routing (SIDR, http://datatracker.ietf.org/wg/sidr/) WG is focusing on securing inter-domain routing. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to BGP and is an important component of BGP security extensions – BGPSEC, also developed in SIDR WG. This is a key technology for improving trust in the global routing infrastructure.

If you look at the agenda, quite a few new proposals are brought to the table and will be discussed in Buenos Aires. Remarkably, most of them are related to the RPKI and Origin Validation, its operational and deployment aspects, which is a good indicator of the maturing process of this technology.

For quite some time the RIR engineers operating apexes of the RPKI hierarchy have been raising concerns about fragility of the system to potential mistakes of “over-claiming.” This is a case when a subordinate certificate “over-claims” resources compared to its parent, which leads to invalidation of the whole branch beneath. The closer to the top of the RPKI hierarchy such mistakes happen, the bigger the impact – some ISPs can lose their routing completely (assuming other folks validate, of course). And the probability of such mistakes is unfortunately non-zero, especially taking into account the inter-RIR address transfers.

A proposal “RPKI Validation Reconsidered” ( http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered) tried to address this issue, but proposed quite fundamental changes to the PKI validation process that raised strong opposition in SIDR.

A new draft “RPKI Multiple ‘All Resources’ Trust Anchors Applicability Statement” ( https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-00) attempts to address this problem, but from a different angle. It suggests that each RIR will move from a Trust Anchor that reflects their current holdings to one that reflects all holdings (e.g. 0/0) so that over-claiming can not occur at an RIR level when dealing with transfers from one RIR to another. Interesting solution – I am sure it will generate some discussion at the microphone!

In order to use information published in RPKI repositories, Relying Parties (RP) need to retrieve and validate the content of certificates, CRLs, and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore, the validation of a certificate tree is usually performed top-down, starting from the TA certificate and descending down the certificate
chain, validating every encountered certificate and its products.

A draft “RPKI Certificate Tree Validation by a Relying Party Tool ( https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-00) describes how a Relying Party tool could discover RPKI objects to download, build certificate path, and validate RPKI objects, independently from what repository access protocol is used. The draft documents the process used by the RIPE NCC RPKI Validator implementation, but if there is interest it may be a good starting point of a generic validation document. I think that work can lead to more coherent and robust implementations of the validators.

A draft “Signaling RPKI Validation Results from a Route-Server to Peers”
( https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-00) proposes how RPKI can be effectively used in an IXP environment, enhancing the functionality of a route server.

This all indicates to me that practical RPKI is getting more momentum.

We talked before about a so-called “route-leak.” Simply speaking, this term describes an otherwise valid announcement that nevertheless violated the intended propagation scope. For example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Because it is a policy violation, neither OV nor BGPSEC can detect or mitigate such “attack.” Seems like a significant “hole” that needs to be fixed.

Next to the “Methods for Detection and Mitigation of BGP Route Leaks” ( http://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation), where the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC, there is a yet another proposal – “Route Leak Detection and Filtering using Roles in Update and Open messages” ( https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-00). This new proposal enhances the BGP Open message to establish an agreement of the (peer, customer, provider, internal) relationship of two BGP neighboring speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks. There are similarities among the two proposals and I think they can complement each other. I hope this will be discussed soon and an agreed common approach will be adopted.

Related to the forwarding plane, a recently created WG – a DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG is making good progress. The goal of the group is to develop a communications protocol intended to facilitate the programmatic, coordinated mitigation of such attacks via a standards-based mechanism. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries.

There are a few drafts focusing on inter-domain operation that will be discussed during the WG meeting. By blocking DDoS attacks with inter-domain cooperation, average utility of DDoS mitigation equipment will increase. This will leverage total capacity of DDoS protection systems all over the internet. With this mechanism, we can manage DDoS attacks that exceed the capacity of its own platform.

Let us hope this work will lead to effective solution of this huge problem of the Internet and facilitate necessary cooperation on the global level.

Related Working Groups at IETF 95

SIDR (Secure Inter-Domain Routing) WG
Monday, 4 April 2016, 14:00-15:30, Atlantico B
Wednesday, 6 April 2016, 14:00-16:00, Buen Ayre A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations) WG
Thursday, 7 April 2016, 16:20-17:20, Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Tuesday, 5 April 2016, 10:00-12:30, Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Friday 8 April 2016, 10:00-12:00, Atlantico B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

There’s a lot going on in Buenos Aires, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see https://dev.internetsociety.org/tag/ietf95/.

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

New Routing Security Survey Shows Incidents and their Impacts

Routing security incidents happen – for many network operators probably at least once a month, and probably close to 5% of those incidents have real (and negative) network impacts. And though overall the routing system tends to be pretty quiet, some networks have really bad days sometimes. These are some of the results from the Routing Resilience Survey Report we just released from our pilot project to analyze routing security incidents and their real-world impacts.

At the end of 2013 we launched, in partnership with BGPmon, a pilot project called the Routing Resilience Survey. As I explained in a November 2013 blog post announcing the project, the effort was focused on collecting incident data related to routing resilience from operators’ points of view. This approach allowed us not only to filter out false positives – for instance, legitimate configuration changes – but also to record the impact and severity of the incidents.

The pilot ran for a little more than six months, from November 2013 until June 2014, with 30 operators from Tier 1, Tier 2/3, cloud and content delivery networks, enterprises, and other types of ISPs from all around the world. Because we allowed the participants to also classify events related to their customers’ networks, the Survey represented 239 autonomous systems in total.

Over the course of the project, we collected more than 2000 potential routing security incidents!

Participants were asked to respond to BGPmon’s weekly summaries of potentially harmful events related to participants’ networks that the monitoring system detected. Were these legitimate incidents, and what were their impacts? Was it a monitoring system or a customer call that alerted the operator to the incident, or did it go unnoticed? These were some of the questions we asked in order to classify the events.

Full study findings are presented in the report at https://dev.internetsociety.org/resources/doc/2014/routing-resiliency-survey-report/

The results are not surprising, but they can help us understand some of the challenges to global deployment of routing security protocols. The main conclusions of the report are:

  • Incidents with real impact are rare.
  • There is a high percentage of false positives.
  • Incidents are fixed quite quickly.

More specifically, we found that the routing security problem is not perceived as critical by many network operators. It is very interesting to see the difference in impact assessment between an operator’s and an external observer’s point of view. And quite frankly, neither is probably right – the truth is most likely somewhere in between. According to the report, “while network operators are aware of the vulnerabilities of the routing system, risks associated with them are perceived as low. In such circumstances, reactive measures seem to be more appropriate and proactive protection is deployed only if it has low operational costs associated with it.”

However, relying only on reactive measures definitely does not offer sufficient protection. Many, if not most, routing incidents happen outside the operator’s control, and resolving the incident often requires help from other network operators.

And, as we have stated plenty of times, deploying simple routing resilience measures like those outlined in the “Mutually Agreed Norms for Routing Security” (MANRS) document can help your network and many networks around you. And if done collectively by network operators around the globe, it can help the entire Internet.

Please read the report and let us know what you think!

Categories
IETF

Anti-spoofing at the Edge – the SAVI WG at IETF

The anti-spoofing mechanisms first outlined in BCP38 have seen low adoption rates for two main reasons: (1) lack of a business case and (2) the fact that proposed mechanisms become more fragile and less effective the more you move away from the source of the forged packet.

It seems that the IETF Working Group on Source Address Validation Improvements (SAVI) may address both of the problems: it is based on a clearer business case and it provides IP source address validation at the maximally fine granularity of individual IP addresses and as close to the source as possible. SAVI’s objective is to prevent hosts attached to the same link from spoofing each other’s IP addresses.

Creating a business case for anti-spoofing in the global context has been challenging: preventing spoofing on internetwork interfaces does not necessarily make your own network less vulnerable to the spoofed attacks, e.g. DNS amplification attacks, it just ensures that your network is not used as a launch pad for such attacks. The situation might be different when spoofing is considered as a local problem, for instance, spoofing of an address of a neighbor computer on a local Ethernet network. In broadband access networks, spoofing may be used to gain access to services or to disrupt services to other customers. Not surprisingly, a mechanism for validating source IP addresses became mandatory in Data-Over-Cable Service Interface Specifications version 3 (DOSCIS 3.0) several years ago.

Preventing spoofing locally, as close to the host as possible is more robust and limits the scope of a possible attack. Implementing anti-spoofing in a local network segment makes possible application of more reliable and fine-grained filters, or bindings, like (IP address)-(MAC address)-(switch port), as opposed to (address range)-(router interface) in the case of traditional ingress filtering.

SAVI takes a similar approach to the DOCSIS source address verification mechanism and extends it on all kinds of network topologies and technologies, not only broadband cable networks. The proposed mechanisms are purely network based and don’t depend on supporting functionality in connected hosts.

The working group has recently published an RFC outlining the general framework and deployment considerations and is working on specifications for specific validation mechanisms. I hope the business case is convincing enough and future implementations are seamless and robust enough to facilitate wide deployment in edge networks.

Categories
Technology

Anti-Spoofing: Continuing the Dialogue

At the RIPE66 meeting in mid-May 2013, Benno Overeinder from NLNetLabs and I organized a panel called “Seven Years of Anti-Spoofing: What Happened Since the RIPE Task Force and What Still Needs to be Done.” We were lucky to get six great panelists who engaged in an interesting discussion of this issue amongst themselves and with the audience. I provided a recap in this blog post: “Can we stop IP-spoofing in the Internet?”. 

But, as it happens in such cases, the main outcome was this webcast and individual takeaways of the meeting attendees. We thought: can we do a better job for those who are interested in this issue and want to come back to it, either to understand it better, or to propose an improvement or a solution?

Several folks, some of whom participated in the panel, came together and published here their perspectives regarding IP-spoofing and anti-spoofing. On the Internet Technology Matters section of our website, you will find several anti-spoofing pieces:

  • Robert Beverly: Initial Longitudinal Analysis of IP Source Spoofing Capability on the Internet
    Robert is behind the Spoofer project, started in 2005, which measures the Internet’s susceptibility to spoofed source address IP packets. He looks at statistics collected by the project and analyzes the trends. He also describes the measurements and future plans “to promote network hygiene and continue to usefully inform not only technical anti-source spoofing efforts, but also debate and policy surrounding IP spoofing.”
  • David Freedman: Why I’m Practicing Anti-Spoofing
    David talks about what motivates him to implement anti-spoofing measures and why it is important that more in the industry show zero-tolerance to IP address spoofing. He describes what’s in his network operator’s toolkit and how he applies these tools. He also touches on what holds some of his peers back from implementing ant-spoofing. “Reflection attacks today are effective mainly because service providers are ignoring (or otherwise not employing) filtering recommendations; this acts, I feel, to the detriment of us all.”
  • Benno Overeinder: Measuring Spoofed Traffic
    How much of DDoS traffic is generated by spoofed reflection attacks? What is the frequency and the impact of such attacks? And where are the origins of such traffic. Benno looks through several security reports and analyzes statistics presented there. “Considering the trend in attacks and their impact, aggravated by the low cost to mount an attack and their untraceability, it is high time for a wider community action. Every effort can help.”

Do you want to share your views, data, or other useful information related to IP address spoofing? Do you have ideas regarding what else could be done to promote anti-spoofing? Please comment or send us an article by email.

Watch the “Anti-Spoofing: Continuing the Dialogue” page for more contributions.