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

BGPSec – A reality now

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Deploy360 Events IETF Improving Technical Security IPv6

Deploy360@IETF 96, Day 4: SIDR & IPv6

berlinThroughout this week at IETF 96 in Berlin we’re bringing you these daily blog posts that highlight what Deploy360 is focused on during that day. And Thursday is an important day as two of our key technologies will be covered in the Secure Inter-Domain Routing (SIDR) and IPv6 Operations (v6ops) Working Groups.

NOTE: If you are unable to attend IETF 96 in person, there are multiple ways to participate remotely.

SIDR holds its session in the morning and will focus on RPKI which adds an authentication framework to BGP and forms an important component of BGPsec for improving trust in the global routing infrastructure.

While RPKI and BGPsec aim to make routing more secure, one of the concerns is mistakes related to “over-claiming” of resources at higher levels of RPKI hierarchy. The draft draft-ietf-sidr-rpki-validation-reconsidered-03 tries to address this by proposing changes to the validation process, whilst the draft draft-lee-sidr-rpki-deployment-02 outlines and provides an analysis of some of the problems that have appeared during the process of RPKI deployment, along with suggesting some solutions to address or mitigate these.

Another draft draft-ietf-sidr-delta-protocol-03 introduces a mechanism whereby Relying Parties can query repositories for incremental updates to certificates, Certificate Revocation Lists (CRLs) and RPKI signed objects. The aim is to provide more efficient synchronization, whilst draft draft-madi-sidr-rp-00 outlines requirements for these Relying Parties.

Also of interest should be the presentation of Tim Bruijnzeels on RPKI and BGP statistics, and of Ruediger Volk on RPKI findings and observations.

During the afternoon, V6OPS will hold its session and will be discussing three drafts. The draft draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 proposes to allow hosts to be assigned a unique IPv6 prefix (typically a /64) in circumstances where a network is shared and a common prefix may not be desirable (e.g. in community wireless applications). This would provide each subscriber with more flexibility to utilise IPv6, whilst ensuring traffic can be directed to a default wireless LAN gateway.

The draft draft-anderson-v6ops-v4v6-xlat-prefix-01 is more straightforward in that it proposes to reserve the IPv6 prefix 64::/16 for use with IPv4/IPv6 translation mechanisms. This would extend the IPv6 prefix 64:ff9b::/96 as specified in RFC 6052.

Last but not least is the draft draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 that attempts to define a solution for connecting  enterprise sites to multiple ISPs using provider-assigned addresses avoiding the use of Network Address Translation (NAT).

For more background, please read the Rough Guide to IETF 96 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

Improving Technical Security Open Internet Standards Technology

Hacking on BGP for Fun and Profit

Of all the many protocols that run over the Internet some are more fundamental than others. Border Gateway Protocol (BGP) is one of the more fundamental ones given that it provides the means for networks to announce their connectivity to each other. The Internet is a network of networks and BGP provides the glue that stitches the (approximately) fifty thousand networks that collectively deliver what we think of as the Internet together.

As we mentioned late last year, the Center for Applied Internet Data Analysis (CAIDA) hosted the inaugural BGP Hackathon at their premises in the University of California San Diego Supercomputer Center this weekend. The two-day event brought together around 90 researchers, practitioners, and students from around the world to develop tools to model, measure, and monitor the routing infrastructure of the Internet. Of the 90 attendees, 50 were competing in teams and 30 of those were graduate students. 33 travel grants were awarded and in addition to the 50 competing participants, there were 25 non-competing domain experts.

The event began with some introductory remarks and level-setting for the participants before the relative anarchy of team formation. Various participants introduced themselves, their expertise, and interest in working on specific challenges. Despite the freeform nature of the proceedings, the group quickly settled down to a manageable number of teams working on a diverse set of challenges and hacking commenced.

Participating teams worked on a variety of challenges, such as:

  • Improving BGP analysis and measurement tools
  • Improving network management tools with OpenConfig
  • Security, including longitudinal study of route validation with RPKI, automated mis-origination detection, and automated countermeasures
  • Visualisation of BGP data including realtime analysis
  • BGP dynamics including interactions between the control plane and data plane, anycast routing, and failover
  • Enhancing BGP daemons with new functionality
  • More realtime functionality for existing tools, e.g. CAIDA ASRank

The teams had an array of tools and data sources available to them during the event, and many of the original developers of these resources were on hand to provide expert guidance to the challenge participants. In addition, San Diego Supercomputer Center made available their COMET supercomputer for teams to use to speed up analysis tasks during their development work.

The Internet Society was one of the sponsors of the hackathon event and served on the Jury that selected four prize-winning teams from the various groups that participated in the event. The winning teams were (in no particular order):

  • Shane Alcock (University of Waikato, NZ) for developing advanced filtering mechanisms for the BGPStream software framework. Shane worked on his own and the results of his efforts will be widely used by the community to select which data a BGPStream application, script, or command-line tool must process.
  • Ricardo Schmidt (University of Twente, NL), Wouter de Vries (University of Twente, NL), Azzam Alsudais (CU Boulder, US), Roya Ensafi (Princeton University, US), and Nick Wolff (OARnet, US) for their work using the PEERING testbed and other tools to observe the impact on control plane and data plane when adding or removing anycast instances. Many content and infrastructure services on the Internet make use of anycast routing to improve service availability and performance. Understanding the dynamics of anycast routing better is an important contribution.
  • Ruwaifa Anwar (Stony Brook University, New York, US), Danilo Cicalese (Telecom ParisTech, FR), Nicolas Vivet (FNISA, FR), Kaname Nishizuka (NTT Communications, JP), Danilo Giordano (Politecnico di Torino, IT), Charles Brock (ICASA/NMT, US), and Bruno Machado (Universidade Federal de Minas Gerias, BR) for their work to automate detection of BGP anomalies. Using data feeds from RIPE RIS and BGPStream, potential anomalies were detected and then correlated with external data to minimise the incidence of false positives.
  • Massimo Candela (RIPE NCC, NL), Maite Gonzalez (NICLabs, Universidad de Chile, CL), Saif Hasan (Facebook, US) and Francesco Benedetto (Roma Tre University, IT) for their work to provide a real-time BGP monitoring service using BGPlay and output from BGPStream.

Selecting these winners wasn’t easy as all teams produced very exciting and interesting results especially when considering that many of the collaborators were new faces and the tools were new in many cases as well. The utility of USC’s PEERING testbed was greatly enhanced during the weekend and many of the challenge teams made productive use of the facility. The long-term goal of the testbed is to enable on-demand, safe, and controlled access to the Internet routing ecosystem for researchers and educators and USC plan to continue making further enhancements now that it has proved to be such a valuable resource. Other platforms made available to participants during the hackathon, e.g. BGPStream and BGPMon, also saw significant improvements during the weeks preceding (and during) the hackathon. 

In conclusion, this event was a great example of how careful planning and detailed organisation can yield excellent results. The participants all learned a great deal during the two days and came away with a much better understanding of the breadth of BGP-related research, the tools and data sources available to them, and most importantly a new set of colleagues and mentors to help them carry on their work. Here’s to the next one!

P.S. If you are interested in BGP and routing security in particular, you may also want to check out the Mutually Agreed Norms for Routing Security (MANRS) initiative.

Photo Credit: iStock
Deploy360 IETF IPv6 Securing Border Gateway Protocol (BGP)

Deploy360@IETF91, Day 5: IDR (Securing BGP), IPv6 and heading on to ION Tokyo

Minions at IETF91As the final day of IETF 91 opens there are only a few sessions left on the long IETF 91 agenda.  For us at Deploy360, our focus will mainly be on the Inter-Domain Routing (IDR) and IPv6 Maintenance (6MAN) meetings happening this morning.  Read on for more information…

NOTE: If you are not in Honolulu but would like to follow along, please view the remote participation page for ways you can listen in and participate.  In particular, at this IETF meeting all the sessions will have Meetecho coverage so you can listen, watch and chat through that web interface.  All agenda times are in HST, which is UTC-10 (and five hours earlier than US Eastern time for those in the US). I suggest using the “tools-style” agenda as it has easy links to the chat room, Meetecho and other documents for each session.

