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

RIRs Enhance Support for Routing Security

BGP hijacking and route leaks represent significant problems in the global Internet routing systems, along with source address spoofing. BGP hijacks are where allocated or unallocated address space is announced by entities who are not holders and are not authorized to use it.

The announcement of allocated address space often creates big news, such as when 53 route prefixes of Amazon were hijacked, but the announcement of unallocated address space (whether IPv4, IPv6 or AS numbers) which are also known as ‘bogons’ often does not generate much publicity as it does not cause immediate disruptions to service or business. With depletion of the IPv4 address space though, the announcement of bogons are on the rise with miscreants scraping the unallocated address space from all RIRs and abusing it.

Resource Public Key Infrastructure (RPKI) was therefore developed to try to solve these problems, and APNIC (the Routing Internet Registry for the Asia-Pacific region) recently announced it will honour the creation of AS0 ROA objects. They join ARIN, AfriNIC and the RIPE NCC in supporting AS0 ROA objects, with only LACNIC yet to implement this.

APNIC members can create AS0 ROAs for the prefixes they manage using the MyAPNIC platform.

So, what is the significance of AS0 ROAs? A quick overview of ROA is in order before explaining the importance of AS0 ROA. According to RFC6483:

A “route” is a unit of information that associates a set of destinations described by an IP address prefix with a set of attributes of a path to those destinations.

The Border Gateway Protocol (BGP) relies on the assumption that the Autonomous System (AS) that originates routes for a particular prefix, is authorized to do so by the holder of that prefix. A Route Origination Authorization (ROA) is used to verifiably assert that the holder of IP address space is authorized to originate routes from a given set of prefixes.

A ROA identifies a single AS that has been authorized by the address space holder to originate routes, and provides a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number.

The information in the ROAs can be used by networks using BGPto perform Route Origin Validation (ROV) on incoming BGP advertisements. ROV allows BGP speakers to determine if they should accept the routes being advertised to them as real, and is based on the state of a received announcement which can be Valid, NotFound, or Invalid.

  • Valid – The announcement is covered by at least one ROA
  • NotFound – The announcement is not covered by any ROA
  • Invalid – Announcement that contradicts ROA information. It can be an AS of unauthorised origin AS, or that the announcement is more specific than is allowed by the maximum length set even if it originates from a valid AS number.

What must be remembered is that RPKI validation relies on the availability of RPKI data, and therefore RPKI caches should be located close to routers that require this data (we are not going to discuss Relying Party-RP or RTR Protocol here).

Up until September 2012, AS0 was listed in the IANA Autonomous System Number Registry as “Reserved – May be used to identifying non-routed networks”. This status was updated with RFC7607 which redefined AS0 in line with RFC6491 “Resource Public Key Infrastructure (RPKI) Objects Issued by IANA”:

AS0 ROA: A ROA containing a value of 0 in the ASID field. “Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)”

Whereas, RFC6483 defines the term “Disavowal of Routing Origination”.

“A ROA is a positive attestation that a prefix holder has authorized an AS to originate a route for this prefix into the inter-domain routing system.  It is possible for a prefix holder to construct an authorization where no valid AS has been granted any such authority to originate a route for an address prefix.  This is achieved by using a ROA where the ROA’s subject AS is one that must not be used in any routing context.  Specifically, AS0 is reserved by the IANA such that it may be used to identify non-routed networks

A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context. The route validation procedure will provide a “valid” outcome if any ROA matches the address prefix and origin AS even if other valid ROAs would provide an “invalid” validation outcome if used in isolation.  Consequently, an AS0 ROA has a lower relative preference than any other ROA that has a routable AS, as its subject.  This allows a prefix holder to use an AS0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered “invalid”, while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes.”

This means that AS0 in a ROA can be used to mark a prefix and all its more specific prefixes as Invalid and not to be used in a routing context. By publishing a ROA that lists AS0 as the only origin, it allows a resource holder to signal that a prefix (including its more specific prefixes) should not be routed. In other words, a BGP speaker should not accept or propagate routes containing AS0.

RFC7607 codifies the BGP speaker behaviour to handle AS0.

