Category: IETF

Jan 04

Russ White On The Process Around Creating RFCs in the IETF

Have you ever been curious about the process of creating a Request For Comments (RFC) document within the Internet Engineering Task Force (IETF)?  These are the standards like, oh, “HTTP”, that power the Internet. Have you been interested in understanding how they work?

If so, someone I know, Russ White, recently completed a 7-part article series about the entire process over on the Packet Pushers Network site. Russ has nicely summarized the series on his site at:

https://rule11.tech/the-rfc-process/

He does a nice job providing an overview of the long process of starting with an idea, creating an “Internet draft”, working it through the IETF process, and then hopefully getting it published.

There are many more details, of course, but Russ lays out the high-level aspects and mentions some of the parts of the process which are harder to understand for someone new to the IETF.

If you are interested in the RFC process, I would encourage you to give Russ’ series of articles a read.

Using Markdown instead of XML

I do have one area of disagreement with Russ. He advocates for using XML for writing Internet drafts, whereas I used to write drafts in XML but have moved over the years to instead using Markdown. If you are writing simple text documents, I believe Markdown is a simpler and easier way to work.

Back in 2019, I gave at tutorial session at the IETF meeting in Prague about “Writing Internet Drafts in Markdown”. The materials are at:

[One important note - this tutorial session was given FIVE YEARS AGO and the state of Markdown tools is always evolving. I would monitor https://authors.ietf.org/drafting-in-markdown to see about new tools and ways to work with Markdown.]

The video of the tutorial session is actually a great comparison of the two ways of creating Internet drafts. In the first half, my friend Matt Miller explains how to create I-Ds using XML tools, and then around the 32-minute mark I explain how to create drafts in Markdown.

Either way - XML or Markdown - hopefully Russ’ series helps explain a bit more about the whole process of writing a RFC.

 

Mar 23

IETF 107 Starts Today as a Virtual Meeting

A view of Vancouver from Skylab - photo from NASA

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

The post IETF 107 Starts Today as a Virtual Meeting appeared first on Internet Society.

Nov 15

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

photo of the "super trees" in Singapore

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.

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.

The post IETF 106 Begins Nov 16 in Singapore – Here is how you can participate remotely in building open Internet standards appeared first on Internet Society.

Apr 07

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

First page of RFC 1

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.

The post Celebrating 50 Years of the RFCs That Define How the Internet Works appeared first on Internet Society.

Dec 03

The Publishing of RFC 8496 Concludes the 10-year Saga of P-Charge-Info

Rfc 8496 p charge info

October 31, 2018, was a special day for me. Not because it was Halloween, but because after 10 years a small little document I co-authored about the "P-Charge-Info" header for SIP-based Voice-over-IP (VoIP) was published as informational RFC 8496. You can see it at either:

Ultimately, all this document does is register the Session Initiation Protocol (SIP) Header Field of "P-Charge-Info" within the "SIP Parameters" registry maintained by IANA at:

But the story of getting that registration to happen is a long one!

In the beginning...

The short version is this. Back in around 2007 or so, I was working for Voxeo and we were using the "P-Charge-Info" header in our large SIP-based application server to pass along billing information. Essentially, when someone made a call on our system, we wanted to pass a billing identifier that was often different from the source phone number (i.e. "CallerID"). This quote from RFC 8496 was pretty much Voxeo's use case:

As another example, a hosted telephony provider or hosted voice application provider may have a large SIP network with customers distributed over a very large geographic area using local market PSTN numbers but with only a very few actual PSTN interconnection points.

The customers may all have local phone numbers yet outgoing calls are actually routed across a SIP network and out specific PSTN gateways or across specific SIP connections to other SIP service providers. The hosted provider may want to pass a billing identifier to its SIP service providers either for the purpose of simplicity in billing or to obtain better rates from the SIP service providers.

While we at Voxeo were already using P-Charge-Info extensively, we wanted to use the P-Charge-Info header with more SIP service providers, and needed some form of documentation for how to use the header. We also were concerned about the profileration of more P-headers and wanted to register "P-Charge-Info" with IANA so that more people might find and use that header rather than inventing their own. (We were happy with P-Charge-Info and didn't want to have to support more SIP headers related to charging identifiers.)

So I began the process of submitting an Internet Draft way back in February 2008 documenting P-Charge-Info and requesting its addition to the IANA registry.

Almost immediately Tolga Asveren, then at Sonus Networks, contacted me to let me know they were using P-Charge-Info in the SIP equipment they were selling. He had some great suggestions, supplied some additional text, and was interested in working on the document with me. So I published a -01 draft 3 days after the first draft, and Tolga and I began our 10-year journey through the process of getting this document published.

Square pegs in round holes - slamming ISDN info into a SIP header

Along the way, others approached us from traditional PSTN telecom companies indicating that they were interested in using P-Charge-Info as a way of passing the "ISUP Charge Number" that was part of ISDN signaling. Though it was not something that either Tolga or I worked directly with, we were okay adding this in, and so two new parameters got added:

  • Numbering Plan Indicator (NPI)
  • Nature of Address (NOA)

... along with a substantial amount of new text.

A 2011 version of the document can show what this was all about.

Lost in limbo

Meanwhile, the document had gotten caught up in the need to wait while RFC 3427 was replaced by RFC 5727, which defined the whole SIP Header Field registration process.

And then I wound up leaving Voxeo to join the Internet Society (my current employer). And so my attention was no longer focused on VoIP and so this draft was truly a "back burner" kind of thing that I just worked on in random moments.

And unfortunately, it turned out that slamming legacy PSTN signalling into a SIP header caused a whole number of challenges, both with getting agreement - and also with some of the internal IETF processes. It turned out that to do this registration, we were going to have to do some other registrations - and more.

I also published a version that changed some of the parameters values in a way that was not backwards-compatible, which caused some friction.

By 2015, both Tolga and I were ready to ... just... let... it... die...

Returning from the dead - and returning to the SIP roots

And then in early 2017, Henning Schulzrinne and Richard Shockey contacted me to let us know that the US FCC was interested in the status of P-Charge-Info. The FCC had some billing issues between carriers where the carriers were in some cases already using P-Charge-Info, but the carriers really wanted an actual RFC versus an expired draft. There was also some potential interest in having the header around as one of many different tools in the FCC's efforts to combat robo-calling / spam phone calls.

So Tolga and I worked with Henning and the IETF area directors to come up with a plan to resuscitate the document. In doing so, we stripped out all the legacy PSTN signaling. Specifically we removed the NPI and NOA parameters, and all the mentions of the ISUP Charge Number.

We returned it to the simplicity of the original document way back in 2008.

The original goal had been to simply document existing usage of the P-Charge-Info header, as it was being used by various SIP providers and vendors. We returned it to that root.

Success!

After a number of further drafts, an expert review by Adam Roach, and more feedback from Area Director Ben Campbell, the draft finally entered the RFC Editor queue by way of the Independent Series Editor (ISE). Many thanks are due to Ben to sponsoring the draft. He, Jean Mahoney, and Adam were all critical in helping get it across the finish line. Thanks, too, to Henning and Richard who provided the spark for us to revive the document.

It would not have happened, either, if Tolga had not taken the lead over the past year in making edits, answering all the questions from people, proposing solutions and continually asking how to move the draft forward. I may have been the one editing the XML and submitting the new draft versions, but he was the one driving the text revisions.

It's great to see the document finally published as Informational RFC 8496. Looking back on the journey, there were:

  • 16 revisions of draft-york-sipping-p-charge-info (2008-2012)
  • 6 revisions of draft-york-dispatch-p-charge-info (2012-2015)
  • 9 revisions of draft-york-p-charge-info (2017-2018)

Now, granted, some of those were a simple "update to keep the document from being 'expired'", but still it was all a great amount of work.

I learned a HUGE amount along the way. When the journey began in 2008, I didn't really understand much about IETF processes. Now I do - and now understand how we could have done this quite differently along the way.

Thanks to everyone who provided feedback and support over the years.

P-Charge-Info is finally registered in that IANA registry! :-)

Nov 02

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 minimisation – draft-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 locally – draft-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 resiliency – draft-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 completely 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)

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/agenda/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/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, 8 November 2018, 13:50-15:50 ICT, Meeting 2
Agenda: https://datatracker.ietf.org/meeting/103/agenda/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 blog, Twitter, or Facebook using #IETF103 to keep up with the latest news.