In the 9:00-11:30 HST block today the Inter-Domain Routing (IDR) is meeting in Coral 2 and it will be, as I understand it, a joint meeting with the SIDR working group that will focus on the proposed BGPSEC protocol.  The agenda is:

  • BGPSEC background/goals/context, Sandy Murphy
  • BGPSEC protocol walk-through, Matt Lepinski
  • BGPSEC protocol time, space analysis, K. Sriram
  • BGPSEC issues for implementors, John Scudder

It should be an interesting session that ties in well with our Securing BGP topic area.

Simultaneously over in the large Coral 3 room, the IPv6 Maintenance Working Group (6MAN) has a very full agenda of proposals to improve how IPv6 works.  For IPv6 fans such as me, this looks to be a great set of discussions!

The final block of sessions from 11:50-13:20 HST does not have any meetings directly tied to the topics we cover here, but I’m intrigued by a document in the Internet Area Open Meeting about tunnels in the Internet’s architecture that will probably be a good session to listen to.

And with that… our time here at IETF 91 in Honolulu will draw to a close.  We’ll have the Internet Society Advisory Council meeting this afternoon… and then we are all heading to Tokyo to present about IPv6, DNSSEC, BGP, BCOP and more at our ION Tokyo event on Monday!  (And you can watch ION Tokyo live via a webcast.)

Thanks for following us this week and to all those who greeted us at IETF 91!  See you next time in Dallas!

P.S. Today’s photo is from Jared Mauch and used with his permission.  NBC Universal, who sponsored the IETF 91 Welcome Reception, gave a stuffed “minion” out to anyone who wanted to have one.  Give some engineers something fun like this and… well… photos are bound to happen!  Jared had a good bit of fun coming up with some photos – you can see his “Minions” photo stream – and the minons were present in many other photos, such as this one I took.

See also:

Relevant Working Groups

We would suggest you use the “tools-style” agenda to find links to easily participate remotely in each of these sessions.

IDR (Inter-Domain Routing Working Group) WG
Friday, 14 November 2014, 0900-1130 HST, Coral 2

6MAN (IPv6 Maintenance) WG
Friday, 14 November 9am-1130am, Coral 3

For more background on what is happening at IETF 91, please see our “Rough Guide to IETF 91″ posts on the ITM blog:

If you are here at IETF 91 in Honolulu, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Deploy360 Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT)

Deploy360@IETF91, Day 2: UTA, DPRIVE, BGP in ANRP, 6LO and IOT, DNSOP

IETF 91 mic lineFor us at Deploy360, Day 2 of IETF 91 brings a heavy focus on DNSSEC and DNS security in general with both DNSOP and DPRIVE meeting. Today also brings one of the key working groups (UTA) related to our “TLS in Applications” topic area.  There is a key WG meeting related to using  IPv6 in “resource-constrained” environments such as the “Internet of Things” (IoT) … and a presentation in the Internet Research Task Force (IRTF) about BGP security and the RPKI.

These are, of course, only a very small fraction of the many different working groups meeting at IETF 91 today – but these are the ones that line up with the topics we write about here at Deploy360.

Read on for more information…

NOTE: If you are not in Honolulu but would like to follow along, please view the remote participation page for ways you can listen in and participate.  In particular, at this IETF meeting all the sessions will have Meetecho coverage so you can listen, watch and chat through that web interface.  All agenda times are in HST, which is UTC-10 (and five hours earlier than US Eastern time for those in the US). I suggest using the “tools-style” agenda as it has easy links to the chat room, Meetecho and other documents for each session.

In the morning 9:00-11:30 block we once again will be splitting ourselves across multiple working groups.  In Coral 2 will be the “Using TLS in Applications” (UTA) working group looking at how to increase the usage of TLS across applications.  The UTA WG is a key part of the overall work of the IETF in strengthening the Internet against pervasive monitoring and should be quite a well-attended session.  The UTA agenda includes multiple drafts related to TLS and email, a discussion of a proposal around “token binding” and what should be an involved discussion about the TLS “fallback dance”, i.e. what should happen when a TLS connection cannot be made at the requested level of security?