“A BGP speaker MUST NOT originate or propagate a route with an AS number of zero in the AS_PATH, AS4_PATH, AGGREGATOR, or AS4_AGGREGATOR attributes. 

An UPDATE message that contains the AS number of zero in the AS_PATH or AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in RFC7606 “treat-as-withdraw”

An UPDATE message that contains the AS number of zero in the AS4_PATH or AS4_AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in RFC6793 “attribute discard”

If a BGP speaker receives zero as the peer AS in an OPEN message, it MUST abort the connection and send a NOTIFICATION with Error Code “OPEN Message Error” and subcode “Bad Peer AS” (see Section 6 of RFC4271).  A router MUST NOT initiate a connection claiming to be AS0.”

Returning to RFC6491, this ‘Recommends’ that IANA issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed, to all Unallocated Resources – namely Resources that have not yet been allocated for special purposes to Regional Internet Registries (RIRs) – or to other resources that are not intended to be globally routed.

This measure can greatly enhance the effectiveness of RPKI and routing security in general, but network operators should also take a look at the MANRS initiative – which is supported by the Internet Society. This specifies additional actions including filtering, anti-spoofing, coordination, as well as support for global validation mechanisms such as RPKI and currently encompasses over 200 Autonomous Systems around the world, including some of the largest ISPs.

If you’re a network operator or IXP, then please see how you can help contribute towards improving the security and resilience of the global routing system.

Further Information

Domain Name System (DNS) Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

APNIC Labs/CloudFlare DNS Outage: Hijack or Mistake?

At 29-05-2018 08:09:45 UTC, BGPMon (A very well known BGP monitoring system to detect prefix hijacks, route leaks and instability) detected a possible BGP hijack of prefix. Cloudflare Inc has been announcing this prefix from AS 13335 since 1st April 2018 after signing an initial 5-year research agreement with APNIC Research and Development (Labs) to offer DNS services.

Shanghai Anchang Network Security Technology Co., Ltd. (AS58879) started announcing at 08:09:45 UTC, which is normally announced by Cloudflare (AS13335). The possible hijack lasted only for less than 2min. The last announcement of was made at 08:10:27 UTC. The BGPlay screenshot of is given below:

Anchang Network (AS58879) peers with China Telecom (AS4809), PCCW Global (AS3491), Cogent Communications (AS174), NTT America, Inc. (AS2914), LG DACOM Corporation (AS3786), KINX (AS9286) and Hurricane Electric LLC (AS6939). Unfortunately, Hurricane Electric (AS6939) allowed the announcement of originating from Anchang Network (AS58879). Apparently, all other peers blocked this announcement. NTT (AS2914) and Cogent (AS174) are also MANRS Participants and actively filter prefixes.

Dan Goodin (Security Editor at Ars Technica, who extensively covers malware, computer espionage, botnets, and hardware hacking) reached out to Cloudflare about this possible hijack and received following statement from Cloudflare PR stating that they are ruling out any malicious intent and there was no drop in customer traffic and it was fixed quickly, but also blamed Hurricane Electric (AS6939) for the leaked route.

Considering this just a configuration mistake which was rectified quickly and didn’t cause any reported damage but it doesn’t solve the problem and there is a possibility that someone with a bad intent can do a lot of harm like the way it was done during Amazon Route 53 hijack, unless we take appropriate steps towards a secure and resilient internet.

Once again, this attack would have been easily avoided if proper prefix filtering was done by Hurricane Electric. As discussed in the previous blog, MANRS can be part of the solution here. Mutually Agreed Norms for Routing Security (MANRS) calls for four simple, but concrete actions ALL network operators should take to reduce the most common routing threats. The first is filtering, which prevents the propagation of incorrect routing information (others are anti-spoofing, address validation, and global coordination.).

So, what are you waiting for? Be part of the solution and help protect the core. Join MANRS.

Deploy360 IPv6

NAT64check proves popular

We’ve already mentioned this a few times this year, but we’ve just published an more in-depth article about NAT64check over on the RIPE Labs and APNIC websites.

NAT64check is a tool developed by the Internet Society, Go6, SJM Steffann and Simply Understand that allows you to enter the URL of a particular website, and then run tests over IPv4, IPv6 and NAT64 in order to check whether the website is actually reachable in each case, whether identical web pages are returned, and whether all the resources such as images, stylesheets and scripts load correctly. The rationale behind NAT64check is also explained, how it works, and how you can use it.

