The Chicago IETF begins in a couple of days, and I wanted to point people to a few highlights from my perspective. Of course, with over hundred working groups, the IETF’s work program is quite diverse, and different people are interested in different topics. There is a lot that is particularly interesting for me:
New transport: I expect a lot of attention again on QUIC, the transport protocol designed to integrate functions from TCP and TLS. They are meeting Thursday at 09:00. They will use their meeting time to discuss the main protocol drafts, and issues such as details of the integration to HTTP. There will be a QUIC Tutorial on Sunday afternoon (15:00).
Coordinated Address Space Management: The CASM BOF will meet Monday 15:20 and discuss how organisations manage their address space and what possibly standardised tools may be useful in that.
Trusted Execution Environments: The A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) BOF meets Tuesday 14:50. They talk about a possible application layer security protocol that would allow configuring security credentials and software running on a Trusted Execution Environment (TEE). These environments are often found in set-top boxes, smart phones, tablets, wearables, etc. Current control and configuration protocols are propietary.
GitHub: More and more of networking software gets developed in GitHub, and it has also become a popular way for us to collaborate on the specifications themselves, with everyone having an ability make edits, raise issues, etc. We now have some experience from doing this, and the WGs Using GitHub (WUGH) BOF will discuss those experiences and find ways to work even better with GitHub. They meet Monday 17:10. There’s also a mailing list for discussing this topic.
YANG: In the Routing Area, YANG work continues to be of high interest. A Joint YANG session among four Working Groups (CCAMP, MPLS, PCE, and TEAS) will be held on Friday 09:00 to coordinate the work. Topics will include TE topology models, MPLS, PCE, Microwave Radio Link, and Transport. In the RTGWG, an update on the RTG YANG Architecture Design Team and work on-going in OpenConfig will be presented Wednesday 09:00.
Administrative matters: Changes to how the IETF is administered are also a popular discussions for the IETF community. The MTGVENUE working group is continuing our effort to define requirements that IETF meeting sites must fulfill, which seems even more important among the increasing number of travel restrictions. The IETF needs to stay as open as possible for all attendees. The group recently went through some changes. The group meets Monday 15:20. And the IASA 2.0 BOF asks whether there should be adjustments or even restructuring of the IETF administrative arrangements overall. Our arrangements have served us well, but there are also issues, and with 10+ years of experience it is time to re-assess the system. We held two workshops earlier on this topic, and the results of those workshops are outlined in an Internet-Draft. The group meets Wednesday 13:00.
New leadership: The IETF Nominations Committee (Nomcom) is charged with selecting persons for the various IETF leadership positions. The changeover is in the March meeting. For our steering group, Eric Rescorla, Adam Roach, and Warren Kumari will be starting as new Security, Applications and Real-Time, and Operations Area Directors. And I will be stepping down after four yours as chair, with Alissa Cooper continuing in that role. Please welcome the new chair and ADs! And thank you for volunteering to do this!
Running code. Last but not least, none of the above matters without software that actually does those things. Our Hackathon and Code Sprint events are open for everyone to attend, do join us and work on something that is important to you or your business! Both events start Saturday morning (09:00/09:30) before the IETF. The Code Sprint is the way that much of IETF’s own web systems and tools have come about. I want to emphasise how much we depend there both on volunteers as well as capable contractors — we need you. There are also many side events during an IETF, for instance the network operators meeting (IEPG, Sunday 10:00).
I also wanted to thank all our sponsors and supporters, and Ericsson in particular for hosting us in Chicago.
The sponsors make our meetings and IETF services possible. Thank you!
See you soon, and I wish everyone safe travels to Chicago. Hopefully the effects of various last-minute restrictions (such as the laptop ban on some flights) will remain minimal. And those participating in the meeting online — see you virtually soon!
Jari Arkko, IETF Chair
Picture credits: Thompson’s original 1830 58-block plat of Chicago from Wikimedia. In public domain.
Recent news stories, and some IETF list discussion, have related to the release of (claimed) CIA materials relating to surveillance, hacking and information warfare. There has been quite a bit of discussion about the details of the various attacks contained in this leak, such as those relating to surveillance through smart TVs, or hacking vehicles. But are there more general conclusions that we can draw from release of this information?
First, we think the content of leaks is not particularly surprising, especially given knowledge of other leaks in recent years, such as those from Edward Snowden. Malware is another tool in the same toolbox that is already known to include many other efforts that attempt to compromise security, such as pervasive surveillance.
But the release of the current tranche of documents does seem to nicely support a number of things that we knew already and that are arguably more worthy of consideration:
Security is not a single feature, rather the level of security one experiences needs to be thought of as an emergent property of the whole system. Communications security, for instance, is necessary but not sufficient. You also have to worry about the security of your devices, platforms, operating systems, and components. And the reliability of your communication partners.
There is no such thing as privileged access for the good guys once there are more than a very small number of people involved. Sooner or later the privileged way to access information or hacks will either leak, be re-discovered independently by others, or be shared to parties that do not have your best interest in mind. In addition, systems built to take advantage of the privileged access will get broken and misused.
All malware is just that, malicious software designed to disrupt or compromise other systems. And all will eventually leak. Secretly held knowledge of vulnerabilities makes us all less safe. The vulnerabilities will be exploited, perhaps traded or shared, instead of being reported and fixed. And when they leak out, they do damage to your friends as well as your supposed enemies.
The security of our communications and applications matters a lot. Lives are at stake, not just your browsing history. Our entire societies run on top of our technical infrastructure, from hospitals and power plants to political processes and our economy. We cannot afford to compromise the security of these systems.
As noted, we think these are matters that are already known, but reminding ourselves of the big picture now and then can be useful.
From the IETF perspective we are of course committed to continuing our effort to provide the best possible technical tools for the Internet and the users. One technical observation that may be of use is that focusing on protecting data and not merely links or transport needs better support, make it easier to achieve in practise and at scale.
Jari Arkko, IETF Chair
Stephen Farrell, IETF Security Area Director
Photo credits: Image of the toxic leak in a reservoir in Ajka, Hungary affecting the villages of Kolontar and Devecsar, photo by DigitalGlobe, sourced from Wikimedia (CC BY 3.0).
The current IETF Administrative Support Activity (IASA) arrangements were created more than ten years ago when the IETF initially took charge of its own administration . The arrangements have served the IETF well, but there’s been considerable change in the necessary tasks and in the world around us since then . What administrative arrangements will best support the IETF going forward?
A series of virtual workshops have been arranged as part of an effort, dubbed the IASA 2.0 project, to gather community input as part of a review and possibly rework of IASA arrangements.
The workshops will help understand what is working well and what challenges or missed opportunities exist in the current system. We also want to understand what the IETF will need in coming years. Possible topics include:
internal IASA and IAOC organizational issues;
roles and interfaces between the IETF, the IAOC, ISOC, the IESG, and contractors;
availability of staff, contractor, and volunteer resources compared to the administrative workload;
finance and sponsorship arrangements.
The workshops will be virtual meetings where the participants can provide their experiences and suggestions. Proposed changes and solutions will be dealt with in a later phase . Meeting notes and an Internet Draft summarizing the input will be produced afterwards.
The agenda will be the same for both workshops, which are scheduled to accommodate participants in different timezones:
IASA 2.0 Workshop 1
Tuesday, 28 February 2017
11:00 UTC (6:00AM ET / 12:00 noon CET)
IASA 2.0 Workshop 2
Tuesday, 28 February 2017
16:00 UTC (11:00AM ET / 17:00 CET).
These documents will be helpful to review in advance of the workshop:
Every year, the IETF selects its leadership through the nominations committee or NomCom process. Today, the committee has announced our new steering group (IESG) members.
The new members are Alissa Cooper (Cisco), who will be new IETF Chair as I am stepping down. Warren Kumari (Google), will be our new Operations and Management Area AD. And Eric Rescorla (Mozilla) becomes the new Security Area AD. Together with the continuing ADs, this is a great team, and the IETF is in extremely capable hands!
When the new members get seated, we will be saying goodbye and thank you to two long-serving ADs: Stephen Farrell (TCD) in the Security Area and Joel Jaeggli (Fastly) in the Operations and Management Area. Their service to the community, dedication to making the Internet better, and rational approach to contentious issues have made the IESG, the IETF, and the Internet better.
Notably, with these appointments we’ll be continuing to demonstrate gender diversity in our leadership. Not only has Alissa been selected as the first female chair, but we’ll continue to have five female area directors serving in the IESG, the most we’ve had at one time. They are in these roles because they are the best people for their roles, but I think this also sets a great example for other tech organisations to follow in gender diversity I would like to challenge other standards organisations to top our results.
The Internet Engineering Task Force (IETF) is a global community of network designers, operators, vendors, and researchers that develops Internet protocols. Our focus is the evolution of the Internet architecture and the smooth operation of the Internet. We do most of our work online, largely through email and mailing lists, but we also regularly meet in-person at locations around the world. Whether online or in-person, we come together as individuals with the shared goal of making the Internet work better.
An important part of the Internet’s success is that it is all voluntary. Everyone connected to the Internet uses the same mechanisms by choice, and the Internet only works because everyone connecting uses the same mechanisms. Those mechanisms are the protocols of the Internet.
Because the Internet is voluntary, it only works if everyone wants to use the same protocols. So, our work on open standards–like that of the open source and and scientific research communities–fundamentally depends on the ability to work collaboratively across national borders.
The IETF does not make comments on political matters. But we do comment on topics that affect the IETF and the Internet. Specifically, the recent action by the United States government to bar entry by individuals from specific nations raises concerns for us—not only because upcoming IETF meetings are currently scheduled to take place in the U.S., but also because the action raises uncertainty about the ability of U.S.-based IETF participants to travel to and return from IETF meetings held outside the United States.
The situation is fluid. Legal and political processes around the imposition of barriers to travel will likely continue. We plan to track the situation closely in the US and elsewhere. We believe that Internet protocols develop best when people of many backgrounds can offer their contributions, and we are negatively impacted by policies that prevent such collaboration.
IETF meeting venues are always reviewed for potential impact on attendance by participants from different countries. Our next meeting is planned for Chicago, and we believe it is too late to change that venue. We recognize, however, that we may have to review our other planned meeting locations when the situation becomes clearer. We are already reviewing what to do as far as location for the next open North American meeting slot.
RFCs are documents designed to serve a variety of purposes. They offer information to developers engineers on how to make the Internet interoperate. They specify protocols, document registries and code points, and describe network experiments. They do all these things with an eye towards short-term relevancy, while being structured in such a way as to save this body of knowledge in perpetuity. Everything from the numbering scheme to the document style to the file format works together to balance the short-term and long-term needs. The RFC format project is pushing those boundaries quite a bit to make documents more easily consumed in the short term, while relying on the advances in technology to support that long-term archive of material. This is not, however, a post about the RFC format (though if you want to know more, feel free to read the FAQ!)
This is a post about what the RFC Editor is doing to improve the archival component of the RFC Series. Late in 2016, the RFC Editor entered into an agreement with the National Library of Sweden to properly archive RFCs, both the ones already published and new ones as they are posted via an RSS feed. The National Library of Sweden was established in 1661, and has had a digital archive since 1997. They take their archiving very seriously, storing material in a bunker 40 meters under the main building of the National Library.
Picture: The library’s system for digital preservation is called Mimer. Mimer is a figure from the old Norse mythology, a gentle giant who was the guardian of Mimers: a fountain of wisdom from which if you got a sip of that well you would become all wise and know everything that had happened before and everything that will happen in the future.
Stepping back for a moment from this very good news, let me explain a bit why archiving isn’t just about having a nice set of offsite backups. Quite a bit of this is explained in draft-iab-rfc-preservation but here is a quick high-level summary. A proper digital archive, at minimum, has that offsite backup component in storing a copy of the material. Beyond that, it also stores quite a bit of metadata about the document, such as when it was retrieved, when it was published, where it came from, who the author(s) and/or editor(s) are, the original location, title, all assigned identification numbers (such as DOI, ISSN, or other custom information, which in our case is the RFC number) and so on. A digital archive commits to storing and maintaining this information, and doing what it can to try and make sure the document can be viewed by whatever modern technology is available at the time.
The RFC Editor needs partners like the National Library of Sweden to archive the series. The resources available to the RFC Editor are necessarily prioritized towards the editing and publishing of RFCs; the archive itself is in those off-site backups and printed hard copies. Having an organization that specializes in digital archiving is a big win for preserving this rich set of material that documents the birth and evolution of the Internet. The RFC Editor will, of course, continue with proper backups, and will always consider the needs of an archive when we discuss any changes to the format and metadata around RFCs.
And with that, I want to offer many thanks to the people at the National Library of Sweden for agreeing to archive the RFC Series. Tack!
The essence of the IETF is that it is a place for people who both write code and specs. The IETF motto is “Running Code and Rough Consensus”. With that in mind, a big part of our work is helping and encouraging for that code writing to happen. This happens at many levels: the IETF Hackathon focuses on open source projects and Internet technology, the CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on.
We will be hosting another IETF Hackathon at IETF-98 which will take place in Chicago at the end of March. The Chicago Hackathon will run from Saturday March 25 to Sunday March 26, but will surely have follow-ups during the rest of the week. We will also get to demonstrate some of the results in the Bits-n-Bites later in the week.
So do considering joining this event. The signup page is here. You can keep up to date by subscribing to the Hackathon mailing list.
Hackathon is free to attend and open to the public.
And remember that what you do at these events is up to you. You decide what is the coolest tech thing that you need to implement! So don’t be afraid to add your own project or team!
I’ll say that again: add your own topic to the wiki, and work on it!
See Charles Eckel’s mail and the wiki for the details.
I would also like to offer IETF-98 as a place for various interop and test events. We typically have several at every IETF. Many people travel to the IETF anyway, so it is a convenient place to spend some time testing. Let us know if you are planning to do some testing, we may in some cases also be able to help with rooms, networking, and help publicise your event to other networkers!
First, there will be a CodeSprint on Saturday March 25th just before IETF-98 in Chicago. CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on. Everyone is welcome to attend! Read more from  and sign up .
And remember that what you do at these events is up to you, you decide. You decide what is the coolest or most useful feature; you decide what IETF data tracker feature you need for your work.
Secondly, we would like to draw your attention to work on tools that serve the IETF, and we would like to signal for a need to draw in further people and vendors in this effort.
Part of the work is on a volunteer basis, both in our Code Sprints and through various long-term efforts. Part of the work is run on a commercial basis, e.g., operations of the various IT systems that our Secretariat provides or the implementation of various new tools that we have decided to implement. The commercial efforts typically require some volunteer effort as well, for instance, Robert Sparks is the project manager for all datatracker related efforts and Joe Hildebrand is the project manager for the IETF web site redesign project.
Thanks to all of the volunteers for their efforts. We are VERY grateful for their work, and it is necessary work. But at the same, we are realizing that resources are spread fairly thin. We’re happy about the turnout in the IETF Code Sprints, but would love to get more people. And we would love to have individuals who care about particular tooling issues enough to adopt them as their longer term project and take them to completion. Getting involved with the volunteer tools work starts best at the Code Sprint, however. The next one will be on Saturday, March 25, just before the IETF begins in Chicago. Join us, and book your flight tickets so that you can spend the Saturday with us!
But the same issue applies even to the commercial parts , and we would like to have more companies or capable individuals bid for some of the projects. The Technology Management Committee and the IAOC have recently awarded the projects for building the tools necessary for the new RFC format, for instance, to two individuals that are very active in the IETF community, one of which was already doing quite a lot for the IETF. For the long-term sustainability of the IETF IT and tool efforts, we would desperately like to extend the set of people and companies looking at and bidding on these efforts. We know that many individuals in the IETF sphere have capabilities in this area, and we’d like to draw your attention to this opportunity as well. We welcome first time qualified bidders, and we pay competitively. If you can do the work, a contract to work on open source tools for the IETF can be rewarding.
Jari Arkko, IETF Chair
Russ Housley, Chair of the IAOC Tools Committee
Do you have an idea that you believe would be worthwhile standardising? Now would be a great time to start talking about it, in time for our meeting in Chicago in March!
New ideas can be proposed in the IETF in many ways:
Small improvements and features of ongoing work: these fit right in, just take the idea to the relevant working group. You can send that mail today!
Bigger new ideas may need a working group’s charter be extended or a new working group be created. Often these can be done directly online after discussion; talk to your WG chairs or Area Directors to get the process started. The proposals for significant new work always get discussed in the whole IETF community, on the mailing list, and approved by the steering group (IESG).
Some bigger ideas benefit from face-to-face discussion with the larger community. This is helpful particularly on complex topics, where we need some time to even get to understand the topic well. This also allows discussion of various common trade-off situations, as improvements often come with cost, for instance.
These ideas need to be discussed in a so called Birds-of-Feather (BoF) session; talk to your Area Director about your idea, and follow the RFC 5434 recommendations for setting up a successful BoF. The deadline for submitting BoF proposals for Chicago is February 10, which is one month away! But the process with new Internet-Drafts, mailing lists, and so on needs to start earlier.
I wanted to send a post summarising my thoughts of the discussions at IETF-97. We had 1042 people from 52 countries on site in Seoul, very active development on a number of fronts, and I thought a successful meeting! (Apologies for sending this post out late, other tasks, holidays, etc intervened.)
The meeting was supported by our host Huawei and co-hosts CNNIC and KISA (Korean Internet & Security Agency), and a long list of sponsors. Thank you for your support!
The topic of the meeting was of course Internet tech and its evolution. The two most active discussion topics were the increasingly serious Denial-of-Service attacks that we are seeing, and the development of a new transport protocol, QUIC, as an alternative to TCP and TLS, especially being more optimized for HTTP/2 usage.
The most recent Denial-of-Service attacks involved a number of compromised Internet of Things devices attacking DNS infrastructure. The IAB had organised a discussion of these attacks as an example of a more general concern: the addition of millions of new hosts has the capability to overwhelm the Internet infrastructure when those hosts misbehave. There are ways to mitigate the attacks, but not without impacts in other ways — such as finding it necessary to deploy your services on large providers.
At the very least, I think it would be beneficial for the IETF community to continue to call attention to folks that the minimum bar when introducing a large number of devices (or any device) to the Internet includes things like automatic software updates and avoiding default passwords. I used to think this was so obvious and it needn’t be said, but I’m not so sure anymore. Nevertheless, the area for us to have an impact is improving on defence and mitigation mechanisms.
You can watch the video from the IAB plenary discussion here:
The IETF recently chartered a working group to specify QUIC (Quick UDP Internet Connections). This new protocol combines the TCP and TLS layers, is typically implemented in user space rather than kernel space, and aims for faster connection setups using resumption, integrated security, and capabilities to evolve the protocol faster (not being in the kernel).
A previous version of the protocol is also already in relatively wide use at Google, and was taken as a starting point for discussion in the working group.
I’m quite excited about this development, and eager to see where it takes us, and it seems that I’m not alone:
Once again the IETF Hackathon was running the weekend before the IETF. I thought it was outstanding to see large student groups among the participants. A student team from SungKyunKwan University worked on the Interface to Network Security Functions (I2NSF) framework, for instance. With jackets made for the event!
There was also a second large student team – on the other side of the world! The team from Université Catholique de Louvain worked on Multipath TCP, but much of their team did their work from back home in Belgium. They won the best of show award:
All videos from the sessions, interviews, etc from the meeting are available as a YouTube playlist. The official proceedings with slides, minutes and everything else are on the IETF website. See also the blog post on routing area outcomes from IETF 97, and the blog post from Srimal Andrahennadi from his experiences in participating as an ISOC fellow at the IETF.
Besides the ISOC fellows group, there are a number of other gatherings happening during the IETF week. ISOC also runs a “Policy Fellows” program, with participants from regulators, governments, and other policy makers that do not usually attend technical conferences. Contact Konstantinos Komaitis at ISOC if you want to participate in this program! The IEPG meeting on Sundays is a discussion among network operators. And the Systers Lunch gathers the women participants. Contact Allison Mankin if you want to join!
So, what’s next? The work has already been going on in the mailing lists and virtual meetings after IETF-97, and will intensify as people come back from holidays. IETF’s official work happens on the mailing list. Our next meeting is at the end of March in Chicago, hosted by Ericsson: