With the intention to encourage the development of a solution to an issue currently under discussion within an IETF working group, I wanted to offer a personal view of a possible ways forward. This view is informed by a number of conversations with people involved in the discussion with different perspectives. However, the following does not represent nor is it intended to suggest an IETF position. The work to develop that remains to be done.
One of the strengths of the IETF process is that it brings together a diverse set of technical specialists—network operators, academics, developers, and protocol designers. The IETF seeks broad participation in its standards development processes because it leads to more robust standards—ones that work better and are more broadly applicable to the many different use cases found on the global Internet. However, it is not uncommon for implementers to learn about changes in protocols close to their publication date. This is an opportunity to encourage those using IETF standards to stay informed, at a minimum by reading the appropriate mailing lists.
In my opinion, unless voices are heard and solutions are found, the objective of end-to-end encryption to protect users privacy will be limited as a result of deployment challenges. I fully agree that end-to-end secure communications is necessary to protect the security of Internet sessions, end users privacy, and anonymity for human rights considerations. Unless we look at the obstacles and find ways to fix them, we won’t reach the goal of end-to-end security.
For the past several years, the IETF has been working to strengthen the Internet against pervasive monitoring. In line with that effort, the TLS Working Group has been developing Transport Layer Security (TLS) 1.3. TLS 1.3 is designed to improve security and protect information sent over the Internet that from being intercepted and decrypted by unauthorized entities. While RFC7258 had already recommended against use of static RSA keys for TLS 1.2, this was formally deprecated in TLS 1.3 in favor of the more secure key exchange based on the Elliptic Curve Diffie-Hellman algorithm. These are important steps towards protecting end user privacy and the security of TLS protected sites to keep pace with the evolving threat landscape.
In the case of TLS 1.3, which is nearing completion, enterprise data center operators have recently proposed a deployment method that would enable intercepting and decrypting traffic within a data center through the use of a static Diffie Hellman key. This proposal would continue a method of intercepting and monitoring traffic similar to what is in place for all previous versions of TLS and SSL with static RSA keys. The intention is to restrict the application of this method for use within a data center only, and not with connections to the Internet.
Some data center operators need the ability to look at network traffic for transaction monitoring because of regulations. At the same time they want to adhere to best practices by encrypting network traffic and thereby protect against malicious interceptions. While the proposed scheme for TLS would address this need for monitoring and is applicable to existing techniques used in some data centers, it should be noted that this is not the only possible technical approach that could enable encrypted traffic transmission in data centers as well as regulatory-required monitoring.
Within this use case, client TLS sessions over the Internet are not intended to use this proposal, but rather to maintain forward secrecy (likely not using the 0-RTT option) with the sessions terminating at the edge of the data center. The proposal is intended for use within the data center where both ends of the encrypted sessions are managed by the enterprise.
Others within the TLS working group have voiced concerns about the proposed approach, as there is no technical way to limit it’s usage to the data center. In other words, the method could be used for wiretapping purposes by a third party if it were deployed for a connection over the Internet. The TLS working group agreed to continue to discuss the issue, but how to solve the problem is uncertain at the moment.
The proposal is not likely to be further considered. With this in mind, a discussion on alternate approaches to meet the use case requirements could be quite useful. It may be possible to adapt existing work in the IETF, not necessarily TLS, to meet the requirement, should the IETF choose to work on this problem.
If TLS 1.3 sessions were terminated at the network edge, another solution could be used within the data center. One possibility is the use of IPsec. While all data centers do not have the same needs, some are working toward use of protocols such as IPsec or tcpcrypt operating at the IP and TCP layers rather than the application layer.
Could IPsec be adapted to meet requirements? IPsec transport mode isn’t well deployed, and has some interoperability issues, but this may present an opportunity to work towards a solution outside of TLS. There are also multiple group keying solutions already defined for IPsec including Group Domain Of Interpretation (GDOI) [RFC6407] and Multimedia Internet KEYing (MIKEY) [RFC3830]. I haven’t seen a proposal yet for a protocol designed fit for purpose, but that could be of interest too. My impression from the set of requirements is that we do have time to work collaboratively to a solution.
It may be of interest to know the I2NSF working group is reviewing a proposal from data center operators in cooperation with the IPSecME working group to automate deployment of IPsec tunnels within a data center; a very productive interim call took place on 6 September specific to this proposal.
A third possibility is a multi-party session transport encryption protocol designed specifically for the data center monitoring use case, of which none have been proposed to date to my knowledge.
A longer term solution is to determine what is missing from application logging and endpoint resources to maintain end-to-end encryption and eliminate monitoring via interception. There are scaling issues with pushing these functions out to the endpoint, so perhaps there are other methods that could be used to enable monitoring functions without exposing potentially sensitive information that may or may not be privacy related. This will take lots of work and I encourage application protocol developers to think toward solutions.
While the exact way forward is yet to be determined, I believe that by working collaboratively we can strengthen the Internet and accommodate a broader set of use cases to make IETF standards more relevant to the implementers and operators who put them into practice.
I personally think that we should be doing something to solve the data center use case and would like to see a separate solution from one that uses TLS. In doing so, the likelihood of TLS 1.3 being deployed as intended to protect users privacy increases, as does the security of the terminating site, and the data center operators would gain a solution fit for purpose within their closed environments. It should be noted that there is nothing that prevents the implementation strategy described in the proposal from being deployed; an RFC isn’t necessary for that to happen.
After reading lengthy email discussions, the TLS 1.3 draft and the proposal, and listening to the presentations at the WG session, it appears that there is motivation and expertise to address use cases not anticipated by TLS 1.3. Some are working toward this with the goal of draft adoption within the TLS working group with an extension based solution in which the client is aware of interception. But adoption is not guaranteed.
If this issue affects you, and you believe you can contribute, I encourage you to read through the WG mailing list archive and propose ways forward either adapting a solution with TLS, via alternate encryption and decryption solutions for use within the data center, or through improvements to applications to eliminate the desire to intercept traffic. The use case presented is important to data center operators and working with those deploying IETF protocols increases the success of those protocols being deployed as intended. The IETF doesn’t need to take action, but I’d like to encourage those with ideas to advance the thinking in this problem space.
IETF 99 is about to kick off in Prague, Czech Republic. There is lots of exciting work going on across more than 100 working groups, plus Birds-of-a-Feather (BoF) sessions, plenary talks, and other meetings. Here are a few sessions to keep an eye out for:
We have close to 200 participants signed up for the Hackathon taking place Saturday and Sunday. Around two dozen teams will be collaborating on code projects spanning the breadth of IETF protocols, from security to DNS to transports to IoT and more.
Folks are invited as always to join the Code Sprint on Saturday to work on tools for the IETF community — please join!
Sunday afternoon’s tutorial sessions will include two new technical tutorials. The TEEP tutorial will explain Trusted Execution Environments (TEE) and their associated protocol needs. The IEEE 802.1 Time-Sensitive Networking (TSN) tutorial with explain the TSN group’s work on transport of data packets with bounded low latency, low delay variation and zero congestion loss, closely related to the IETF’s Deterministic Networking working group.
While not an IETF event, the Applied Networking Research Workshop, put on by ACM, the IRTF, and ISOC, is taking place on Saturday. The workshop will provide a venue for discussing emerging results in applied networking research related to measurements, transport, implementation and operational issues, and internet health metrics. (Registration required.)
Those interested in 5G may want to attend the NETSLICING BoF, which is looking at isolation of resources and virtual network functions to support a variety of services. There will also be a plenary lunch time panel on Tuesday about 3GPP and IETF collaboration on 5G in Congress Hall III.
Other BoFs during the week: BANANA, focused on developing solution(s) to support dynamic path selection on a per-packet basis in networks that have more than one point of attachment to the Internet; IDEAS, which is aiming to standardize a framework that provides identity-based services that can be used by any identifier-location separation protocol; and IASA 2.0 where the community discussion about administrative re-arrangements for the IETF continues. Also in the realm of new work proposals, the IPPM working group will be discussing a charter update to allow the WG to take on work related to in-situ OAM.
We continue to see high interest in ongoing work related to data modeling, QUIC, and security. Catch the OPSAWG session for some discussion about managing the development and use of YANG models and the joint CCAMP/MPLS/PCE/TEAS session focused exclusively on YANG models, among other sessions. The QUIC WG will meet jointly with the HTTPBIS working group to discuss interaction between QUIC and HTTP, in addition to two meeting slots on its own. In the security area, both the TLS and ACME working groups are close to finalizing several core deliverables, and the SAAG meeting will feature a talk on post-quantum crypto.
We wouldn’t be able to hold IETF meetings without the support of our sponsors. Big thanks to IETF 99 hosts Comcast NBCUniversal and CZ.NIC! And to all of our sponsors for the meeting.
Wishing everyone a productive and enjoyable meeting!
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.
5G is the latest generation of cellular network standards. There’s a tremendous amount of activity around it in the industry. But how does 5G relate to Internet technology? Are there 5G-related work items that the IETF should be working on, for instance?
While at times the 5G stories take on an almost myth-like nature, the basics underneath 5G are concrete changes in the technology and our increasing needs for communication. The traffic growth for both our smartphones and homes continues to be exponential. And as organisations and societies increasingly connect their systems, there are also many new needs.
5G responds to these needs with new radio technology and a core network that employs state-of-the-art network technologies such as an increased use of cloud, virtualisation, and open source components and processes. From a standards perspective, the timelines for the first systems are very near. The 5G work happens to a large extent in 3GPP, as did previous generations. The work on 5G is planned to take place in two releases, of which the first one is Release 15, scheduled to be stable and all protocols completed latest by September 2018, just 14 months away. Additional work will be done in Release 16, which will complete by March 2020.
What is 5G?
But what exactly is 5G then? First, it is a new, very capable radio. With beamforming, MIMO antenna technology, and frequency bands reaching to millimeter waves, it provides both higher transmission speeds and serves more users at the same time. The new radio is also needed to serve mass deployment of networked sensors, and to enable various mission-critical services that may require better latency or reliability characteristics. 5G radio can provide speeds in the Gigabit range, up to 10 Gbps or even beyond, although for large numbers of users the speeds are lower, but still target at least tens of megabits per user, for tens of thousands of users.
Second, 5G targets a set of use cases, such as the familiar mobile broadband use case. But 5G is also intended to open the use of communication and cellular networks for many new industries. The goal is to be able to tailor communication platform for a wide range of different services, ranging from low power IoT devices to self-driving
cars, from mission critical public safety communication to providing services to energy providers. any of these use cases were hard to provide with previous generation technologies. For instance, one use case is about controlling remote machinery — an example of a service that benefits from lower latencies that 5G provides. There is also a higher demand on flexibility and configurability/orchestration.
From an IP networking perspective, as noted, 5G follows the same evolution as the rest of the networking industry. From a practical perspective, this is a big change, however, and requires effort. The work on details is ongoing for Release 15, but architecturally, the key directions are clear.
To give a few practical examples, interfaces to the devices are relatively similar to those in 4G. One difference is an ability to place different devices in different virtual networks or “slices”, which can be tuned and evolve independently from each other, both in resources and networking technology behind. Another difference to 4G is that the 3GPP security group plans to enable a more flexible authentication framework for the devices. And some of the control protocols inside the network may be changed from DIAMETER-based ones to REST-based APIs. From what we understand, the tunneling-based architecture for mobility is not changing, but of course with most services being provided in virtualised environments, the tunnel endpoints may physically reside in different places.
It should also be said that 5G is not a replacement for Internet-based services or Internet technology: majority of the traffic that 5G will carry is for the usual Internet services, like videos from content providers. 5G is also not immune to impacts from Internet evolution. For instance, we’ve seen big changes in use of encryption in the Internet, transport protocols are evolving, the use of CDN systems is growing, and all networks are becoming virtualised, software-defined, and cloud-resident systems. 5G networks need to serve the Internet that continues to evolve in this manner.
Is there an IETF connection?
It is useful to understand how 5G affects Internet technology. IETF work has been and will be affected by 5G. To begin with, the IETF works on many of the general facilities that modern networked systems such as 5G are based on.
Conceptually, one can think of the interactions as falling in the following categories:
New dependencies on existing IETF technology. For instance, the flexible authentication framework mentioned above is EAP (RFC 3748, RFC 5448). This is likely to be merely a reference to existing RFCs, or if additions are needed, they are small.
Dependencies to ongoing work at the IETF. This includes various general facilities as noted above, but also other things. For instance, the IETF DETNET working group defines mechanisms to guarantee deterministic delays for some flows across a network. As one of the 5G use cases is time-critical communication and low-latency applications, this is a component technology that is being looked at. Similarly, IETF routing-related work such as traffic engineering, service chaining and source routing are likely tools in managing traffic flows in 5G networks.
Topics where there is clear demand for a feature, but it is unclear whether changes to Internet technology are needed, or the details remain to be determined. For instance, in the upcoming IETF meeting in Prague, we will be discussing whether some additional support is needed for what is in 5G called Network Slicing. There are many IETF tools, however, for dealing with virtualisation and separation of networks, so first order of business is probably mapping what can be done with those tools.
Larger, architectural changes, e.g., “future Internet” type solutions such as ICN (Information Centric Networking) are sometimes suggested also in the context of 5G. While these are perhaps unlikely in the first release of 5G, it is of course certain that the evolution of the Internet continues (and there will be future releases of 5G standards as well).
We asked Gonzalo Camarillo and Georg Mayer (liaisons between 3GPP and IETF) about collaboration between IETF and 3GPP. They said that our best approach is to ensure that the 3GPP engineers are involved in the IETF work they are interested in. And that 3GPP states clearly what their requirements (rather than solutions) are. They also noted that the work in 3GPP is ongoing. Hence completing protocol requirements for 5G will still take some time. Gonzalo and Georg will be contacting the relevant parties on both sides to keep us in sync.
Exchange of information would also benefit from informal collaboration, for instance through Internet technology experts working with the 3GPP community. This enables common topics to be easily discussed and brought forward.
We should also note that there are clear boundaries between the two organisations. The IETF works on Internet technologies which may or may not get used in different networks. 3GPP puts together systems, architectures, and designs protocols specific to their networks and layers. The IETF is not in charge of making system level or requirement decisions for the 3GPP. Similarly, 3GPP leaves the evolution of Internet protocols to the IETF.
Also, recently Alissa Cooper, Chair of the IETF, visited a 3GPP meeting. Her report is here.
Finally, it should be noted that many of the existing tussles in the Internet continue to exist with 5G. For instance, the ability to provide a highly dynamic and programmable radio environment continues to present opportunities for collaboration between networks and applications. Such collaboration is not something that has historically been easy in the Internet, however. When we discussed this as a part of the growing use of encryption, the necessary changes to network management practices due to the encryption changes caused pain for operators. Perhaps as some time has passed, and networks continue to evolve, we could consider network – application collaboration as an opportunity and ask what useful things networks can do for applications?
On the joint day of the the recent IESG and IAB retreats, the group discussed a number of topics related to network operator activities for encrypted flows. As part of that conversation, the group looked at RFC 4084, which tackled the question what “Internet Access” means. A dozen years on, that subject probably deserves a new look, and several of the folks at the retreat agreed to draft a new version for community review.
As one of those volunteers, I’d like to dive into RFC 4084 a bit and explore what may have changed since it was published. After walking through the need to avoid pejorative terms, the RFC sets out the following types of connectivity: web connectivity; client connectivity only with no public address; client connectivity only with a public address; firewalled Internet connectivity; and full Internet connectivity.
For those who have bought enterprise connectivity recently, it’s obvious that several common categories are missing: dark fiber, lit service connectivity to a home office, managed MPLS tunnels, and so on. More importantly, though, the RFC doesn’t really touch on cellular wireless connectivity at all, which is now one of the most common ways people connect to the Internet. That means that it doesn’t touch on topics like data caps, roaming for data services, zero rating, or data compression proxies. For cellular connectivity, those can be the key to understanding the trade-offs in connectivity, privacy, and costs for a particular service offering.
Beyond that proliferation in available offerings, there has been another major change, in the ubiquity of filtering. RFC 4084 describes filtering at the ISP level in section 3 and notes “the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services”. RFC 7754 has since provided a much more detailed description of blocking and filtering, and it highlights restricting objectionable content as a category beyond blocking objectionable traffic. That blocking may be a requirement imposed by state regulators. In those jurisdictions, what RFC 4084 described as “full Internet connectivity” has disappeared, because service providers are required to prevent their customers from reaching specific Internet resources, services, or destinations. Even where blocks are not in place, regulatory increases in the amount of Internet tracking data retained and the length of time it is kept have become common. These may contribute to self-censorship in the use of some content. Put simply, firewalled Internet connectivity has become the default offering required of service providers within those territories.
Lastly, the document describes Internet connectivity in terms that apply to the services which would be consumed by a human user and, though some social networking or streaming services are not included, it is generally useful in that regard. As we move into an era in which devices talk to other devices, we also need to examine what a service provides for traffic among devices or between devices and back-end services. Is the implication of a web-only service that the Internet of Things is not supported, or is the implication that it must be reached by a web-based gateway or proxy? The difference between those two is a serious topic of contemplation now, and the architecture of a number of services will depend on it.
In many cases, the architecture of the Internet has developed in the course of a commercial dialog between network operators’ offerings and consumers’ use. Many efforts to make cellular systems walled gardens failed, for example, because the users simply weren’t willing to use them that way and wanted the broader connectivity of the Internet. As we look at this new tension among users’ desires for confidential communication, network operators’ management practices, and regulatory frameworks, a common vocabulary for the services available to the user may help us understand what architectures we can build. If you’d like to contribute to the early discussion, email@example.com is one place to start.
Last week I had the opportunity to participate at the 3GPP plenary meeting in West Palm Beach, Florida, USA, at the invitation of the 3GPP liaison to the IETF, Georg Mayer. In addition to attending meetings of 3GPP’s radio access network group and system architecture group, I had the chance to kick off their new “Wednesday Speaker Club” series with a discussion of how 3GPP and the IETF can cooperate on 5G standardization.
The push towards the next generation of wireless networking technology has been gaining increasing attention and spurring new work across the industry, SDOs, and open source projects. 3GPP participants are investing tremendous effort to define and prioritize 5G requirements to help bring this technology to fruition. They are also working against very tight timelines, with the initial set of 5G standards due to be completed by June 2018. It is therefore both timely and important to identify whether dependencies between 5G and IETF work exist, as well as to identify mechanisms to ensure smooth collaboration.
The IETF and 3GPP have a long history of working together and many successes to build on, including our experience with SIP/IMS, EAP-AKA, and Diameter. Because 5G encompasses a broader swath of folks than those who have been involved in previous joint efforts, I spent part of my time at the meeting introducing how the IETF works, our focus on broadly deployable internet technology, and what we work on. I highlighted some areas of existing IETF work that may be of relevance in the 5G context, including our work on data models, service chaining, deterministic networking, and QUIC (look for more details on these areas in a forthcoming blog post). And I engaged with 3GPP participants around specific strategies to help our two organizations collaborate. You can see my slides here.
The speaker club Q&A session focused on the potential and practicalities of improving collaboration. We talked about the need to have technical experts from each group engage directly with each other (in addition to our existing liaison managers working in both directions), opportunities to provide more introductory presentations in both directions so people not familiar with 5G or specific IETF work can learn more, and ways to identify potential 5G requirements that may yield IETF protocol dependencies early on, even if later analysis in 3GPP reduces the urgency of the need for IETF protocol work.
IETF 99 should serve as a useful opportunity to continue this dialogue and gain more clarity about what specific dependencies we might expect between the 5G plans and IETF work. As noted in my recent post about BOF proposals, we’ll have a slot on the agenda to discuss some of the network slicing work motivated by 5G, in addition to numerous hallway conversations and ad hoc discussions I’m sure. For those working on other aspects of 5G not covered in the BOF proposals and who may be looking for guidance or input about overlaps with IETF work, feel free to reach out to the IAB, the IESG, or our liaison to 3GPP, Gonzalo Camarillo, with questions and comments. Several of us have been working to understand the 5G requirements better and would be happy to hear from you.
BANdwidth Aggregation for interNet Access (BANANA) will be having a working-group-forming Birds of a Feather (BOF) session at IETF 99. BANANA is concerned with providing coordinated Internet Access to a device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability. The goal of this BOF is to determine whether the scope of the problem is well defined and understood, whether there is a critical mass of participants willing to work on the problem, and whether in general the working group would have a reasonable probability of success if chartered. The BANANA mailing list is here.
IDentity Enabled Networks (IDEAS) will be having a working-group-forming BOF. The goal of this work is to standardize a framework that provides identity-based services that can be used by any identifier-location separation protocol. The new requirements driving this framework go beyond the traditional discovery service and mapping of identifier-to-location for packet delivery. The goal of the BOF is to identify what specific work items are appropriate for IETF standardization. The IDEAS mailing list is here.
Network Slicing (NETSLICING) will be having a non-working-group-forming BOF. In this work proposal, a “network slice” is conceptualized as a logical network comprised of the union of resources (connectivity, storage, computing), network functions, and service functions. Network slicing is a concept garnering much attention as part of 5G standardization and development efforts. The goal of the BoF is to identify whether a shared understanding exists of terminology, decomposition of the problem space, and relationships between the goals of the work and existing protocol work in other IETF working groups. Getting clarity on the priority of relevant requirements from 3GPP is also critical. The relevant mailing list is here.
We also received a proposal for a WG-forming BOF concerning 5G IP Access and Session Management Protocols (5GIP), which was not approved for this meeting cycle so as to provide more time for refinement. The responsible area director and others in the IESG and IAB who have been exploring the overlap between 5G and IETF work will continue to engage with the proponents to help gain more clarity, refine scoping, and understand overlaps with other SDOs.
Finally, we’ll have one newly chartered working group meeting for the first time at IETF 99: DKIM Crypto Update (DCRUP). The DCRUP working group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. The mailing list is here.
Looking forward to productive discussions in all these areas at IETF 99.
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.