Category: Securing BGP

Show Your Commitment To Routing Security – Join the MANRS Initiative!

MANRS logo

Do you want to make the Internet’s routing infrastructure more secure?  Have you implemented anti-spoofing techniques to help protect against attacks such as DDoS attacks?  Have you secured your use of BGP on your network?

If so, why not consider publicly showing your support by signing up as a participant in the MANRS initiative?

This new routing security initiative, launched today, aims to promote better collaboration between network operators to make the Internet more secure and resilient.  As the home page says:

How can we work together to improve the security and resilience of the global routing system?

Originally called the “Routing Resilience Manifesto”, the initiative published today the “Mutually Agreed Norms for Routing Security” (MANRS) at:

With the announcement came news of an initial set of participants that includes some of the largest global network operators such as Comcast, Level 3 and NTT.  More companies will be added and signups are already coming in!

To participate, a network operator needs to agree to at least 2 (and ideally all 4) of these actions:

Basically you could think of this as a “code of conduct” for network routing… an agreement that companies publicly say they are going to follow to help the overall Internet’s routing infrastructure be more resilient and secure.

Our colleague Andrei Robachevsky has been heading this project and working with a team of people from network operators around the world (some of whom have already signed on as formal participants, others who hope to do so soon).  It’s great to see this out there and we look forward to seeing the list of participants grow.

Please do read the MANRS document and sign up if your network can undertake those actions.  If every network operator can mind their MANRS, we’ll all have a much safer, more secure and more resilient Internet!

P.S. If you are looking for information about how to get started with anti-spoofing or securing BGP, please see our Network Operators Start Here page to get started.


INET Trinidad and Tobago To Cover IPv6, DNSSEC, IXPs and more

INET Trinidad and TobagoThis Wednesday and Thursday the INET Trinidad and Tobago event will bring a great amount of technical presentations to the Caribbean region. Starting on October 8, 2014, some of the presentations covering IPv6 and DNSSEC include:

  • IPv6: What Is It? Why Is It Needed?
  • IPv6 Deployment: Business Cases and Development Options (in the Caribbean)
  • Securing the DNS and Internet Routes

The event continues on Thursday, October 9, with a range of sessions related to Internet Exchange Points (IXPs), cybersecurity and trends in the overall industry.  It looks like a great event and the excellent news is that you can watch it all live at:

Note that Trinidad and Tobago use Atlantic Standard Time (AST) which is UTC-4 and right now the same as US Eastern Daylight Time.

Our colleague Shernon Osepa has more information about the INET Trinidid and Tobago event in a post on our Internet Technology Matters (ITM) blog earlier today.

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!

Watch ION Belfast Live TODAY To Learn About IPv6, DNSSEC, BGP and more

ION Belfast LogoWant to learn the current state of IPv6 deployment? DNSSEC? Securing BGP and more? If so you can watch LIVE today our ION Belfast event at:

Today’s ION agenda begins at 1:45 pm British Summer Time (UTC+1) and is packed with information about our topics. Sessions include:

  • Two Years After World IPv6 Launch: Are We There Yet?
  • Why Implement DNSSEC?
  • IPv6 Success Stories – Network Operators Tell All!
  • IETF Update
  • Panel: Routing Around Catastrophe
  • Securing BGP

There are an outstanding set of speakers and we’re very excited to hear their sessions and the conversations that will emerge out of them.

All the sessions will be streamed live and will be recorded for later posting on our Deploy360 YouTube channel.

Please join us as it should be a great event!

NOTE: As we mentioned yesterday, there are also what look to be some excellent sessions happening in the morning UK time as part of the UKNOF agenda.  In particular, these two sessions should be of interest to those concerned about IPv6:

  • 11:30 BST – What went wrong with IPv6?
  • 12:00 BST – IPV6-only Data Centres: What happens when you turn off IPv4

They, too, will be webcast on the same live stream link and will be recorded for later viewing.

Again, it should be an outstanding day at the combined UKNOF / ION Belfast event – we do hope you will join us!

