IETF 107 Starts Today as a Virtual Meeting

Later today, the 107th meeting of the Internet Engineering Task Force (IETF) will begin its working group sessions in an unconventional way. Previously, over 1,000 engineers were expected to be in Vancouver, Canada, to engage in the IETF’s work creating the open standards that make the Internet possible.

But with the global COVID-19 pandemic, the IETF leadership decided to cancel the in-person meeting in Vancouver. Instead a scaled-down, completely virtual meeting will take place. Only 12 of the IETF’s 115+ working groups will be meeting this week. Other working groups, and the research groups of the Internet Research Task Force (IRTF) may schedule interim meetings in the weeks and months ahead.

You can participate remotely in IETF 107. The steps are all outlined in this “Guide for IETF 107 Participants“. Useful resources include:

To be clear, most of the work of the IETF in creating the Internet’s open standards ALREADY takes place online. People create “Internet-Draft” documents that propose new ways to make the Internet work better. Those documents are discussed and debated on email lists for working groups. Eventually those working groups reach “rough consensus” and the documents are published as “Requests For Comments” or simply “RFCs”.

However, sometimes people disagree about what would be best for the Internet. Sometimes people strongly disagree! Sometimes Working Groups just cannot make progress through email discussions.

And so three times a year, engineers from around the world gather in different locations to have face-to-face discussions. These are the “IETF meetings” such as the one this week. At these sessions, people can discuss and debate intensely. They can stand in long microphone lines to voice their points. They can hum in agreement or disagreement. They can also have side meetings, go to dinner or drinks with people, meet in hallways, and through all of that work out differences that help move Internet standards forward.

This week, some of those engineers (myself included) will be trying out a new model to see how well this can all work in a virtual setting.

Many thanks to the IETF leadership, secretariat, and support teams for all their work to make this “IETF 107 Virtual” happen! I am looking forward to seeing how it goes.

Please join in if you are interested in the work of the IETF!

P.S. If you are not aware of the connection between the IETF and the Internet Society, please read about our relationship.

Image credit: a photo of Vancouver from NASA


IETF 106 Begins Nov 16 in Singapore – Here is how you can participate remotely in building open Internet standards

Starting Saturday, November 16, 2019, the 106th meeting of the Internet Engineering Task Force (IETF) will begin in Singapore. Over 1,000 engineers from around the world will gather in the convention center to join together in the debates and discussions that will advance the open standards that make the Internet possible. They are gathered, in the words of the IETF mission, “to make the Internet work better“.

Pick your protocol – the future of DNS, DOH, TLS, HTTP(S), QUIC, SIP, TCP, IPv6, ACME, NTP… and many, many more will be debated in the rooms and hallways over the next week.

What if you cannot be IN Singapore?

If you are not able to physically be in Singapore this week, the good news is you can participate remotely! The IETF website explains the precise steps you need to do. To summarize quickly:

  1. Register as a remote participant. There is no cost.
  2. Review the agenda to figure out which sessions you want to join. (I will note that there are some very interesting (to me!) Birds-of-a-Feather (BOF) sessions at IETF 106.)
  3. Choose the channel(s) you will use to participate, including:
  4. Join the mailing list for the working group(s) you are interested in. While the face-to-face meeting in Singapore will have discussion, the working group mailing list is where the activity is finalized. By clicking on the working group name in the IETF 106 agenda you can find out how to join the group’s mailing list.

Again, the IETF 106 Remote Participation page has more details.

Also, watch the IETF blog, as updates are sometimes posted there (such as this post about IETF BOF sessions).

Do note that the time in Singapore is UTC+8 (this time zone conversion tool may help). For me based in the US Eastern time zone, that means many of the sessions will happen in the middle of my night. (So yes, dear DNS Operations (DNSOP) friends, this means odds are pretty good you will NOT see me online for the Thursday morning meeting as it will be 12:30am where I live! 😏)

If you find it helpful, the IETF provides an IETF 106 agenda with UTC times.

If you have never participated in an IETF meeting before

… I would suggest you review these materials first:

And then really look through the materials provided for each of the sessions you want to attend. The IETF 106 agenda has pointers to all the necessary slides and other documents. (Try the first “X” icon on the right side of the screen in the row for the working group.)

One important note I always mention to first-time attendees – you are entering conversations that are already in progress! With the exception of BOFs, all the other Working Group sessions are face-to-face discussions that continue discussion and debate from the working group email lists. There are typically no introduction tutorials or anything… you are just entering into the middle of the ongoing work of the Working Group! It can be disorienting at times because you may have no idea what people are talking about. This is why it is helpful to review the agenda and learn what documents will be discussed so that you can read those in advance.

That’s it!

With those few steps, you, too, can join with the thousands of engineers around the world at IETF 106 in the work of building open Internet standards, and helping to “make the Internet work better”.

See you online!

Image credit: a photo I took of the “supertrees” in the “Gardens by the Bay” when I attended an event in Singapore in 2013. You can view a larger set of photos. The supertrees may (or may not) have changed dramatically in the 6 years since I took these photos.

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