On the topic of UTA, I’ll note that one of the groups main documents, draft-ietf-uta-tls-bcp, a best practice document on “Recommendations for Secure Use of TLS and DTLS“, has a new version out that incorporates all of the feedback received to date.  This document should soon be at the point where it will enter the publication queue.

Meanwhile, over in the Kahili room the 6LO WG will be talking about using IPv6 in “resource-constrained” and low power environments. The work here is important for sensor/device networks and other similar “Internet of Things” (IoT) implementations.   Among the 6LO agenda items are a discussion of using IPv6 in near field communications (NFC) and what should be quite an interesting discussion around the challenges of using different types of privacy-related IPv6 addresses in a constrained environment.

Simultaneously over in Coral 4 will be the open meeting of the Internet Research Task Force (IRTF) and of particular interest will be the presentation by one of the winners of the Applied Networking Research Prize (ANRP) that is focused on BGP security and the Resource Public Key Infrastructure (RPKI).  As the IRTF open meeting agenda lists the abstract:

The RPKI (RFC 6480) is a new security infrastructure that relies on trusted authorities to prevent attacks on interdomain routing. The standard threat model for the RPKI supposes that authorities are trusted and routing is under attack. This talk discusses risks that arise when this threat model is flipped: when RPKI authorities are faulty, misconfigured, compromised, or compelled (e.g. by governments) to take certain actions. We also survey mechanisms that can increase transparency when RPKI authorities misbehave.

The slides for the presentation are online and look quite intriguing!

After that we’ll be spending our lunch time at the “ISOC@IETF” briefing panel that is focused this time on the topic of “Is Identity an Internet Building Block?”  While not directly related to our work here at Deploy360 we’re quite interested in the topic.  I will also be directly involved as I’ll be producing the live video stream / webcast of the event.  You can join in and watch directly starting at 11:45 am HST (UTC-10). It should be an excellent panel discussion!

As I described in my Rough Guide post about DNSSEC, the 13:00-15:00 block brings the first meeting of the new DPRIVE working group that is chartered to develop “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.”  The DPRIVE agenda shows the various documents under discussion – there are some very passionate views on very different perspectives… expect this session to have some vigorous discussion!

In the last 15:20-17:20 meeting block of the day we’ll focus on the DNS Operations (DNSOP) Working Group where the major DNSSEC-related document under discussion will be Jason Livingood’s draft-livingood-dnsop-negative-trust-anchors that has generated a substantial bit of discussion on the dnsop mailing list.  The DNSOP agenda contains a number of other topics of interest, including a couple added since the time I wrote about DNS for the Rough Guide.  The discussion about root servers running on loopback addresses should be interesting… and Brian Dickson (now employed by Twitter instead of Verisign) is bringing some intriguing new ideas about a DNS gateway using JSON and HTTP.

After all of that, they’ll let us out of the large windowless rooms (granted, in the dark of evening) for the week’s Social event that will apparently be a Hawaiian Luau.  After all the time inside it will be a pleasure to end the day in casual conversations outside. Please do look to find us and say hello… and if you are not here in Honolulu, please do join in remotely and help us make the Internet work better!

See also:

Relevant Working Groups

We would suggest you use the “tools-style” agenda to find links to easily participate remotely in each of these sessions.

UTA (Using TLS in Applications) WG
Tuesday, 11 Nov 2014, 900-1130, Coral 2

6LO (IPv6 over Networks of Resource-constrained Nodes) WG
Tuesday, 11 Nov 2014, 900-1130, Kahili

IRTF (Internet Research Task Force) Open Meeting
Tuesday, 11 Nov 2014, 900-1130, Coral 4

DPRIVE (DNS PRIVate Exchange) WG
Tuesday, 11 November 2014, 1300-1500 HST, Coral 5

DNSOP (DNS Operations) WG
Tuesday, 11 November 2014, 1520-1720 HST, Coral 4

For more background on what is happening at IETF 91, please see our “Rough Guide to IETF 91″ posts on the ITM blog:

If you are here at IETF 91 in Honolulu, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Deploy360 Improving Technical Security Securing Border Gateway Protocol (BGP)