P.S. And if you are motivated to deploy these technologies such as IPv6 and DNSSEC, please visit our Start Here page to find resources to help you get started!

Watch UKNOF Today To Learn About IPv6, IXPs, Internet Connectivity

UKNOF 29 - ION BelfastWant to learn about IPv6, Internet Exchange Points (IXPs) and some of the latest connectivity ideas in the United Kingdom? If so, you can watch the live webcast of UKNOF 29 starting today, September 8, 2014, at 13:30 British Summer Time (BST, which is UTC+1). The critical links to know are:

Today’s sessions are mainly focused on network operations and Internet connectivity and include:

  • HEAnet’s Optical Backbone & School’s Connectivity
  • Watery Wireless
  • Options for Metro 100Gig
  • Network Function Virtualisation, bringing virtualised network infrastructure into the cloud
  • Broadcast editing and delivery over IP (from the BBC)
  • LINX’s UK regional peering strategy
  • An overview of BT’s network infrastructure in Ireland and Northern Ireland including connectivity to the the rest of the UK
  • UKNOF Status Update

Tomorrow, Tuesday, September 9, 2014, the morning sessions include some that may be of interest to our readers and then the afternoon will be our ION Belfast event.  Here’s the current UKNOF agenda going from 09:30-12:35 BST:

  • Latest Internet Plague: Random Subdomain Attacks  (about DNS security)
  • Tales of the unexpected – handling unusual DNS client behaviour
  • Using 100 Billion DNS Queries to Analyse the Name Collision Problem
  • What went wrong with IPv6?
  • IPv6-only Data Centres
  • Introduction of UK IPv6 Council

In particular I would point your attention to the “What went wrong with IPv6?” talk at 11:30 BST by Dave Wilson from HEAnet. He recently gave a version of this talk at RIPE 68 and both the video and the slides from that talk are available. He asks some great questions and, I think, has some great ideas for we can advance IPv6 deployment – definitely worth listening to!

ION Belfast LogoAfter a lunch break, our ION Belfast event will then begin with a packed agenda talking about IPv6, DNSSEC and securing BGP.  That, too, will be webcast live for all to see!

All in all it will be two days of outstanding sessions talking about the Internet’s infrastructure and how we can make it work better, faster and more secure!

I hope you will join me in tuning in to watch!

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.


IETF LogoToday seems to be “DNS Day” here at IETF 90 in Toronto with the two major DNS-related working groups we follow here at Deploy360, DNSOP and DANE, both meeting on the same day.  We’ve also got V6OPS meeting again (as they did yesterday), have several IPv6-security drafts in OPSEC and have routing discussions happening in IDR.  Oh, and we’ll be splitting ourselves 3 ways in the first time slot (and wishing we had clones!). Plus, we’ll have the “ISOC@IETF” briefing panel at lunch time looking at security and privacy issues. It’s going to be a busy day!

If you’d like to join the DNSOP or DANE 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.


As I mentioned in my Rough Guide post about DNSSEC/DANE at IETF 90, there is a great amount happening in both DNSOP and DANE.  Here is the relevant excerpt from that post:

DNS Operations (DNSOP)

Tuesday morning from 9:00-11:30 EDT the DNSOP Working Group kicks off with a full agenda that includes a great amount of DNSSEC activity. Matthijs Mekking will bepresenting a draft about DNSSEC key and signing policies. Daniel Migault will betackling the topic of what the requirements are for DNSSEC validation so that DNS resolvers can always have validation enabled.

Of particular interest to folks looking to get DNSSEC deployed (as I am) will be the “DNSSEC Roadblock Avoidance” draft that explores what are the problems with DNSSEC validation in many common network environments – and how do we mitigate those problems.

As the agenda indicates, there will be a range of other topics covered in DNSOP, too. The biggest and most controversial discussion may be around how we optimize the distribution of root zone data, with Warren Kumari and Paul Hoffman offering one view of distributing the root zone and Paul Vixie and Xiaodong Lee offering another view of how to scale the root of DNS. Given that DNSSEC plays an important role in both scenarios we’ll be paying close attention to what I expect will be quite a passionate discussion!