The post Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy appeared first on Internet Society.

Oct 24

New Internet Draft: Considerations on Internet Consolidation and the Internet Architecture

Swirling vortex of stars

Are there assumptions about the Internet architecture that no longer hold in a world where larger, more centralized entities provide big parts of the Internet service? If the world changes, the Internet and its technology/architecture may have to match those changes. It appears that level[ing] the playing field for new entrants or small players brings potential benefits. Are there technical solutions that are missing today?

These questions were one of many asked in a new Internet Draft published yesterday by former IETF Chair Jari Arkko on behalf of several Internet Architecture Board (IAB) members with the title “Considerations on Internet Consolidation and the Internet Architecture”:

https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00

The draft text is based on the IAB “Consolidation” blog post back in March 2018as well as a new post Jari and Brian Trammell have written for the APNIC and RIPE sites.

The abstract of the Internet Draft is:

Many of us have held a vision of the Internet as the ultimate distributed platform that allows communication, the provision of services, and competition from any corner of the world. But as the Internet has matured, it seems to also feed the creation of large, centralised entities in many areas. This phenomenon could be looked at from many different angles, but this memo considers the topic from the perspective of how available technology and Internet architecture drives different market directions.

The document discusses different aspects of consolidation including economic and technical factors. It ends with a section 3, “Actions,” that lists these questions and comments for discussion:

  •  Are there assumptions about the Internet architecture that no longer hold in a world where larger, more centralised entities provide big parts of the Internet service? If the world changes, the Internet and its technology/architecture may have to match those changes. It appears that level the playing field for new entrants or small players brings potential benefits. Are there technical solutions that are missing today?
  • Assuming that one does not wish for regulation, technologies that support distributed architectures, open source implementations of currently centralised network functions, or help increase user’s control can be beneficial. Federation, for example, would help enable distributed services in situations where smaller entities would like to collaborate.
  • Similarly, in an asymmetric power balance between users and services, tools that enable the user to control what information is provided to a particular service can be very helpful. Some such tools exist, for instance, in the privacy and tracking-prevention modes of popular browsers but why are these modes not the default, and could we develop them further?
  • It is also surprising that in the age of software-defined everything, we can program almost anything else except the globally provided, packaged services. Opening up interfaces would allow the building of additional, innovative services, and better match with users’ needs.
  • Silver bullets are rare, of course. Internet service markets sometimes fragment rather than cooperate through federation. And the asymmetric power balances are easiest changed with data that is in your control, but it is much harder to change when someone else holds it. Nevertheless, the exploration of solutions to ensure the Internet is kept open for new innovations and in the control of users is very important.
  • What IETF topics that should be pursued to address some of the issues around consolidation?
  • What measurements relating to the developments centralization or consolidation should be pursued?
  • What research – such as distributed Internet architectures – should be driven forward?