Internet Resilience Discussions at IETF 104

Let’s look at what’s happening in the Internet Engineering Task Force (IETF) and the upcoming IETF 104 meeting in the area of Internet infrastructure resilience. As usual, my focus here is primarily on the routing and forwarding planes, and specifically routing security and unwanted traffic of Distributed Denial of Service Attacks (DDoS) attacks. There’s interesting and important work underway at the IETF that can help addressing problems in both areas.

This time there are a lot of new ideas, especially of an operational nature, that people bring to the IETF in the form of Internet Drafts that aim to improve the security and resilience of the Internet infrastructure. So I’d like to introduce some of them to you, but keep in mind that an Internet Draft (I-D) does not necessarily indicate IETF endorsement. It also does not constitute a standard and may even not result in any work at the IETF.

So let’s look at what’s happening in BGP land.

Can BGP Communities be harmful? 

In the recent paper “BGP Communities: Even more Worms in the Routing Can“, the authors demonstrated that Border Gateway Protocol (BGP) communities can be exploited by remote parties to influence routing in unintended ways. Due in part to their ill-defined semantics, BGP communities are often propagated far further than a single routing hop, even though their intended scope is typically limited to nearby ASes. As a consequence, remote adversaries can use BGP communities to trigger remote blackholing, steer traffic, and manipulate routes even without prefix hijacking.

The problem of ill-defined semantics is aggravated by the fact that BGP communities, and especially well-known communities, are manipulated inconsistently by current router implementations. There are differences in the outcome of the “set” directive in several popular BGP implementations. For example, in Juniper Network’s Junos OS, “community set” removes all received communities, well-known or otherwise, whilst in Cisco Systems’ IOS XR “set community” removes all received communities except a few.

An I-D “Well-Known Community Policy Behavior” describes the current behavioural differences in order to “assist operators in generating consistent community-manipulation policies in a multi-vendor environment, and to prevent the introduction of additional divergence in implementations.”

The document also urges network operators never to rely on any implicit understanding of a neighbor ASN’s BGP community handling.  For instance, “before announcing prefixes with NO_EXPORT or any other community to a neighbor ASN, the operator should confirm with that neighbor how the community will be treated.”

BGP Large Communities in the IXP environment

Some networks peer at multiple IXPs in order to improve redundancy and geographical optimization.  It is also common that, in the case of using a Route Server (RS) to implement multilateral peering relationships, Large Communities are used to instruct the RS on how to handle an announcement (e.g. not to advertise to a particular ASN), or to send additional information to the peer, e.g. the status of the validation.

The I-D “BGP Large Communities applications for IXP Route Servers” attempts to document commonly used Large Communities to facilitate consistency of use across multiple IXPs.

Building a more robust routing policy with maximum prefix limits

Has your network experienced a situation where a peer suddenly floods your border router with many more routes than expected, sometimes causing resource exhaustion and other troubles? 

The I-D “BGP Maximum Prefix Limits” describes mechanisms to reduce the negative impact of these types of misconfigurations. Instead of a general limit on the number of prefixes received from a BGP neighbour, as defined in the BGP specification, it proposes a more granular scheme with three control points to mitigate the impact:

  • Pre-Policy Inbound Maximum Prefix Limits – when the limit is checked before any policy is applied (e.g. filtering). These limits are particularly useful to help dampen the effects of full table route leaks and memory exhaustion when the implementation stores rejected routes.
  • Post-Policy Inbound Maximum Prefix Limits – checked after the import policy is applied. They are useful to help prevent FIB exhaustion and prevent accidental BGP session teardown due to prefixes not accepted by policy anyway.
  • Outbound Maximum Prefix Limits – trigger termination of a BGP session with a neighbor when the number of address prefixes to be advertised to that neighbor exceeds a locally configured upper limit. These limits are useful to help dampen the negative effects of a misconfiguration in local policy.  In many cases, it would be more desirable to tear down a BGP session rather than flooding the neighbors with misconfigured announcements.

These recommendations are distilled from a broader framework, presented by Job Snijders at the RIPE 77 meeting last year.

Leveraging RPKI for proven operational practices

A common best practice to ensure that one’s customers only announce their own networks and the networks of their customers, is to build prefix filters. 

In the case there are only direct customer relationships (i.e. the network operator’s customers are ‘stub networks’), the task is relatively easy. One needs to collect prefixes, legitimately originated by these networks, and this is most commonly done by using an IRR of choice and collecting corresponding “route” objects. But with the proliferation of RPKI, it can become a more robust alternative, providing a cryptographically verifiable ROA object that serves a similar purpose.

If you are a bigger network and some of your customers also provide transit services for smaller networks, the task is more difficult. How to determine who are the customers of your customers and so on? 

To help with this task, there is a special IRR object – “as-set”. This object is a list of ASNs or other “as-sets” that defines the customer cone of a particular AS.

However, when it comes to RPKI, there is no way for an operator to assert the routes for its customer networks, making it difficult to use the information carried by RPKI to create meaningful prefix filters without relying on RPSL “as-sets”.

