Deploy360 Improving Technical Security

RIPE 74 – Highlights from Days 3, 4 & 5

The RIPE 74 meeting was happening last week in Budapest, Hungary, and we’ve been highlighting the presentations and activities related to the Deploy360 technologies. Although much of the action for us happened on the first couple of days, there’s still quite a few things to highlight from the rest of the week.

Wednesday and Thursday were largely devoted to the Working Groups, and there were several interesting presentations during the IPv6 Working Group.

First up, Enno Rey (ERNW) presented the results of his testing of different operating systems for IPv6 address selection as defined in RFC 6724. This defines multiple ways for source addresses to be selected, and the tests were applied to different versions of Windows (7/8.1/10), Linux (Ubuntu 16.4 & Debian 8), iOS (9.3.2) and Windows 10 Mobile. Whilst different behaviours were observed, all the operating systems did appear to conform to the RFC in a consistent manner, which suggests that interactions with other mechanisms need to be considered when unpredictable behaviour is encountered.

Friso Feenstra (Rabobank) then followed-up on Tuesday’s presentation about how Rabobank had deployed IPv6, with some details about their addressing plan. This is a large bank with a presence in some 20 countries, nearly 1,000 offices and 12 data centres, and he outlined how their /29 prefix was allocated to minimise the size of routing tables, and to keep ACL and firewall configuration simple. They also defined security areas to allow specific network and device rules to be applied, and to ensure routing is clearly demarcated.

Another good case study was provided by Martin Levy (Cloudflare) who talked about how Cloudflare had enabled IPv6 support by default on their websites. This had led to a significant jump in IPv6 traffic as it provided a bridge for IPv6-enabled clients to access IPv4-only content via IPv6, and the presentation includes some interesting figures about who are the top IPv6 network operators, where the traffic is coming from, and the types of devices being used.

Quite a lot of deprecated DNS A6 queries were still being seen though, as well as incomplete A & AAAA records which is limiting the effect of Happy Eyeballs. Cloudflare was therefore proposing to return both a A and AAAA response to an valid query, which should then be cached by resolvers. This is currently the subject of an Internet Draft, although there are two alternative proposals going through the IETF.

Next up was our colleague Jan Žorž who again presented the results from the NAT64/DNS64 testing being undertaken by the Go6lab and supported by the Internet Society. We already discussed this earlier in the year, but it’s again worth mentioning the NAT64check tool that enables websites to be checked for consistency over IPv4, IPv6-only and NAT64, as well to compare responsiveness using the different protocols. This allows network and system administrators to easily identify anything is ‘broken’ and to pinpoint where the problems are occurring, thus allowing any non-IPv6 compatible elements on the website to be fixed.

Rounding off the IPv6 Working Group was a presentation from Jordi Palet (Consulintel) on using 464XLAT in Residential Networks. 464XLAT allows IPv4-only applications on IPv6-only networks to access IPv4 services elsewhere on the Internet, and therefore provides a solution for deploying IPv6 to residential customers where you don’t want existing applications to break. It makes efficient use of existing IPv4 resources, yet allows networks to grow without being reliant on IPv4 availability. As a result, RFC 7084 was currently being updated to recommend support for 464XLAT in the basic requirements for IPv6 customer edge routers.

It should also be mentioned there was a lively panel discussion during the IPv6 Working Group on the topic of IPv6 in the Enterprise. This involved Marcus Keane (Microsoft), Enno Rey (ERNW), Benedikt Stockebrand (Stepladder IT Training & Consulting), Sander Steffann (SJM Steffann) and Friso Feenstra, (Rabobank). A video of the proceedings is available.

There were also a few other things to highlight in the other Working Groups:

During the Routing Working Group, there was an update on MANRS from Ben Maddison. This initiative defines four concrete actions that network operators should implement to promote a culture of collaborative responsibility, and the next steps are to develop a MANRS certification programme as well as partnerships with IXPs.

In the Open Source Working Group, a couple of useful RPKI tools were announced by Andreas Reuter (Freie Universität Berlin). RPKI MIRO is a framework to monitor and inspect RPKI repositories, and includes the RPKI Browser which provides GUI access to the structure of the RPKI and the content of RPKI objects. RTRlib is a C library that implements client functionality to gather data from RPKI caches and perform origin validation, and is used in several applications (e.g. Quagga) to validate and monitor BGP updates.

