Categories
About Internet Society

Working together to build a bigger, stronger Internet

[Published on behalf of the Internet Society Board of Trustees.]

The Internet Society’s vision is that the Internet is for everyone. Earlier this month, we wrote about our efforts to ensure a stable and diverse funding model to support the work that takes us towards our vision. The role of the Board of Trustees is to provide, with support from the community, the strategic direction for that work. In this post, we discuss our recent and current strategic efforts, put them into context, and provide pointers with more information for our community to get involved in defining our wanted future.

Naturally, the starting point of our current strategy was to agree with the community on the overall direction. Therefore, two years ago, during 2017, the Board consulted with our community to revise our mission statement into what we have today. Many of you contributed to that 2017 effort, which resulted in the following three focus areas:

  • Building and supporting the communities that make the Internet work;
  • Advancing the development and application of Internet infrastructure, technologies, and open standards; and
  • Advocating for policy that is consistent with our view of the Internet

Based on that community agreement on the development of this new mission, the Board of Trustees began the work on a plan to change the structure of the Internet Society in order to best support this refreshed mission. This plan eventually led to the creation of two new “supporting organizations” during 2018.

One aspect of our plan was working with the Internet Engineering Task Force (IETF) to create a new supporting organization in the form of the IETF LLC. The establishment of the IETF LLC was discussed at length with the IETF community. While the Internet Society remains the largest funding source for the IETF, the result is that the IETF LLC formally gives the IETF legal status, and more freedom to manage their support activities, including budgeting.

A second aspect of our plan was the creation of the Internet Society Foundation to provide funding to the community in several key areas. As the Foundation team recently explained in the Foundation’s own Action Plan 2020, they will be funding work within our Chapters, Special Interest Groups (SIGs), and other communities; funding research and innovation; and supporting partners to help develop disaster-resilient communities. In addition, the Foundation will be supporting projects that strengthen communities, and improve lives and livelihoods. As usual, we will be seeking ideas from our community.

The Internet Society Foundation has already been providing grants in 2019 and is looking forward to expanding that work in 2020. Remain alert for future calls for grant applications.

Once our new mission and the structure above were in place, in 2019 the Board of Trustees turned its focus on aligning ISOC’s internal structure and short term-plan with the long-term direction given by our mission. Encouraged by the Board, both efforts were championed by Andrew Sullivan, our President and CEO, and the Internet Society Executive Team.

ISOC’s new internal structure makes it easy to set up projects that include the necessary competence. It also facilitates identifying areas where new capabilities need to be developed. We believe that the new structure provides ISOC with a solid foundation to implement its future action plans.

ISOC’s 2020 Action Plan was developed together with our community. Through the outreach we conducted over the past six months, over 3,000 of our members contributed to surveys and feedback sessions, helping to shape and guide the direction of this new Action Plan. The Board of Trustees approved the Action Plan on November 24, 2019, in part because we are confident that what we now have in place reflects the voice of our community. 

We also want to thank all the members our community who joined us last Wednesday, December 11, to learn more about the Action Plan and how we will focus on building, promoting, and defending the Internet to make it bigger and stronger for everyone. We look forward to working with you all to move our 2020 projects forward and to achieve the tangible and impactful outcomes we seek.

As we set out on the path to 2025, we plan to continue consulting our community to develop our action plans. Please, stay tuned and continue providing us with your valuable input. Our goal is to make sure the direction of the Internet Society and its work remain aligned with community interests.

To sustain the important work in support of our mission, the work within our supporting organizations, and the projects within our Action Plan, we on the Board of Trustees have a duty to ensure the long-term viability of the Internet Society. Therefore, reducing financial risk is of strategic importance for the Internet Society. Previous boards have worked on revenue diversification activities for many years with limited success.  As we wrote earlier this month, we believe the sale of the PIR will help the Internet Society reduce this financial risk, while at the same time enabling PIR to do much more to grow the .ORG domain business and provide new services to .ORG registrants.

If you are interested in the work Board does, several years ago we started making both the minutes and the video recordings of our Board meetings publicly available. We also hold Open Forum meetings and webminars where the community can interact with the Board. In addition, trustees interact with parts of the community at multiple events on a constant basis.

As we head toward 2020 and to our longer-term strategy for 2025, we look forward to continuing to work with all of our Chapters, Special Interest Groups (SIGs), Organization members, individual members, and partners to realize our vision that “The Internet is for everyone”. We believe in an Internet that is open, globally-connected, secure, and trustworthy. Thank you for all you do to ensure that the Internet is a resource to enrich people’s lives and a force for good in society.


Image: Community members of Pu’uhonua O Waimanalo work together with the Internet Society to learn how to use and install the Internet during the Internet Society/ Pu’uhonua O Waimanalo training session on November 14th, 2019. © Elyse Butler

Categories
Technology

Celebrating 50 Years of the RFCs That Define How the Internet Works

50 years ago today, on 7 April 1969, the very first “Request for Comments” (RFC) document was published. Titled simply “Host Software”, RFC 1 was written by Steve Crocker to document how packets would be sent from computer to computer in what was then the very early ARPANET. [1]