BGPmon: Using BGP Data To Fight Spam

BGPmon logoCan we use BGP data to find email spammers? And could securing BGP provide a mechanism to help reduce spam?

In a fascinating article on BGPmon’s site, Andree Toonk explores how they found that “IP squatting” is used by spammers.  Essentially the attack seems to work like this:

  1. The spammers identify a block of IP addresses (IPv4) that are not currently being used on the actual Internet.
  2. The spammers send out BGP announcements routing that block of IP addresses to their servers.
  3. The spammers send out their spam email messages.
  4. When done (or when the IP address block is blocked by anti-spam tools), the spammers stop announcing the BGP routes for those IP address blocks.

They then can move on to announcing other IP address blocks to send more spam.

The article provides a very compelling and very readable description of two case studies where they found this to happen. In one case the spammers also used an Internet Route Registry (IRR) to attempt to give their BGP route announcement more legitimacy.

The BGPmon article doesn’t get into solutions… but preventing these kind of attacks is precisely why we set up the Securing BGP topic area of this site.

A general area of “source address validation” is critical here – the idea being to have some way to know that the router announcing the BGP routes has the actual authority to do so. New tools such as RPKI are emerging that let us securely validate the origin of route announcements to prevent spammers from performing the attacks like this.  With such tools a router would reject BGP announcements that came from the spammers’ systems because the spammers would not be able to securely assert that they had the right to announce those IP address blocks.  The challenge, of course, is to get more routers start signing route announcements – and more routers start validating route announcements.  (Read about how Jan set up RPKI for his lab.)  There are other tools and methods being explored, too.  The point is to not allow “spoofed” IP address blocks to get into the global routing tables.

This idea of securing BGP route announcements is also part of the “Routing Resilience Manifesto” that continues to be developed as (voluntary) guidelines for network operators.

If we are collectively able to implement some of these mechanisms for securing BGP we can potentially make a significant reduction in the ability of spammers to send their email – and make the Internet more secure and working better in the process.  Please do check out our Securing BPG section and consider what you can do in your network today!

Deploy360 Improving Technical Security Securing Border Gateway Protocol (BGP) To archive Transport Layer Security (TLS)

BGP Hijacker Steals Bitcoins

Securing BGPResearchers at Dell’s Secureworks have uncovered multiple BGP incidents used to steal bitcoins. According to Secureworks, the attacker used a compromised administrator account at a yet undisclosed Canadian ISP.

With this account they were able to then inject BGP routes which redirected traffic from machines mining Bitcoins to the attacker’s compromised host. Secureworks estimates that at least $83,000 worth of Bitcoins, Dogecoins, HoboNickels, and Worldcoins were stolen over a period of 4 months.

Details such as the identity of the Canadian ISP or which routes were injected are not included in their report. However, there are two obvious technologies that would have prevented this attack. The first, and most obvious, is Border Gateway Protocol(BGP) security. Something like BGP Resource Public Key Infrastructure (RPKI) would have prevented the receiving BGP peer from accepting bogus routes. The second is Transport Layer Security(TLS) connections between the hosts controlling the *coin miners, and the miners themselves.

If either of these technologies had been deployed in this instance the attack would have been mitigated. The easier of the two is TLS, which only requires the two end-points to start encyrpting their peer-to-peer communications, and does not require anything of the intermediary ISPs. Had the miners been using TLS in this instance, the attacker would not have been able to steal Bitcoins. Instead merely interrupting service for the duration of the hijacking attempt.

The report also contains numerous neat graphics exaplaining how a BGP Man in the Middle(MITM) attack works. They unfortunately use routable IPs in their examples, but the graphics still convey the idea quite nicely.


For more information about TLS, and developing secure applications, check out our page on TLS for Applications. Or visit the IETF’s Using TLS in Applications (UTA) working group.

For more information about Securing BGP, and Secure Inter-Domain routing(SIDR), check out our page on Securing BGP. Or visit the IETF’s Secure Inter-Domain Routing(SIDR) working group.

Deploy360 Domain Name System Security Extensions (DNSSEC) IETF

Deploy360@IETF90, Day 5: HOMENET, SIDR, TRANS and GROW… and then we're done!