That just leaves the DNS Working Group and the presentation on DNS Privacy from Benno Overeinder (NLnet Labs). We already discussed DNS over DTLS a few weeks ago, but DNS queries and responses are normally exchanged unencrypted on the network between a DNS client and server, and can therefore be monitored to reveal potentially sensitive information. The aim is deploy mechanisms to provide confidentiality to DNS transactions using TLS, and NLnet Labs and others have developed some test resolvers that can support this. For more information, check out the IETF DNS Privacy Tutorial.

That concludes the week, and we say Viszlát from the beautiful city of Budapest. All the presentations from the meeting can be found on the RIPE 74 website.

The next RIPE meeting will be held on 22-26 October 2017 in Dubai, UAE, which will be the second time it’s gone there. We’ll see you then, Inshallah…

Deploy360 Domain Name System Security Extensions (DNSSEC) Events Improving Technical Security IPv6

RIPE 74 starts in Budapest next week

The RIPE 74 meeting is happening next week in Budapest, Hungary. Proceedings commence bright and early with two tutorials on peering and network automation, before the opening plenary starts at 14.00 CEST/UTC+2.

Both Jan Žorž and Kevin Meynell from Deploy360 will both be attending, and will be reporting on relevant developments as always.

In the opening plenary, there will be presentations on the DNSSEC Key Rollover in 2017 from Ed Lewis (ICANN), and the effect of the DNS on Tor’s anonymity from Laura Roberts (Princeton University). This will be followed by several lightning presentations as yet to be announced.

Jan will once again be chairing the BCOP Task Force on Monday evening starting at 18.00 UTC+2. This will discuss progress on documenting best current operational practices, with a new BCOP on IPv6 prefix assignment for end-users to be presented, as well as how to move forward with the global BCOP repository. The Task Force is still looking for volunteers to help support the task of writing other identified BCOPs in the pipeline.

Tuesday is mostly a plenary session, but looks to have some interesting talks lined-up. There are two presentations on RPKI adoption that examine how this has contributed to route security, another on the security implications of IPv6, and a report on expected IPv4 transfers. There’s also a couple of interesting IPv6 case studies being presented on IPv6 addressing in CDNs, and why Rabobank implemented IPv6.

However, be sure to catch the ‘Internet of Stupid Things’ presentation from Geoff Huston (APNIC Labs) who’s always good value for money, and whilst it’s not specifically a Deploy360 topic, it would be worth checking out the ‘Quantum Internet’ presentation from Stephanie Wehner (Delft University of Technology).

On Tuesday evening, there’s also a BoF on IoT security that will discuss stability and security issues of this ever-expanding network of devices, including how botnets pose a substantial threat to the very infrastructure those devices depend upon.

Wednesday and Thursday are set aside for Working Groups, and we’ll be following the IPv6DNS and Routing Working Groups and reporting on developments there.

The IPv6 Working Group will include a short update from Jan on active proposals for IPv6 BCOPs, and on his experiments with NAT64. There will also be an update on using 464XLAT in Residential Networks from Jordi Palet Martinez (Consulintel), and on the Sunsetting of the SixXS tunnel broker service (that we previously reported on) from Jeroen Massar.

The Routing Working Group will have a presentation on MANRS from Ben Maddison, whilst over in the DNS Working Group it would be worth catching the presentation on DNS Privacy Enhanced Services from Benno Overeinder (NLnet Labs).

Finally on Friday, along with the regular agenda items, there will be presentation on BGP Flow Specification Interoperability from Christoph Loibl (next layer).

There are again over 600 registered attendees, so it’s sure to be a busy and productive week. For those of you who cannot attend in person – there is remote participation available with audio and video streaming and also a jabber chat room, so everyone is welcome to participate!

The full programme can be found at:

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

Securing Routing: MANRS, RPSL & RPKI @ APRICOT 2017

To wrap-up our reports on APRICOT 2017, we’d like to highlight the Network Security session that featured our Internet Society colleague Andrei Robachevsky, as well as highlight other routing security related topics.

Andrei presented the Mutually Assured Norms for Routing Security (MANRS) initiative that has now been running for two years. This aims to address the issue that BGP is largely based on trust, with no inherent validation of the legitimacy of routing updates and limited ways of authenticating Internet resource data. Whilst there are tools and techniques to improve this, these only have limited deployment and there’s little incentive to do so as implementing them on your own network has little direct benefit to yourself.