If you just want to take a look at the tool, then please go to either or, type the URL you wish to check into the box at the top of the page, and the result should be returned within a few seconds. It’s simple and easy, and will help you identify what needs to be done to make your website accessible with IPv6.

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



12 Steps to enable IPv6 in an ISP Network

IPv6 BadgeHere’s an quick guide on how to enable IPv6 in an ISP from Jordi Palet (Consulintel), that’s just been published by LACNIC. It’s not intended to be a comprehensive technical digest of how to deploy IPv6 in a network that currently has IPv4, but rather an summary of the 12 fundamental steps, not including services (DNS, web, email, etc..) for enabling native IPv6 support as well as maintaining IPv4 as a transparent service.

  1. Work out how many customers (home+corporate) your network has, and your expected growth in the short-to-medium term. If the total is fewer than 50,000 customers, we recommend you request a /32 from your RIR, a /31 if you have up to 100, 000 customers, a /30 for up to 200, 000 customers, and so on. If you already have a /32 and have more than 50, 000 customers, you can request an upgrade of your actual prefix. To request your IPv6 prefix, you need to contact the RIR for your region: AfriNIC (Africa), APNIC (Asia-Pacific), ARIN (North America), LACNIC (Latin American) and RIPE NCC (Europe).
  2. Audit your network, as you need to know which equipment has the right IPv6 support, and which needs to be updated or replaced. It’s important to have a detailed inventory, from your upstream connections to the customer CPEs. If your vendors don’t provide the right support, you need to be pushing them for it as the market is big and free…
  3. Get professional training from companies that have demonstrable experience with IPv6 deployment in ISPs. IPv6 is not more difficult, but IPv4 and IPv6 are different and the difficulty can be changing your mindset and it’s necessary to ‘unlearn IPv4 in order to correctly understand IPv6. Possibly will be convenient that you agree on a consultancy service together with the training. It may seem excessive, however, you will save a lot of time, as the transition to IPv6 will become more important and urgent and that time will cost much more in terms of business losses and problems with IPv4 than the cost of that training and consultancy.
  4. Confirm with your upstream providers that they have IPv6 support, enable BGP4+ with them, and do the same for CDNs, caches and IXPs. If the upstream providers don’t have IPv6 support, then you need to be looking for other partners. This part of your network must be dual-stack, but if there is no way to get dual-stack from one or more of your upstream providers, you may need to use a tunnel. This is typically provided using 6in4 (protocol 41, manually configured) or GRE, but you should consider this only as a temporary solution.
  5. Review your security policies. These should be equivalent to what you apply with IPv4, but remember that you should not filter ICMP with IPv6 amongst other things, as this will prevent the correct flow of traffic across your network. Review also the IPv6 prefix filtering with your BGP peers – these policies are again conceptually equivalent to those for IPv4, but using different protocol.
  6. Configure IPv6 support in all your monitoring systems. IPv6 has the same importance as IPv4, so any system that allows you to view traffic quality, quantity, stability, visibility of prefixes, etc.., needs to support the same with IPv6.
  7. Now that you know the differences between IPv4 and IPv6, you’re ready to design your detailed addressing plan. This is the key to correct IPv6 deployment, and is very different from IPv4. For sure, you’ll need an IPAM (IP Address Management) device or tool, as it’s impossible to manage millions of IP addresses using the traditional text file or spreadsheet methods you used with IPv4.
  8. Deploy IPv6 in your core and distribution networks. Dual-stack is possibly sufficient in the first phase, but in the next phase it may be possible to remove IPv4 from certain parts of those networks so you can reuse the IPv4 addresses elsewhere.
  9. Start a small trial in your corporate network. Remember that /64 is the minimum for each LAN or VLAN, that the golden rule is to have dual-stack in the LAN/VLANs (even when using private IPv4 addresses), and that is easier to use SLAAC and RDNNS. DHCPv6 is another option, but is usually unnecessary and Android also doesn’t support it. In this pilot phase it may be interesting to involve some of your corporate customers, even some residential ones, and you can use manual provisioning for just a few users.
  10. Prepare your access network as well as the provisioning system, and your billing systems may be affected too. It’s time to define which transition mechanism is the right one, and my recommendation is 464XLAT[1], at least for the residential customers and mobile networks. It’s also essential to have good support from the CPE vendors, and for provisioning it’s best to use DHCPv6-PD. Use the RIPE BCOP in order to understand how to number your customers.
  11. Configure PLAT (NAT64+DNS64) in your network. Don’t use CGN as it’ll bring more problems and higher costs (not only for the CGN itself, but also the logging systems). If you’ve got a mobile network with PLAT deployment and you’re setting up an IPv6-only APN, most smartphones and other 3G/LTE devices will already support this. Android and Windows devices come with the CLAT, whilst Apple/iOS/ only use the PLAT because all their apps are required to support IPv6.
  12. Update the CPEs, and try again with some customers once they’re been updated them as this is the most critical and complex part of the process.  Once done, you’re ready for your mass IPv6 activation (maybe in phases or regions, etc.) and you can make your commercial announcement!

