By: Mat Ford
Date: July 6, 2016
Getting new work started in the IETF usually requires a birds-of-a-feather (BoF) meeting to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and the level of interest in and support for the work. In this article, we’ll review the BoFs that took place during IETF 95, including their intentions and outcomes. If you’re inspired to arrange a BoF meeting, please be sure to read RFC 5434: Considerations for Having a Successful Birds-of-a-Feather (BoF) Session.
Babel Routing Protocol (babel)
Description: Babel is a loop-avoiding distance vector routing protocol that has good provisions for dynamically computed metrics and remains robust even in the presence of metric oscillations and failure of transitivity. Babel has seen some production deployment, notably in hybrid networks (networks that combine classical, wired segments with mesh segments) and in global overlay networks (networks built with large numbers of tunnels spanning continents). Babel is also considered as part of the IETF Homenet protocol stack. There exist three independent implementations of Babel, all of which are open source.
The core of the Babel protocol is described in detail in RFCs 6126 and 7557, which are both Experimental. While these RFCs have been useful (as indicated by the independent reimplementations of Babel), a number of parties have expressed a desire to have a new specification that clarifies RFC 6126 according to the feedback provided by the independent reimplementations, and to integrate the contents of RFC 7557 without expanding the scope of Babel.
The goal of this BoF was to discuss the value and scope of the work required to create a standards track successor to RFCs 6126 and 7557, including what technical topics need attention as part of advancement. The BoF also discussed the applicability of Babel.
Outcome: This was a well-moderated and productive discussion that focussed on the background to Babel and the work that needs to be done in an IETF working group. There was solid interest in the room from people interested in contributing to the work and reviewing documents. A charter for a WG has been circulated for review.
Low Power Wide Area Networks (lpwan)
Description: Low-Power Wide Area Networks (LPWAN) are long-range low-power lossy networks, many of which operate in license-exempt bands. LPWANs provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles. Existing pilot deployments have shown the huge potential and met industrial interest, but the loose coupling with the Internet makes the device management and network operation complex and implementation-specific. As of today, there is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability.
Outcome: Discussion ranged across a wide variety of L2 technologies that could be classified as LPWANs. The implications for the IP protocol stack of each were also discussed. The group will need to focus more on fewer L2 technologies and engage with external SDOs to make progress.
Alternative Resolution Contexts for Internet Naming (arcing)
Description: RFC 819 describes Internet names as a set of directed graphs in an absolute naming context. While that work eventually led to the creation of the Domain Name System, it is important to note that it does not imply that there will be a single resolution system for Internet names. While the most common Internet names by far are those which are part of the Domain Name System, that set of names is not the whole.
A number of independent naming and resolution contexts have emerged. In addition to those created for onion routing and multicast DNS, there are large sets associated with the Handle system, Uniform Resource Names (URNs), and Internet scale proprietary names (e.g., Twitter handles). It is apparent that the desire to reuse Internet protocols that default to DNS-based resolution in other resolution contexts has created ambiguities in the resolution context that should be used for individual names. Those ambiguities may result in operational difficulties (queries in the wrong context) and in concerns about limitations implied for DNS-based names.
Outcome: This meeting was intended to address the questions of whether there are interesting problems here and whether it is possible to provide good guidance on resolving them. There was some support for the idea that a WG-forming BoF could be held during IETF 96 in Berlin. The chairs encouraged attendees to write drafts describing their preferred solutions for this problem. Writing about technology efforts that have these issues now would also be helpful.
Limited Use of Remote Keys (lurk)
Description: HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. Currently, most trust models assume private keys are associated and owned by the HTTP server, and that the server is responsible for both the hosted content and for the network delivery. Although these assumptions were largely true in the past, today the deployment of services on the Internet often relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application, such as a Web browser, expects to authenticate a content provider, but is actually authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application-layer content.
Outcome: There was a lack of agreement about the problem and how to address it, and a range of potential solutions were identified and discussed. Focussing on the Content Delivery Network use case was identified as a way to make progress, and there was consensus that the IETF was an appropriate place to work on this problem. It is clear that more work to define the problem scope will be necessary before that work can start in earnest. This seems likely to return as a future BoF meeting.
Intelligent Transportation Systems (its)
Description: The goal of this group is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks.
It concentrates on 1-hop moving network to nearby moving network communications. This has immediate applicability in mobility environments such as vehicle-to-vehicle or vehicle-to-infrastructure communications. In some of the moving network applications, the window of opportunity for exchanging data with the immediate infrastructure may be very short. The safety and security requirements are higher in connected mobility environments. The links are very heterogeneous, such as 802.11p/ac/ad OCB, Infra-red, VLC, cellular, 802.15.4, and so forth.
The BoF was intended to bring implementers, users, and experts from academia, institutes, IT, the automotive industry, and public authorities together to discuss.
Outcome: There was good discussion of the problem space and several comments about the need to address security and privacy considerations. There is a pressing need to engage key SDOs and industry players, in order for the output of any IETF work on this topic to see widespread deployment in vehicular networks. A WG charter will be developed on the mailing list.
Alternatives to Content Classification for Operator Resource Deployment (accord)
Description: Mobile Radio Access Networks (RANs) have historically allowed content-type based classification to associate service descriptions with flows with the goal of efficient use of the often-volatile radio bearer. The increased use of Transport Layer Security (TLS) and other encrypted transports eliminates this metadata from the view of the operator and forces a reexamination of this method. While having endpoints expose metadata to the radio access network (RAN) outside of the encrypted channel would resolve this, it would degrade the confidentiality expected by users and require extensive coordination among application developers, user endpoint manufacturers, and RAN operators. To avoid these disadvantages, the WG will examine both what specific network treatments need to be elicited for the efficient operation of RANs, if any, and what the minimal communication to elicit those treatments would be. This BoF session was part of the follow-on activity stemming from the Internet Architecture Board (IAB) Managing Radio Networks in an Encrypted World (MaRNEW) workshop in 2015 (https://www.iab.org/activities/workshops/marnew/).
Outcome: The meeting benefited from a high-level introduction that helped bring attendees up to a minimal understanding of the relevant parts of mobile network architecture. Discussion revolved around whether progress could be made now by running experiments without any additional protocol machinery (0-bit solution) and whether it was necessary to provide some minimal signalling (1-bit solution). The difficulty of extracting useful data from operators was noted. It was also noted that TCP optimizers seem to have fallen out of favour with many operators as they don’t offer any performance improvement. Discussion also included general ways to improve performance in radio networks.
IAOC Meeting Venue Selection Criteria & Procedures (mtgvenue)
Description: The IETF has expressed concern regarding the process of selecting a meeting venue. The IETF Administrative Oversight Committee (IAOC) and IAOC Meetings Committee have undertaken to document the process, which has been posted at an IAOC-private site for some time and is being updated, in an Internet-Draft for community discussion. This meeting was to allow community discussion of concerns relating to meeting venue selection and the draft process.
Outcome: The session provided a lot of background about the way the IAOC Meetings Committee has been operating and the draft set of meeting venue criteria that have been developed. An analysis of the impact of applying the draft meeting criteria to IETF venues for IETF 74 to IETF 100 was also presented. There was some time available for input and discussion from the community, and that continues on the mailing list.