IETF LogoYou might think the final day of IETF 90 might be a bit quieter for us… but in fact the morning session from 9:00-11:30 EDT has three sessions happening simultaneously that are related to the work we do (HOMENET, SIDR and TRANS) – and in my personal case I want to be in two separate places at the same time!  (Which I will be attempting to do via monitoring Jabber chat rooms.)   The day will actually start at 8:00am with an informal breakfast meeting of some of the folks subscribe to the DNSSEC coordination mailing list.  After that we’ll be heading into the morning session block where we’ll be choosing between the three conflicting sessions.

One of those three sessions is HOMENET, which Chris described in his Rough Guide post about IPv6:

(HOMENET) is chartered to address the challenges in the evolving networking technology within and among relatively small “residential home” networks. This work is not necessarily dependent on a specific version of IP but the thrust of all discussions within the WG is how the IPv6 protocol suite can better serve these often overlooked networks out at the consumer edge of the Internet. 

The HOMENET agenda is filled with IPv6-related drafts and discussion points… BUT… there is also a DNSSEC angle that I described in my own Rough Guide post:

the HOMENET Working Group has on its agenda two documents from Daniel Migault that that look at two different aspects of DNSSEC interaction with customer-premise equipment (CPE).  The first draft outlines an architecture in which a CPE device could manage some of its naming services and then outsource other naming services, such as DNSSEC management, to external services.  The second draft proposes new DHCP optionsthat would provide a means to update the trust anchors used in DNSSEC and also provide a way to update the time of a CPE device. These are both definitely important work as we need CPE devices to provide solid DNSSEC support if we are to get DNSSEC validation happening everywhere.

The challenge for me is that one floor down in the hotel the TRANS working group will also be talking about DNSSEC.  As I said in the Rough Guide post:

 the TRANS Working Group focused on “Certificate Transparency” (CT) will be having a discussion about whether there is a role for CT to play in logging DNSSEC information. There is not a draft associated with this idea but there was a lengthy discussion in the trans mailing list that began with a message from Nico Williams and continued on into great detail. My understanding is that the discussion will be mainly about what, if any, role CT might play with DNSSEC and DANE. Given some of the passions involved with this whole topic I expect there to be a great amount of discussion.

Meanwhile, in a room nearby to TRANS, the Secure Inter-Domain Routing (SIDR) working group that focuses on securing BGP will be meeting.  As our colleague Andrei Robachevsky wrote in his Rough Guide post about routing resiliency, there is a great amount of work happening in this group this week.  Of particular interest may be a discussion around “RPKI Revisited” led by Geoff Huston about the Resource Public Key Infrastructure (RPKI). As Andrei writes:

Perhaps a bigger change that is being discussed is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries described by the draft “RPKI Validation Reconsidered”. The problem in a nutshell is that in the current model, specified by RFC 6487, a certificate is considered invalid if a proper validation path cannot be built for all resources specified by that certificate. But in operational reality such a situation can occur, for instance, with the resource transfer, when “shrinkage” of the parent certificate will immediately invalidate the whole branch beneath, unless all subordinate certificates are also re-issued. If such a situation happens high in the hierarchy, say at the RIR level, the impact can be pretty severe. The draft also describes alternative approaches, although the focus of the discussion now is on the problem.

After those three sessions in the first meeting block, the second meeting block really has for us only the Global Routing Operations (GROW) Working Group.  The GROW agenda covers a number of routing security topics, one of which, as Andrei writes, deals with the issue of route leaks:

One of the items, which originally emerged in the SIDR WG and has now also been discussed in the GROW WG, is so-called “route-leaks”. Simply speaking, this describes a violation of a “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer. This introduces the potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see

After that, our team will be attending the regular meeting of the Internet Society Advisory Council and then will be starting the process of heading home!   As you can tell from our posts, it’s been a VERY busy – but successful – week!

If you’d like to join the HOMENET, SIDR or GROW sessions (or any of the others) remotely to hear the discussion you can follow the instructions on the IETF 90 Remote Participation page or use the “tools-style” agenda page that provides easy links to the audio stream, jabber chat room documents and more for each of the sessions.