Your network is now ready for the future, and you can start considering how to profit from IPv6 through new services and applications. IoT is the key hint, but you’ll be sure to find other advantages.

[1] 464XLAT is one of the most recent transition mechanisms (and the most widely used one with millions of users in 3G/4G networks). It has the advantage of using IPv6-only in the access network so the ISP doesn’t require IPv4 addresses there, but provides private IPv4  addresses to the users (by means of the CLAT) so that devices and applications still work in a transparent manner.

Deploy360 IPv6

The Business Case for IPv6 in Pakistan

We had a very successful ION conference in Islamabad on 25 January 2017, and amongst the interesting topics presented at the conference, it’s worth highlighting the statistics on IPv4 and IPv6 allocation in Pakistan. Let me share those in detail here.

As per the APNIC resource delegation data (as of 1 January 2017). There are 5,314,816 IPv4 address allocated to ISPs and enterprises in Pakistan. However, if you look at the graph then it shows PTCL as the holder of nearly 73% IPv4 addresses in Pakistan, leaving the remaining 27% to the rest of the ISPs and enterprises. PTCL is undoubtedly the biggest broadband provider in Pakistan and also provides services to Ufone (telco operator), so you’d expect them to have the largest user base for both wired and mobile broadband services.

The main concern though, is that it’s now only possible to obtain a /22 IPv4 prefix from APNIC (as per the last /8 policy), and those will soon be exhausted. This means that if ISPs need more IPv4 address, the only option will be to buy them open market. The current going rate for IPv4 addresses is around USD 10 for each address  in a /18 block, plus the APNIC transfer fees, which amounts to nearly USD 164K for 16,384 IPv4 addresses.

The other option is deploying Carrier Grade NAT (CGN) to put many users behind a single IPv4 address.In theory, it’s safe to consider that each user may have around 250 concurrent sessions, so with around 65,000 sessions available per IP address, it’s possible to put 250 users behind a single IPv4 address with CGN. The downside though, are that you need powerful boxes to manage that many sessions and it is difficult to guarantee performance.

There’s another graph showing IPv6 delegations in Pakistan, with a very uniform address allocation to all existing APNIC members (with few negligible exceptions). No single entity has an edge over another, and it doesn’t cost anything extra (if you already hold IPv4 addresses) to obtain IPv6 addresses from APNIC. There’s no need to install complex and difficult to manage CGN solutions, nor buy expensive IPv4 addresses from the open market. It’s an open and level playing field for all operators wanting to serve the 200 million plus population of Pakistan.

For many years there was a big debate in Pakistan about the financial benefit of deploying IPv6, but these statistics clearly illustrate the business case for doing it. You can either deploy IPv6 at minimal cost by upgrading some old hardware (very rare), or deploy CGN and buy IPv4 from open market at significant expense. The choice is yours!

Deploy360 aims to help you deploy IPv6, so please take a look at our Start Here page to understand how you can get started with IPv6.

Deploy360 Events

ION Bangladesh / bdNOG 5 in Dhaka