Steve and the other early authors were just circulating ideas and trying to figure out how to connect the different devices and systems of the early networks that would evolve into the massive network of networks we now call the Internet. They were not trying to create formal standards – they were just writing specifications that would help them be able to connect their computers. Little did they know then that the system they developed would come to later define the standards used to build the Internet.

Today there are over 8,500 RFCs whose publication is managed through a formal process by the RFC Editor team. The Internet Engineering Task Force (IETF) is responsible for the vast majority (but not all) of the RFCs – and there is strong process through which documents move within the IETF from ideas (“Internet-Drafts” or “I-Ds”) into published standards or informational documents[2].

50 years ago, one of the fundamental differences of the RFC series from other standards at the time was that:

  • anyone could write an RFC for free.
  • anyone could read the RFCs for free. They were open to all to read, without any fee or membership.

As Steve Crocker notes in his recollections, this enabled the RFC documents to be widely distributed around the world, and studied by students, developers, vendors and other professionals. This allowed people to learn how the ARPANET, and later the Internet, worked – and to build on that to create new and amazing services, systems and software.

This openness remains true today. While the process of publishing a RFC is more rigorous, anyone can start the process. You are not required to be a member (or pay for a membership) to contribute to or approve standards.  And anyone, anywhere, can read all of the RFCs for free. You do not have to pay to download the RFCs, nor do you have to be a member of any organization.

More than anything, this open model of how to work together to create voluntary open standards is perhaps the greatest accomplishment of the RFC process. The Internet model of networking has thrived because it is built upon these open standards.

Standards may come and go over time, but the open way of working persists.

While we may no longer use NCP or some of the other protocols defined in the early RFCs, we are defining new protocols in new RFCs.  The next 1,000s RFCs will define many aspects of the Internet of tomorrow.[3]

We may not know exactly how that future Internet will work, but it’s a pretty good guess that it will be defined in part through RFCs.



[1] See our History of the Internet page for more background.

[2] For more explanation of the different types of RFCs, see “How to Read a RFC“.

[3] As noted in our 2019 Global Internet Report section on “Takeaways and Observations”, we are concerned that an increasing number of new services and applications on the Internet are relying on application programming interfaces (APIs) controlled by the application or platform owner rather than on open standards defined by the larger Internet community.

Categories
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: https://localroot.isi.edu/ 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
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-dnsop
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 7 November 2018, 09:00-11:00 ICT, Meeting 1
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-dprive
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 8 November 2018, 13:50-15:50 ICT, Meeting 2
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-dnssd
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

 

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.

Categories
About Internet Society

Strengthening Foundations for Creating Open Internet Standards

The Internet Engineering Task Force has reached a significant milestone in the process of evolving its own administrative structure to best suit the current requirements of its work. After nearly two years of discussion about various options, the IETF community has created the IETF Administration LLC (IETF LLC), a new legal entity. Both the Internet Society’s CEO & President Kathy Brown and the Internet Society’s Board of Trustees Chair Gonzalo Camarillo have expressed strong support for the process that has led to this point, and for the direction the IETF has decided to take. Continuing its long-standing positions, the Internet Society also made financial commitments to support the process, and to the IETF going forward.

All of us at the Internet Society who work closely with the IETF believe this new administrative structure strengthens the the foundation for an Internet built on open standards. The new structure will not change any aspect of the IETF’s technical work or the Internet standards process, and clarifies the relationship between ISOC and the IETF. Importantly, the IETF and ISOC continue to be strongly aligned on key principles. ISOC initiatives related to the IETF, such as the Technical Fellows to the IETF and the Deploy360 Programme, will continue to support participation in the IETF and deployment of the standards created by the IETF.

In the more than three decades since it began, the IETF has evolved its administrative structure several times. The process that drove this latest evolution reflects a few important core operating principles of the IETF: open, consensus-based processes, improvement based on lessons learned from experience (“running code”), and always seeking ways to make the Internet work better – including the operational and administrative practices on which itself runs from day-to-day. We at the Internet Society look forward to the IETF’s continued success.

Categories
Improving Technical Security Technology Transport Layer Security (TLS)

TLS 1.3 – Internet Security Gets a Boost

Today marks the formal publication of an overhaul of the Transport Layer Security (TLS) protocol. TLS is an Internet standard used to prevent eavesdropping, tampering, and message forgery for various Internet applications. It is probably the most widely deployed network security standard in the world. Often indicated by the small green padlock in a web browser’s address bar1, TLS  is used in financial transactions, by medical institutions, and to ensure secure connections in a wide variety of other applications.

We believe the new version of this protocol, TLS 1.3, published as RFC 8446, is a significant step forward towards an Internet that is safer and more trusted.

Under development for the past four years and approved by the Internet Engineering Task Force (IETF) in March 2018, TLS 1.3 addresses known issues with the previous versions and improves security and performance, in particular it is able to establish a session more quickly than its predecessors. Because it is more efficient, TLS 1.3 promises better performance for the billions of users and organizations that use TLS every day. As with every IETF standard, TLS 1.3 was developed through open processes and participation, and included contributions from scores of individuals.