MANRS therefore 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 global validation. The initiative was launched on 6 November 2014 with 9 network operators, and has since expanded to encompass 90 Autonomous Systems.

In order to help network operators facilitate the actions, a MANRS Best Current Operational Practices (BCOP) document has been produced, and a set of online training modules is under 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 with IXPs, 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 Routing Resilience Manifesto website.

Tom Paseka (Cloudflare) then covered some of threats to the Internet in more detail, and how to mitigate them. Spoofing and Denial-of-Service attacks were becoming wider in scope and involving more-and-more bandwidth such as the Mirai botnet that exceeded 500 Gb/s. A number of recommendations and techniques exist to mitigate these attacks, but operators and vendors in many cases simply did not implement these. There needed to be more awareness and responsibility amongst those involved in provisioning networks about the collective security of the Internet.

On the practical side of things though, there was a tutorial held during the conference on how to implement RPSL and RPKI which are two ways of improving security. Routing Policy Specification Language (RPSL) is used by network operators describe their routing policies, whilst Resource Public Key Infrastructure allows the holders of Internet resources (IP address and AS numbers) to be authenticated and can be used to prevent route hijacking.

Securing Internet Routing: RPSL & RPKI Tutorial

Deploy360 Domain Name System Security Extensions (DNSSEC) Events Improving Technical Security

RIPE 72 – Highlights from Day 4 & 5

RIPE 72The RIPE 72 meeting was happening last week in Copenhagen, Denmark, and we’ve been highlighting the presentations and activities related to the Deploy360 technologies. In this post we’re summarising the last couple of days of activity before the meeting drew to a close.

The Thursday was also mostly devoted to Working Groups, including the second part of the IPv6 Working Group. We have highlighted this before, but it’s worth mentioning again the report on IPv6 deployment in Latin America and the Caribbean from LACNIC. This is a comprehensive survey of the current state of IPv4 exhaustion, case studies of IPv6 deployments, but perhaps more interestingly the problems, challenges and regulatory barriers that were experienced. The report also provides insight into the rationale of those ISPs not currently considering the deployment of IPv6.

This was followed by a useful presentation on Going v6-only at home by Luuk Hendriks (University of Twente) which aimed to get an IPv6 only Wireless LAN up and running in a home environment. The rationale was to find a solution that is generally deployable and therefore not to have to buy any special hardware or require hacks, as well as discover which elements had shortcomings. It transpired that problems were mostly related to applications insufficiently supporting IPv6, but the primary issue proved to be a lack of AAAA records that effectively disabled IPv6. Whilst there are workarounds such as NAT64 and DNS64, there remains a question mark over how these can support DNSSEC as we highlighted last week.

On a similar theme was the presentation on How to Make Trouble for Yourself – You Build an IPv6-Only Network in 2016 from Roger Jørgensen (nLogic). This was about the challenges of building a next generation network serving the Norwegian county of Troms which is situated in the Arctic and requires the deployment of IPv6 to ensure it can support future requirements for the next 25-30 years. Given the remoteness of the region it’s essential that Customer Premises Equipment (CPE) is reconfigurable and IPv6 manageable, but the first challenge was a lack of DHCPv6 support which meant static IPv6 addresses needed to be configured via an uploadable config file which allows the CPEs to then be registered with the Junos Space Management Platform which does fully support IPv6.

The IPv6 Working Group session was rounded off with the results of a survey about which open source code repositories were available via IPv6. As of the end of 2015 there were 25,522 ports located on 5,344 hosts in the FreeBSD ports collection. Of these, 3,925 hosts only had an IPv4 address whilst not one host only had an IPv6 address, meaning there were 1,419 hosts with both an IPv4 and IPv6 address although 359 of these did not have a resolvable DNS record. Just 10,308 ports could therefore be downloaded with IPv6, although if you add in dependencies then this rises to 17,715 ports (69.4% of the total) that cannot be built by an IPv6-only user.

It’s worth balancing this up though, with the presentation from Jen Linkova (Google) during the final plenary session about Google’s public DNS64 server that is currently in beta. More information is available at

Over in the DNS Working Group there were several presentations related to DNSSEC. First up was Duane Wessels (Verisign) who summarised the changes to the Zone Signing Keys (ZSKs) for the root zone that is planned to change to 2,048 bits, followed by rollover of the Key Signing Key (KSK). This was followed by presentation on ZSK controlling from Paul Ebersman (Comcast), with the session rounded off with a panel discussion on the issues to address with the DNS. The DNS Manifesto summarises much of this, including the issues related to DNSSEC and the lack of data encryption.

