The Yokohama IETF Hackathon is now in progress! There is a bit less people than in the previous one, but still a good turnout, and a good number of exciting projects:
- IPv4 configuration through DHCPv6 (per RFC 7341)
- Improving privacy through DPRIVE. Currently, DNS queries leak a lot of metadata information to access networks, even if actual communications are secure.
- Home networking on IPv6, and the ability to support multiple home routers, multiple interfaces, and so on. Building new solutions on top of the HOMENET working group’s work.
- Intent-based network modelling, generating network configuration from high level descriptions of what applications need, without the applications having to configure specific nodes or paths.
- Building tools to test the myriad of configurations that ICE allows.
- Data-based network control with I2RS, NETCONF, and YANG. Also building tools to help analyse and verify YANG models across IETF and other standards organisations and open source projects.
- Improving Daala video codec.
- Building information-centric networking on top of link layers directly, running on very small devices and the RIOT operating system.
- Building support for Service Function Chaining (SFC), allowing complex or simple services to be built from network components in a flexible manner.
I’m very excited to see the results of these projects tomorrow Sunday! I also wanted to thank Charles Eckel for running the show and Cisco DevNet for sponsoring the event!
Jari Arkko, IETF Chair
(Photo credits Terry Manderson and Jari Arkko)
The Yokohama Code Sprint is in progress! There are a few new code sprinters, and part our efforts has been in setting up development environments for them, as well as building a Docker image so that future setup will be easier. We will also be working on improving agenda tools, building RSS feeds for RFC archival purposes, fixing statistics tools, and many other tasks. Thanks for all the hard work!
For the first time, the sprinters have also gotten t-shirts and “I’m a Sprinter” buttons from the secretariat. And Tero Kivinen, a long-time Code Sprint contributor has milled some “Yokohama Code Sprint” aluminium coins for the participants! The coins acts as the “dot” for the sprinter’s badges 🙂
Jari Arkko, IETF Chair
Photo credits: Tero Kivinen and Jari Arkko
Welcome to IETF-94, and back to Yokohama! We were here in 2002, yet I remember it like yesterday. The impression left by the scenery, the Japanese friendliness, food, and many other things was lasting!
First off, I wanted to note that the network is up, secretariat is ready to hand out badges, meeting rooms are ready, and we are eager to start the week! I also wanted to thank very much our host, WIDE project, and all the other sponsors who are making this event possible: IIJ, NTT Communications, Broadband Tower, Inc., Fujitsu, Hitachi, Huawei, JPRS, KDDI, NEC, SoftBank, APNIC, Equinix, Otsuka, CTC, Dell, Extreme Networks, INTEC, JPNIC, net one, NISSHO Electronics, Nixi, Sakura Internet, Toshiba, A10 Networks, Alaxala, Cisco, NTT EAST, and Cisco DevNet. What a wonderful and long list of supporters!
Our week begins with Saturday and Sunday being full of coding, hacking, welcome receptions, and newcomers’ events. If you are already here, consider joining the IETF Hackathon to program cool new Internet tech. Code is what matters, after all. Or come help program IETF tools in the Code Sprint.
The one BOF that we have this time is the Internet Storage Sync (ISS) BoF on Tuesday. It proposes work on network-based storage services, such as Dropbox to allow users to sync local files with remote servers. Today, the sync protocols are proprietary, often inefficient or lacking in features. The BoF will consider whether we should standardize a new protocol to help these issues and provide interoperability among services. Read more information on the topic from github and from draft-cui-iss-problem. And join the discussion on the mailing list.
But this year we’ve already created 19 new working groups (and terminated 13), so do check out some of the other new efforts going on as well. These include, for instance, DETNET (Monday), DOTS (Tuesday), COSE (Tuesday), GEOJSON (Thursday), and LAGER (Thursday).
On Wednesday we will have the plenary session. This time both the technical and administrative plenaries will be held in one session. The focus in the session will be less on reporting and more on bringing up hot topics to discuss. All reports will be available in the meeting materials, and the meeting time is used more on issues that deserve your attention and discussion. We still have a technical topic as well, discussed in depth, followed by open discussion. The topic this time is “Measurement-Driven Protocol Engineering”.
On the break before the plenary, you may wish to join the screening of the film ‘Net of Rights’.
The operations area of the IETF is busy with more than 160 YANG data models in the different WGs. But the focus this week is not only on the management of specific protocols, but also (and maybe more importantly) on the coordination and interaction of all those models within the IETF and with other SDOs.
The transport area working group (TSVWG, Monday and Thursday) will be working on drafts that cover several aspects of tunneling, both specific encapsulations like GRE-over-IPv6 and general guidelines for encapsulation, ECN handling in tunneling, and “circuit breakers”. We’ll also get an update on the SPUD prototype, which generated considerable interest at the MaRNEW workshop in Atlanta.
Finally, some additional thanks and practical arrangements. I wanted to thank the NOC team and the volunteers from WIDE. When I visited the NOC I counted twenty people in the room, all helping to set up the network. Much appreciated!
If you are unable to attend IETF 94 in person, you can participate remotely. Working Group sessions can be joined via Meetecho, or by listening to audio streams and participating in Jabber chat rooms. Additionally several sessions—the IRTF Open session, the plenary, and the Thursday Lunch Speaker Series session will be streamed live via that IETF’s YouTube channel (over both IPv4 and IPv6). These will also be available for on-demand viewing shortly after each session. For all the details, see the IETF Live webpage.
Check out also the rough guides to IETF-94 from ISOC, with lots of material covering the main events, as well as focusing on scalability, routing, and Internet Governance matters in particular.
Looking forward to seeing you all in the meeting or in the discussions over the Internet!
Jari Arkko, IETF Chair
Both the IETF and the W3C are meeting in Japan this month. The W3C TPAC meeting is going on this week in Sapporo, and the IETF meeting is beginning next week in Yokohama. Given the proximity of the gatherings and the technical topics, many people are attending both. This was the first visit to the W3C for some of us, and we wanted to share our experiences and point out important work that crosses organisations.
The IETF and W3C have of course historically worked closely together, and even though our work methods differ, we share a very similar worldview in collaborating to build better web technology. Many current developments are likely to require more systems-level understanding and collaboration, for instance, improvements in security and privacy, or supporting interoperable Internet of Things applications.
To increase cross-pollination, both organisations had made an offer for reduced registration fees for new participants from the other meeting. On the W3C side 9 new people and on the IETF side 15 new people took advantage of that offer.
To a new attendee who is used to how the IETF works, the W3C model appears to be that work is done throughout the year with teleconferences (it is common for W3C groups to have weekly teleconferences) and by having working groups scheduling their own face-to-face meetings. A lot of the work also happens offline, for instance in open source repositories and informal groups. At the W3C plenary meeting (TPAC, once a year) there is often a lot of status reporting and general discussion. But at the TPAC, working groups will meet for one or two entire days rather than just for one or two hours. Having all-day working group sessions means that more work can get done, but it makes it very hard to participate in multiple working groups: one has to use the agendas to decide when to switch back and forth, and one misses a lot of the discussion.
While most of the IETF week is spent in working group meetings, at the TPAC there is a full day reserved for the plenary. This time the plenary started with Tim Berners-Lee, Vint Cerf, and Jun Murai having a panel discussion about the future of the web and the Internet. One of the issues they discussed was how to build support for a more trustworthy web. What is missing from the enabling protocol space to make strong authentication, high integrity, and other trust building mechanisms better available? Vint suggested that this is a topic that the W3C and IETF should discuss together.
The other notable thing about the W3C meeting week is that there is quite a lot of time reserved for unstructured discussions and parallel breakouts both for new topics and topics within a working groups. A big part of the plenary day is in the “unconference” format, in which topical sessions are proposed on a meeting wiki. Scheduling some unstructured discussion time may be something worth thinking about in the IETF as well.
W3C uses “Interest Groups” to start work that isn’t ready to be in a Working Group. Some of the ones to follow include the Privacy, Web and TV, Digital Publishing Interest Groups. The Web Payments Working Group has recently been chartered based on work started in the Web Payments Interest Group.
Interaction with the IETF
The most notable case of joint work between the W3C and the IETF is WebRTC, which is joint work with the IETF RTCWeb working group. But there are other W3C working groups that are chartered to work with the IETF, for instance the Web Applications, Web Performance, Web Platform, Geolocation, Internationalization (I18N), Web Application Security, and Web Cryptography groups. Some work in the IETF (such as WEBPUSH) has been triggered by needs of W3C work. There’s also a healthy overlap in participation and functional liaison relationship between the two organisations.
Web of Things
Internet of Things was a hot topic also at the W3C meeting. The Web of Things (WoT) Interest Group has two full days of sessions on Thursday and Friday, and also multiple joint sessions with other groups earlier during the week. The starting point for the group’s work is the desire to improve interoperability at the higher layers and applications, and not just in the underlying protocols. What can be done to make the web a platform that better supports building cross-domain applications, and connecting components from multiple sources?
The top three building blocks for combining the Web and IoT worlds being worked by the group are “scripting API and protocol mappings”, “thing discovery”, and “thing description”. Each of these topics has its own task force, and a fourth task force is looking into “security, privacy, and resilience” aspects that are naturally highly important for WoT. As is often the case with W3C work, APIs can be created for browsers to support new types of web applications. Finding the right model to allow such APIs to discover and communicate with objects is of course crucial.
The WoT group is finalising now the technology landscape scanning for relevant and suitable technologies and many familiar IETF protocols and formats have been extensively discussed in the group (e.g., HTTP, CoAP, WebSockets, CoRE link format, and SenML). The mechanisms specified at the IETF have so far been good building blocks, but when the W3C group moves forward, we are likely to find missing pieces that require more standardization work. At that moment it is important to coordinate between the IETF and W3C so that the right work gets done. Fortunately there is again a healthy overlap with participants, so we expect the information to flow well between the two organisations. In particular, the IRTF Thing-to-Thing proposed Research Group (T2TRG) will have a joint meeting with the W3C WoT group on the weekend before the IETF meeting.
Barry Leiba, Ari Keränen, Heather Flanagan, Karen O’Donoghue and Jari Arkko
A recent paper on shortcomings of Diffie-Hellman key exchange has received attention and raised questions about security on the Internet, as Diffie-Hellman is used for cryptographic handshakes in popular Internet protocols.
While the specific issues from the paper are new, the underlying issues have been known for a while by those working on security-related protocols in the IETF. In fact, work across the IETF in this area is underway, motivated in part by an IETF-wide discussion begun nearly two years ago which identified pervasive surveillance as an attack on the Internet that should be mitigated in the design of Internet protocols (RFC 7258).
For example, the IETF Using TLS in Applications (UTA) Working Group summarized security attacks in RFC 7457, including those related to the ones raised in the paper. The goal of RFC 7457 is to motivate improvements to some of the protocols used to secure Internet transmissions, such as Web pages that have URLs that start with “HTTPS://”. Following RFC 7457, the UTA Working Group has produced RFC 7525, which provides recommendations on improving the security of deployed services that use TLS by using specific, stronger cipher suites.
Similar work is happening with IKE/IPsec, which is a protocol suite for secure Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. The IETF IPsecME Working Group regularly updates its cryptographic algorithm advice for implementors. The original IKE specification in RFC 2409 and updated in RFC 3526 together specify the two most commonly used Diffie-Hellman key sizes of 1024 (DH 1024) and 1536 bits. This was updated in IKE version 2 in RFC 4307 in 2005 where it recommended Diffie-Hellman key sizes of 2048 bits and demoted DH 1024. However, the industry has been slow adopting these updated recommendations and as a result of the recent revelations, work has started on updating RFC 4307 which will completely remove support for DH 1024.
There are also some subtleties relating to IPsec that make it different from TLS. For example, unlike TLS servers, IPsec can initially appear to accept weaker cryptographic options only to reject those later in the session establishment phase. As such, it is actually nearly impossible for an Internet probe to determine the strength of the cryptographic parameters required by an IPsec server. For more information, see this article by Paul Wouters.
So, as we approach the second anniversary of the discussion that led to RFC 7258, the IETF community has done considerable work to strengthen trust in the Internet, in line with its mission of “making Internet work better”. But, a lot of work also remains – in deploying the better versions, in building defences to new attacks, and in understanding the issues and possible improvements. This is a continuous process.
Paul Wouters and Jari Arkko
(Picture credits: The Great Paris Cipher from UK National Archives)
We’re both at ICANN 54 in Dublin, and of course a big topic is the IANA transition. At this meeting most of the focus is on ICANN accountability changes. Those are important for us because the IANA stewardship transition plan for the names community depends on those accountability changes. People want to make sure that ICANN (the organization) complies with the community’s will. Since we think that’s what it means to be a bottom-up organization, it seems like a natural reform to us and one the ICANN community deserves.
There are disagreements about the specific ways to do this, and people also recognize the risk of accidentally creating new issues when making a change. The amount of progress we’ve seen during the meeting is impressive, however. The feelings here are at once familiar and strange — the exact ways people hammer out consensus in ICANN are not the way we do things in the IETF, but seeing hard positions start to converge is for sure something we understand. One thing we’re noticing is people embracing practical power that rests with the community rather than mere legal enforcement by courts. We think that’s positive for three reasons. First, it hands the power directly to the people who need it instead of giving them indirect means to achieve it. Second, it seems to represent lower risk to IANA: lengthy legal proceedings would be bad operationally. Finally, this mode of operation has always worked for the IETF.
We care about the overall stability of Internet systems and organizations, but a current big interest in this is due to the IANA transition. If the different operational communities can’t together make this transition happen, we’ll have to face bad options. We will lose some of the confidence people have in the Internet community. The transition was part of the promise at the foundation of ICANN, and the promise has come due.
We really appreciate the hard work people are doing on these accountability changes. We are very happy with the progress that has already been made this week. The key to completing this process is to focus on the practical ways to put the appropriate and sufficient power in the community hands.
Jari Arkko, IETF Chair and Andrew Sullivan, IAB Chair (representing our personal opinions in this post)
The ICANN 54 meeting is now starting in Dublin, Ireland. On the agenda are various topics around the IANA stewardship transition. The transition is about moving the oversight role of the US government to the relevant communities that use the IANA system. The plan for the transition involves three main components, one related to protocol parameters and the IETF, one related to addresses and the RIRs, and one related to the names and ICANN.
The main topic of the week will be the accountability improvements needed by the names part. As part of the transition changes, the names community has wanted to ensure that they have sufficient control of their organisation. The basics are very similar to what we do at the IETF, where appeals and recalls can keep the leadership in check, but the detailed legal arrangements have lead to a heated debate at ICANN’s accountability working group (CCWG). If you want to read more about, these links are a good start: 1, 2, 3, 4, 5, 6.
The transition coordination group (ICG) will be also meeting to finalise the transition plan based on the comments the proposal received in the public comment period. At this point, the names part of the transition is waiting for the accountability changes, whereas the numbers and protocol parameters portions of the proposal are complete and have no dependencies on the work of the accountability working group or any other remaining process. Indeed, implementation of those proposals can continue without waiting for the accountability working group to complete its work.
But of course, we want the whole system to move forward. Early indications are that progress is being made in the names part.
Once the meeting is over, we will provide a summary of the week’s discussions here.
Jari Arkko, IETF Chair
At IETF-94 we will have yet another code sprint to work on IETF tools. Robert Spark writes:
“At the codesprints, we get together to work on code for the IETF data tracker, web site and other tools. Some people may be working on improvements in existing functionality, others may be adding exciting new functionality. All code will become part of the open source IETF tools.”
Please join us to help with the effort, or come program your personal favourite new feature! The sign up page for the codesprint is in the wiki.
Jari Arkko, IETF Chair
In early 2002, the RFC Editor revised their website look and feel to one that would stay essentially unchanged for the next 13 years. While the site has been very light-weight in terms of size and features, technology and user expectations have moved on and it was time for the site to change.
I began my role as RFC Series Editor in 2012. I did quite a bit of research on the RFC Editor website prior to interviewing for and accepting the position, and was surprised at the outdated look of the site. Still, there were many other priorities to take up at the time: the community was vocal about the need to change the format of RFCs, the Style Guide needed to be brought up to date, the structure of the various functions within the RFC Editor had to be cleared up, and various other projects all demanded more immediate attention. Today, we are at a point where we expect more traffic coming to our website. When the new format project is completed, more traffic will land in the RFC Editor web space as people access the new HTML and PDF formats, and to quickly get a copy of the XML of an RFC to work on their next -bis draft. We wanted the site to be stable, easy to navigate, and more attractive to the community in time for that expected traffic.
The goal of the new website isn’t just an improved user experience, though that was the primary driver. A secondary, but important, goal was to improve the manageability of the site. All previous updates to the text content–and there have been several functionality additions over the years–were often done by manually creating an HTML file and copying it into place. Scripts have been added that automatically generate content as well, but overall, the old site was, to put it bluntly, clunky. The new site, based on a WordPress platform, is going to be significantly easier to update and maintain. I am looking forward to the easier management experience.
The inspiration for the new layout started with the IRTF website. They have a very clean and well organized site. Of course, they were also daring enough to expand into using color, which is still something we are very cautious about doing. Color perception is a tricky thing, and the RFC Editor is designed to be a conservative entity. We may well add color in the future, but the changes made so far are big enough that we decided to hold off on that for now.
The vendor that took on the work was AMS, home of the IETF Secretariat and the RFC Production Center and Publisher. Most of the work required was in integrating the old scripts into the WordPress framework, and in making sure that the file system structure and associated archives were complete. It was several months worth of effort, and I am very grateful to the team for all their hard work!
If you haven’t seen the new site, please take a look! Feedback is welcome – please post it to email@example.com (I will approve your post if you are not already a subscriber). If you have a bug report, please send it to firstname.lastname@example.org.
Heather Flanagan, RFC Series Editor