The I-D “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” attempts to fix that problem by introducing a new attestation object called an AS-Cone.  An AS-Cone is a digitally signed object with the goal of enabling operators to define a set of customers that can be found as “right adjacencies” or transit customer networks, facilitating the construction of prefix filters for a given ASN, thus making routing more secure.

By leveraging RPKI, AS-Cone also addresses two fundamental problems with the RPSL “as-set”. The same AS-SET name can exist in multiple IRRs, and a relying party does not necessarily know which “as-set” belongs to which ASN, and which as-set to use. 

Improving AS-PATH validation

The Border Gateway Protocol (BGP) was designed with no mechanisms to validate BGP attributes. The ability to manipulate one of them – AS_PATH – creates one of the most serious vulnerabilities of the Internet routing system. BGPsec was therefore designed to solve the problem of AS_PATH correctness.  

But according to the authors of a new I-D “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization” even leaving aside the complexity, its backward support for ‘insecure’ BGP allows an attacker to mount a downgrade attack to nullify all the work of AS_PATH signing. 

The authors suggest a more pragmatic approach that can help leveraging the benefits of RPKI without the need for the ubiquitous deployment of BGPsec. The idea is that any AS can declare its upstream providers and peers – the networks that can propagate its prefix announcements. The more networks that do that, the more chances to detect misconfigurations whether malicious or not.

The draft defines the semantics of Autonomous System Provider Authorization (ASPA) objects that should become part of RPKI. ASPAs are digitally signed objects that bind in a selected AFI Provider AS number to a Customer AS number (in terms of BGP announcements not business), and are signed by the holder of the Customer AS. An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements onward, e.g. to the Provider’s upstream providers or peers.

Mitigating DDoS attacks

DDoS attacks are a persistent and growing threat on the Internet.  As they evolve rapidly in the terms of volume and sophistication, a more efficient cooperation between the victims and parties that can help mitigate such attacks is required. The ability to quickly and precisely respond to a attack when it begins, and communicate precise information to a mitigation service provider is crucial.

Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS) Working Group busy. The aim of DOTS is to develop a standards based approach for the real-time signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. Specifications outlining the requirements, architecture and the use cases for DOTs are maturing, and there is a hackathon planned at IETF104 to conduct further interoperability testing of DOTS protocols.

Another interesting case getting more importance, especially with the advent of consumer IoT devices, is mitigation of outbound DDoS attacks originating in a home network. The I-D “Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home” proposes a solution to these cases by proposing a DOTS signal channel Call Home extension that enables the DOTS server to initiate a secure connection to the DOTS client. The DOTS client then conveys the attack traffic information to the DOTS server. 

In a typical deployment scenario, the DOTS server is enabled on a CPE, whilst a client resides in an ISP network. In this case the DOTS server in the home network initiates the Call Home during peace time, and subsequently the DOTS client in the ISP environment can initiate a mitigation request whenever the ISP detects there is an attack from a compromised device in the DOTS server’s domain. Subsequently, the DOTS server would use the DDoS attack traffic information to identify the compromised device in its domain launching the DDoS attack, notify the network administrator, and take appropriate mitigation action such as quarantining the compromised device or block its traffic to the attack target until the mitigation request is withdrawn.

The meeting in Prague is certainly going to be interesting regarding Internet infrastructure security and resilience, and will hopefully have a positive impact in this area.

Relevant Working Groups at IETF 104

SIDROPS (SIDR Operations) WG
GROW (Global Routing Operations) WG
IDR (Inter-Domain Routing) WG
DOTS (DDoS Open Threat Signaling) WG
About Internet Society IETF Improving Technical Security

Join a Local IETF Viewing Hub in Africa

The Internet Engineering Task Force (IETF) is the premier Internet standards body, developing open standards through processes to make the Internet work better. It gathers a large, international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. Core Internet technologies such as DNS, routing and traffic encryption use protocols standardized at IETF.

The IETF holds three meetings yearly which are livestreamed and can be followed individually, or with others sharing similar interest at a common venue. The next IETF meeting will be held from 25-29 March 2019 in Prague. The usual audience for an IETF meeting is network engineers, system engineers, developers, and university students or lecturers in information technology fields.

The Internet Society Africa Regional Bureau is running an initiative to encourage remote participation in IETF meetings that aims to promote the work of the IETF. IETF Remote Hubs aim to raise awareness about the IETF and allow those who cannot travel to a meeting to participate in the meeting remotely. The meetings are streamed in English only.

Join one of the following IETF Remote Hubs in your area, raise your awareness about the IETF and engage in the various topics of your interest!

Internet Society Gauteng Chapter
Venue: Tshimologong Precinct Wits Link center
Date: Tuesday 26 March 2019
Topics of discussion:

  • Home Networking (homenet)
  • Using TLS in Applications
  • dns over https (doh)
  • quantum Internet proposed Research group (QIRG)
  • Network Time Protocol
  • Messaging Layer Security
  • Transport Layer Security (tls)
  • Thing-to-Thing

ETHNOG Ethiopia
Venue: HiLCHO
Date: Tuesday 26 March 2019
Topic of discussion: Network Time Protocol