Many companies have indicated that they plan to implement and deploy TLS 1.3 in the near future and several have already done so. Part of their readiness can be traced back to the fact that the standard’s development was informed along the way by “running code” – test implementations that helped identify issues in and provide additional clarity to the specification, ensuring TLS 1.3 would not only look good on paper but that it would work well in the real world too. TLS 1.3 was also reviewed extensively by academic security and cryptography experts to help identify and address possible weaknesses before it was widely deployed.

A popular saying in the IETF community is that “there are no protocol police.” This reflects the reality that adoption of IETF protocols is voluntary and each network, enterprise, and Internet user is free to decide whether or not to use them. Given how widely TLS is deployed, it is inevitable that some challenges will be encountered as TLS 1.3 adoption gathers pace. Additional work may be required to address these challenges. However, on balance, TLS 1.3 represents a significant security win for the Internet and its users. We look forward to using it and tracking its adoption on the Internet.

See also:


1 – Editor’s Note: The TLS protocol is often mistakenly called “SSL” or “Secure Socket Layer”. SSL was the name of the original protocol developed by Netscape back in the mid-1990s. It was replaced by TLS 1.0 in 1999. (Yes, almost 20 years ago!) TLS 1.0 was in turn replaced by 1.1, 1.2, and now 1.3.

Categories
Building Trust Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Improving Technical Security Open Internet Standards

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

DNS privacy will receive a large focus in the latter half of the IETF 102 week with attention in the DPRIVE, DNSSD, and OPSEC working groups. In an interesting bit of scheduling (which is always challenging), most of the DNS sessions are Wednesday through Friday. As part of our Rough Guide to IETF 102, here’s a quick view on what’s happening in the world of DNS.

Given that IETF 102 is in Montreal, Canada, all times below are Eastern Daylight Time (EDT), which is UTC-4.

IETF 102 Hackathon

The “DNS team” has become a regular feature of the IETF Hackathons and the Montreal meeting is no different. The IETF 102 Hackathon wiki outlines the work that will start tomorrow (scroll down to see it). Major security/privacy projects include:

Anyone is welcome to join the DNS team for part or all of that event.

DNS Operations (DNSOP)

The DNS sessions at IETF 102 start on Wednesday morning from 9:30am – 12noon with the DNS Operations (DNSOP) Working Group. Paul Wouters and Ondrej Sury will be speaking about “Algorithm Implementation Requirements and Usage Guidance for DNSSEC“, where they will be offering updated guidance around what cryptographic algorithms should be used for different aspects of DNSSEC.  Shumon Huque will be bringing the latest updates to draft-huque-dnsop-multi-provider-dnssec, exploring how to deploy DNSSEC in environments where multiple DNS providers are in use. Paul Wouters will also bring a new draft, draft-pwouters-powerbind, which introduces a new flag for DNSSEC keys that can address a potential attack. Given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action. The DNSOP working group also has a second meeting block on Thursday from 18:10-19:10.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 EDT.  As shown on the agenda, there will be three major blocks of discussion. After some initial discussion of current work on existing DNS privacy policies, there will be a larger discussion about some new work called “Oblivious DNS” that aims to make DNS privacy protection even stronger. This work originated in a paper at Princeton University – https://odns.cs.princeton.edu/ – and now is captured in draft-annee-dprive-oblivious-dns. It should be quite an interesting discussion!

The third major area will continue discussion about how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  This is work outside the current  DPRIVE Working Group charter and so the group will be discussing whether to ask to expand their mandate to cover this new work.

Extensions for Scalable DNS Service Discovery (DNSSD)

Privacy will also get attention at the DNSSD Working Group on Thursday morning from 9:30-12:00 EDT.  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 agenda allocates 65 minutes to Christian Huitema to guide a discussion around the way forward. Drafts under discussion include:

There are other drafts under discussion at DNSSD, but these are the ones probably most of interest to readers of this article.

DNS Resolver Identification and Use (DRIU)

IETF 102 will feature a number of Birds-of-a-Feather (BOF) sessions, and one in particular relates to DNS security. The quick description is:

The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties.

The DRIU session will be on Thursday from 15:50-17:50, right before the second DNSOP session (although in a different room).

Operational Security Capabilities for IP Network Infrastructure

In the very last slot on Friday afternoon from 11:50-13:20, the OPSEC working group will feature Benno Overeinder speaking about “Recommendations for DNS Privacy Service Operators. This document outlines things DNS operators should thing about when considering offering “DNS privacy” services. It builds on the work coming out of the DPRIVE working group and the experience gained from the IETF Hackathon and the real-world deployment of these new protocols.

DNSSEC Coordination informal breakfast meeting

As a final note, on Friday morning before the sessions start we are planning 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. True to the “informal” nature, 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 Monday meeting. 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. 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 102:

DNSOP (DNS Operations) WG
Wednesday, 18 July 2018, 9:30-12:00 EDT, Laurier
Thursday, 19 July 2018, 18:10-19:10 EDT, Place du Canada