The Deploy360 team has just completed a couple of hectic weeks that included our ION Conference in Bangladesh, participating in SEE 5 in Albania, before Jan headed off to SEEDIG in Serbia. The ION Conference was organised jointly with bdNOG 5 on 11 April 2016 at the Lakeshore Hotel in Dhaka, and attracted a very high turnout of 152 participants. This had been preceded by three days of technical training provided by bdNOG and APNIC.

Kevin Meynell opened the event with a overview of the Deploy360 programme, followed by a welcome from Professor Shabbir Ahmed, President of the ISOC Bangladesh Dhaka Chapter.

Jahangir Hossain (ISOC Bangladesh Dhaka) then explained Secure BGP and reported on RPKI adoption in Bangladesh. There were currently 2,079 advertised IP prefixes in Bangladesh, of  which 97 had Route Origin Authorisations (ROAs) accounting for 4.67% of the total. Unfortunately, 26 of these prefixes were invalid according to their ROAs, which was something that needed further investigation.

Jan speaking about DANE

Next up was a panel session on MANRS that included Fakrul Alam (APNIC), Rashed Amin (Link3 Technologies) and Jan Žorž. This introduced the Routing Resilience Manifesto initiative that aims to help network operators around the world 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. Although the initiative was new to most of the audience, it still generated significant discussion and several network operators expressed interest in signing-up during and after the conference.

Jan then updated the audience on DANE adoption and implementing it in the go6lab. This has previously been covered in the ION Cape Town and the Let’s Encrypt certificates for mail servers and DANE blogs, but the .bd domain is not currently signed with DNSSEC which has limited potential deployment of DANE in Bangladesh. Hopefully the increasing usage of TLS and Jan relating his experiences of successfully deploying DANE will encourage the implementation of DNSSEC in the .bd domain shortly.

The session after the tea break was devoted to the bdNOG report (provided by Rashed Amin, bdNOG President) and the keynote speech on the Potential of Indigenously Developed Telemedicine using the Internet (provided by Dr. Khondkar Siddique-e-Rabbani, University of Dhaka). There were also remarks from the Chief Guest Dr. Shahjahan Mahmoud, the Honourable Chairman of the Bangladesh Telecommunication Regulatory Commission, and from the Special Guest M.A Hakim, the President of ISPAB Bangladesh.

Kevin & Jan at ION Bangladesh/bdNOG 5

After lunch, Kevin talked about what was happening at the IETF and how to get involved. He pointed out that had been 1,824 registered participants from 65 countries at the recent IETF in Buenos Aires, but not one was from Bangladesh even though India was well represented. There was clearly a very active Internet community in Bangladesh, but for whatever reason little engagement with the IETF. However, he encouraged the local community to check out the IETF Fellows and Regulators to the IETF programmes.

Pubudu Jayasinghe (APNIC) followed this with an update on the current situation in the Asia-Pacific region with respect to IPv4 address availability, how to request IPv6 addresses, and the rollout of RPKI to provide cryptographic attestations about route advertisements. The rest of the session was devoted to submitted papers including The Future of SIP in WebRTC (provided by Shaila Sharmin, Link3 Technologies) and a Holistic view of 802.1x integration & optimisation (provided by Faisal, BDPEER).

The final session focused on IPv6. Abdul Awal (BDREN) set the scene with a presentation on IPv6 deployment in BDREN, the Bangladesh National Research and Education Network, as well as the wider challenges of deploying IPv6 in Bangladesh. This led into the IPv6 Panel session moderated by Kevin that included Asela Galappattige (Sri Lanka Telecom), Nurul Islam Roman (APNIC), Sumon Ahmed Sabir (Fiber@Home), Matsuzaku Yoshinobu (IIJ) and of course Jan.

Lalbagh Fort in Old Dhaka

The panel session focused on the message that deploying IPv6 was not a complex or expensive process, but eking out IPv4 addresses would be in future. IPv4 addresses were a finite resource and would increasingly only be obtainable through recovery and trading, which would impose a real cost for network providers. This was particularly an issue in countries like Bangladesh that currently had relatively limited Internet penetration, but which had large productive and aspirational populations that would put heavy demands on address resources. IPv6 deployment was presently quite low in Bangladesh, but the experience of BDREN demonstrated that networks could be substantially enabled for IPv6 with minimal effort and limited impact on existing services.