Mozambique Research and education Network – MoRENet
Venue: Ministry of Science and Technology, Higher Education and Vocational Training
Date: Tuesday 26 March 2019
Topics of discussion:

  • Dns over https (doh)
  • Quantum Internet proposed Research group (QIRG)

Internet Society Benin Chapter
Venue: University
Date: Tuesday 26 and Thursday 28 March 2019
Topics of discussion:

  • Using TLS in Applications (26 March morning)
  • Dns over https (doh)  (26 March morning)
  • Messaging Layer Security (28 March morning)

Coded Club Ghana
Venue: University of Professional Studies, Accra
Date: Thursday 28 March 2019
Topics of discussion:

  • GitHub Integration and Tooling  (morning)
  • Human Rights Protocol Considerations (Afternoon)

ISOC Mali Chapter
Venue: AGETIC, ACI 2000 Hamdalaye
Date: Tuesday 26 2019
Topics of discussion:

  • Home Networking  (homenet)- Morning
  • Dns over https (doh)- Morning
  • Thing-to-Thing- Afternoon

ISOC Botswana
Venue: University of Botswana
Date: Tuesday 26 March 2019
Topic of discussion: Thing-to-Thing- Afternoon

ISOC Ghana Chapter
Venue: Ghana-Korea Information Access Center, University of Ghana Legon
Date: Tuesday 26 March 2019
Topics of discussion:

  • Software Updates for Internet of Things (Morning)
  • Crypto Forum (Morning)
  • Automated Certificate Management Environment (Morning)
  • Technology Deep Dive – Modern Router Architecture BOF (Afternoon)

ISOC Namibia
Venue: NBII – 1-4 Gluck Street, Windhoek West
Date: 26- 27 March 2019

Topics of discussion:

  • Home Networking
  • Quantum Internet Proposed Research Group
  • Decentralized Internet Infrastructure
  • Crypto Forum 

Youth4Internet Cote Ivoire
Venue: Bingerville
Date: Monday 25- Friday 29 2019
Topics of discussion:

  • Transport Layer Security (tls)- (25 morning)
  • Network Time Protocol – (25 afternoon)
  • Transport Layer Security (tls)- (25 afternoon)
  • Quic- (27 morning)
  • Hypertext Transfer Protocol (httpbis)- 28 afternoon)
  • Global Access to the Internet for All- (29 morning)
  • IP wireless Access in Vehicular environment- (29 morning)

CyberStorm – Mauritius
Venue: Pointe aux Piments, Villa MU
Dates: 21- 29 March 2019
Topics of discussion:

  • Hackathon
  • TLS, 6man
  • HRPC
  • UTA

This page will be updated with info on the hubs and the contact persons at each of the hubs:

IETF Open Internet Standards Technology

Concluding the IETF Rough Guide, Long Live the IETF Blog

For many years we have produced a series of blog posts as a Rough Guide to each upcoming IETF meeting usually in the week prior to the meeting. The Rough Guides were intended to provide a snapshot of IETF activity of interest to the Internet Society because of programmatic activity that we were engaged in. They were also an opportunity to highlight the activities sponsored directly by the Internet Society that were happening adjacent to the upcoming IETF meeting.

Rough Guides were intended to help guide a non-specialist but technically minded audience to the hot topics and debates of interest at each upcoming IETF meeting with pointers to the agenda and remote participation possibilties. Originally intended to help spur meeting attendance by those interested in the key topics, they became a way to highlight important discussions taking place and ways to get involved in person or remotely.

As we are now less than a week away from the IETF 104 meeting in Prague it seemed like the right time to share an update regarding our plans for writing about IETF activity. We have decided to discontinue producing the Rough Guides. Instead, we will be helping to supply relevant, high-quality content for the IETF Blog.

News about upcoming meetings, post-meeting wrap-ups and articles about work on specific technical topics taking place at IETF are now regular features of the IETF blog. It is providing an excellent resource for the wider audience interested in the work of the IETF and ways to get involved. Recent posts on the IETF Blog have included a summary of potential new work being discussed at IETF 104; an update on ACME  a technology that is automating steps towards increased encryption on the Internet; and an introduction to MUD  a new protocol which addresses the challenge of managing an increasing number of Things on our networks.

We will continue to write about the IETF and the technical work taking place in the many working groups through the Internet Society’s regular channels. We may also help to curate content from the IETF community for publication on the IETF blog, as needed.

Deploy360 IETF IPv6

How IPv6 SLAAC Responds to Renumbering Events

If you follow the IPv6 Maintenance (6man) Working Group of the Internet Engineering Task Force (IETF), you may have noticed the 300+ message email thread on an Internet Draft that was recently published on the “Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events”. This was prompted by the experiences of developing Best Current Operational Practice on IPv6 prefix assignment for end-users, an activity led by ISOC’s Jan Žorž and published as ripe-690.

SLAAC is used to automatically assign an IPv6 address to a host, but there are a number of scenario where hosts may end up using stale configuration information and thereby leading to interoperability problems.