Agenda: https://datatracker.ietf.org/meeting/102/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 18 July 2018, 13:30-15:00 EDT, Place du Canada
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 19 July 2018, 9:30-12:00 EDT, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DRIU (DNS Resolver Identification and Use) BOF
Thursday, 19 July 2018, 15:50-17:50 EDT, Viger
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-driu

OPSEC (Operational Security Capabilities for IP Network Infrastructure) WG
Friday, 20 July 2018, 11:50-13:20 EDT, Viger
Agenda: https://datatracker.ietf.org/meeting/102/agenda/opsec/
Documents: https://datatracker.ietf.org/wg/opsec/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Deploy360 Events IETF IPv6 Open Internet Standards

Rough Guide to IETF 102: IPv6

In this post for the Internet Society Rough Guide to IETF 102 I’ll review what’ll be happening at the IETF meeting in Montreal next week on the topic of all things IPv6.

IPv6 global adoption rates have shown slow growth since IETF 101 and are currently approaching 25% overall. With the almost total depletion of the remaining pools of new IPv4 addresses, more-and-more networks have been increasing their IPv6 deployments, with the top 15 network operators supporting nearly half-a-billion IPv6 users. In addition, 28 percent of the Alexa Top 1000 websites are IPv6-enabled, including many of the large content providers who are now delivering native IPv6 traffic to mobile devices in particular. The US recently reached 40% deployment with nearly 80% of smartphones using IPv6, whilst along with Belgium, India, Germany, Brazil and Japan who still lead the way, we’re starting to see significant growth in countries such as Switzerland, Portugal, Estonia, Uruguay, Ecuador, Peru and New Zealand.

IPv6 is always an important focus for the IETF, particularly with respect to the standardisation work related to the Internet-of-Things.

The IPv6 Maintenance (6man) Working Group is a key group and it will be meeting on Monday morning. It hasn’t published any RFCs since the last meeting, but has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.

On Monday afternoon, the IP Wireless Access in Vehicular Environments (ipwave) Working Group will also be meeting. This group has yet to publish its agenda, but has recently updated the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications; and has been defining the use cases for IP-based vehicular networks. Two new drafts have also been published since the last meeting relating to DNS Name Autoconfiguration for Internet of Things Devices and IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks.

There are two IPv6-related working groups on Tuesday. The Routing Over Low Power and Lossy Networks (roll) Working Group focuses on IPv6 routing issues for these networks and has published three RFCs since its last meeting. This includes an applicability statement for battery-powered remote metering devices and two others relating to routing headers and multicast parameters. There’s also a new draft on route discovery for symmetric and asymmetric Point-to-Point traffic flows.

The IPv6 over Networks of Resource Constrained Nodes (6lo) Working Group has a busy agenda with the IPv6 Backbone Router draft being prepared for a Working Group Last Call. There will also be an update regarding IESG review of the proposed revisions of RFCs 6550 and 6775 where 6LoWPAN Neighbor Discovery nodes in an RPL domain do not participate in the routing protocol, and a review of security considerations for Address Protected Neighbor Discovery that protects the owner of an address against address theft and impersonation inside a low-power and lossy network. Other drafts up for discussion include Design Considerations for Low-Power Networks to provide guidelines for improving interoperability, IPv6 over Power-Line Communication Networks, and on enabling IPv6 mesh networks over Bluetooth.

Moving ahead to Wednesday afternoon, the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Working Group has an extremely busy agenda. The 6top protocol that enables distributed scheduling is now aiming for IETF Last Call, whilst the IESG feedback on the security functionality will be discussed. Two other drafts are also aiming for Working Group adoption including a description of a scheduling function that defines the behavior of a node when joining a network and a mechanism for carrying important information in infrequent network broadcasts. Another new draft defines a secure joining mechanism for enrolling devices into an 802.15.4 TSG network using 6TiSCH signalling methods.

The Homenet (homenet) Working Group is being held during late Wednesday afternoon. It recently published RFC 8375 which relates to the special use domain ‘home.arpa’, and the group will continue to discuss the Homenet profile of the Babel routing protocol. There are two updated drafts on the agenda, relating to third party provisioning of naming services for home networks and defining DHCPv6 options so that naming services can be outsourced.

Thursday morning sees the meeting of the Low Power Wide-Area Networks (lpwan) Working Group. This group recently published RFC 8376 which provides an informational overview of LPWAN technologies in order to perform a gap analysis.