The conference was concluded with some final remarks from Kevin, thanking the host bdNOG, as well as the sponsors Afilias, APNIC, ISPAB, ISOC Bangladesh Dhaka and the Bangladesh ICT Business Promotion Council, before the training certificates were presented. The Deploy360 team would also like to thank bdNOG and their officers for helping us bring an ION Conference to Bangladesh for the first time, as well their contributions towards making the event a successful and productive one.

The State Minister for ICT, Zunaid Ahmed Palak at the Cyber Security and Network Security Workshop

Our work was still not yet over though, as the following day Kevin was invited to open the Bangladesh Cyber Security and Network Security Workshop that was also attended by the State Minister for ICT, Zunaid Ahmed Palak. This workshop involved around 100 participants from the Internet community, academia, government as well as law enforcement agencies.


Further Information

The proceedings from ION Bangladesh are available here.


Is RPKI ready to ROA?

Securing BGPIt’s worth drawing attention to the Study and Measurements of the RPKI Deployment. This is a recently published thesis analysing the deployment of RPKI and the quality of the data, but is also worth reading for its comprehensive documentation of routing incidents, the problems they can cause, and mitigation measures that can be implemented.

The analysis reveals that the global percentage of IPv4 address space covered by a Route Origin Authorisation (ROA) was 6.03% in September 2015, although this figure varies widely between the RIR regions. The RIPE NCC and LACNIC lead the way with 18.67% and 13.87% respectively, AfriNIC comes close to the average at 5.31%, but ARIN registers just 1.98% and APNIC even further behind with just 0.40% .

Perhaps more interestingly though, an authentication analysis undertaken between March 2012 and September 2014 revealed issues with the registration of many RPKI resources, as well as a couple of RIR repositories. However, whilst the percentage of invalid RPKI-covered prefixes in 2012 was as high as 21%, this progressively dropped to just over 7% by September 2015 which indicates a decrease in problems as RPKI deployments has risen.

It’s also interesting to note that even where invalid prefixes were found, most of them were covered by another valid or not found prefix. This suggests that dropping invalid prefixes from the routing table may be less problematic than previously thought by network operators.

More Information

For more information on Securing BGP, please do look at our Start Here page to understand how you can get started transitioning your networks.

Deploy360 Events IETF

Chris Grundemann @ APRICOT 2015 to talk IETF and BCOP

APRICOT 2015After nearly 3 weeks at home (my longest stretch since last August), I’m off to join the already-in-progress APRICOT 2015 in Fukuoka, Japan.

For those who don’t know, the annual APRICOT (Asia Pacific Regional Internet Conference on Operational Technologies) is a:

Ten-day long summit consist[ing] of seminars, workshops, tutorials, conference sessions, birds-of-a-feather (BOFs), and other forums all with the goal of spreading and sharing the knowledge required to operate the Internet within the Asia Pacific region.

Learn more about APRICOT and all of the prestigious organizations who collaborate to help make it happen here.

This is a pretty massive event, and there is a ton going on next week. I’ll start with a couple of the activities I’m most involved in. Next, I’ll rundown a few other potentially exciting/informative/important sessions that caught my eye.

Operators and the IETF BoF

I’m very pleased to announce that I will be hosting a BoF on Wednesday, 4 March from 17:30 – 19:00 (local, UTC+9) in rooms 502 + 503 to talk about our project to address the perceived gap between Operators and the IETF. This project has become about more than just operators though, we’re really trying to make it easier for newcomers to bring real-world experiences into the IETF process.

I will be presenting the results from our 2014 survey of operators but the real purpose and value of this session will be the discussion in the room. We understand the problems, now let’s start finding solutions, together!

Read more about this project here, read the IETF Internet-Draft with detailed survey results here, and then come to the BoF and help us continue this conversation! Want to get a jump start? Whether or not you’ll be in Japan next week, you can join the ‘synergy‘ mailing list and join the discussion today.

One thing that makes this super exciting is that we are already testing ideas generated from this project. The IETF Help Desk is one such idea, which we’ll get to see in action in Fukuoka.

IETF Help Desk @ APRICOT 2015

Following our success with the alpha run at NANOG 63, we’ll be continuing to test the IETF Help Desk concept next week at APRICOT 2015. The IETF Help Desk is designed to be your one stop for all your IETF questions.