For example, a typical IPv6 deployment scenario is when a CPE (Customer Premises Equipment) router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of the leased prefix on the LAN-side via SLAAC.

In such scenarios, if the CPE router crashes and reboots, it may lose all information about the previously leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems.

ripe-690 had tried to address this problem by recommending that operators lease stable IPv6 prefixes to CPE routers, but for various reasons, ISP may not be able or willing to do this, and may instead lease dynamic prefixes. In fact, a recent survey of ISPs indicates that 37% of the surveyed ISPs lease dynamic IPv6 prefixes to their customers, as opposed to the stable prefixes recommended by ripe-690.

Most of the input on the 6man mailing list fell into one of the following camps:

  • “ISPs should be leasing stable prefixes — if they don’t, they are asking for trouble!”
  • “CPE routers should record leased prefixes on stable storage, such that they can deprecate such prefixes upon restart — if they don’t, they are asking for trouble!”
  • “No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments”

This Internet Draft therefore tries to improve the current state of affairs through the following improvements:

  • Allow hosts to gracefully recover from stale network configuration information — i.e. detect and discard stale network configuration information.
  • Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner; unless it is actively refreshed by Router Advertisement messages.
  • Specify the interaction between DHCPv6-PD and SLAAC — which was rather under-specified.
  • Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart.

Based on the mailing list discussions, there would seem to be consensus this is a problem that needs to be addressed by the 6man Working Group.

The topic is therefore likely to be on the working group agenda at the IETF 104 Meeting at the end of this month in Prague, Czech Republic. So if you’re a network operator, vendor or otherwise have operational experience of this issue, you’re strongly encouraged to contribute to the discussion.

Further Information

Deploy360 Domain Name System (DNS) IETF

DNS Security & Privacy discussed at e-AGE18

The Internet Society continued its engagement with Middle East networking community by participating in the e-AGE18 Conference, where we took the opportunity to promote the importance of DNS Security and Privacy. The conference was held on 2-3 December 2018 at the Marriott Hotel in Amman, Jordan and was organised by the Arab States Research and Education Network (ASREN) and co-sponsored by the Internet Society.

Kevin Meynell from the Internet Society’s Middle East Bureau, highlighted the importance of implementing DNSSEC which allows DNS resolvers to authenticate the origin of data in the DNS through a verifiable chain-of-trust. This reduces the possibility of spoofing where incorrect or corrupt data is introduced into a resolver, or a man-in-the-middle attack whereby DNS queries are re-directed to a name server returning forged responses.

Unfortunately, only the Saudi Arabia ccTLD (.sa) has operationally deployed DNSSEC in the Middle East region at the present time, although Iran (.ir) and Iraq (.iq) have deployed it on an experimental basis. On the positive side, around 18% of DNS queries originated from Middle East countries are being validated compared to 12% globally, with Yemen (45.1%), Saudi Arabia (32.1%), Iraq (30.6%), Bahrain (23.2%) and Palestine (22.5%) leading the way. This is possibly because there is a greater prevalence of the use of third-party DNS resolvers (e.g. Cloudflare, Google, Quad9 in the region.

Of course, whilst DNSSEC ensures that DNS records have not been modified without the owner’s consent, it does not keep the queries themselves confidential. DNS queries reveal what site a host is communicating with, and as they are (by default) sent in clear text, they can easily be eavesdropped.

The IETF DNS Private Exchange (DPRIVE) Working Group has therefore recently developed mechanisms to encrypt queries and responses to/from resolvers and therefore provide some confidentiality of DNS transactions. These include DNS-over-TLS (DoT), DNS-over-DTLS (DoD) and DNS-over-HTTPS (DoH), and with the exception of DoD, there are already several public DNS resolvers (Cloudflare, Quad9 & CleanBrowsing) and a few clients (Stubby 1.3+, Unbound 1.6.7+, Knot 2.0+, Mozilla Firefox 62+ and Android 9 Pie) that support these mechanisms.

It should be pointed out that clients and resolvers need to be upgraded to support DoT and DoH, and all these mechanisms currently only encrypt DNS communications between client (stub-resolver) and recursive resolver, not between recursive resolver and authoritative DNS servers. Support for the latter would require all authoritative DNS servers to be upgraded to support DoT and DoH, and there are concerns about the increased computing requirements that would required on the more heavily name servers to initiate the encrypted connections.

In addition, providers of the recursive resolver are in the position to monitor and log queries and responses, so need to be trusted. Nevertheless, these are important developments towards improving the security and confidentiality of the DNS.

Last but certainly not least, attention was drawn to DNS Flag Day which is important to be aware of. DNSSEC and other extended features of the DNS require EDNS0 (Extension Mechanisms for DNS – RFC 6891), and properly implemented name servers should either reply with an EDNS0 compliant response, or provide a regular DNS response if they don’t understand.

However, a lot of name server software is not implemented properly which has meant resolvers have had to incorporate workarounds when name servers don’t respond correctly, but these cause unnecessary retries, delays, and prevent the newer features of the DNS being used. The vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) are therefore removing these workarounds as of 1 February 2019, with the consequence is that hostnames served by broken DNS implementations will no longer be resolved. So please check whether your domain is affected!