Beyond those topics you can probably expect to see some of the many other documents under DNSOP (scroll down the page to see the full list) raised for consideration – unless, of course, the root optimization discussion consumes most of the time, as could easily happen.

DNS-based Authentication of Named Entities (DANE)

Later on Tuesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. We should see discussion aroundthe “DANE and OpenPGP” draft as well as the “DANE and SMIME” draft. One of the DANE WG co-chairs, Olafur Gudmundsson, told me that the “SMTP security via opportunistic DANE TLS” draft and the “Using DANE with SRV Records” draft will both be going to Working Group Last Call and so that may or may not trigger some comments.

What may generate more discussion, though, is interest in changing the “DANE Operational Guidance” draft into a “DANEbis” document, i.e. looking at it as a replacement/update for RFC6698 that defines DANE. This should be an interesting discussion!

On a similar track, Paul Wouters will be speaking about standardizing how “Raw Public Keys” for TLS can be authenticated using DANE. As I understand it, Paul wants to extend the TLSA record used in DANE to support more than just PKIX-formatted certificates, allowing DANE to be used for applications that do not require PKIX certs.

I am also intrigued to learn more about ideas from Haixin Duan to use DANE to better secure the usage of HTTPS connections in content distribution networks (CDNs). Haixin Duan and some colleagues have written a paper that goes into more detail (search for “DANE” to jump to the relevant section).

If there is time Olafur tells me that the chairs also intend to kick off a discussion of “reverse DANE”, i.e. DANE records for clients, that might lead to some interesting applications and areas of work.

Unfortunately at the same time as DNSOP from 09:00-11:30,  the Using TLS in Applications (UTA) working group will be meeting. While the UTA agenda  doesn’t directly mention DNSSEC, we definitely pay attention to UTA given that the drafts all focus on securing TLS and that DANE could potentially play a role here. We also have an interest for our “TLS For Applications” section of Deploy360.


Beyond DNS, today the IPv6 Operations (V6OPS) working group is back with an agenda once again looking at the operational aspects of running IPv6.  The first document on running multiple IPv6 prefixes was actually addressed in yesterday’s session so there may be more time available for other discussions.  I’m personally intrigued by the discussion about power consumption due to IPv6 multicast on WiFi devices.  I’ve not been directly following that draft so I’m intrigued to learn more.

Outside of V6OPS, IPv6 will also feature prominently on today’s OPSEC agenda with two drafts from Fernando Gont being presented that talk about how firewalls interact with IPv6. First he’ll be discussing how many firewalls drop IPv6 extension headers (EH) and his thoughts about that.  Second, he’s got a draft on “Requirements for IPv6 Enterprise Firewalls” that looks quite interesting.

(As an aside, having lived in Canada from 2000-2005, I’m very pleased that there is at least one draft (Fernando’s) being presented here in Toronto that includes “eh” in it, given that this is a very common Canadian verbal expression, as in “It’s going to be a great day, eh?” :-) )

Routing and Securing BGP

Today is also the day one of the major routing working groups we track will be meeting, unfortunately in that same 9:00-11:30 am block as DNSOP and UTA.  The Inter-Domain Routing (IDR) working group has an extremely packed agenda full of all sorts of drafts related to securing BGP and improving the security of our routing infrastructure.  As our colleague Andrei Robachevsky wrote in his Rough Guide post, IDR “continues to work on better handling of malformed BGP attributes that may cause serious outages, and even cascading effects for other networks.  Because of the timing conflict, I won’t personally be in IDR, but you can expect to find Andrei there.

ISOC@IETF90 Briefing: Internet Security and Privacy: Ten Years Later

In the midst of all the working groups today we’ll spend our lunch time from 11:45-12:45 at the traditional “ISOC@IETF Briefing Panel” that happens every Tuesday of an IETF meeting.  The theme this time is “Internet Security and Privacy: Ten years later” and the abstract begins:

Many fundamental Internet protocols and architectural elements were designed for relatively closed and controlled networks and later used in a fairly trusted environment. Then came explosive Internet growth that changed its very nature – the Internet became a global, open communication medium to which anyone could connect and contribute.

At the same time, the Internet model was also changing. Concentration and centralization of certain functions at various Internet architecture layers created new types of vulnerabilities and, consequently, facilitated new threats such as pervasive monitoring. These vulnerabilities manifest themselves in different ways – for instance, in lack of diversity in implementations of critical security protocols, like TLS.

The number and nature of connected devices is also changing dramatically – sensors, controllers, appliances, etc., all communicating without human intervention.

The Internet continues to change and this evolution will continue. How will security and privacy challenges be addressed ten years from now? What are the missing building blocks that need to be developed? Will current approaches allow us to catch up or is a change of paradigm required?

There are a great set of panelists and this should be a great discussion.  It will be live streamed over YouTube and anyone is welcome to watch.  (Unless they are trying to view the stream from Germany, where apparently they can’t.)

And after all that is done we’ll probably be going to the IETF Social event tonight to talk to more people about how we might be able to help them… before eventually getting to bed to get ready for Day 3…

The information about the relevant working groups today is:

DNSOP (DNS Operations) WG
(Tuesday, July 22, 2014, 0900-1130 EDT, Ballroom)

UTA (Using TLS in Applications) WG
(Tuesday, July 22, 2014, 0900-1130 EDT, Ontario)

IDR (Inter-Domain Routing Working Group) WG
(Tuesday, 22 July, 0900-1130 EDT, Tudor 7/8 Room)

OPSEC (Operational Security) WG
(Tuesday, 22 July, 1300-1400 EDT, Territories Room)

V6OPS (IPv6 Operations) WG
(Tuesday, July 22, 2014, 1420-1620 EDT, Ontario)

DANE (DNS-based Authentication of Named Entities) WG
(Tuesday, July 22, 2014, 1640-1840 EDT, Canadian)

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.

Congrats on 25 Years of RIPE Meetings – And We’ll Be Promoting Videos From RIPE68

ripe-25-anniversaryAs the RIPE 68 meeting has drawn to a close in Warsaw, Poland, we would just like to take a moment to join with our CEO and many others in congratulating the RIPE community on their 25th anniversary.  Over these past 25 years the RIPE community has done an amazing amount of work together to create a stronger and better Internet.  On a global level, we are all collectively so much better off because of all the work that has happened within the RIPE community. Do check out their “25 Years of RIPE Timeline” to learn more.

We heard from Chris Grundemann and Jan Žorž that the 25th anniversary celebration on Tuesday evening was a great event – and both of them have raved about what an excellent – and exhausting – week this has been for them. As we wrote about last week, they’ve had an extremely busy week with a great amount of activity on IPv6, DNSSEC, securing BGP and our BCOP and  Operators and the IETF projects. Outside of that, Jan is also a member of the RIPE Program Committee (and was chosen again for that role) and so he was super-busy with helping with general organizational issues.  Our colleague Andrei Robachevsky was also there being very active on issues around routing resiliency and some of the great work happening there.

One of the great things about the RIPE meetings is how quickly they make the videos and presentations available for viewing.  There were some outstanding presentations at this RIPE 68 meeting in Warsaw, and so we’ll be highlighting and promoting some of the sessions that we found most valuable and interesting.  We’ve already started this yesterday with a post about Chris’ presentation about operators and the IETF, but we’ll be doing more of that over the next few weeks.

Congrats again to the RIPE community on their 25th anniversary - and we look forward to seeing all that will happen over the next 25 years!

Turkish Hijacking of DNS Providers Shows Clear Need For Deploying BGP And DNS Security

bgpmon-turkish-hijackOver the weekend there were extremely disturbing reports out of Turkey of escalations in the attempts by the Turkish government to block social media sites such as Twitter and YouTube. The steps now being taken appear to have the Turkish Internet service providers (ISPs) hijacking the routes to public DNS servers such as those operated by Google and masquerading as those DNS servers to provide answers back to their citizens.