These are all excellent questions, many of which have no easy answers. The draft encourages people interested in this topic to join the IAB’s “architecture-discuss” mailing list (open to anyone interested to subscribe) as one place to discuss this. This is all part of the ongoing effort by the IAB to encourage a broader discussion on these changes that have taken place to the way in which the Internet operates.

It is great to see this Internet Draft and I do look forward to the future discussions to see what actions or activities may emerge. It’s a challenging issue. As the draft discusses, there are both positive and negative aspects to consolidation of services – and the tradeoffs are not always clear.

This broader issue of consolidation or centralization has been an area of interest for us at the Internet Society for quite some time, dating back to our “future Internet scenarios” in 2008 and even before. More recently, our Global Internet Report 2017 on the “Paths to Our Digital Future” recognized the concerns – so much so that we decided to focus our next version of the GIR on this specific topic. (Read our 2018 GIR concept note).

Beyond the Global Internet Report, we’ve published articles relating to consolidation – and it’s been a theme emerging in several of our “Future Thinking” posts. I know that we will continue to write and speak about this theme because at its core it is about the future of what we want the Internet to be.

Please do join in these conversations. Share this Internet Draft with others. Share our 2017 Global Internet Report. Engage in the discussions. Help identify what the issues may be – and what solutions might be.

The Internet must be for everyone. Together we can #ShapeTomorrow.