Reminder: This is not an official (read: approved or funded) IETF activity. We’re just a bunch of folks who happen to participate in both the IETF and APRICOT who’ve volunteered to staff the table and help our fellow community members.

IETF Help DeskWe hope to answer questions such as:

  • “Why should I participate in the IETF?”
  • “How do I get involved in the IETF?”
  • “What is the difference between an Internet-Draft and an RFC?”
  • “How do I submit an idea to the IETF?”
  • “What is the IETF working on in space?”
  • “How do I comment on an existing IETF document?”

Please come ask your questions about the IETF! Look for the “IETF Help Desk” banner.

Best Current Operational Practices (BCOP) BoF

The bad news is that the BCOP BoF is at the exact same time as the Operators and the IETF BoF. The good news is that there will finally be a BCOP BoF at APRICOT!

A BCOP is a living document describing the best operational practices currently agreed on by subject matter experts. BCOPs are vetted and periodically reviewed by the global network engineering community (GNEC). Groups around the world have formed to find, create, and share these documents in an open, transparent, bottom-up, and community-led manner. This BCOP BoF at APRICOT 2015 marks the Asia Pacific region adding support for this effort.

It may be a tough choice on Wednesday afternoon. Join the Operators and the IETF discussion, or jump in at the ground floor of an Asia-Pacific BCOP effort. Decisions, decisions. To help you decide, you can learn more about BCOP efforts globally here. If you decide to join the BCOP BoF you can find it in room 411 from 17:30 – 19:00 (local, UTC+9) on Wednesday, 4 March.

Routing Resilience Manifesto & MANRS

My colleague Andrei Robachevsky will also be there talking about the Routing Resilience Manifesto and accompanying Mutually Agreed Norms for Routing Security (“MANRS”) document. He wrote about it over on the Internet Technology Matters blog yesterday and in part, he wrote:

We are looking for leaders, the network operators who take security and resilience seriously and have already implemented the Actions outlined in MANRS, and probably many more. We are looking for leaders whose reputation will motivate others to step up and do the same.

I know that many such leading operators are planning to attend APRICOT 2015. I’ll be there, too, presenting MANRS at the Peering Forum on 3 March and the APCERT session on 4 March. But I am also looking forward to meeting with you in person and hearing your feedback and answering your questions about this initiative.

Packed Agenda

Which Wednesday afternoon BoF to attend isn’t the only tough choice you’re likely to face next week at APRICOT 2015. As usual, they have put together a great program. Here’s a few highlights from my perspective:

  • RIPE NCC Measurements Tools Workshop – Monday 09:00 – 12:30 in room 409 + 410
  • Internet Measurement – Tuesday 09:00 – 10:30 in room 502 + 503
  • Internet Society @ APRICOT 2015 – Tuesday 17:30 – 19:00 in room 411
  • APNIC Plenary on Real Mobile/Wireless Broadband – Wednesday 09:00 – 10:30 in room 501
  • Understanding and Deploying DNSSEC – Thursday 11:00 – 12:30 in room 409 + 410

Let’s Chat!

As always, one of the primary reasons I do all this travel is to get a chance to talk to you. Yes you. If you’ll be at APRICOT 2015 please let me know and let’s find some time to chat. See you soon!

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

Discussing the Routing Resilience Manifesto at APRICOT 2015

Last February at APRICOT 2014 our team organized a NetOps workshop where I presented an idea for an initiative called the Routing Resilience Manifesto. I called the presentation “Collective responsibility and collaboration for routing security and resilience,” which, in fact, captured the objective of the Manifesto.

Since then, we successfully launched the initiative (in November 2014) with nine network operators signing on to the recommended actions on day one. That list has now grown now to almost 20 operators. The primary recommendations document within the Routing Resilience Manifesto initiative is dubbed “MANRS,” for Mutually Agreed Norms for Routing Security. You can read more about it at

Twenty network operators may sound small compared to almost 50,000 ASes advertised on the Internet. But Rome wasn’t built in a day, either.

In fact, we are not looking to sign up as many operators as possible (at least not at this stage). What we are aiming at is anchoring this initiative in regions and economies so it gains recognition and local operational communities can understand and get on board with the effort’s objectives.