Effectively, the Turkish ISPs, operating to comply with a Turkish government ban, are performing a “man-in-the-middle” (MiTM) attack against their citizens and giving them false information.

The Internet Society made a statement on the subject yesterday, explaining its “deep concern” for the situation, and our Chief Internet Technology Officer Leslie Daigle has described how these recent moves “represent an attack not just on DNS infrastructure, but on the global Internet routing system itself.


As we noted ten days ago, ISPs in Turkey started out attempting to implement the government’s ban by simply blocking those sites in DNS. When Turkish citizens tried to go to those social media sites, their device would query DNS to get the correct IP address to connect to.  The Turkish ISPs who were providing the DNS servers used by the Turkish citizens simply failed to give back a response for Twitter and YouTube.

Turkish citizens found they could get around this block by simply changing their devices’ DNS settings to point to open public DNS resolvers such as those operated by Google.

Predictably, the Turkish ISPs then attempted to block the addresses for Google Public DNS servers and other similar servers. The ISPs then started to engage in the typical kind of “whac-a-mole” game with their citizens where the citizens would find new ways to get around the censorship… and the ISPs would then try to shut down those.

BGP Hijacking

Starting this past Saturday, March 29, though, reports started coming in that the Turkish ISPs were taking this to a whole new level by hijacking routing of the Border Gateway Protocol (BGP) and pretending to be Google’s Public DNS servers (and the servers of other similar services).

In other words, the devices operated by Turkish citizens on Turkish networks were connecting to what they thought were Google’s Public DNS servers (and other services) and were getting back answers from those services.

The answers the Turkish citizens were receiving were just the wrong answers.

Instead of going to Twitter or YouTube they were being redirected to sites operated by Turkish ISPs.  Google confirmed this in a post on their Online Security Blog that included in part:

A DNS server tells your computer the address of a server it’s looking for, in the same way that you might look up a phone number in a phone book. Google operates DNS servers because we believe that you should be able to quickly and securely make your way to whatever host you’re looking for, be it YouTube, Twitter, or any other.

But imagine if someone had changed out your phone book with another one, which looks pretty much the same as before, except that the listings for a few people showed the wrong phone number. That’s essentially what’s happened: Turkish ISPs have set up servers that masquerade as Google’s DNS service.

Writing over on the BGPMon blog, Andree Toonk detailed the specifics of the BGP route hijack that took place.  Essentially, the Turkish ISPs started “advertising” a more specific route for Google’s Public DNS servers.  The way BGP works, Google advertises a route for traffic to get to its servers on its network.  As the BGPMon blog post indicates, that is normally a “″ route directing people to AS 15169.  However, the Turkish ISPs advertised a specific route for “″ that went to their own network.

In BGP, a router typically selects the most specific route as the one to use to connect to a given IP address.  So all the routers on networks connected to Turkish ISPs would use this very specific route instead of the one advertised by Google.

They apparently did this for all of Google’s Public DNS addresses as well as those of other open public DNS providers as well.  Over on the Renesys Blog, Earl Zmijewski shared their observations including showing precisely when the hijacking occurred:

The Turkish ISPs are pretending to be Google’s specific DNS servers to everyone who is connected to their network.

Delivering False DNS Information

The Turkish ISPs went a step further, though, in that they set up their own DNS servers that answered as if they were Google’s Public DNS servers.  As Andree Toonk wrote on the BGPmon blog:

Turk Telekom went one step further, instead of null routing this IP address they brought up servers with the IP addresses of the hijacked DNS servers and are now pretending to be these DNS servers.  These new fake servers are receiving traffic for and other popular DNS providers and are answering DNS queries for the incoming DNS requests. 

Stéphane Bortzmeyer also documented this in a lengthy post on his blog where he used the RIPE NCC’s Atlas probe network to show that DNS answers in Turkey are different from those in other areas.  The Renesys blog post also confirmed this, as did many posts on social media services and other online sites.  A good number of tech media sites have weighed in on the matter as well.

The Need To Secure BGP