There will be a discussion relating to the Working Group Last Call on the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities; and on how to advance the LPWAN Static Context Header Compression (SCHC) for CoAP specification. Two other drafts are being presented for adoption by the Working Group relating to SCHC specifications (see https://tools.ietf.org/html/draft-petrov-lpwan-ipv6-schc-over-lorawan-02 and https://tools.ietf.org/html/draft-zuniga-lpwan-schc-over-sigfox-03).

Last, but very much not least, the IPv6 Operations (v6ops) Working Group will be meeting on both the Thursday afternoon and Friday morning. It’ll kick-off with a presentation on World IPv6 Trends from APNIC Labs who are one of the organisations tracking IPv6 deployment. There’s then one new draft up for discussion on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks which 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.

There are also four existing drafts to be discussed. Requirements for IPv6 Routers defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS) by means of new mechanisms that were not available when RFC 7084 was published; Multi-Addressing Considerations for IPv6 Prefix Delegation considers prefix delegation considerations for both classic routing and various multi-addressing use cases; whilst IP over Ethernet (IPoE) Session Health Checking describes a mechanism for IP over Ethernet clients to achieve connectivity validation using PPP-style keepalives such as BFD Echo, or ARP and Neighbor Discovery functions.

At the Internet Society, we continue to promote IPv6 deployment. You can check out the World IPv6 Launch measurements for our latest measurements of IPv6 around the globe. You can also check out the Deploy360 online resources for getting started with IPv6 deployment. And you can read more about other topics of interest to the technology programmes of the Internet Society in the rest of our Rough Guide to IETF 102 posts.

IPv6-related Working Groups at IETF 102:

6MAN (IPv6 Maintenance) WG
Monday, 16 July 2018 @ 09.30-12.00 UTC-4, Laurier
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/

IPWAVE (IP Wireless Access in Vehicular Environments) WG
Monday, 16 July 2018 13.30-15.30 UTC-4, Laurier
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-ipwave/
Documents: https://datatracker.ietf.org/wg/ipwave/documents/
Charter: https://datatracker.ietf.org/wg/ipwave/documents/

ROLL (Routing Over Low power and Lossy networks) WG
Tuesday, 17 July 2018  09.30-12.00 UTC-4, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-roll/
Documents: https://datatracker.ietf.org/wg/roll/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-roll/

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Tuesday, 17 July 2018  13.30-15.30 UTC-4, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-6lo/
Documents: https://datatracker.ietf.org/wg/6lo/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6lo/

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Wednesday, 18 July 2018 13.30-15.00 UTC-4, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

Homenet (Home Networking) WG
Wednesday, 18 July 2018 15.20-16.50 UTC-4, Centre Ville
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-homenet/
Documents: https://datatracker.ietf.org/wg/homenet/documents/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

LPWAN (IPv6 over Low Power Wide-Area Networks) WG
Thursday, 19 July 2018 09.30-12.00 UTC-4, Centre Ville
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-lpwan/
Documents: https://datatracker.ietf.org/wg/lpwan/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/

V6OPS (IPv6 Operations) Working Group
Thursday 19 July 2018 13.30-15.30 UTC-4, Laurier & Friday, 20 July 2018 09.30-11.30 UTC-4, Place du Canada
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-v6ops/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blogTwitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Events IETF Internet of Things (IoT) Open Internet Standards

Rough Guide to IETF 102: Internet of Things

The buzz around the Internet of Things (IoT) is only increasing, to the surprise of, well, no one. We are often asked what is happening in the IETF in relation to IoT and in this short post I’d like to highlight some of the relevant activities and sessions scheduled during the upcoming IETF 102 meeting in Montreal. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance (OTA, which became an Internet Society Initiative in April 2017) IoT page for more details about many of these topics.

The IETF Hackathon, held on the weekend preceding the main IETF meeting (July 14-15), includes projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki. Projects of interest include those relating to:

  • Software Updates for Internet of Things (suit)
  • Authentication and Authorization for Constrained Environments (ace)
  • IPv6 over Low Power Wide-Area Networks (lpwan)
  • Work on IoT Semantic / Hypermedia Interoperability (WISHI)

The Thing-to-Thing Research Group (T2TRG) investigates open research issues towards turning the IoT into reality. The research group will be meeting on Thursday afternoon in Montreal to report out on their recent activities. Their summary meeting agenda can be found here. As in the past, full details and latest info on their activities can be found in GitHub. Of particular note is the recent update of a key draft document: State-of-the-Art and Challenges for the Internet of Things Security.

Two recently chartered IoT-related working groups met for the first time as working groups at the last IETF meeting in March, and are tackling very serious problems. I am very pleased to see these moving forward:

I would like to draw your attention to two recently initiated activities:

In this edition of the Rough Guide I would like to highlight some recent work in SUIT, addressing hash-based signatures. (Description courtesy Russ Housley)

Today, RSA is often used to digitally sign software updates. In preparation for a day when RSA, DSA, and ECDSA cannot be depended upon, a digital signature algorithm is needed that will remain secure even if there are significant cryptoanalytic advances or a large-scale quantum computer is invented. The hash-based digital signature algorithm specified in [HASHSIG] is one such algorithm. The use of hash-based signatures to protect software update distribution will allow the deployment of software that implements new cryptosystems even if such advances break current digital signature mechanisms.

[HASHSIG] specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm, and it is in the final stages of approval in the IRTF CFRG. [HASHSIG-COSE] specifies the conventions for these digital signatures with the CBOR Object Signing and Encryption (COSE) [RFC8152] syntax. The LMS algorithm is one form of hash-based digital signature; it can only be used for a fixed number of signatures. The LMS algorithm uses small private and public keys, and it has low computational cost; however, the signatures are quite large. The mechanism has broader applicability than SUIT, so a home that supports the broader perspective is desirable.