ASREN is a non-profit association of National Research and Education Networks in the Middle East that aims to connect institutes to enable access to services, applications and computing resources within the region and around the world, and to boost scientific research and cooperation amongst its members. Its mandate covers 22 countries, and it has partnered with the major regional R&E networking initiatives elsewhere in the world, including GÉANT (Europe), Internet2 (United States), CANARIE (Canada), WACREN (West Africa) and RedCLARA (Latin America). International connectivity is supported by the EU-funded EUMEDConnect3 project.

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

Further Information

Building Trust Deploy360 Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 4: Trusted Systems, IoT & IPv6

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Thursday actually represents the last day of the meeting this time, although there’s still several sessions to draw attention to.

SUIT is meeting first thing at 09.00 UTC+9. This is considering how the firmware of IoT devices can securely updated, and the architecture and information models for this will be discussed. There are three other drafts relating to manifest formats that are the meta-data describing the firmware images.

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

DMM is the first of the afternoon sessions at 13.50 UTC+7, and there are several IPv6-related drafts under consideration. Proxy Mobile IPv6 extensions for Distributed Mobility Management proposes a solution whereby mobility sessions are anchored at the last IP hop router, whilst Segment Routing IPv6 for Mobile User Plane defines segment routing behaviour and applicability to the mobile user plane behaviour and defines the functions for that. There’s also three updated drafts on 5G implementations which may interest some.

To round off the week, there’s a choice of two sessions starting at 16.10 UTC+7.

ACME will be focusing on the ACME TLS ALPN extension that allows for domain control validation using TLS, and Support for Short-Term, Automatically-Renewed (STAR) Certificates. It will also consider how ACME can support TLS certificates for end-users.

Alternatively, 6TiSCH will be focusing on the specification for a combining a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH). The 6top protocol that enables distributed scheduling is now heading for publication as an RFC, and there are also updates to the description of a scheduling function that defines the behavior of a node when joining a network and to define a security framework for joining a 6TiSCH network. If there’s time, a method to protect network nodes against a selective jamming attack will be discussed.

With that, IETF 103 comes to a close and we say Sà-wàd-dee to Bangkok. Many thanks for reading along this week… please do read our other IETF 103-related posts … and we’ll see you at IETF 104 which is being on 23-29 March 2019 in Prague, Czech Republic.

Relevant Working Groups

Deploy360 Events IETF Transport Layer Security (TLS)

IETF 103, Day 3: DNS Privacy, TLS & IoT

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Wednesday is a relatively light day in this respect, although there’s some pretty important matters being discussed today.

DPRIVE kicks off the day at 09.00 UTC+9, and will mostly be discussing user perspectives with respect to the recently introduced implementations of DNS-over-TLS and DNS-over-HTTPS, as well as the issues of DNS privacy between resolvers and authoritative servers. There’s also a new draft up for discussion on DNS-over-TLS for insecure delegations that describe an alternative authentication mechanism without need for DNSSEC support.

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

TLS holds its second session of the week immediately after lunch at 12.20 UTC+7. This will carry-on where it left off on Monday, although will be discussing a DANE Record and DNSSEC Authentication Chain Extension for TLS. The intention is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups.

Then at 13.50 UTC+7, Homenet will be focusing on Homenet Naming and Service Discovery Architecture. There’s also an agenda item for general security questions, and a demonstration of SecureHomeGateway, before moving into discussions on re-chartering the group.

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Events IETF Internet of Things (IoT) IPv6 Securing Border Gateway Protocol (BGP)

IETF 103, Day 2: IPv6, NTP, Routing Security & IoT

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And following on from the previous day, Tuesday also features a packed agenda.

LPWAN will be discussing whether to move to a Working Group Last Call on the Static Context Header Compression (SCHC) framework for IPv6 and UDP, that provides both header compression and fragmentation functionalities. Three other drafts describe similar schemes for SigFox,LoRaWAN and IEEE 802.15.4 type networks.

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

Then at 11.20 UTC+7, IPWAVE will be focusing on updates to the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications, and the use cases for IP-based vehicular networks. There have also been a couple of updates to DNS Name Autoconfiguration for Internet of Things Devices and IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks, so these may also be discussed.

6MAN will be meeting at 13.50 UTC+7 and has nine drafts up for discussion. The couple of working group sponsored drafts relate to specifying a IPv6 Segment Routing Header (SRH) and how this can be used by Segment Routing capable nodes, and specifying a Router Advertisement flag to indicate to hosts that a link is IPv6-only. There are also a couple of new drafts that specify how IOAM (In-situ Operations, Administration and Maintenance) records are encapsulated in IPv6, and defining the building blocks that can be used for OAM in Segment Routing with IPv6.

The other drafts being discussed cover communicating NAT64 prefixes to clients with Router Advertisements, Updates to Requirements for IPv6 Options, Path MTU Discovery solutions, a new Path MTU Hop-by-Hop Option to record minimum Path MTU from source to destination, and IPv6 Packet Truncation procedures.

