Categories
Deploy360 Improving Technical Security

MANRS BCOP published

The Internet Society’s Mutually Assured Norms for Routing Security (MANRS) initiative recently published a Best Current Operational Practices (BCOP) document to provide guidance to network operators in facilitating the MANRS actions.

The MANRS initiative has been running since 6 November 2014 and aims to help network operators around the world to work together to improve the security and resilience of the global routing system through four actions that include filtering, anti-spoofing, coordination and support for global validation. It currently involves 45 organisations encompassing nearly 100 Autonomous Systems around the world, including some of the largest ISPs.

Based on the BCOP document, a set of online training modules is under currently development. These will walk students through a tutorial and provide a test at the end, with a view to this being the first step towards a MANRS certification. A partnership programme is currently being developed, and other partners are being sought who’d be interested in including it in their curricula.

If you’re interested in signing-up to MANRS, more information is available on the MANRS website.

More Information

Categories
IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 98: Internet Infrastructure Resilience

Let’s look at what’s happening in the area of Internet infrastructure resilience in the IETF and at the upcoming IETF 98 meeting. 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 is interesting and important work underway at the IETF that can help address problems in both areas.

DDoS attacks are a persistent and growing threat on the Internet. And as DDoS attacks evolve rapidly in the aspect of volume and sophistication, a more efficient cooperation between the victims and parties that can help in mitigating such attacks is required. The ability to quickly and precisely respond to a beginning attack, communicating the exact information to the mitigation service providers is crucial.

Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG busy. 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. Specifications outlining the requirements, architecture and the use cases for DOTS are maturing and will be discussed at the meeting.

Draft “Inter-organization cooperative DDoS protection mechanism” (https://datatracker.ietf.org/doc/draft-nishizuka-dots-inter-domain-mechanism) goes further than communication between a victim and a mitigation service provider. It attempts to describe possible mechanisms that implement the cooperative inter-organization DDoS protection by DOTS protocol, leveraging the capacity of the protection by sharing the resources among several organizations.

A recently chartered SIDR Operations Working Group (SIDROPS) has taken over the technology developed in the SIDR WG and is focused on 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. The working group meets for the first time and will, among other things, discuss mitigation mechanisms for route leaks.

There are still two proposals addressing the route leak problem. One is an IDR WG document, “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. Another is an independent submission, “Route Leak Detection and Filtering using Roles in Update and Open messages” (https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy). 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. An updated version of the specification allows signaling a potential leak more than one hop away.

Both proposals will be discussed at the SIDROPS as well as at the IDR WG sessions.

Another item that can certainly contribute to better resilience of an IXP infrastructure and is on the agenda of the IDR WG session is a proposal, “Making Route Servers Aware of Data Link Failures at IXPs” (https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/). When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes a means for the peers to verify connectivity amongst themselves, and a means of communicating the knowledge of the failure back to the route server.

To summarize – there is important work underway at the IETF that will hopefully lead to a more resilient and secure Internet infrastructure.

Related Working Groups at IETF 98

SIDROPS (SIDR Operations) WG
Tuesday, 28 March, 14:50-16:20, Zurich C
Agenda: https://datatracker.ietf.org/meeting/98/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/

GROW (Global Routing Operations) WG
Monday, 27 March, 17:10-18:10, Zurich G
Agenda: https://datatracker.ietf.org/meeting/98/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Friday, 31 March, 09:00-11:30, Zurich G
Agenda: https://datatracker.ietf.org/meeting/98/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Tuesday, 28 March, 16:40-18:40, Zurich G
Agenda: https://datatracker.ietf.org/meeting/98/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

There’s a lot going on in Chicago, 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 http://dev.internetsociety.org/rough-guide-ietf98.

Categories
Building Trust IETF Improving Technical Security Open Internet Standards Technology

ISOC Rough Guide to IETF 96: Internet Infrastructure Resilience

We continue to look at the work in the IETF with a wider angle – not just routing resilience, but also the resilience of the data forwarding plane – specifically to DDoS attacks. There is interesting and important work underway at IETF 96 in Berlin next week that can help address 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.

While RPKI and BGPsec are aimed at making routing more secure, these infrastructures introduce their own risks. One of the concerns, for example, was the amplifying impact mistakes of “over-claiming” at the higher levels of RPKI hierarchy (say the RIR level) have on the INR holders. Another concern was related to potential abuse of RPKI to reach certain policy and law enforcement objectives. To answer the question about what operational impact various adverse actions and mistakes may have a draft-ietf-sidr-adverse-actions-00 enumerates possible actions and analyses four operational scenarios. The document intends to provide a basis for the design of future RPKI security mechanisms that seek to address the concerns associated with such actions. The draft was discussed prior to the adoption it as a WG document and the authors have requested a last call already on the -00 version.

By the way, after some impasse, the proposal ” RPKI Validation Reconsidered“, which tries to address the issue of “over-claiming” by proposing changes to the PKI validation process, is making good progress and has a good chance of reaching consensus.

A draft “ Signaling RPKI Validation Results from a Route-Server to Peers”, which proposes how RPKI can be effectively used in an IXP environment, enhancing the functionality of a route server has been adopted as a WG document and will progress.

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

BGPsec is maturing as well. The protocol specification has been submitted to the IESG for publication. BGPsec Operational Considerations attempts to collect and present the most critical and universal operational considerations. As the document states, it is expected to evolve as BGPsec is formalized and initially deployed. This document is submitted for publication as a Best Current Practice.

In the area of route leaks there are 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 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.

The idea of “negotiating” the relationships through the BGP Open message is an interesting one. It can certainly help minimize unilateral mistakes. It has some limitations, since routing policy is not always defined on a per peer (or, per session) basis, but sometimes with a greater, per prefix granularity.

Another difference is that the first draft suggests per hop (i.e. every element of the AS_PATH may have this flag set), while the second one – per update tagging of routes. The latter does not allow detection of leaks in certain situations, on lateral peering leaks, for instance.

I hope good ideas from both drafts will be integrated into a single solution.

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 is now adopted by the WG and is in its third revision ( https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing). There is still quite some discussion on additional attack vectors this proposal may introduce due to the well-known and transitive nature of the attribute.

Also in the same problem area a recently created WG – a DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) 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 architecture of DOTS systems is shaping up. The draft “ Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture” has been adopted as a WG document. In this architecture, DOTS clients and servers communicate using the DOTS signaling. As a result of signals from a DOTS client, the DOTS server may modify the forwarding path of traffic destined for the attack target(s), for example by diverting traffic to a mitigator or pool of mitigators, where policy may be applied to distinguish and discard attack traffic. Any such policy is deployment-specific.

