We had a great meeting in Berlin, the IETF crowd clearly likes to meet there! As our meeting ended, we had 1424 people participating on site and 337 people remotely. Out of the registered remote participants, 79 were from USA, 73 from India, 52 from Brazil, and 13 from Japan.
But while the numbers are interesting, what matters more is whether our gatherings have an impact on the real-life Internet out there. I certainly felt that the topics handled during the week were very significant for the Internet’s evolution. But more on that in a bit.
Not Just about the IETF
I also wanted to observe that the IETF meetings are not just about the IETF. We typically get many other meetings happening around the IETF time as well. This time we had for instance 6LO interop event with ETSI, an applied networking research workshop, an informal gathering of the operators in the IEPG meeting, interaction between the RIOT summit and our working groups, and many others.
And of course the IETF meeting itself is not just talk and specifications. We also love running code, for it is what actually makes the Internet tick
One of the ways that we can focus on running code is through the IETF Hackathon, which started with the main gathering on Saturday and Sunday, but for the first time ran through the week in the lounge and at the Bits-n-Bites event. The Hackathon had more participants than ever, 158. But again the numbers are not as interesting as what the people were doing. You could feel the buzz of excitement and ongoing hacking just by entering the room.
The winning project hacked FD.io to make it do identifier-locator based forwarding on IPv6. Another project interop tested 7 implementations of TLS1.3. This has a direct impact on how well our browsers work.
But back to our technical program during the main meeting week. With 128 different meetings, I cannot report on everything, but here are some highlights:
The QUIC (Quick UDP Internet Connections) BOF was held to consider a proposal that has originally come from Google, and is already seeing widespread usage there. The basic idea is that an efficient and secure transport can be built by applications, encompassing both TCP and TLS functionality. The new transport would run on top of UDP, and promises the ability for protecting more of the session than TCP and TLS-based designs can, absorbing multipath- and mobility functionality, and be very efficient transport for web traffic.A standard in this space would likely see significant deployment in the Internet. For me the most interesting aspect of this design is that as an application level implementation, further evolution of the design is easy and can happen in a distributed manner.The BOF was the most well-attended IETF session during the week, or possibly ever. I’m very excited to see what comes out of it!
The transport community was also otherwise very active. For instance, the L4S BOF considered proposals for improved TCP performance on latency and scalability. The area is also still working to meet the needs for managing radio networks in an encrypted world that operators told us about in the IAB MARNEW workshop last fall, and any new encrypted transport protocol will have to find some way to address those needs.
The LEDGER meeting discussed standards for interoperability between payment systems, for instance the ability to make payments across multiple payment networks or Bitcoin-like systems. This would be a new area for the IETF, and I don’t know if we’ll be working on this yet. But some of the technical challenges here related to security, naming, and routing certainly appear familiar.One of the underlying primitives that LEDGER would need is something called Crypto Conditions, an ability to specify when a condition is fulfilled, for instance when a sufficient number of parties from a group have signed something. This is another topic that I’m interested to follow.
The HOMENET working group had observed a mistake that had been made with respect to a recently published RFC, RFC 7788. This RFC accidentally refers to the “.home” special use name, but doesn’t specify its semantics in other DNS systems and didn’t go through the process normally required for special use name allocations.While this problem has been recognised and there’s an approved erratum for the RFC, I believe it is important that a more permanent fix be developed by approving a new RFC without the reference in the near future. The assignment of possible special use names for HOMENET use can take place in parallel.
The NETMOD working group and the IETF Routing Area have been steadily working on producing YANG models. There have been several NETMOD refinements to aid in this, such as improved ways to combine data models. We are now focusing on how to get the YANG models – such as topology, BGP, IS-IS, OSPF, and MPLS – to be completed in the next year. Implementation experience on these is very welcome!
The LPWAN meeting discussed how to run IPv6 and higher layer Internet protocols such as CoAP on highly constrained low power wide area networks (LPWANs). The energy and packet size constraints on these networks require highly innovative solutions to just be able to run IP in these networks. Participants representing four of the major LPWAN technologies were present in the meeting and showed high levels of interest in both participating in as well as utilizing the output from this effort.
The recently-chartered SIPBRANDY working group met for the first time this week. The group is describing best practices for cryptographic protection of SIP-signaled real-time media. It hopes to solve keying issues that have so far prevented wide deployment of the Secure Realtime Protocol (SRTP).
Open source is a big part of our efforts. Some of the events beyond the IETF Hackathon included the first meeting of the BABEL working group, focused on a new routing protocol from the open source world, and a gathering of the open source developers from the routing area.
IETF Financing and Sponsors
I would very much like to thank Juniper Networks for hosting this successful meeting in Berlin. Juniper is one of our IETF Global Hosts, companies who are committed to supporting several meetings across 10 years.
I was also happy to hear that the IETF Endowment received over 3 million dollars from our friends at AfriNIC, ARIN, RIPE NCC, and ISOC. This is a major show of support for the IETF mission, and much, much appreciated. Thank you all.
I should also note that it is important that we evolve the IETF funding model. We’re very meeting focused in our funding that with regards to meeting fees from the participants and sponsor support. Re-balancing that to both meetings and other IETF’s work is important. The IETF Endowment is one step in this direction. For your information, ISOC will be holding an information and discussion session on the endowment on September 9, 2016 at 1400 UTC.
Finally, what’s next? Back to work, of course, on the mailing lists, virtual meetings, and design teams. Our next physical meeting is in Seoul, South Korea.
A brief version of this article exists also as a video:
Jari Arkko, IETF Chair
The author would like to acknowledge the help of Alia Atlas, Spencer Dawkins, Deborah Brungard, Stephen Farrell, Joe Hildebrand, Ari Keränen, Alissa Cooper, Suresh Krishnan, Ben Campbell and others in understanding what happened at IETF96 and writing this article
“There’s a huge problem with the Internet of Things and we need to do something about it.” That was the invitation that brought participants to the Internet of Things Software Update Workshop (IoTSU) held at Trinity College, Dublin on June 13 and 14.
The “huge problem” with many IoT devices is that they are un-patchable, and if they cannot be patched, they cannot be made secure. The IoT is on a growth path that is quickly leading to the ubiquitous deployment of unattended devices throughout our homes, offices, factories, and public spaces. All of them, by definition, are connected to the Internet and hackers will eventually discover and exploit the vulnerabilities in these devices. When that happens, there must be a way to detect the intrusion and deploy software updates to fix the security flaws. This is a hard problem to solve and it has the attention of the IoT industry as well as that of the Internet Architecture Board (IAB) and the Science Foundation Ireland-funded CONNECT Centre who sponsored this workshop.
The workshop materials and raw minutes are here. An IAB report will be published in the near future.
The participants at the IoTSU workshop submitted nearly 30 papers on topics covering analysis of past incidents, current practices, and proposals for future standards. The organizers classified the papers and the participants discussed them during four sessions across two days. The following summarizes just a few topics from the workshop that I felt were particularly significant.
Problem Scope and Technical Constraints: IoT devices are deployed on a range of hardware platforms, many of which are more highly constrained than others. At one end of the spectrum are the “System-On-Chip” devices with full memory management units (MMUs) running embedded Linux and full time access to mains power and a permanent Wi-Fi connection. At the other end of the spectrum are tiny “motes” connected via Low-Power and Lossy networks and required to run for years on battery power or harvest their own energy. The biggest software update challenges are with these highly constrained devices considering that all updates must be done securely and with zero risk of bricking the device. It seemed that most of the participants felt the greatest need was to first address the challenges at the lower end of this spectrum.
Photo: Hannes Tschofenig
IoT as a Service: When I buy a product, I have a certain set of expectations regarding ownership, control, and life expectancy for that product. An IoT device, however, is not a standalone product; it is highly dependent on the services it receives over the Internet and all of the technical, organizational, and policy infrastructure that underpin those services. Many of the IoT devices on the market are being sold today as products, and consumers are not always aware of the services those devices depend upon for their long term continued operation. Developers and vendors need to keep this perspective in mind when designing and marketing the IoT.
Full Lifecycle Requirements:
To properly address the challenges of the IoT software update problem, it is essential to consider the full lifecycle of the IoT device. This begins during manufacturing when the security credentials must be generated, allocated, and provisioned into the devices in a secure manner. It also incorporates the lifecycle of the device vendor who might be bought out or go bankrupt – we need to consider how to continue patching essential devices when the original manufacturer no longer exists. Finally, it ends with addressing various end-of-life scenarios such as how to decommission and recycle those devices that no longer can or should be supported.
The workshop concluded with a discussion about next steps. For starters, the organizers will publish an official workshop report. The participants also supported the concept of publishing a document to capture the current best practices in the IoT industry relative to software update. Some also brought up the need to clarify the scope of the workshop activities in terms of whether the focus should be on constrained devices or to also include other platforms or even networks of connected devices such as those found in vehicles. There may also be the opportunity for future standards work such as recommendations for certain minimum hardware requirements to address the need for random number generation, real time clock, and memory to support multiple binary images during an upgrade.
The participants at the IoTSU workshop came together because of their common concern about issues that could potentially threaten the long term success of the IoT. It was a good mix of representatives from both industry and academia who willingly and openly shared their experience and expertise. I believe the workshop was a good first step towards working together to address the common challenges that we are facing as the IoT continues to grow.
When the idea of participating in this hackathon came about, the goal was mostly to leverage FD.io’s Vector Packet Processor (VPP) as a platform and show its performance, capabilities, modularity and development simplicity. So we looked across existing IETF technologies and drafts which were not yet implemented in VPP and found out this new ILA technology (draft-herbert-nvo3-ila), which seemed to be a perfectly valid use-case for VPP used as a physical or virtual router.
What’s really fantastic is that the ILA draft author, Tom Herbert, as well as other very motivated people spontaneously volunteered to join the team. We ended up with a team consisting of folks in-between IETF standardization and Linux Foundation open-source software, and developed together from scratch, a full ILA implementation. In two days we went across many phases of standard implementation development, from understanding the draft, coding the first shot, testing it, to finally understanding the technology better and doing more with less code. Then testing again, and interoperating with an existing Linux implementation.
At the end of the second day of the hackathon, the newly created implementation, comprising most of the features specified in the ILA draft, was upstreamed to the main VPP repository. And performance tests of the yet-to-be-optimized code were showing promising results too.
Summarizing, this two-days project really showed how the IETF hackathon can facilitate joint collaboration between open-source and standardization people at very early stages of drafts and implementation development, taking advantage of their complementing experience and knowledge and resulting in better standards and optimized running code.
Pierre Pfister and Maciek Konstantynowicz
The ILA team was: Pierre Pfister, Tom Herbert, Maciek Konstantynowicz, Damjan Marion, Shwetha Bhandari, Bill Cerveny, Ignas Bagdonas, Ole Troan, Wolfgang Beck
I arrived in Berlin today, but there are many volunteers and support vendors who arrived days earlier to prepare for the meeting. It takes a lot of effort to setup the network, for instance. The team reports that the network is up and running, and that they have taken over the hotel network as well.
Some minor routing issues with some destinations were seen earlier on v6, but the team is fixing that. Everything should be running smoothly, but if not, please drop us a note.
We all are grateful for having this team work for us! Thank you!
Interestingly, at this IETF we’re for the first time implementing the BCP-38 (ingress filtering) policy on our routers; Jim Martin and Warren Kumari wrote a script to automate that setup. I talked to Jim a bit about the arrangements, and thought it was a good demonstration of how some good things in the Internet are fundamentally hard, and require some effort. There is no “apply BCP-38” button on most routers But maybe there should be?
The team has also deployed a monitoring mechanism to follow what’s going on in the network. You can see it on the left in the picture below, whereas on the right you see some nice art
I was also positively surprised by the amount of activity already going on in the hotel in other efforts, such as the MAMI network measurement project meeting, ETSI interop, the Cryptec meeting, and probably many things that I didn’t know about. One of the purposes of the IETF meeting is to be a place for all kinds of hallway conversations, testing, and other discussions to take place, alongside with the actual working group meetings.
For the weekend, I’d like to highlight the following activities:
IETF Hackathon: Come build your favourite new tech! The Hackathon runs mainly during Saturday and Sunday, but we’ve also reserved some space in the IETF lounge throughout the week of IETF to help and encourage people to continue to collaborate with their colleagues on various hackathon projects and activities. This is not meant to compete with sessions but rather to provide an opportunity for those without packed agendas to make better use of their otherwise free time. We will see how things go in Berlin, and we welcome your thoughts and suggestions on improving the Hackathon at any time. More information about the Hackathon can be found on the web, and more about the week-long Hackathon experiment here.
IETF Code Sprint is running on Saturday, please join and program the IETF tools that you need. See the Code Sprint web page for sign-up and other information.
Applied Networking Research Workshop (ANRW) runs on Saturday, and focuses on interesting research results. Join the workshop, details
at the workshop page.
Tutorials run on Sunday, and include both newcomer’s orientation to the IETF and discussion of new work in IEEE 802. The orientation is available both in English and German. See the agenda for the sessions.
For next week, the meeting rooms are ready. This is the plenary room:
During nearly every IETF meeting since 1993, an informal gathering of women participants, the Systers, has taken place. We chose the name Systers as an answer to the late Anita Borg’s call for women in computer systems to support and celebrate each other.
In 2013 and 2014, gifts by Comcast, EMC, and Verisign Labs established a lunch fund for the gathering. For most of the participants, the Systers gathering is a chance to catch up with friends across all areas of the IETF, to employ an informal mentoring and information gathering forum, and to encourage each other in a largely male-dominated field.
The Systers IETF list, email@example.com, offers this kind of support before and after the face-to-face meetings. The list is for Systers involved in IETF topics–both technical and specific to women.
Traffic is typically light with some discussions, but mostly for organizing per meeting gatherings. The list is open to any woman interested in the IETF, whether she participates only by mail or also in person.
Women participants, please consider joining us for the Systers lunch at IETF 96. We always hold our lunches on Thursdays. We haven’t set a location yet, so join the firstname.lastname@example.org mailing list so you can RSVP and get location information. To join the list, or if you are interested in learning more about the Systers or contributing to our fund, please contact email@example.com.