Last, but not least we need to highlight a couple of appeals made during the Routing Working Group related to Deploy360 technologies. The first was on RPKI Validation from Alex Band (RIPE NCC) which summarised RPKI update in the RIPE region, as well provided a review of existing RPKI validation software including the RIPE NCC implementation. The RIPE NCC validator had been built somewhat as a proof of concept, but suffered from high CPU and memory usage with the growing data set, and did not leverage data from the Internet Routing Registry. They therefore wish to redesign this, and are asking for community feedback on the feature set.

The second appeal was made by Job Snijders (NTT) who asked network operators not to accept route announcements from external neighbours containing ‘bogon’ ASNs. NTT will adopt the policy of not accepting ASNs 23456, 64496-131071 and 4200000000-4294967295 from July 2016 as these numbers are variously reserved for private use, documentation/code examples or other reasons and should not be routed. They are normally seen due to misconfigurations or bugs, but can also be used maliciously and should be eliminated from the global routing table.

So that’s it from us for RIPE 72 which proved to be a week that broke all attendance records. All the presentations from the meeting can be found on the RIPE 72 website.

The next RIPE meeting will held on 24-28 October 2016 in Madrid, Spain. We look forward to seeing you then!


Building Trust Improving Technical Security

Is IP Spoofing A Problem Worth Solving?

During RIPE 71 last week in Bucharest, Benno Overeinder from NLnetLabs and I organised a BoF to discuss the problem of source IP spoofing.

Some may ask with a certain level of frustration, “Anti-spoofing?!! Source address validation?! BCP 38?! Again?!” Indeed, visible progress in anti-spoofing has been quite disappointing. Despite existing technical solutions and more than a decade of consistent evangelizing, not much has changed by the look of the symptom – most notably reflection-amplification DDoS attacks. They have only gotten bigger!

Several aspects make this problem especially tough.

  • Existing technical measures are only effective and applicable close to the edge – computers and other end-devices connected to the net. This requires deployment of anti-spoofing measures by a vast majority of networks on a global scale – something that is not easy to achieve.
  • Accountability is a problem. Tracing spoofed traffic back to its real source is impossible in the majority of cases
  • The business case is very weak. There are network types where confidence in the validity of the source IP address is important for their proper operation, but in general, and coupled with the lack of accountability, implementing source address validation has costs and does not bring real benefits for an individual network.
  • We do not even know where we are. There is a challenge in detecting “spoofable” networks and therefore a lack of statistically representative data regarding the state of affairs. It is impossible to say how the situation has changed over last decade.

And so, we had to pose a question as to whether solving this problem is worth it at all. Should we, as a community and as individual operators, concentrate our efforts on reactive measures of mitigating the outcome of the spoofing – a volumetric DDoS attack? Should we make mitigation measures more accessible, less costly, more automated and more effective?

And, in general:
Are we solving the problem?
Are we solving the right problem?
Are we solving it in the right way?

There was an interesting discussion and people lined up at the microphone. It was hard to expect a breakthrough, but from my perspective three points were reinforced:

Measurements. Being able to identify source address validation capabilities (or lack thereof) is an essential element of any solution in this space. Otherwise, it is like tilting at windmills.

Spoofer is a good start. But the number of measurements is too low and their location is somewhat biased. We need to expand these and find and correlate these data with other sources to produce a more statistically representative set.

Incentives. Without a stronger business case we cannot expect a solution at scale. This is, unfortunately, not telling the BCP38 story better, this means creating better incentives. This might need both a carrot and a stick.

A carrot could be a self-enforcing reputation of a growing group of adopters of these measures that publicly declare their actions – this is what MANRS is doing. The more operators join, the more important anti-spoofing measures become, the stronger the cultural shift toward collaborative security will be.

A stick might be liability. As Paul Vixie wrote recently, “In the world of credit cards, ATM cards, and wire transfers, state and federal law explicitly point the finger of liability for fraudulent transactions toward specific actors. And in that world, those actors make whatever investments they have to make in order to protect themselves from that liability, even if they might feel that the real responsibility for preventing fraud ought to lay elsewhere. We have nothing like that for DDoS. The makers of devices that become part of botnets, the operators of open servers used to reflect and amplify DDoS attacks, and the owners and operators of networks who permit source address forgery, bear none of the costs of inevitable storms of DDoS traffic that result from their malfeasance.”