In addition to the WG session, there is plan to organize two design team meetings. One on Joint Use Case, Requirements and Architecture, and another with the implementers.

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

Related Working Groups at IETF 96

SIDR (Secure Inter-Domain Routing) WG
Thursday, 21 July, 10AM-12:30PM, Bellevue
Agenda: https://datatracker.ietf.org/meeting/96/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations) WG
Friday, 22 July, 12:20-1:20PM, Tiergarten
Agenda: https://datatracker.ietf.org/meeting/96/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Tuesday, 19 July, 10AM-12:30PM, Schoeneberg
Agenda: https://datatracker.ietf.org/meeting/96/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Tuesday, 19 July, 4:20PM-6:20PM, Bellevue
Agenda: https://datatracker.ietf.org/meeting/96/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

There’s a lot going on in Berlin, 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 http://dev.internetsociety.org/rough-guide-ietf96.

Categories
IETF Open Internet Standards Technology

Rough Guide to IETF 93: Internet Scalability & Performance

In this post I’ll shine a light on some of the Internet Engineering Task Force (IETF) and Internet Research Task Force (IRTF) efforts underway to explore and address more sophisticated ways to use available bandwidth, improve Internet performance, and otherwise efficiently get Internet content to where it needs to be. These groups will all be meeting as part of the IETF 93 meeting in Prague next week.

On the Sunday of IETF meetings, the Education team organises various tutorial sessions, and IETF 93 will include an ‘Introduction to Performance Measurements and Monitoring’ that will provide an overview of IETF work on the topic.

Internet performance is to a large extent governed by the way transport protocols operate, and the tcpm WG will be meeting to discuss proposed new functionality to improve and enhance the working of TCP, the main transport protocol used on the Internet today. One of the advances developed in the tcpm WG, TCP Fast Open, was included in recent announcements by Apple that should provide a big boost to networking performance in their products.

Multipath TCP is another IETF protocol now seeing more widespread deployment in operational networks, and the meeting in Prague will include updates on implementation experiences and new work to use and extend Multipath TCP.

Getting new code deployed in networking stacks is often hard because of uncertainties about how existing hardware and software on the network will react. After a successful Bar BoF meeting in Dallas, the proposed How Ossified is the Protocol Stack? (hops) research group will meet in Prague to discuss measurement techniques and data sources that could help make better engineering decisions to work around some of the ossification in the protocol stack. The hope is that techniques similar to ‘happy eyeballs’ for IPv6 can be used to support deployment of new transport features and protocols.