The information about the relevant working groups today is:

HOMENET (Home Networking) WG
(Friday, July 25, 2014, 0900-1130 EDT, Canadian)

TRANS (Public Notary Transparency) WG
(Friday, July 25, 2014, 0900-1130 EDT, Manitoba)

SIDR (Secure Inter-Domain Routing) WG
(Friday, 25 July, 0900-1130 EDT, Territories Room)

GROW (Global Routing Operations) WG
(Friday, 25 July, 1150-1320 EDT, Ontario Room)

For more background on what is happening at IETF 90, please see our “Rough Guide to IETF 90” posts on the ITM blog:

If you are here at IETF 90 in Toronto, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Deploy360 Encryption Securing Border Gateway Protocol (BGP) To archive

Video: CrypTech and RPKI (Randy Bush at RIPE 68)

How do we build an open hardware security module that’s verifiably secure? Can we use Openflow and BGP RPKI to enforce route validation in the data plane? In this two part lightning talk Randy Bush introduces two projects he and others have started. The first project is, an open reference design for hardware security modules that aims to be secure from government and private party intrusion. Randy lays out the goals of the project and solicits help from the community. The second project is a BGPSEC experiment being carried out in a New Zealand IXP. In the experiment an Openflow switch placed between two BGP peers is programmed exclusively with routes validated from a route server using RPKI. Randy’s talk, entitled “CrypTech and RPKI/Flow IX” is available for viewing, and the slides are available for download.


After watching, check out our page on BGPSEC to learn more about deploying BGPSEC and RPKI.

Deploy360 Events IETF Securing Border Gateway Protocol (BGP)

3 Sessions About Securing BGP At IETF89 Next Week

BGPNext week at IETF 89 in London there will be a good bit of discussion around the security and resilience of the Internet’s routing infrastructure.  Given our interest in securing BGP, members of our team will be attending the SIDR, GROW and IDR Working Groups next week and engaging in other routing discussions as well.

My colleague Andrei Robachevsky wrote about routing as part of the IETF 89 “Rough Guide” today and explained some of the activities that will be happening during the week.  I’d encourage you to read his post as he goes into some detail about the different drafts that are being considered by the three working groups.

Relevant Working Groups

SIDR (Secure Inter-Domain Routing)
Tuesday, March 4, 0900-1130 UTC, Balmoral Room
WG Agenda:

GROW (Global Routing Operations)
Tuesday, March 4, 1300-1400 UTC, Blenheim Room
WG Agenda: (not yet available)

IDR (Inter-Domain Routing Working Group)
Thursday, March 6, 1300-1500 UTC, Blenheim Room
WG Agenda:

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

Deploy360 Securing Border Gateway Protocol (BGP) To archive

BGP Hijacking In Iceland And Belarus Shows Increased Need for BGP Security

Want to understand better why we need to secure the Border Gateway Protocol (BGP) to make the Internet’s routing infrastructure more secure? Just read this article on Wired’s site, “Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet“, or the corresponding post on the Renesys blog, “The New Threat: Targeted Internet Traffic Misdirection“.   The key point is that attackers are abusing BGP to hijack the routing of traffic off to a another network – but without the end-user having any clue that their traffic was diverted.  As noted by Jim Cowie on the Renesys blog:

What makes a Man-in-the-Middle routing attack different from a simple route hijack? Simply put, the traffic keeps flowing and everything looks fine to the recipient. The attackers keep at least one outbound path clean. After they receive and inspect the victim’s traffic, they release it right back onto the Internet, and the clean path delivers it to its intended destination. If the hijacker is in a plausible geographic location between the victim and its counterparties, they should not even notice the increase in latency that results from the interception. It’s possible to drag specific Internet traffic halfway around the world, inspect it, modify it if desired, and send it on its way. Who needs fiberoptic taps?

He goes on to illustrate with an example where traffic was diverted to an ISP in Belarus:

In February 2013, we observed a sequence of events, lasting from just a few minutes to several hours in duration, in which global traffic was redirected to Belarusian ISP GlobalOneBel. These redirections took place on an almost daily basis throughout February, with the set of victim networks changing daily. Victims whose traffic was diverted varied by day, and included major financial institutions, governments, and network service providers. Affected countries included the US, South Korea, Germany, the Czech Republic, Lithuania, Libya, and Iran.

