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 89, 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.
Authentication and Authorization for Constrained Environments (ace)
Description: A problem with constrained devices is the realization of authentication and authorization operations. The aim of ACE is to form a working group (WG) that will provide constrained devices with the necessary prerequisites to use REST operations in a secure way, considering such things as authorization information and the related keying material. Constrained devices will thus be enabled to authenticate operations from other (constrained or less-constrained) devices, to communicate securely with them, and to verify their individual authorization to access specific resources.
Proceedings: http://www.ietf.org/proceedings/89/minutes/minutes-89-ace
Outcome: A good discussion with some concrete problems identified, although more work is required to clearly delineate the scope of any new WG. Since the meeting, a new working group has been proposed in the Security Area (https://mailarchive.ietf.org/arch/msg/ietf-announce/xR8bmbZLOU6QR80mS-HIDVcxEJs).
Domain Boundaries (dbound)
Description: Both users and applications make inferences from domain names, usually in an effort to make some determination about identity or the correct security stance to take. Such inferences, however, are usually based on heuristics, rules of thumb, and large static lists describing parts of the Domain Name System (DNS) name space. These mechanisms are unlikely to be sustainable in the medium term as the DNS root undergoes rapid expansion. There have been some proposals to improve this state of affairs and the purpose of this BoF is to identify the problems, the work to address each problem, and to determine whether there is sufficient interest and energy to set up a working group to complete that work.
Proceedings: http://www.ietf.org/proceedings/89/minutes/minutes-89-dbound
Outcome: This is an important problem for the community to address and further work is required to come to agreement on a clearly described problem statement to help focus the effort. A discussion list has been created (https://www.ietf.org/mailman/listinfo/dbound) and a design team formed to come up with a clear problem statement and some boundary conditions.
Encryption of DNS requests for confidentiality (dnse)
Description: As part of the discussion about responding to pervasive surveillance and the need to make such surveillance more difficult and costly to perform, DNS has been identified as a protocol that can reveal a lot about users and their activities. Existing security solutions (like DNSSEC) do not provide confidentiality of user traffic. There have been proposals to encrypt DNS requests, to prevent information disclosure to third parties, both inside the IETF (draft-wijngaards-dnsop-confidentialdns) and outside of it (DNScurve).
The intention of the dnse BoF is to start from existing problem statements and to find out if something can be recommended to improve DNS traffic confidentiality. The recommendation could be an existing solution (such as IPsec) or a way to map DNS requests into a general-purpose security solution (such asDatagram Transport Layer Security (DTLS)) or the development a new standard for DNS encryption. In the last case, this may require a new WG.
Proceedings: http://www.ietf.org/proceedings/89/minutes/minutes-89-dnse
Outcome: The BoF discussion went well and triggered a second session of the DNS Operations working group to continue the discussion. A mailing list has been created (https://www.ietf.org/mailman/listinfo/dns-privacy) for focused discussion of the problem statement surrounding the addition of privacy to the DNS protocol.
Transport Services (taps)
Description: Many transport protocols and congestion control mechanisms offer services to applications in addition to the long-standing services provided by Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). For an application programmer, using protocols other than TCP or UDP is hard: not all the alternative protocols are available everywhere, hence a fallback solution must be implemented. Some protocols provide the same services in different ways. Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and the potential benefits of other transport protocols are lost.
This BoF is intended to identify the services provided by existing IETF transport protocols and congestion control mechanisms as well as network requirements for common APIs that applications use to communicate. By finding a mapping between these two lists, it is possible to define services that a transport application programming interface (API) should offer. Specifying how these transport services can be implemented using native IETF transports and encapsulated transports, including the definition of mechanisms to validate that a transport (or transports) can be supported on a path would be the next step.
Proceedings: http://www.ietf.org/proceedings/89/minutes/minutes-89-taps
Outcome: This was not a working group forming BoF. The meeting included many interesting presentations and useful discussions. More focus is required with regards to a shared understanding of the issues and concrete, useful next steps.
Read the related IETF Journal article.
Tunneling Compressed Multiplexed Traffic Flows (tcmtf)
Description: RFC 4170 Tunneled Multiplexed Compressed Real-time Transport Protocol (TCRTP) defines a method for grouping packets when a number of UDP/RTP VoIP flows share a common path, considering three different layers: header compression, multiplexing, and tunneling. TCRTP optimizes the traffic, increasing the bandwidth efficiency of Voice over Internet Protocol (VoIP) and reduces the amount of packets per second at the same time. More recently, real-time services that use bare UDP instead of UDP/RTP have become popular. There is a need to replace RFC 4170 with an extended solution able to optimize these new flows, also using improved compression methods.
The BoF will discuss the proposed charter, with the aim of the creation of a WG in order to specify the protocol stack, signaling mechanisms, and maximum added delay recommendations for tunneling, compressing, and multiplexing traffic flows (TCM-TF). This BoF is intended to form a WG.
Proceedings: http://www.ietf.org/proceedings/89/minutes/minutes-89-tcmtf
Outcome: This is the second BoF of TCMTF. The problem statement was well presented and the use scenarios are quite clear. TCP is now out of scope. Discussion continues on applicability and latency considerations, but it seems that for very low bandwidth links in developing countries, a new standard here would be useful. There is a mailing list for continuing discussion (https://www.ietf.org/mailman/listinfo/tcmtf).
Virtualized Network Function Pool (vnfpool)
Description: A Virtualized Network Function (VNF) provides a network function (e.g., packet filtering at firewalls, load balancing, etc.) and is typically implemented as a software instance running on a commodity hardware server via a virtualization layer (i.e., hypervisor). This is distinct from monolithic network devices, where either a single or a number of different network functions are provided in the same specialized hardware server. There is a trend to move such network functions away from specialized hardware to commodity hardware servers, based on virtualized resources, to support VNF and further also to support Service Function Chaining (SFC). In SFC, a network service can be implemented by a set of sequentially connected VNFs deployed at different points in the network. We call a group of VNFs a VNF set, which can be used not only as an SFC, but also solely as one or more pools of VNFs.
A VNF set can introduce additional points of failure beyond those inherent in a single specialized server, and therefore poses additional challenges on reliability of the provided services. Currently, generalized pooling and other redundancy mechanisms may be applied to address some reliability requirements of a single VNF. However, the complexity of dealing with a growing number of VNFs including stateful and stateless functions, and extending the redundancy across a VNF set (i.e., multiple pools for multiple VNFs) requires further solution development. In the current charter, the WG would focus on the work around several mechanisms supporting the reliability of a VNF set: redundancy across a VNF set and stateful failover among pool members.
Proceedings: http://www.ietf.org/proceedings/89/minutes/minutes-89-vnfpool
Outcome: A good discussion that identified a need for further work on the intended scope of any potential working group on this topic, and the need to work closely with the SFC WG to avoid any potential overlap.