The team from hackers.mu that participated remotely in the IETF Hackathon on 11-12 November 2017.
Hackers.mu is a developer group based in Mauritius made up of a wide range of people from different backgrounds: high school students, university students, professional engineers, and advisors to the minister of ICT. We participated remotely in the IETF Hackathons held in conjunction with IETF 98 and IETF 99 in the Automatic Multicast Tunneling (AMT) and Human Rights Protocol Considerations (HRPC) projects, respectively. After hearing about the recent changes happening in the TLS Working Group, we decided to work on TLS implementations for IETF Hackathon held just before IETF 100. We packed our laptops and headed to Pereybere, which is found in the north of the Island.
Hackers.mu remotely participating in the IETF Hackathon
We stayed at a very comfortable location with proper A/C. We deployed our network, and connectivity was provided via a 3G mobile dongle. A big thank you to the TLS champions who were very helpful and considerable on Instant Messaging. After we showed them our initial code, they directed us to a bunch of servers that we could use to test. Also, it was very helpful to work alongside the people actually implementing the next iteration of the TLS draft. We were able to see how they were changing the implementation to work around problematic middleboxes. We learned a lot.
We had 8 people from Mauritius and 1 Mauritian from Denmark: Codarren Velvindron, Nitin Mutkawoa, Pirabarlen Cheenaramen (working from .dk), Nigel Yong, Sheik Meeran
Ashmith Kifah, Muzaffar Auhammud, Yasir Auleear and Yashvi Paupiah. We worked on the following Open Source software: wget, curl, monit, ftimes, aria2c, stunnel nagios plugins and hitch. Our project presentation slides are available here. A few of our members woke up every morning and went for a 30 minute swim in the morning before going back to the Hackathon room. The beach was less than 5 minutes from our Hackathon venue.
Overall, it was a fun IETF 100 Hackathon, and we really enjoyed how intensive it was. Along the way, we learned a lot about TLS internals, and the subtle details of the different implementations. Also, we would like to thank the hardworking people behind the remote participation infrastructure. They have done an amazing job! We were able to watch live from Mauritius the IETF Hackathon awards session. The TLS team won a prize for best remote participation!
We are looking forward to participating in the next IETF Hackathon scheduled for 17-18 March 2018, just before the IETF 101 meeting in London.
HTTPS (HTTP over TLS) is possibly the mostwidely used security protocol in existence. HTTPS is a two-party protocol; it involves a single client and a single server. This aspect of the protocol limits the ways in which it can be used.
The recently published RFC 8188 provides protocol designers a new option for building multi-party protocols with HTTPS by defining a standardized format for encrypting HTTP message bodies. While this tool is less capable than other encryption formats, like CMS (RFC 5652) or JOSE (RFC 7516), it is designed for simplicity and ease-of-integration with existing HTTP semantics.
The WebPush protocol (RFC 8030) provides an example of the how the encrypted HTTP content coding could be used.
In WebPush, there are three parties: a user agent (in most cases this is a Web browser), an application server, and a push service. The push service is an HTTP server that has a special relationship with the user agent. The push service can wake a user agent from sleep and contact it even though it might be behind a firewall or NAT.
The application server uses the push service to send a push message to a user agent. The push service receives a message from the application server, and then forwards the contents of the push message to the user agent at the next opportunity. It is important here to recognize that the push service only forwards messages. It has no need to see or modify push messages. Both the user agent and the application server only communicate via the push service, but they both want some assurance that the push service cannot read or modify push messages. Nor do they want the push service to be able to create false push messages.
For example, an alerting service might use WebPush to deliver alerts to mobile devices without increased battery drain. Push message encryption ensures that these messages are trustworthy and allows the messages to contain confidential information.
The document draft-ietf-webpush-encryption, which was recently approved for publication as an RFC, describes how push messages can be encrypted using RFC 8188. The encrypted content coding ensures that the push service has access to the information it needs, such as URLs and HTTP header fields, but that the content of push messages is protected.
There has been a lot of progress on the project to revamp of the www.ietf.org website. The updated website will be the “front door” for the IETF, not only for for active IETF participants, but also provides an onramp for potential participants, and helps explain the work of the IETF to people who are not directly involved in developing Internet standards. The complete Scope of Work for the project is available here.
Based on recent feedback, including the demo table at IETF 98, the initial design and features of the website have been improved in many ways. For example, in response to the feedback provided, there is now a single page that provides links to tools and resources commonly used by active IETF participants.
The project is now entering the next phase of the website development. The goal for this phase is to gather input more broadly. While there are still a few features to be implemented and some content still needs to be fine tuned, the general organization and the look-and-feel of the website has been implemented based on the initial research and input received to date. Of course, there will be some additional significant work before the site is ready for production; for example, before the website is final, we will implement methods to ensure that well-known URLs continue to work as expected.
Working on technical standards in the computing, communications and networking industries often involves dealing with patents. Like most standards-development organizations (SDOs), the IETF has policies that deal with patents covering IETF protocols, specifications and standards. The IETF’s first patent policy appeared in RFC 1310 (Mar, 1992), but the basis for today’s policy approach originated with RFC 2026 (October 1996), which still defines many aspects of the Internet Standards Process. The first major overhaul of this policy occurred a decade later in RFC 3979 (also designated as BCP 79). Though the IETF’s policies relating to copyrights, open source code and other forms of intellectual property (IPR) evolved, particularly after the formation of the IETF Trust in December 2005, the IETF’s patent policy remained relatively stable for more than 20 years.
As stated in RFC 2026, the overall intention of these policies has been to benefit the Internet community and the public at large, while respecting the legitimate rights of others, and that remains the case today.
As originally codified in RFC 2026, the IETF patent policy states that anyone who makes a contribution to an IETF specification or standard must disclose any patents held by the contributor or his/her employer which cover or may cover the contribution and are “reasonably and personally known” to the contributor, as well as any such patents that cover contributions of others. If an IETF participant knows of third party patents covering some aspect of an IETF document, disclosure is voluntary. Unlike many SDOs, the IETF does not require that patent holders make any particular commitment to license their patents on fair, reasonable and non-discriminatory (FRAND) or any other terms (a discussion of the history behind this approach can be found here). However, the IETF provides a facility (the IPR Disclosure Form) whereby patent holders can voluntarily disclose their licensing terms, and many make use of this facility to declare, for example, that they will not assert patents against implementations of IETF standards except in defensive situations.
In 2010, following a period of extensive discussion of IPR policies in the industry and at other SDOs, and with the completion of a major overhaul of the IETF copyright policy in 2008 (RFC 5378/BCP78), we began to consider updating BCP 79 to reflect current practices at the IETF, as well as the evolving roles of the RFC Editor, IETF Secretariat, IETF Executive Director, IRTF, IAB and other groups operating within IETF.
This was not a quick process. We began work in 2010 and held a first BOF at IETF 81 in Quebec City (July 2011). We published a -00 version of a revised policy in December 2012 and held a second BOF at IETF 87 in Berlin (July 2013). We received comments and input from a wide range of community members, legal counsel and interested parties. The Internet-Draft went through 13 versions and was finally published as RFC 8179 in May 2017, seven years after we began to work on it.
The principal changes that RFC 8179 introduced to BCP 79 are described in Section 13 of the document. A quick summary of the highlights is below:
What’s a Contribution to the IETF? — Over the years, the modes in which IETF work takes place have changed. We updated BPC 79 to reflect the reality that technical contributions are made in BOFs, and online via chat rooms and other online fora. In addition, we have clarified the rules regarding oral contributions and when they trigger a requirement to disclose patents.
What is Participation in the IETF? – Many of the obligations imposed by BCP 79 apply to persons who “participate” in IETF standardization activities. So what does “participate” mean? Does it include walking into a meeting room where a discussion is taking place, sitting in the back saying nothing, or silently “lurking” on an email list? In BCP 79bis, we clarify that participation in the IETF means either making a contribution or “in any other way acting in order to influence the outcome of a discussion relating to the IETF Standards Process”. Thus, silently rolling your eyes or giving a thumb’s down during a technical presentation could subject you to the IETF’s disclosure requirements.
What to Disclose? – In addition to information regarding a patent and the portion(s) of an IETF document that it covers, the inventor(s) must now be disclosed.
Updating Disclosures – We have added a lot of needed detail around the process for updating IPR disclosures, including when such updates are required and how they should be made.
Licensing Declarations – When a person or company makes a voluntary statement about the terms on which it will license its patents covering IETF standards, that statement is viewed as binding and irrevocable so that others may rely on it.
General Disclosures – We updated the procedures relating to voluntary disclosures that are not required by the IETF rules. These disclosures of patents potentially covering IETF documents can be made by anyone and will be posted on the IETF IPR Disclosure page. We also clarified that required disclosures that are deficient in some way (e.g., they omit some required information) are also posted.
Failure to Disclose – We outline some of the remedial measures that can be taken when the IETF disclosure rules are violated, including IESG actions described in RFC 6701.
Evaluating Alternative Technologies – We provide some guidelines around the consideration of patent and licensing disclosures by IETF WGs. We also discuss some areas in which royalty-free licensing is preferred, such as security technology.
Alternate Streams – We have made it easier for other groups using the IETF RFC publication process, such as the RFC Editor, IAB and IRTF, to adopt the IETF patent policy.
As you can see, the changes are mostly clarifications; the basic patent policy remains as it was defined in 1996. Changes in patent law or patent practice may, at some point in the future, necessitate an update to RFC 8179, but that will be someone else’s task.
Emergency calls placed by vehicles involved in a crash can provide significant benefit, especially when vehicle occupants are injured or unable to place a 9-1-1 call themselves. Sometimes called “Advanced Automatic Crash Notification” or “vehicle telematics”, the ability to automatically or manually place an emergency call when a vehicle is involved in a crash has been available for over two decades in the U.S., while the EU has a mandated system called “eCall” that is in the process of being deployed. Recently published IETF RFCs aim to expand the capabilities of such services, and to make them more broadly implementable.
Current U.S. systems are proprietary; some use non-standard in-band modems to send vehicle location and crash data from the vehicle to a call center, which then relays the information to the Public Safety Answering Point (PSAP, also known as an emergency call center). The relaying is done either by non-standard out-of-band data transmission or orally by a service center agent. Other systems place a 9-1-1 call, play a prerecorded message to the PSAP call taker, and use text-to-speech to convey vehicle location and sometimes crash data. The EU eCall system uses a standardized in-band modem to convey vehicle location and crash data from the vehicle to a specialized PSAP, which has a corresponding modem to receive the data.
The IETF has published two documents: RFC 8147 and RFC 8148 that specify how such calls operate using next-generation (all-IP) technology. Vehicles using these RFCs initiate emergency calls either manually or automatically in the event of a crash or other serious incident; the calls carry a standardized set of vehicle location and incident data. Such a call can be routed to a PSAP equipped for this, where the data can be automatically processed and displayed to a call taker at call assignment. During the call, the call taker can request that the vehicle send updated data or perform an action such as flashing its lights.
The IETF developed a generalized mechanism for making data related to an emergency call available to the PSAP along with the emergency call. This mechanism, called “Additional Data”, RFC 7852, allows standardized data “blocks” to be sent in a SIP (RFC 3261) call, either as data in the body of an INVITE message, or as a URL sent in the header which, when dereferenced, yields the data block. RFC 8148 defines a data block for the U.S. “Vehicle Emergency Data Set” developed by the Association of Public-Safety Communications Officials (APCO) and the National Emergency Number Association (NENA), while RFC 8147 defines a block for the eCall data set used in the EU. These RFCs also provide a mechanism for the call taker to request that the vehicle perform an action, such as honking the horn or flashing the lights to allow the responders to locate the vehicle.
Periodic posts on the IETF Blog highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. This one is by Mirja Kühlewind, who is an IETF Transport Area Director. You can also see her interview here.
Mirja Kühlewind, IETF Transport Area Director at IETF 98.
I first got involved with the IETF when I started my PhD. A colleague, who was already involved pointed out that it was starting work closely related to my own interests. I attended my first IETF meeting in 2010, when the CONEX [Congestion Exposure] Working Group (WG) held a Birds-of-a-Feather meeting. From then on, it was my own initiative that kept me working with the IETF—I had support from my group, and they usually had enough travel budget for me to attend the meetings.
Three years ago, I became chair of the RMCAT [RTP Media Congestion Avoidance Techniques] Working Group. I only gave that up when I became Transport Area Director (AD). I also was chair of the TCPINC Working Group for half a year. So I became an AD just six years after starting to participate in the IETF.
There are a limited number of people involved in the Transport Area. As soon as I became more active, I was encouraged to take the role of a Working Group chair. Transport AD wasn’t an option until I finished my PhD. Ultimately, though, it worked out nicely because I got stable funding for a project for a little more than two years, which freed me up to consider the position.
The project is generally funded by the European Union, with additional funding by Switzerland for my part, which includes work we planned to bring into the IETF. This would have allowed me to justify spending so much of my time on IETF work. However, since the project funding is coupled to certain research goals, I additionally contacted some companies and they provide support for some of my time and travel budget.
I hope that my experience as AD can count as management experience and that people value it. It’s a good way to improve your skills because you are in a management position where you don’t have any power, but you need to motivate people. For me, it is about how well I manage Working Groups and how well I manage my time. I spend 40% of my time on my AD work and 60% on my research project. It can be a challenge to balance them.
I don’t think that ETH directly benefits from me being Transport AD. But they did get external funding for our project, and that funding had a strong focus on making an impact on industry. So my standardization work may have helped to get the project funded. I don’t think I needed a leadership role for that. Being a Working Group chair was probably enough to show that I had IETF experience, but my AD role of course also makes a good impression.
Everybody’s biggest concern about taking on an IETF leadership role is time management. I do it on a 40% basis. It’s a little stressful, yes, but it is possible. The other reason it’s hard to find people for the Transport AD role is that the right person not only needs support, money, and time for the IETF, but also must have an overview about what’s going on in Transport. I was in the unique position that I was following the same Working Groups that I now carry as AD—it’s no extra effort.
I don’t have a plan yet for when my term is over, but I know I’d like to stay involved in the IETF. When my ETH project is finished, I’ll be a four-year post doc. I’ll need to make a decision about whether to stay in academics or go into industry. If I apply for a job next year, I won’t stand as Transport AD—I can’t ask a new employer to let me spend 40% of my time on the IETF. Even as a professor, it would be hard for me to get 40% of my time off for the IETF.
It’s been an interesting experience, particularly because I’m just starting my career. I’ve learned a lot, and I’ve made a lot of industry contacts that I’ve gotten to know well. I’m grateful—the IETF as a community has provided me with networking opportunities and a source of ideas for research.
Photos from IETF 98
A collection of photos from the IETF 98 meeting held 26-31 March in Chicago, Illinois, United States.
Before IETF 98 began, the IETF Hackathon was in full swing.
Applied Network Research Prize winner Alistair King presents his research at IETF 98 Chicago 26/03/2017
Applied Network Research Prize winner Yossi Gilad presents his research at IETF 98 Chicago 26/03/2017
David Clark speaking on the question:What is the relationship between Internet Protocols and Human Rights? During the IETF 98 Plenary on Wednesday, 29 March 2017 Niels ten Oever, Head of Digital for Article 19, and David Clark, Senior Research Scientist at the MIT Computer Science and Artificial Intelligence Laboratory, tackled this question. They offered different perspectives on the role human rights considerations should play in the Internet protocols and, in particular, how these considerations ought to factor into the work of the IETF. (L to R: Niels ten Oever, David Clark, Lee Howard)
Outgoing IETF Chair Jari Arkko speaking at the IETF 98 technical Plenary, Chicago 29/03/2017
Incoming IETF Chair Alissa Cooper speaks during IETF 98 Plenary on Wednesday, 29 March 2017.
John Mattsson, senior specialist at Ericsson Security Research speaking as part of the IETF Host Speaker Series on ‘The real deal on cellular security’ during the IETF98 meeting in Chicago, Thursday, 30th, March 2017.
IETF 98 Wrap up video with Jari Arkko and Alissa Cooper, Friday, 31 March 2017.
Periodic posts on the IETF Blog highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. This one is by Jari Arkko, who will step down as the current IETF Chair during IETF 98 and begin an appointment as a member of the Internet Architecture Board (IAB).
I had my first contact with the IETF in 1996. I started working with modem pool and access server products at Ericsson. Some of what we wanted to build for our products needed standards so they could interoperate. I started working with AAA protocols and extensions. Later I became chair of the EAP, EMU, and MOBIKE working groups. These were long-term efforts that I was heavily involved in.
When I was first approached about the area director role, it didn’t sound like a feasible goal, but it grew on me. But a few years later, I applied to become an Internet Area Director. It turned out to be a perfect fit — I got to work on many topics that I really cared about, such as IPv6 transition techniques. And it was good for our company because this is the layer where our products mostly were.
I was an AD from 2006 to 2012. Six years is on the long side for this job. We tell people that four years is optimal because it takes about two years to learn the job. When I was an AD, the IETF took up 50–100% of my time. Meanwhile, Ericsson benefitted from me advising them on where the technical pieces that we cared for were heading to.
I spent the year after the AD term in the the IAB. I was already wondering if I wanted to be the IETF chair. But I knew it would be a growing experience, perhaps even a scary challenge. But I thought about it for a long time and decided to go for it.
I was IETF Chair from 2013 to 2017. And this year we are again in a situation where things are changing: I will still be at the IE, contributing, and again at the IAB.
I have personally benefitted tremendously from the involvement with the IETF. Those challenges were well worth taking! It is a privilege to witness Internet technology in the making. .And the nature of a leadership role in the IETF demands that you see things in a broader way, talk with other companies, talk with lots of people with new ideas. It forces you to understand the bigger picture. I’ve become personal friends with lots of people in the industry, a perk I’ve enjoyed a great deal.
In a leadership role, you get the feeling that you are in the middle of important issues. As chair of one of the more active or high-profile working groups, you are doing things that are broadly visible and have an impact on the Internet. As IETF chair, I was witness to many interesting things. I am an engineer and have no interest in going into political matters. Yet observing the IANA [Internet Assigned Numbers Authority] transition was a wonderful experience, and I was glad to see how that played out.
The work of the IETF chair represents almost 100% of my efforts, although I spend a fair bit of time at Ericsson. My main role at Ericsson is to share with people what is happening in the Internet and make sure we take it into account. There were many cases, including Internet of Things technology, HTTP and encryption changes, where our business was affected by what was happening at the IETF. The company appreciates our IETF team’s involvement and expertise on these topics.
If you are thinking about applying for an IETF leadership position, my suggestion is to take the challenge! Expose yourself to new things. You will understand more, which is a benefit to both you as a person and your employer.
For me, being a leader in the IETF has underscored that we actually can make a difference. We can make significant technical changes in the Internet, or change how the Internet is administered. Yes, some of the work is hard and takes a lot of effort, but isn’t that the exciting part?
Periodic posts will highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. The first of these is by Alissa Cooper, current IETF ART Area Director, who will take on the IETF Chair position during IETF 98.
Alissa Cooper, IETF 96 at Intercontinental Hotel, Berlin, Germany.
I started participating in the IETF in 2008 and went to my first meeting at IETF 72 in Dublin. I was working at the non-profit Center for Democracy and Technology (CDT) in Washington, DC, where my role was to explore and articulate the technical implications of policy. I worked on a number of issues there, including online privacy.
In 2008, real-time applications were the focus of many of the consumer privacy issues of most interest to CDT. Initially, I focused on the Geopriv Working Group. I became a document author and then a co-chair of the group. It was a busy time in Geopriv – many tough battles had already been fought concerning the design of the technology, but finishing out the protocol suite required substantial effort. Over time the IETF grew into a larger portion of my job responsibilities because it was well aligned with the rest of the CDT work I was doing.
In 2011, I was appointed to the Internet Architecture Board and soon thereafter became the lead of the IAB’s Privacy Program. CDT was thrilled—they saw it as a huge honor that one of their own had been selected to serve in this capacity.
In 2013, I joined Cisco, and in 2014, I joined the Internet Engineering Steering Group as Applications and Real-Time area director. I’ve tried to do my area director work approximately half-time and my day job half-time. I’m leaving the post as I’ve been appointed IETF Chair beginning in March 2017—my new full-time role for the next two years.
Leadership in the IETF offers exposure to a broad swath of Internet technology that most of us otherwise wouldn’t be able to justify spending our time learning and influencing. This is particularly true on the IESG, but also on the IAB. It’s incredibly enriching and highly beneficial because you’re able to make connections between your day job and things going on across the whole industry.
IETF leadership also requires management skills of many kinds. You have to manage authors, your time, big community processes. It requires a lot of strategy and work in the background to achieve good outcomes. Many people do not realize the depth of the management education you get while serving in the IETF leadership.
Lastly, you get to (try to) promote your vision of what the future of the Internet should look like. Everybody might not agree with you, but serving in the leadership gives you a platform to steer and influence.
Cisco has been a big supporter of the IETF because it is deeply invested in the growth and stability of the Internet. Its customers like the idea that the products they buy from different vendors interoperate. Cisco enjoys having people in leadership positions dedicating a portion of their time to furthering interoperability and making sure that standards are keeping pace with other technological developments.
In recent years, some IETF participants have encountered difficulty in trying to convince their employers about the value of the time commitment associated with IETF leadership positions. But in reality it is possible to balance your day job with an IETF leadership role—you set the parameters for how you manage your time. Lots of positions require a half-time commitment or less.
Having a well-functioning IETF and an Internet that runs on secure, performant, interoperable standards should be pretty important to any large tech company at this point in history. If that model goes away, the options for how we replace it are all inferior. Hopefully the indirect benefits of supporting IETF leaders are obvious, but if not, current and past IETF leaders are always happy to explain the benefits. We have a big incentive to expand the population of people willing to take on leadership roles.
IETF Hackathons embody the IETF’s tradition of running code—testing theories against the realties of implementation, with a goal of accelerating the definition and adoption of protocols and technologies that make the Internet work better. One of the best things about theses events is the shared success of a broad range of participants, from long-time IETF contributors to those who have never attended an IETF meeting or joined an IETF working group. Of particular note, university students from around the world have been remarkable contributors at the past few hackathons.
Team from Sungkyunkwan University IETF Hackathon at IETF 97
At the most recent IETF Hackathon in Seoul, a team from Sungkyunkwan University worked on implementations of the specifications being defined with the Interface to Network Security Function (I2NSF) Working Group. Powered by energetic professors and students from Sungkyunkwan University in South Korea, the team used RESTCONF and NETCONF together with YANG data models to implement network security services using OpenDaylight and mininet. In doing so, they validated the approach defined by the IETF’s I2NSF Working Group.
Charles Eckel, an Open Source Developer Evangelist for Cisco DevNet, who has led the IETF Hackathons over the past few years, has witnessed first hand how teams with a diverse set of participants often leads to impressive results. Eckel commented, “The most successful hackathon teams are those with a good mix of participants with different skillsets. When you combine IETF newcomers with great coding skills with IETF veterans with tremendous knowledge of evolving Internet protocols—that’s where the magic happens.”
IETF Hackathons provide students with unique learning opportunities as well. Eckel observes, “The mentoring and teamwork that comes from working closely with a group of people on a focused effort over the course of two days is a rich and valuable experience that you are not likely to get merely by reading a few drafts and attending a handful of meetings.”
On numerous occasions, even the hurdle of geography has been cleared by hackathon participants. For example, Ecole Polytechnique de Louvain in Belgium organized two teams working on Multipath TCP during the IETF 97 Hackathon in Seoul. Five participants in Seoul, including three PhD students, worked with 25 students in Louvain-la-Neuve on a new socket API that allows application developers to more easily make use of multipath TCP subflows. Together, the teams received the Best Overall award for the hackathon.
The result confirms Eckel conclusion that, “IETF Hackathons are great events for both long-time IETFers and well as newcomers. “
The next IETF Hackathon will be held in Chicago on 25-26 March 2017. As Eckel notes, “For someone with coding skills and an interest in working on the Internet, IETF Hackathons provide opportunities to get plugged into a project and immediately start producing tangible results.”