Ongoing work includes:

MUD

I also want to (again) point you to “Manufacturer Usage Description Specification” (MUD) which was developed in the Operations and Management Area Working Group (opsawg). MUD holds significant promise, and I am pleased to see that it is gaining some serious traction: The Internet Engineering Steering Group (IESG) recently approved it as a proposed standard.

From the abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

Eliot Lear, one of the MUD authors, has written a great article about it for the IETF Journal: Managing the Internet of Things – It’s All About Scaling.

As I have noted in previous IoT Rough Guides, MUD also plays a significant role in the project – Mitigating IoT-Based Automated Distributed Threats – being developed by the US National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).

If you have an interest in how the IoT is developing and being standardized in the IETF, I hope to see you in person or online at some of these meetings during IETF 102. (Note that If you know you will be unable to travel to the meeting and would like to participate remotely, you must register as a remote participant. There is currently no fee to be a remote participant at an IETF meeting but registration is required. If you do not want to register, you may opt to listen to the live audio stream of the sessions instead.)

Schedule and locations subject to change. Please refer to the online agenda to confirm. All times Montreal Time: EDT (UTC-4)

6LO (IPv6 over Networks of Resource-constrained Nodes) WG
Tuesday, 17-July 2018, 13:30-15:30, Duluth Meeting Room
Agenda/Materials
Documents
Charter

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Wednesday, 18-July 2018, 13:30-15:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

ACE (Authentication and Authorization for Constrained Environments) WG
Monday, 16 July 2018, 09:30-12:00, Viger Meeting Room
Agenda/Materials
Documents
Charter

CORE (Constrained RESTful Environments) WG
Monday, 16 July 2018, 15:50-17:50, Duluth Meeting Room
Thursday, 19 July 2018, 18:10-19:10, Van Horne meeting room
Agenda/Materials
Documents
Charter

HOMENET (Home Networking) WG
Wednesday, 18-July 2018, 15:20-16:50, Centre Ville Meeting Room
Agenda/Materials
Documents
Charter

IPWAVE (IP Wireless Access in Vehicular Environments) WG
Monday, 16 July 2018, 13:30-15:30, Laurier Meeting Room
Agenda/Materials
Documents
Charter

LPWAN (IPv6 over Low Power Wide-Area Networks) WG
Thursday, 19 July 2018, 09:30-12:00, Centre Ville Meeting Room
Agenda/Materials
Documents
Charter

LWIG (Light-Weight Implementation Guidance) WG
Friday, 20 July 2018, 11:50-13:20, Duluth Meeting Room
Agenda/Materials
Documents
Charter

OPSAWG (Operations and Management Area) WG
Tuesday, 17 July 2018, 15:50-18:20, Blenheim meeting room
Agenda/Materials
Documents
Charter

ROLL (Routing Over Low power and Lossy networks) WG
Tuesday, 17 July 2018, 09:30-12:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

SUIT (Software Updates for Internet of Things) WG
Wednesday, 18 July 2018, 09:30-12:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

T2TRG (Thing-to-Thing) RG
Thursday, 19 July 2018, 15:50-17:50, Laurier meeting room
Agenda/Materials
Documents
Charter

TEEP (Trusted Execution Environment Provisioning) WG
Monday, 16 July 2018, 13:30-15:30, Viger Meeting Room
Agenda/Materials
Documents
Charter

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blogTwitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Building Trust Events IETF Improving Technical Security Open Internet Standards

Rough Guide to IETF 102: Internet Infrastructure Resilience

As usual, in this post I’ll focus on important work the IETF is doing that helps improve the security and resilience of the Internet infrastructure.

At IETF 102 there are a lot of new ideas being brought to the community in the form of Internet Drafts aimed at improving the security and resilience of the Internet infrastructure, and I’d like to introduce some of them to you. But keep in mind – an Internet Draft does not indicate IETF endorsement, is not a standard, and may not result in any further work at the IETF.

So, let us look at what is happening in the domain of BGP, the routing protocol that connects the Internet.

Route leaks

There has been slow progress in the work on mitigating route leaks in the IDR Working Group (WG). One of the reasons for the slowness was that the group was considering two proposals addressing the route leak problem and both are IDR WG documents:  “Methods for Detection and Mitigation of BGP Route Leaks”, and “Route Leak Prevention using Roles in Update and Open Messages”. Plus, there is a third submission “Route Leak Detection and Filtering using Roles in Update and Open Messages” that also provides a solution in this area.

Fortunately, it seems that the relationship between all three is clearer now. Preventing route leaks locally by the potential culprit is described in draft-ietf-idr-bgp-open-policy. It also defines roles that can be useful in other solutions. draft-ietf-idr-route-leak-detection-mitigation now incorporates some ideas from draft-ymbk-idr-bgp-eotr-policy and is focused on detection and mitigation of the leaks upstream, more than one hop away from the culprit. In other words, the group is now working on two complementary and not conflicting solutions. Hopefully that will help with finalizing them soon.

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 fact, this should become a norm for every network, as defined in Action 1 of MANRS.