People still consider this a problem worth solving. The general feeling is that abandoning it will just make the mitigation part harder and harder, not cheaper and simpler. At the same time anything that contributes to the effective mitigation of a DDoS attack should be taken as an integral element of the overall solution.

Please let us know if you have thoughts on anti-spoofing or ideas on how to address it – and whether or not you think it is a problem worth solving. We’ve created a mailing list to follow up the BoF discussions at RIPE, which you can join at Or, of course, you can always comment here on the blog or on Twitter, Facebook, or Google+.

Deploy360 Improving Technical Security IPv6

RIPE 71 – Highlights from Day 2

RIPE71_logoThe RIPE 71 meeting is happening this week in Bucharest and each day we’ll be highlighting the presentations and activities related to the Deploy360 technologies.

Most of Tuesday was taken up by the plenary session, but well worth highlighting is the presentation by George Michaelson on IPv6 deployment. Since 2010, APNIC has been collecting 12-15 million samples per day using placement of adverts through Google on selected websites. This has previously been undertaken with Flash, but due the increasing security issues that are leading browsers to discontinue support, they have recently moved to using an HTML5 model. In fact, with Flash predominantly running on Windows-based platforms, they are now seeing a wider range of operating systems and browsers, as well as getting a good insight into cellular networks for the first time.

One significant recent IPv6 deployment is by cable provider Sky UK which is upgrading approximately 80,000 customers to per night, with nearly 17% of their hosts currently enabled for IPv6. Whilst this dwarfs any other UK provider, it puts them on target for 20%+ IPv6 capability by 2016.

T-Mobile USA is also known to have deployed 464XLAT which allows clients on IPv6-only networks to access IPv4-only services. This is predominantly a cellular provider with some WiFi services, and is indeed showing around 60-80% IPv6 capability. Android devices in particular show high consistent usage of IPv6 capability, and with Google, Facebook, CloudFlare and Akamai routinely supporting dual-stack content, this is reducing the CGN/NAT requirement for IPv4. It should be noted though, that Apple does not implement 464XLAT in its iOS devices, which explains the very low visibility of these devices.

SK Telecom in Korea is deploying 464XLAT to its 20 million customers as well, and has converted approximately 4 million devices to IPv6 capability. As Korea has more mobile users than broadband users, this deployment along probably amounts to a 2% IPv6 penetration rate in Korea.

Over in the US, a number of the major providers including AT&T Verizon Cellular, Comcast and Sprint appear to have been deploying true dual-stack on cable and wireless networks as similar prominence of iOS devices can be seen alongside Android devices. There are exceptions seen on the AT&T and Sprint cellular networks suggesting 464XLAT deployment, but interestingly iOS devices are still seen in some numbers which may relate to APN problems or even vendor marketing preferences with respect to the handsets.

Check out George’s excellent presentation for more information on deployments in Ecuador, Brazil, Peru, Poland, Norway and Romania and the suppositions about how they’re provisioning IPv6.

Later that evening was the well attended Anti-Spoofing BoF chaired by ISOC’s Andrei Robachevsky and Benno Overeinder of NLnet Labs. This presented the problems of spoofed Internet traffic and outlined some of the solutions, but posed the question as to whether the problem was being solved in the right way, or should community efforts be better focused on the attacking vectors of a DDoS attack. The aim was to understand the challenges from the perspective of IXP customers (e.g. ISPs, CDNs) and to discuss their future needs, and led to a long and fruitful discussion running well over the time allocated for the session. Andrei will be posting more over on the Tech Matters Blog shortly.

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at

Deploy360 Events Improving Technical Security IPv6

RIPE 71 – Highlights from Day 1

RIPE71_logoThe RIPE 71 meeting is happening this week in Bucharest and each day we’ll be highlighting the presentations and activities related to the Deploy360 technologies.

To kick-off, is the interesting initiative presented by Randy Bush during the opening plenary on the Automated Certificate Management Environment (ACME). Currently only between 40% and 60% of web and e-mail traffic is encrypted over TLS, but obtaining and managing digital certificates is not always straightforward, prone to error and can be expensive. ACME aims to offer a standards-based REST API for Certification Authorities (CAs) allowing system administrators to automatically obtain trusted certificates without any human intervention. This is accomplished by running a certificate agent that proves to the CA that a server controls a domain, allowing it to request, renew, and revoke certificates for that domain.