The article shows several graphical examples of how the network traffic was routed though the Belarusian ISP, such as this one:

Renesys map of route hijackingThe Renesys blog post goes on to show examples from a second series of incidents related to an ISP in Iceland, including one where traffic from one network in Denver, Colorado, went to another network in Denver… by way of Iceland!

As both the Wired article and the Renesys post say, the attackers behind these attacks have not yet been identified, and may well never be.  This kind of attack, though, is being seen on an increased basis.

This is why we’ve opened up our new topic area on Securing BGP.  We collectively need to all work together to make the Internet’s routing infrastructure more secure and more resilient against these type of attacks.  We’ll be working over the months ahead to add more content to this site – and we could use your help finding or writing items on our “Securing BGP Content Roadmap”.   If you operate a network router, we would also encourage you to join our Routing Resiliency Survey so that we can help in the effort to collect data about what kind of BGP attacks are being seen.

We need to prevent these type of hijackings from happening – and we need your help to do so!

Deploy360 Securing Border Gateway Protocol (BGP)

Introducing A New Deploy360 Topic: Securing BGP

BGPHow can we help network operators ensure that their usage of the Border Gateway Protocol (BGP) is as secure as possible?  How can we help enterprises who operate their own routing infrastructure make sure that they are keeping their own networks secure?  How can we help network operators at all levels make sure they are doing their part to keep the Internet’s routing infrastructure as secure and resilient as possible?

A year ago we launched the “Routing” topic on Deploy360 to explore these kind of questions.  We’ve written many articles about routing resiliency and featured panels about improving routing resiliency/security at our ION conferences, such as a recent session at ION Toronto.

However, as we went around speaking with people about the need to make the Internet’s routing infrastructure more resilient and secure,  one extremely important bit of feedback we received from people was that our topic here on Deploy360 of “Routing” was far too broad.  It wasn’t as specific as our areas on IPv6 and DNSSEC, and that provided multiple challenges both in terms of creating a logical flow of providing deployment information and also in finding resources and/or people to create new materials.

We’ve listened to all that feedback and are changing how we address the overall routing resiliency topic.  Instead of one massive topic, we’re going to be breaking the area down into several smaller topics that we will be rolling out over the course of 2014.

Today we’re pleased to announce the first new topic area, Securing BGP, where we will be focusing on the tools, services and technologies that can help make BGP routing more secure.  We’ll be talking about not only basic “good hygiene” for routing but also specific tools that can help secure BGP such as prefix filtering, ACLs, RPKI, BGPSEC and much more.  We have created a set of initial pages related to the topic which will be populating with more content over the weeks and months ahead:

Perhaps more importantly we have outlined a content roadmap for the resources related to securing BGP that we want to add to the site and are now actively looking for resources that are out there now that we can point to – or identifying authors who can write some of the resources that don’t yet exist. Naturally we’ll be adding blog posts related to securing BGP to our Deploy360 blog – and you can expect sessions related to securing BGP to appear at our future ION conferences.

How You Can Help

We need your help!  In order to provide the best possible resources to help network operators secure their use of BGP, we need to hear from you!  We need your feedback to help us know that we are helping you make your network more secure.  A few specific requests:

1. Read through our pages and content roadmap – Please take a look through our “Securing BPG” set of pages, and also please take a look at our content roadmap for BGP.  Are the current resources listed helpful?  Is the way we have structured the information helpful?  Will the resources we list on our roadmap help you make your routers more secure?

2. Send us suggestions – If you know of a report, whitepaper, tutorial, video, case study, site or other resource we should consider adding to the site, please let us know. We have a list of many resources that we are considering, but we are always looking for more.

3. Volunteer – If you are very interested in this topic and would like to actively help us on an ongoing basis, please fill out our volunteer form and we’ll get you connected to what we are doing.

4. Help us spread the word – As we publish resources and blog posts relating to securing BGP, please help us spread those links through social networks so that more people can learn about the topic.