We are looking for leaders, the network operators who take security and resilience seriously and have already implemented the Actions outlined in MANRS, and probably many more. We are looking for leaders whose reputation will motivate others to step up and do the same.

I know that many such leading operators are planning to attend APRICOT 2015. I’ll be there, too, presenting MANRS at the Peering Forum on 3 March and the APCERT session on 4 March. But I am also looking forward to meeting with you in person and hearing your feedback and answering your questions about this initiative.

It is easy to find me – please drop me a message and we’ll work something out.

See you in Fukuoka!

Deploy360 Domain Name System Security Extensions (DNSSEC)

Video: Geoff Huston – what if everyone did DNSSEC? (APNIC 38)

What if everyone enabled DNSSEC?  What would happen to your network? Should you be scared?

The good folks at APNIC are out with a video from Geoff Huston answering these questions:

If you want to get started with DNSSEC so that your domain name can be secure from being impersonated, please visit our Start Here page to find resources targeted for your type of organization.

Help us make the Internet more secure – deploy DNSSEC validation and start signing your domains NOW!

P.S. For a good example of HOW DNSSEC can help protect you, please read our recent article about email hijacking attacks that are going on now – but could be prevented by the use of DNSSEC.

Deploy360 Domain Name System Security Extensions (DNSSEC)

Finally! A DNSSEC Validation Trend Chart – Up And To The Right!

Finally!  What I’ve always wanted for tracking the growth of DNSSEC validation by DNS resolvers is some kind of “trend chart” along the lines of Google’s IPv6 Statistics page that could show the growth in DNSSEC validation.  At the recent ICANN DNSSEC Workshop in London Geoff Huston of APNIC provided to us that exact kind of chart at the URL:

Sure, the URL is not exactly very typing-friendly, but a quick bookmark can solve that (and we’ve added it to our DNSSEC Statistics page to help in that regard).  The chart looks like:

DNSSEC Validation Trend Line


Which shows the nice upward trend.  Geoff’s team includes some other tools so that, for instance, you can set the “average interval” to 7 days and get a much smoother line:

DNSSEC validation weeklyThis is what I intend to start using now to show the growth in DNSSEC validation as we continue to see further deployment happening within networks around the world.

Speaking of geography, Geoff’s site also has a “world map” view showing DNSSEC validation by country at the URL:

Right now, of course, the map shows a whole lot of red for low levels of DNSSEC validation:

DNSSEC Validation world map


Let’s see if we can make that change!  (Deploy DNSSEC-validating resolvers on your network today! 🙂 )

A cool feature is that below the world map you can get individual trend charts for both various regions and even for individual countries.  It also shows the ranking of countries in terms of DNSSEC validation (click/tap the image to get to the page – and then scroll down to see):



Our colleague Jan Žorž may be pleased to see how high his home of Slovenia is ranking!

All of this is based on the measurements Geoff’s team has been doing using Flash-based advertising using Google’s advertising network, something he explained in a recent talk at the RIPE 68 event.

While obviously the various charts show how far we have to go in getting DNSSEC deployed, at least now we have some solid measurement charts we can use to track the progress!  Many thanks to Geoff and his team for making this site possible.

We’re looking forward to continuing to see the DNSSEC validation chart grow up and to the right!

P.S. If you want to understand how to get started with DNSSEC, please visit our Start Here page to find resources focused on your type of organization.

Deploy360 Domain Name System Security Extensions (DNSSEC)

Video/Slides – Geoff Huston On Measuring DNSSEC Usage at RIPE67

How many people are actually performing DNSSEC validation on DNS queries? What is the true penetration of DNSSEC usage?  While there are many sites offering DNSSEC statistics about the number of signed domains or TLDs, what kind of measurements can be done on the validation side of DNSSEC?  And what is the performance impact of doing DNSSEC validation?

At the RIPE67 meeting Geoff Huston of APNIC gave an entertaining presentation around these exact questions based on measurements through a system of Flash-based web advertisements he has been using.  His slides are available online and the video presentation runs about 28 minutes:

Geoff Huston speaking

The information is certainly useful and we look forward to future presentations based on these measurements!