This initiative is currently supported by Let’s Encrypt, but the IETF ACME Working Group has produced an Internet Draft with the view to making ACME a common standard. There are three steps to obtaining a certificate that include generating a key pair that identifies that a server controlling one or more domains, before validating that it controls those domains through a challenge response. A Certificate Signing Request is then generated which is then sent to the CA which can then issue the certificate, all using JSON over HTTP.

Let’s Encrypt is also provisioning a free CA (supported by sponsors) which only supports automatic issuing of certificates through ACME in order to encourage uptake of the technology. This CA is already in the global root distributions, and aims to go into full production from 3 December 2015 with a beta service already being available.

It’s also worth pointing out the presentation given by Marco d’Itri on BGP Security at IXs. This reported on an experiment that was undertaken to test which networks would accept incorrect routes that a peer announced to them, demonstrating a sizeable number of vulnerable networks at major Internet Exchanges. Quite concerning results, but another good reason to point operators in the direction of the Routing Resilience Manifesto.

Last but not least, Jan Žorž was chairing the BCOP Task Force during the evening. There were five BCOP documents up for discussion in this session relating to low-cost community-owned exchanges, IPv6 in Enterprises, IPv6-only networks, network security recommendations, and MANRS Implementation. As mentioned in yesterday’s blog post, the group was looking for help to support the task of writing the documents and several volunteers put themselves forward,  but some more help is still required for the IPv6-only BCOP document if you feel you can contribute.

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at

Building Trust Improving Technical Security Open Internet Standards Technology

New Whitepaper Explores Ways to Make IP Spoofing a Problem of the Past

In March 2013, Spamhaus was hit by a significant DDoS attack that made its services unavailable. The attack traffic reportedly peaked at 300Gbps with hundreds of millions of packets hitting network equipment on their way. In Q1 2015, Arbor Networks reported a 334Gbps attack targeting a network operator Asia. In the same quarter they also saw 25 attacks larger than 100Gbps globally.

What is really frightening about this is that such attacks were relatively easy to mount. Two things made these attacks possible: bots with the ability to spoof the source IP address (setting it to the IP address of a victim) and “reflectors” – usually open DNS resolvers. A well selected DNS query can offer a 100-times amplification, meaning that one needs only to generate queries totaling 3Gbps to create a merged flow of 300Gbps. A relatively small set of clients can accomplish this.

Of course there are DDoS attacks that do not use these two components; they hit the victim directly from many globally distributed points. But they are traceable and two orders of magnitude more difficult and expensive to accomplish.

Mitigating the reflection component of the attack is one way of addressing the problem. As reported by the OpenResover project, in the last two years the amount of open DNS resolvers has dropped almost by half – from 29M to 15M. However, there are other types of amplifying reflectors – NTP and SSDP are among them, and even TCP-based servers (like web servers, or ftp servers) can reflect and amplify traffic.

And reflectors are just the accomplices. The root cause of the reflection attacks lies in the ability to falsify, or spoof, the source IP address of outgoing packets. As Paul Vixie put it, “Nowhere in the basic architecture of the Internet is there a more hideous flaw than in the lack of enforcement of simple SAV (source-address validation) by most gateways.”

Tackling this problem is hard. Lack of deployment of anti-spoofing measures is aggravated by the fact that the implementation of anti-spoofing measures is often incentive-misaligned, meaning that networks only help other networks by implementing the practice and do not directly help themselves. There are also real costs and risks for implementing anti-spoofing measures.

In February 2015, a group of network operators, security experts, researchers and vendors met at a roundtable meeting organized by the Internet Society with a goal to identify various factors that aggravate or help solve the problem, and to identify paths to improve the situation going forward.

The main conclusion is that there is no silver bullet to this problem and if we want to make substantive progress it has to be addressed from many angles. BCP38, which is sometimes promoted as *the solution* to the problem, – is just one tool, not effective in some cases. Measurements, traceability, deployment scenarios and guidance, as well as possible incentives, communication and awareness – are among the areas identified by the group where positive impact should be made.

For example, measurements and statistically representative data are very important; if we want to make progress, we need to be able to measure it – the ability currently missing to a great extent.