Running in parallel is SIDROPS that is discussing five drafts. RPKI Validation State Unverified proposes to introduced a new ‘Unverified’ validation state for route prefixes, whilst BGPsec Validation State Unverified proposes a similar validation states for BGPsec routes. Two other drafts introduce and define a digitally signed object into an RPKI  that provides a means of verifying that a Customer Autonomous System holder has authorised a Provider Autonomous System to be its upstream provider. That leaves a draft considering policy for dropping invalid routes – including hijacked and missing or erroneously created ROAs for route prefixes.

To conclude the day, there’s a choice of two sessions at 16.10 UTC+7.

NTP is a working group we’ve decided to cover as (amongst other things), it’s working to improve the security of the Network Time Protocol. There’s no less than 20 drafts on the agenda, although Network Time Security for the NTP specifies a mechanism for using TLS and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of NTP. Following on from this will be a review of the NTS implementations and interoperability testing.

T2TRG researches the issues of turning the IoT into reality, and will continue to discuss the State-of-the-Art and Challenges for the Internet of Things Security, the guidance for designing IoT systems using the REST architectural style, and a new data and interaction model called CoRAL (The Constrained RESTful Application Language).

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Deploy360 Domain Name System (DNS) Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 1: IPv6, TLS, DNS Privacy & Other Crypto

The Working Group sessions start tomorrow at IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Only four days have been scheduled for the working groups this time around, which means there’s a lot of pack into each day; with Monday being no exception.

V6OPS is a key group and will be meeting on Monday morning starting at 09.00 UTC+7. It’s published four RFCs since its last meeting, including Happy Eyeballs v2, and this time will kick-off with a presentation on the CERNET2 network which is an IPv6-only research and education in China.

There’s also four drafts to be discussed, including three new ones. IPv6-Ready DNS/DNSSSEC Infrastructure recommends how DNS64 should be deployed as it modifies DNS records which in some circumstances can break DNSSEC. IPv6 Address Assignment to End-Sites obsoletes RFC 6177 with best current operational practice from RIPE-690 that makes recommendations on IPv6 prefix assignments, and reiterates that assignment policy and guidelines belong to the RIR community. Pros and Cons of IPv6 Transition Technologies for IPv4aaS discusses different use case scenarios for the five most prominent IPv4-as-a-service (IPv4aaS) transitional technologies, whilst NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks is an updated draft that describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network.

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

Running in parallel on Monday morning is ROLL which focuses on IPv6 routing issues for low-power and lossy networks. This will be discussing an update ton the ROLL-BIER design that extends RPL to support routing based on Bit Index Explicit Replication (BIER) in environments with limited and lossy updates. There are also seven other drafts up for discussion, all related to RPL enhancements.

CFRG will be held during the late morning at 11.20 UTC+7. The group has yet to publish the agenda, but there’s a number of currently active drafts covering issues that include Public Key ExchangeThe Transition from Classical to Post-Quantum Cryptography, Randomness Improvements for Security ProtocolsRe-keying Mechanisms for Symmetric Keys, and Hash-Based Signatures.

There’s a choice of two sessions after lunch, starting at 13.50 UTC+7.

TLS holds the first of its two sessions (the second is on Wednesday afternoon) and has a number of important drafts up for discussion including the proposed DTLS 1.3 specification, and Connection Identifiers for DTLS, to avoid the need for additional handshaking upon NAT rebinding. There is also a proposal to deprecate TLS 1.0 and 1.1 as these versions lack support for current and recommended cipher suites.

Other drafts cover TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates, a TLS 1.3 extension that allows a server to authenticate with a certificate while also providing a pre-shared key (PSK) as an input, and definition of universal PSKs for TLS that use an extra key derivation step to reuse the same secret for all TLS 1.3 KDF hashes. In addition, a revised working group charter has been proposed.

DNSOP meets at the same time, and there’s a couple of interesting drafts worth mentioning. One outlines how run a root server instance on the same server as a recursive resolver in order to decrease access time, and another specifies a way of resolvers telling clients what its associated DNS-over-HTTPS (DoH) servers are.

6LO concludes the day at 16.10 UTC+7. This will be discussing drafts to update RFC 6775 to support registration extensions for simplifying these operations in 6LoWPAN routers, to update Address Protected Neighbor Discovery for Low-power and Lossy Networks, to update RFC 4944 with a simple protocol to recover packet fragments over a mesh network, as well preparing the IPv6 Backbone Router draft for a Working Group Last Call. The session will be rounded-off with a performance report on fragment forwarding and recovery.

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF

Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy

As happened earlier this year at IETF 102 in Montreal, DNS privacy will receive a large focus in the DNSOP, DPRIVE and DNSSD working groups. Given the critical role DNS plays as part of the “public core” of the Internet in linking names and identifiers to IP addresses, the DNS must have stronger security and privacy controls.  As part of our Rough Guide to IETF 103, here’s a quick view on what’s happening in the world of DNS.

Note – all times below are Indochina Time (ICT), which is UTC+7.