Packet networks give rise to transient congestion by design and several groups are meeting to discuss different aspects of congestion control and avoidance (aqm and rmcat). For regulators, being able to monitor the performance of networks, and the extent to which congestion or other factors are impacting consumers’ experience of the network is very important. The lmap working group is meeting in Prague to advance their important work on standardizing a large-scale broadband performance measurement infrastructure.

Related Working Groups and BoFs at IETF 93

iccrg (Internet Congestion Control Research Group)
Wednesday, 22 July 2015, 1550-1720, Congress Hall I
Agenda: https://datatracker.ietf.org/meeting/93/agenda/iccrg/
Documents: http://tools.ietf.org/group/irtf/trac/wiki/ICCRG
Charter: https://irtf.org/iccrg

mptcp (Multipath TCP) WG
Tuesday, 21 July 2015, 1300-1500, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/93/agenda/mptcp/
Documents: https://datatracker.ietf.org/wg/mptcp/
Charter: http://datatracker.ietf.org/wg/mptcp/charter/

tcpm (TCP Maintenance and Minor Extensions) WG
Wednesday, 22 July 2015, 1300-1530, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/93/agenda/tcpm/
Documents: https://datatracker.ietf.org/wg/tcpm/
Charter: http://datatracker.ietf.org/wg/tcpm/charter/

hopsrg (Proposed How Ossified is the Protocol Stack?) RG
Friday, 24 July 2015, 0900-1130, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/93/agenda/hopsrg/
Charter: https://datatracker.ietf.org/doc/charter-irtf-hopsrg/

aqm (Active Queue Management and Packet Scheduling) WG
Monday, 20 July 2015, 1850–1950, Congress Hall I
Agenda: https://datatracker.ietf.org/meeting/93/agenda/aqm/
Documents: https://datatracker.ietf.org/wg/aqm/
Charter: http://datatracker.ietf.org/wg/aqm/charter/

lmap (Large-Scale Measurement of Broadband Performance) WG
Monday, 20 July 2015, 0900-1130, Athens/Barcelona
Agenda: https://datatracker.ietf.org/meeting/93/agenda/lmap/
Documents: https://datatracker.ietf.org/wg/lmap/
Charter: http://datatracker.ietf.org/wg/lmap/charter/

rmcat (RTP Media Congestion Avoidance Techniques) WG
Monday, 20 July 2015, 0900-1130, Congress Hall II
Agenda: https://datatracker.ietf.org/meeting/93/agenda/rmcat/
Documents: https://datatracker.ietf.org/wg/rmcat/
Charter: http://datatracker.ietf.org/wg/rmcat/charter/

Follow Us

There’s a lot going on in Prague, 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 http://dev.internetsociety.org/rough-guide-ietf93.

Categories
IETF Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Open Internet Standards Technology

ISOC Rough Guide to IETF 91: Routing Resilience & Security

Improving the overall security, efficiency, and resilience of the Internet’s global routing system will be a hot topic at next week’s IETF 91 meeting in Honolulu. In this post, I’ll share a few of the highlights in some of the IETF Working Groups.

De-aggregation