Another recommendation that came out of this meeting was the possibility of anti-spoofing by default. The only place you can really do anti-spoofing is the edge (or as close as possible). Addressing the challenge at the edge seems only possible with automation and if anti-spoofing measures are switched on by default.

Read more about this in a whitepaper that contains the main takeaways from that discussion and articulates possible elements of a comprehensive strategy in addressing source IP address spoofing challenge.

I ask you to read the whitepaper, and ultimately deploy these anti-spoofing technologies in your own network. Can you do your part to prevent DDoS attacks? And if you are willing to do your part, how about signing on to the Mutually Agreed Norms for Routing Security (MANRS) and joining with other members of the industry to make a more secure Internet?

Deploy360 Events Improving Technical Security

SINOG 1.6 workshop on DDoS and AntiSpam for Network Operators

SINOG_1.5 workshop
SINOG_1.5 workshoThep

The SINOG (Slovenian Network Operators Group) organized an interim meeting on topic of DDoS mitigation techniques and AntiSpam tools for operators. This meeting turned into a workshop with some good presentations from experienced operators about how they are doing this in practice and also from some vendors to see what’s available on the market for this purpose. While the initial thought was of 30 – 40 attendees this topic seems to be very popular, as now we are expecting more than 100 people to show up and listen to this 4 hours event with packed agenda of good talks. Workshop starts today (1st April) at 16:00 CET (and that’s not a joke 🙂 ) and below you can also find a video stream link.

The workshop will be opened by Matjaž Straus Istenič (SINOG chairman) and then further chaired by Urban Kunc (SINOG co-chair) and myself.

Previous workshop (SINOG_1.5) theme was WiFi for operators and attendance turnout was brilliant, but we never expected that SINOG_1.6 would bring in even more people.

On 9th/10th of June Go6 Institute is organizing 10th Slovenian IPv6 summit (first day) and SINOG2 meeting (second day) and preparations for the “big” event are already underway. If you have any interest in operators community in this region and would like to propose a talk – please send an email to organizers <>.

Today workshop will be video recorded and streamed live, if you speak Slovenian or you are just curious what’s going on there – you can join the live stream.


Onwards and Upwards

Happy New Year 2015Wow! What an amazing year 2014 has been.

Here at Deploy360 we’ve been extremely busy! Whether it was organizing meetings, hosting meetings, creating content, curating content, public speaking, researching, meeting new people, making plans with old friends, or traveling between all of these things (so many planes), we’ve barely had time to catch our breath this year!

Because I know your time is as short as ours, let’s quickly run through some of the highlights you helped us achieve! In 2014, we:

We also saw IPv6 traffic (as measured by Google) exceed 5%, DNSSEC-signed top-level-domains (TLDs) hit 614 or 788, and a massive increase in awareness of the need for TLS and anti-spoofing, as well as for properly securing BGP.

With all that great news, and while I hope everyone is getting a bit of much needed rest during the holiday season, this is still no time to start feeling too satisfied with ourselves. If we thought 2014 was busy, I think we’ll be further surprised by what we can get done together in 2015! Of course, just as for the past three years, Deploy360 will only be as successful as our community is strong – we need your help.

Let’s now look briefly at a few of the things we’ll be working on this year, and how you can contribute:


Deploy360 remains the flagship project of our humble team here at ISOC. With your support we will continue to build the best repository of deployment and operationalization material on IPv6, DNSSEC, Securing BGP, TLS, and Anti-Spoofing – as well as any new topics that present themselves. Our goal is two-fold in 2015; to build out our resources by fulfilling our content roadmaps, and to translate the most useful and often referenced resources into as many languages as is practical. Both of these things are in progress.

We already have work underway to translate a large portion of our website, including many of our resources, into the five UN languages other than English. Over the next few weeks and months, you will see these translations published here on the Deploy360 website. This is not the end however, but just a beginning. We’ll continue to identify top resources and new languages to continue our translation efforts through 2015 and beyond. We look forward to your input and feedback. Both on which resources to translate and what languages to translate them into.