Image credit: a cropped section of a photo by Paul Gilmore on Unsplash

The post New Internet Draft: Considerations on Internet Consolidation and the Internet Architecture appeared first on Internet Society.

Jul 13

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.

The post Rough Guide to IETF 102: DNSSEC, DNS Security and Privacy appeared first on Internet Society.

Mar 22

How Do We Connect Everyone to the Internet? An IETF 101 Technical Plenary

How do we connect everyone, everywhere, to the Internet? What role do “community networks” play in helping connect more people? How can we best use wireless spectrum and what are the issues with that? How can satellites fit into the picture? And what is the state of satellite technology? And what about the role of “space lasers”?

All that and more was the subject of yesterday’s featured panel at the Technical Plenary at IETF 101 in London.

Interested to learn more? Watch/listen to the Global Access to the Internet for All (GAIA) session TODAY (22 March) at 1:30pm UTC:
– Agenda
– Video/slides/chat
– Audio-only

Organized by the Internet Architecture Board (IAB) and the Internet Research Task Force (IRTF), the panel was moderated by our Jane Coffin and included these speakers:

  • Leandro Navarro Moldes, Associate Professor, Universitat Politècnica de Catalunya (SLIDES)
  • Steve Song, Wireless Spectrum Research Associate, Network Startup Resource Center (SLIDES)
  • Jonathan Brewer, Consulting Engineer, Telco2 Limited (SLIDES)

You can watch the recording of the session at:

The session began with Leandro Moldes outlining how half the world is still not connected to the Internet and is not able to benefit from all the opportunities. He explored the reasons why, the challenges with business models, and the opportunities to improve the situation. He spoke about the different types of community networks and the need for small providers to cooperate and collaborate to be most effective.

Next Steve Song opened with the provocative question – do we care more about connecting refrigerators than poor people? He went on to talk about the impact of fiber optic connections in Africa – and then explained both the opportunities and challenges of using radio spectrum for communication. Steve discussed the economics and politics of spectrum allocation and finished looking at some of the upcoming next generation technologies. A key message: access diversity is critical!

Finally, Jonathan Brewer provided a view on satellite options for Internet access. He outlined typical orbits and latencies; spoke about different architectures and common deployment scenarios; and explained different satellite spectrum bands and then pros and cons. We learned about “rain fade” and other terms. He also offered three newer commercial ventures as examples of the exciting activities in the space sector.

After the panelists spoke, Jane opened the floor to questions. Attendees asked about the diversity of options, the need to include more people and regions, and more. And yes, there was a discussion about “space lasers” and how some of these new networks are building mesh networks based on using lasers between satellites.

It was an educational session that offered many ideas for how to connect the rest of the world.

If you would like to learn more and find out how to help:

Image credit: Stonehouse Photographic

The post How Do We Connect Everyone to the Internet? An IETF 101 Technical Plenary appeared first on Internet Society.

Mar 16

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 blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.

The post Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy appeared first on Internet Society.