As the Internet grows, so grows the routing table, although it doesn’t need to grow as fast. Almost half of the IPv4 routing table (45% for IPv4 and 24% for IPv6, to be precise, see http://bgp.potaroo.net/index-cidr.html) contains redundant information. More specific prefixes are announced along with the covering ones, which is called de-aggregation.

Apart from putting extra burden on routers, this growth may case also instability. See, for instance, some observations of what happened when the IPv4 routing table hit the 512K boundary (http://www.bgpmon.net/what-caused-todays-internet-hiccup/, http://www.renesys.com/2014/08/internet-512k-global-routes/).

Some of the causes of de-aggregation are traffic engineering, security concerns (announcing more specifics to win over potentially hijacked prefixes), or simply configuration mistakes. Is there a technical solution to this problem?

Some people think so. One of the proposals “Filtering of Overlapping Routes” published two years ago is aimed at filtering the overlapping routes (longer prefixes) when the rest of the information is the same for the covering prefix. The proposal was discussed in the GROW WG, but it seems it has not gotten enough traction and was not adopted as a WG item.

And while IPv4 may be a lost cause, shouldn’t we follow the same path with IPv6? Ilijtch van Beijnum observes some of the de-aggregation problems in IPv6 that happen when one organization announces different prefixes to different ISPs from its different units that may be geographically distributed. His draft “Controlled IPv6 de-aggregation by large organizations” proposes some solutions.

Route Leaks

Route leaks, a violation of the so-called valley-free routing principle, can undermine security of the routing system by giving an adversary an ability to re-direct traffic targeted to specific destinations. Internet history knows many cases when route leaks caused serious disruptions (see, for instance Geoff Huston’s “Leaking Routes“, or Jim Cowie’s “China’s 18-Minute Mystery“).

This is aggravated by the fact that these anomalies are immune to the solutions being developed in the SIDR WG, i.e. RPKI and BGPSEC (see http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help).

Unfortunately we are still lacking a common definition of the term, making discussion of threats and possible solutions difficult. A new draft “Problem Definition and Classification of BGP Route Leaks” makes such an attempt and will be discussed in the GROW WG.

A companion draft “Methods for Detection and Mitigation of BGP Route Leaks” will be discussed in the IDR and SIDR WGs.

SIDR

Since the previous IETF, a draft “RPKI Validation Reconsidered” is being discussed in the SIDR WG. The draft reviews the certificate validation procedure specified in RFC6487 and highlights aspects of potentially acute operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement.

To put it simpler, the idea is that if only a subset of the resources specified in the certificate extensions cannot be validated, it doesn’t invalidate the rest of them. From an operational point of view this should increase robustness of the overall system, but it also fundamentally changes the PKI validation process.

In general, as the IETF-developed building blocks are becoming parts of the deployed solutions there is more attention to risks, resilience and robustness of the overall system. Not surprisingly the 2014 ANRP award was given to Sharon Goldberg and her colleagues for the paper “On the Risk of Misbehaving RPKI Authorities“. The paper contains a proposal on how to protect against “Dutch Police Attack” where the RPKI is used for IP prefix takedowns. It is the suspenders proposal that featured in SIDR and will be discussed at the WG session. Depending on the feedback, we may see an I-D.

The development of the BGPSEC protocol continues. And at the upcoming IETF, SIDR and IDR WGs will hold a joint session for the purpose of discussing the BGPSEC protocol.

MANRS

Of course the utility of the developed building blocks, solutions, and practices is only materialized when they are deployed in operators’ networks. And when we talk about the security and resilience of the global routing system, the deployment should match the global scale of it.

This is where technology meets with social and economic facets of the solution. This is where collaboration, shared responsibility, and individual commitment are essential.

Throughout the history of the Internet, collaboration among participants and shared responsibility for its smooth operation have been two of the pillars supporting the Internet’s tremendous growth and success, as well as its security and resilience. And today we, as a community made another important step in this direction, when leading network operators around the world announced that they have implemented a package of recommended measures that help improve the security and resilience of the global Internet. This “package” is documented in the “Mutually Agreed Norms for Routing Security” (MANRS) and it is live on the Internet: https://www.manrs.org). But more about this in another blog post!

Related Working Groups at IETF 91

SIDR (Secure Inter-Domain Routing) WG
Monday, 10 November 2014, 0900-1130 HST, Coral 1
Agenda: https://datatracker.ietf.org/meeting/91/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations) WG
Monday, 10 November 2014, 1730-1830 HST, Coral 4
Agenda: https://datatracker.ietf.org/meeting/91/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Thursday, 13 November 2014, 1300-1500 HST, Kahili
Friday, 14 November 2014, 0900-1130 HST, Coral 2
Agenda: https://datatracker.ietf.org/meeting/91/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

Follow Us

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. 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 http://dev.internetsociety.org/rough-guide-ietf91.

Categories
Domain Name System Security Extensions (DNSSEC) Improving Technical Security Open Internet Standards Technology

Creating a Secure and Resilient Internet: Community Collaboration Required

“The Internet is open, interconnected and interdependent. It’s an ecosystem based on collaboration and shared responsibility.”

These are the opening remarks of our new infographic called “Collaboration for a resilient and secure Internet.” In it, we’ve tried to convey the idea that when it comes to Internet security and resilience, the traditional approach of just protecting our own assets is not good enough – the Internet demands a sense of collective stewardship and shared responsibility to be truly secure and truly resilient to attack.

When performing a risk assessment, do you also look at risks your network presents to the Internet ecosystem – so-called “outward” risks? How much do you care if your network passes traffic with spoofed IP addresses? How many of your DNS resolvers, NTP and SNMP servers are ready to answer queries from anyone in the world? Do you scrutinize routing announcements you are getting from your customers and peers?

There are several technologies and best practices available to mitigate these risks. Implementing them has costs, but through collective action we are creating a safer global network – a benefit that is hard to overestimate.

Please check out the infographic below and let us know what you think. What else can we do to encourage *every* network operator to deploy these technologies and best practices and help keep the Internet secure?