From our Deploy360 point of view, this kind of attack against the Internet provides a great case study of why we need to better secure BGP and why we need to get DNSSEC validation more widely deployed.

With BGP, the fact that anyone can advertise a route for any other network means that ISPs can do precisely what the Turkish ISPs have done and hijack routes to masquerade as anyone else.  Clearly this is unacceptable.  As we talk about on our “Securing BGP” page, and is also detailed more deeply in the BGP Operations And Security Internet-Draft, there are efforts underway to deploy “secure origin validation” so that routers in the network know which advertised routes to trust and which ones not to trust.

If the routers on networks in Turkey had secure origin validation in place, when they received the more specific route from the Turkish ISPs they could have checked the origin, realized that the route advertisement was not coming from the operator of the original network and simply disregarded the more specific route. They would have continued to use the original routes that were advertised by the original network operators.

Now, granted, if the ONLY routes from the networks inside of Turkey out to the rest of the Internet are through a small number of large Turkish ISPs who work with the government to enforce banned sites, then this kind of origin validation will not help the “downstream” networks.  While they may disregard the announced specific route because of origin validation, their traffic using the original route will still have to travel through the networks of the small number of large ISPs who can then - within the large ISP networks – perform the BGP hijacking.  However, if any of the downstream networks have alternate Internet connections (and this may not be possible within Turkey) they may be able to use routes going out those connections.

It is also useful to note that secure origin validation could help networks outside of Turkey.  When a government is causing network operators to mess around with the routing tables that make up the fundamental architecture of the Internet, they are playing with fire. One mistake could have a very large impact on the rest of the Internet, such as the time when a Pakistani ISP rerouted global YouTube traffic to a network in Pakistan back in 2008!  In their escalating attempts to block access for Turkish users, it is entirely possible that someone at one of the Turkish ISPs could leak incorrect routes out into the larger Internet.  Secure origin validation running on other networks around the Internet would prevent these incorrect routes from being taken seriously.

Where DNSSEC Would Help

On the DNSSEC side, if the Turkish citizens had DNSSEC-validating DNS resolvers running on their local networks or even better on their actual devices, and if, for instance, Google had DNSSEC-signed the DNS records for their Public DNS servers, then Turkish users would be able to know that they were not getting to the correct servers.  Note that this would not  help them get to new servers… but they would know that they were not getting the correct information. Applications that validated the DNSSEC signatures on information retrieved from DNS could then discard the invalid information and try other ways to get that information.

DNSSEC helps ensure that you are getting to the correct site and not to a site set up by, for example, a spammer or phisher trying to steal your identity. Similarly it could protect you from going to sites set up by a government (or via a government mandate) that are pretending to be a site that they are not. For this to work, of course, the original sites (such as Twitter and YouTube) need to have their DNS information signed with DNSSEC, and users out on the Internet need to have DNSSEC validation happening in their local DNS resolvers.

Which is why we need to get DNSSEC deployed as fast as possible – to ensure that the information that we all get out of DNS is the same information that was put in to DNS by the operators of a given domain… and not the information put in by an attacker, which, in this case, could be ISPs acting on behalf of a government.

Again, this would not necessarily help a Turkish user get to Twitter or YouTube, but would prevent them from going to spoofed sites.  Additionally, if the operating system were validating the DNSSEC signatures on name server records the system could have noticed that the information it was getting back from, for instance, Google’s Public DNS, did not validate with the “global chain of trust” and so could have warned that the DNS information was suspicious (or perhaps chosen to try to use additional DNS servers that did validate correctly).

How To Help

The question now is what we do to strengthen the Internet against these kind of attacks on the Internet’s infrastructure.  Within our area of focus, we have three requests:

1. Understand how to secure BGP, and do so! - Please visit our “Securing BGP” section of the site, read the BGP Operations and Security Internet Draft, look at our BGP content roadmap and see if there are any documents there that you can contribute to help us build out our content and get more people taking these steps to secure their routers.  If you are a network operator, any steps you can take to make your routers more secure will go far.