In the case where there are only direct customer relationships (i.e. the network’s customers are all “stub networks”), the task is relatively easy – one needs to collect the list of prefixes legitimately originated by these customer networks. This is most commonly done by using an IRR and collecting corresponding “route” objects, but with the proliferation of RPKI this can become a more robust process using cryptographically verifiable ROA objects that serve 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 does one determine who are the customers of one’s 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 a 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 Internet Draft “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” tries 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 considered transit customer networks, thereby facilitating the construction of prefix filters for a given ASN and 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,
  • a relying party does not know which “as-set” belongs to which ASN, and which as-set to use.

Validating AS-PATH without BGPsec

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 more serious vulnerabilities of the Internet routing system. BGPsec was designed to solve the problem of AS_PATH correctness.

But according to the authors of a new Internet Draft, “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization“, even leaving aside its complexity, its backward compatibility with ‘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 do that – the more chances to detect misconfigurations (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 a 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, e.g. to the Provider’s upstream providers or peers.

Using blockchain to secure IP addresses allocation, delegation and bindings

While RPKI technology offers the significant benefits of cryptographically secured authentication and authorisation of ownership of Internet number resources (IP address blocks and AS numbers), aligned with the distribution hierarchy of Internet number resources, it has also raised some concerns. The concerns are mostly related to centralization of routing authority and creating single points of failure, or even kill switches, represented by the  RIRs and IANA.

A technology that can facilitate building cryptographically strong and credible ledgers, without relying on a hierarchical system, is blockchain. Can it be applied in this case?

The Internet Draft, “An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings“, looks at how blockchain technology can be used to secure the allocation, delegation, and binding to topological information of the IP address space.  The main outcomes of the analysis are that blockchain is suitable in environments with multiple distrusting parties and that Proof of Stake is a potential candidate for a consensus algorithm.

However, several questions remain open, such as the balance of power between providers and customers, enforcement of RIR policies, incentives for adoption or deployment cost.

As you can see, the meeting in Montreal is certainly going to be full of interesting discussions in the area of Internet infrastructure resilience, and will hopefully lead to some important work, specifications and improvements to the fabric of the network that we all depend on for so much.

Related Working Groups at IETF 102

SIDROPS (SIDR Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/

GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy

It’s going to be a crazy busy week in London next week in the world of DNS security and privacy! As part of our Rough Guide to IETF 101, here’s a quick view on what’s happening in the world of DNS.  (See the full agenda online for everything else.)

IETF 101 Hackathon

As usual, there will be a good-sized “DNS team” at the IETF 101 Hackathon starting tomorrow. The IETF 101 Hackathon wiki outlines the work (scroll down to see it). Major security/privacy projects include:

  • Implementing some of the initial ideas for DNS privacy communication between DNS resolvers and authoritative servers.
  • Implementation and testing of the drafts related to DNS-over-HTTPS (from the new DOH working group).
  • Work on DANE authentication within systems using the DNS Privacy (DPRIVE) mechanisms.

Anyone is welcome to join us for part or all of that event.

Thursday Sponsor Lunch about DNSSEC Root Key Rollover

On Thursday, March 22, at 12:30 UTC, ICANN CTO David Conrad will speak on “Rolling the DNS Root Key Based on Input from Many ICANN Communities“. As the abstract notes, he’ll be talking about how ICANN got to where it is today with the Root KSK Rollover – and about the open comment period on the plan to roll the KSK in October 2018.

David’s session will be streamed live for anyone wishing to view remotely.

DNS Operations (DNSOP)

The DNS sessions at IETF 101 really begin on Tuesday, March 20, with the DNS Operations (DNSOP) Working Group from 15:50 – 18:20 UTC. Several of the drafts under discussion will relate to the Root KSK Rollover and how to better automate and monitor key rollovers. DNSOP also meets on Thursday, March 22, from 18:10-19:10, where one draft of great interest will be draft-huque-dnsop-multi-provider-dnssec. This document explores how to deploy DNSSEC in environments where multiple DNS providers are in use. As per usual, given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 UTC.  As shown on the agenda, there will be two major blocks of discussion. First, Sara Dickinson will offer recommendations for best current practices for people operating DNS privacy servers. This builds off of the excellent work she and others have been doing within the DNS Privacy Project.

The second major discussion area will involve Stephane Bortzmeyer discussing how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  When the DPRIVE working group was first chartered, the discussion was whether to focus on the privacy/confidentiality between a stub resolver and the local recursive resolver; or between the recursive resolver and authoritative server; or both. The discussion was to focus on the stub-to-recursive-resolver connection – and that is now basically done from a standards perspective. So Stephane is looking to move the group on into the next phase of privacy. As a result, the session will also include a discussion around re-chartering the DPRIVE Working Group to work on this next stage of work.

Extensions for Scalable DNS Service Discovery (DNSSD)

On a similar privacy theme, the DNSSD Working Group will meet Thursday morning from 9:30-12:00 UTC and include a significant block of time discussing privacy and confidentiality.  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. draft-ietf-dnssd-privacy-03 and several related drafts explore how to add privacy protection to this mechanism. The DNSSD agenda shows more information.

DNS-Over-HTTPS (DOH)

IETF 101 will also feature the second meeting of one of the working groups with the most fun names – DNS Over HTTPS or… “DOH!” This group is working on standardizing how to use DNS within the context of HTTPS. It meets on Thursday from 13:30-15:30. As the agenda indicates, the focus is on some of the practical implementation experience and the work on the group’s single Internet-draft: draft-ietf-doh-dns-over-https.

DOH is an interesting working group in that it was formed for the express purpose of creating a single RFC. With that draft moving to completion, this might be the final meeting of DOH – unless it is rechartered to do some additional work.

DNSSEC Coordination informal breakfast meeting

Finally, on Friday morning before the sessions start we are planning 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. True to the “informal” nature, 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 Wednesday meeting. 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. 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 101:

DNSOP (DNS Operations) WG
Tuesday, 20 March 2018, 15:50-18:30 UTC, Sandringham
Thursday, 22 March 2018, 18:10-19:10 UTC, Sandringham

Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 21 March 2018, 13:30-15:00 UTC, Balmoral
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 22 March 2018, 9:30-12:00 UTC, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DOH (DNS over HTTPS) WG
Thursday, 22 March 2018, 13:30-15:30 UTC, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/agenda/doh/
Documents: https://datatracker.ietf.org/wg/doh/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blogTwitter, or Facebook using #IETF101 to keep up with the latest news.

Categories
Building Trust Events Improving Technical Security Open Internet Standards Technology

Applied Networking Research Workshop (ANRW) Call for Papers Due 20 April

We’re excited to share news of the third edition of the Applied Networking Research Workshop (ANRW2018), which will take place in Montreal, Quebec, on Monday, July 16 at the venue of the Internet Engineering Task Force (IETF) 102 meeting. The workshop program already includes some great invited talks and the Call for Papers is open now, with a deadline of 20 April.

ANRW2018 will provide a forum for researchers, vendors, network operators and the Internet standards community to present and discuss emerging results in applied networking research. The workshop will also create a path for academics to transition research back into IETF standards and protocols, and for academics to find inspiration from topics and open problems addressed at the IETF. Accepted short papers will be published in the ACM Digital Library.

ANRW2018 particularly encourages the submission of results that could form the basis for future engineering work in the IETF, that could change operational Internet practices, that can help better specify Internet protocols, or that could influence further research and experimentation in the Internet Research Task Force (IRTF).

If you have some relevant work and would like to join us in Montreal for the workshop and maybe stick around for the IETF 102 meeting taking place the same week, please see the full Call for Papers, which includes detailed paper submission and formatting instructions. In a new twist for 2018, the workshop will be accepting some talks that are not-for-publication resubmissions of works that have been published elsewhere during the last 12 months.

The one-day workshop is co-sponsored by the Association for Computing Machinery (ACM), the Internet Society and the Internet Research Task Force (IRTF).

I hope to see you in Montreal for what promises to be a very interesting workshop and a great opportunity for cross-fertilisation between the networking research and Internet standards communities.

Categories
Improving Technical Security Open Internet Standards

The Danger Of The New Internet Choke Points

Many people were shocked by the scale and pervasiveness of government monitoring and tampering with Internet communications. From a security point of view, technically many of these actions are man-in-the-middle, zero-day exploits, trojans, key compromises, etc. – they are known attacks. But the scale and the capabilities of the spying agencies turn this into a qualitatively different threat with a significantly higher risk.

This understanding has already prompted protocol designers, software and hardware vendors, Internet service providers, and content providers to re-evaluate prevailing security and privacy threat models and to refocus on providing more effective security and confidentiality.

But what makes the scale so big that it changes the equation significantly?

The key aspect here is that it is long-term, indiscriminate data collection of all communication flows available at a particular point, allowing correlation of data flows over a long period of time.

And not all collection points are equally valuable for that task.

The Internet was designed to avoid single points of failure – choke points – or to mitigate their impact. Originally, that meant resilience against failures at the IP layer. But as the Internet evolved, the concentration and centralization of certain functions at various layers of the Internet architecture has created new choke points and, consequently, new threats. Pervasive monitoring is one of them.

In our paper submitted to the W3C/IAB workshop on “Strengthening the Internet Against Pervasive Monitoring” (STRINT), we looked at the problem of pervasive monitoring from an architectural point of view. We identified some components of Internet infrastructure that provide attractive opportunities for wholesale monitoring and/or interception, and, therefore, represent architectural vulnerabilities.

Can their impact be mitigated? And how? Can the Internet evolve to reduce such vulnerabilities, and what would be the driving forces? What are the forces that could prevent this from happening? We pondered these questions, too, and encourage you to read our paper, provide feedback in the comments below, and engage in the dialog that will be coming up at IETF 89 in London.