At this time we don’t have any plans for new Deploy360 topics. This means that we will be fully focused on the existing topics and on adding to this site the most helpful resources for deploying those technologies. This is the number one area that you, as an individual, can help out. We need Subject Matter Experts (SMEs) and folks who have deployed IPv6, DNSSEC, secure BGP, TLS, and anti-spoofing in their networks and their applications to document their experiences and to share them with those who still need to deploy these key technologies. I ask all of you to give us a few hours, or a couple days, of your 2015 to write case-studies, lessons-learned, tips-n-tricks, pit-falls, and everything else you’ve learned; share them here on the Deploy360 website and/or present them at an ION conference. This is one of the most direct ways that you can contribute to the future evolution of the Internet, and we’d love to share your story!

We also always need additional sponsors, particularly for the ION conference series – if you want to explore opportunities, let us know!


While the Best Current Operational Practice (BCOP) groups that have sprung up around the world are fully independent and none are owned in any way by the Internet Society (in fact, the idea is much older than Deploy360), we are committed to continuing our support. We remain dedicated to facilitating the creation of additional BCOP groups wherever they make sense, to helping the existing groups grow and expand, and to finding a proper home for the now evidently needed global repository of BCOPs.

This is another area where our team at ISOC cannot possibly create success alone. These must, by definition, be community efforts. The Deploy360 team will continue to help organize, promote, and facilitate BCOP groups around the world. However, without the participation and support of the Global Network Engineering Community (GNEC), these groups will never flourish. Here again, I invite you to help make a difference in our industry, and in our world, by contributing a portion of your time in 2015. You can shepherd a document with little to no subject matter expertise. If you are a SME on virtually any network engineering topic, you can contribute as an author and/or editor of a new or existing BCOP document. There are also opportunities for leadership within the various groups, task forces, and committees that have sprung up all over the world – including a new one you might create!

Operators and the IETF

I’m extremely proud of the course our new-in-2014 Operators and the IETF project has taken. It’s a very honest pride because this is yet another project that is successful only because of your participation. We are merely facilitators. The effort’s entire direction has been set by a survey and a multitude of interviews, formal and informal, with network operators from around the world.

The best part about this work, for me, is that it has transcended its original purpose. While we remain dedicated to helping network operators of all types contribute to, and benefit from, the IETF; it has become obvious that the problems (perceived or otherwise) we have uncovered are much more universal. It’s my hope that our (the deploy360 team along with you and the rest of our amazing community) efforts will not only benefit network operators but all newcomers to the IETF. This includes of course the new generation of network savvy developers, to name just one additional group.

You can jump in and help in a number of ways. To get involved, or just learn more, join the ‘synergy‘ mailing list and/or contact us directly.


While DNSSEC is one of our Deploy360 topics, we’ve also taken on support of the protocol above and beyond the typical Deploy360 topic. This will not slow down in 2015. In fact, it’s accelerating in some ways. We’ll continue to support the DNSSEC Deployment Workshops and related events. We’ll continue to publish the weekly DNSSEC deployment maps. We’ll continue our support of New this year, we will also be funding work to accelerate the deployment of the DANE protocol – and through that DNSSEC.

Watch our blog for more developments in this area as they happen, as well as more ways to get involved (we always need sponsors for our work).

Onwards and Upwards

As I hope is clear, 2015 is set up to be another banner year for Deploy360 and all of our supporting programmes and projects. We (the Deploy360 team and you, the Deploy360 community) drove into the future in 2014. With your continued commitment we will maintain that trajectory, onwards and upwards – into the foreseeable future and beyond!

Thank you all! For everything we’ve accomplished together so far, and for everything we’ll get to do in 2015!

We look forward to hearing from you soon.

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

IETF 91 Rough Guide On Routing Resilience And Security – De-aggregation, Route Leaks and more

IETF LogoWhat will be happening next week at IETF 91 with regard to improving the security and resilience of the Internet’s routing infrastructure?

Our colleague Andrei Robachevsky tackles this question in his post this week: “Rough Guide to IETF 91: Routing Resilience & Security“.

Andrei explains that one of the major issues in routing right now is the growth in the size of the global routing tables and the growth of “de-aggregation”… and the challenges that lie therein.  He also writes about “route leaks” and what is being done to address this issue and he writes about the ongoing work related to RPKI in the SIDR working group.

He finishes up talking about the MANRS initiative announced yesterday  and how that can help with overall routing security and resiliency.

Please do read Andrei’s Rough Guide post … and then do check out our topic areas on Securing BGP and Anti-spoofing to learn more about how you can secure your routing infrastructure.  We will look forward to seeing some of you next week at IETF 91!

Deploy360 Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (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.