2. Deploy DNSSEC validation - Wherever you can, turn on DNSSEC validation in any DNS recursive resolvers.  The steps to do so are very simple for the common DNS resolvers.

3. Sign your domains with DNSSEC – If you have a domain registered, see if you can sign it with DNSSEC (here are the steps you need) and if you encounter any issues please raise the issue with your domain name registrar, DNS hosting operator, IT department or whomever is blocking the process.

These steps will make attacks on the Internet’s infrastructure such as those happening in Turkey today more difficult and raise the complexity needed by the attackers.

Beyond these steps, this situation clearly points out the need for a wider diversity of Internet access methods.  Even with these steps above implemented, Turkish users who are limited to only the specific Turkish ISPs have no choice in receiving their default routes and connections.  If more options were to be available in the region, the ability of those users to have access to the information on the Internet would not be restricted.

The Internet needs to be hardened against attacks such as these.  Please help make the Internet stronger!



Deploy360@IETF89, Day 4: dane, sunset4, v6ops, 6tisch, idr, dbound, eppext, sipcore and dnsop

IETF LogoThe fourth day for our Deploy360 team at the 89th IETF meeting could perhaps best be described as “utter madness” as there are multiple working groups meeting on ALL of the topics we cover here:  IPv6, DNSSEC, securing BGP and even our new TLS for Applications area. In particular, several of the major DNS groups are holding their only meetings today.

Details and links are farther down below (along with remote participation info), but as we mentioned in our pre-IETF89 posts about IPv6, DNSSEC and Securing BPG,  today will bring:

  • The meeting of the DANE Working Group (read more about the DANE protocol).
  • The work in SUNSET4 on phasing out IPv4 and the second meeting of v6OPS focused on operational guidance for IPv6.
  • The 6TiSCH work on IPv6 in resource-constrained “Internet of Things” kinds of networks.
  • The IDR working group has many work items relating to BGP.
  • There is a new DBOUND BOF session that is looking into boundaries in the DNS related to domain names and how those could apply to security policies.
  • In EPPEXT there is an extension proposed for how to securely pass DNSSEC keying material between operators and registries.

Beyond all of those, there are two other Thursday meetings that have come to our attention:

  • In the 1300-1500 block when we already have 3 other sessions of interest, the SIPCORE Working Group is planning a 45 minute discussion on “Happy Eyeballs for SIP” looking at what needs to be done to make SIP work over IPv6. (Where SIP is the dominant open standard used in voice-over-IP.)
  • At the end of the day, a brand new timeslot was opened up from 1840-2040 where the DNSOP Working Group is going to get a head-start on their Friday morning agenda and very specifically focus on the outcome of yesterday’s DNSE BOF around what can be done to protect the confidentiality of DNS queries.  The main point of this evening timeslot is so that TLS can be discussed with some of the people from the UTA Working Group joining in to the discussion (since UTA and DNSOP are scheduled at the same time on Friday morning).

All in all its going to be an extremely busy day for all of us!  We’re looking forward to it, though, as great things are definitely happening!

Thursday, March 6, 2014

dane (DNS-based Authentication of Named Entities) WG
0900-1130 UTC, Park Suite

sunset4 (Sunsetting IPv4) WG
0900-1130 UTC, Palace C
Agenda: with the Multiple Interface (mif) WG meeting)

v6ops (IPv6 Operations) WG
1300-1500 UTC, Sovereign Room

6tisch (IPv6 over TSCH mode of 802.16e4)
Thursday, March 6, 2014, 1300-1500 UTC, Buckingham Room

idr (Inter-Domain Routing Working Group)
1300-1500 UTC, Blenheim Room
WG Agenda:

sipcore (Session Initiation Protocol Core)
1300-1500 UTC, Palace C
WG Agenda:

dbound (Domain Boundaries) BOF
1520-1650 UTC, Blenheim Room
List of BOFs:

eppext (Extensible Provisioning Protocol Extensions) WG
1700-1830 UTC, Park Suite

dnsop (DNS Operations) WG
1840-2040 UTC, Sovereign Room

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.