DNS Operations (DNSOP)

The DNS sessions at IETF 103 start on Monday afternoon from 13:50-15:50 with the DNS Operations (DNSOP) Working Group.  As per usual, DNSOP has a packed agenda. The major security/privacy-related drafts include:

  • DNS query minimisationdraft-ietf-dnsop-rfc7816bis – Back in 2016, RFC 7816 defined an experimental way to increase DNS privacy and limiting the exposure of DNS query information by simply not sending the entire query all the way up the DNS resolver chain.  This new work is to move that RFC 7816 document from being an experiment to being an actual Internet standard.
  • Running a DNS root server locallydraft-ietf-dnsop-7706bis – Another way to increase DNS privacy is to not send queries up the DNS resolver chain to the root by running your own local copy of the root DNS servers. Back in 2015, the informational RFC 7706 defined how to do this and specified running it on the “loopback” interface of your local computer. This new work broadens that to allow the local copy to run more generally on local systems. At the recent ICANN 63 meeting in Barcelona, this was discussed as “hyperlocal” copies of the root zone of DNS. Wes Hardaker at ISI also has a site about this effort: Not only could this increase privacy, but also resiliency of the DNS system. However, it is not without its critics and so there could be a good discussion in Bangkok.
  • Serving stale data to increase DNS resiliencydraft-ietf-dnsop-serve-stale – This project is setting up the criteria for when DNS resolvers could continue to use DNS data even after the Time To Live (TTL) expires. Basically, if you can’t reach an authoritative server for some reason, under what conditions could you continue to serve the records you previously retrieved from that server?

If there is time in the session, Paul Hoffman’s draft-hoffman-resolver-associated-doh may come up for discussion. This relates to the somewhat controversial DNS Over HTTPS (DOH), now defined in RFC 8484, that lets an app such as a web browser send DNS queries over HTTPS to a DOH server where the DNS resolution can occur.  The controversy with DOH is primarily two points: 1) it lets an application bypass local DNS servers and thereby bypass local DNS filtering or restrictions; and 2) the first announced use of DOH was by Mozilla Firefox with a DOH server from Cloudflare. This second point brought concerns about centralization and potential choke points.  As more entities have stood up DOH servers, there has been a need to help DOH clients understand which DOH server to use. Paul’s draft provides one such mechanism.

If by some miracle there happens to still be time in the session and there is an open mic, I may see if I can briefly ask the group if there is interest in moving forward the draft that several of us worked on about DNSSEC cryptographic algorithm agility – draft-york-dnsop-deploying-dnssec-crypto-algs .  However, given the agenda, I highly doubt there will be an opportunity – it will need to be mailing list activity.

DNS PRIVate Exchange (DPRIVE)

[UPDATE, 4 November 2018: The DPRIVE session at IETF 103 was cancelled after the working group chairs determined they did not have enough presenters to have the discussion they were seeking to have. They plan to take the conversation back to the DPRIVE mailing list and perhaps hold a virtual interim meeting in December 2018.]

The DPRIVE working group meets Wednesday morning from 09:00-11:00 ICT.  This meeting at IETF 103 is primarily focused on the discussion about how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  Specifically they will spend about 30 minutes on the “user perspective” of DNS privacy and a full hour on the “authoritative and recursive perspective” as the working group looks at whether to expand its work to increase the privacy of even more elements of the DNS infrastructure.

Extensions for Scalable DNS Service Discovery (DNSSD)

Privacy will also get attention at the DNSSD Working Group on Thursday afternoon from 13:50-15:50 ICT.  DNSSD focuses on how to make device discovery easier across multiple networks. For instance, helping you find available printers on not just your own network, but also on other networks to which your network is connected. However in doing so the current mechanisms expose a great deal of information.

The working group had a lengthy discussion at IETF 102 in Montreal about DNS privacy – and are planning for a significant 50 minute discussion block here at IETF 103 in Bangkok.

DNSSEC Coordination informal breakfast meeting

As a final note, on Friday morning we may try an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. This time we are not sure yet because with the formal meetings ending on Thursday, many people may be traveling home on Firday. We’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

DANE and DNSSEC will also appear in the TLS Working Group’s meeting on Wednesday. The draft-ietf-tls-dnssec-chain-extension will be presented as a potential way to make DANE work faster by allowing both DANE and DNSSEC records to be transmitted in a single exchange, thus reducing the time involved with DANE transactions. There has been a lengthy discussion on the TLS list and the chairs are scheduling 55 minutes for this discussion.

Given the key role DNS plays in the Internet in general, you can also expect DNS to appear in other groups throughout the week.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 103:

DNSOP (DNS Operations) WG
Monday, 5 November 2018, 13:50-15:50 ICT, Chitlada 1

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 7 November 2018, 09:00-11:00 ICT, Meeting 1

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 8 November 2018, 13:50-15:50 ICT, Meeting 2


Follow Us

It will be a busy week in Bangkok, and whether you plan to be there or join remotely, there’s much to monitor. Follow us on the Internet Society blogTwitter, or Facebook using #IETF103 to keep up with the latest news.