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 87, 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.
Stacked Tunnels for Source Routing (status)
Description: The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons, including Label Switched Path stitching, egress protection, explicit routing, egress ASBR (Autonomous System Boundary Router) link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both interdomain and intradomain routes.
This BoF was intended to discuss the practicalities of various use cases and to establish a consensus regarding the problem space and desirability of developing solutions in this area.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-status
Outcome: A packed meeting demonstrated a clear demand to work on this. The overwhelming majority want to work on MPLS (Multiprotocol Label Switching), with some support for an IPv6 variant using extension headers. There was clear consensus to charter work on architecture, use cases, and requirements.
Network Service Chaining (nsc)
Description: Service chaining is a broad term used to describe a common model for delivering multiple services in a specific order. Service chaining decouples service delivery from the underlying network topology and creates a dynamic services plane that addresses the requirements of cloud- and virtual-application delivery. Packets and/or flows that require service chaining are classified and redirected to the appropriate, available services. Additionally, context can be shared between the network and the services.
The goal of this BoF was to let service providers explain their NSC use cases and requirements so that the IETF is exposed to the problem space and can determine next steps.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-nsc
Outcome: This was not a working-group forming BoF and there remains quite some work to do to get to a WG. More clarity regarding the problem statement and the relevant IETF work is a top priority.
PKIX over Secure HTTP (posh)
Description: Channel encryption with TLS (Transport Layer Security) depends on proper checking of the server’s identity, as specified in RFC 2818 or RFC 6125 for PKIX certificates. However, in multitenanted environments it is effectively impossible for a hosting service to offer the correct certificates on behalf of a hosted domain, since neither party wants the hosting service to hold the hosted domain’s private keys. As a result, typically the hosting service offers its own certificate (say, for hosting.example.net), which means that TLS clients and peer servers need to “just know” that the hosted domain (say, foo.example.com) is hosted at the service.
This situation is clearly insecure. POSH (PKIX Over Secure HTTP) solves the problem via two interconnected aspects: TLS clients and peer servers retrieve the material to be used in checking the TLS server’s identity by requesting it from a well-known HTTPS URI (uniform resource identifier). If a hosted domain securely delegates an application to a hosting service, it redirects requests for the well-known HTTPS URI to an HTTPS URI at the hosting service.
The goal is to form a working group to produce a specification for POSH, and informally provide advice about how to use the POSH technique for particular application protocols.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-posh
Outcome: A good meeting helped clarify the problem space and the strong potential for IETF work. Next steps is to fine-tune the proposed WG charter.
IPRbis (iprbis)
Description: Experience shows that BCP 79 (Best Current Practice 79) needs a few updates. A draft is available with the proposed updates, and this BoF meeting provided the community with an opportunity to discuss the proposed changes. It was not intended to form a WG.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-iprbis
Outcome: A good discussion and some consensus was reached on difficult issues. In order to maintain momentum, an updated document will be posted and consensus confirmed on the mailing list.
Deterministic IPv6 over IEEE802.15.4e Timeslotted Channel Hopping (6tsch)
Description: If formed, a WG on this topic would develop an architecture that supports centralized and distributed routing and resource allocation over a TSCH-based mesh. The group would resolve the impacts on existing protocols such as RPL (Routing Protocol for Low-Power and Lossy Networks) and 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks). It would define a component that provides the expected link functionality for IPv6 over the TSCH MAC and a G-MPLS switching sublayer, and standardize the protocols or protocol extensions to establish time slots between peers and reserve resources along a path.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-6tsch
Outcome: An excellent meeting that demonstrated strong support for doing the proposed work. Although many expressed willingness to contribute to the work, concerns were expressed about the potentially large scope. A refined charter with fewer work items is likely to be approved soon.
Domain-based Message Authentication, Reporting and Conformance (dmarc)
See pp.XX-XX for our article on this topic.
Tunnelling Compressed Multiplexed Traffic Flows (tcmtf)
Description: The interactivity requirements of some emerging services (e.g., VoIP, videoconferencing, telemedicine, video vigilance, and online gaming) make them send high rates of small packets in order to transmit frequent updates between the two extremes of the communication. They also demand small network delays. In addition, other services also use small packets, although they are not delay-sensitive (e.g., instant messaging, m2m packets sending collected data in sensor networks using wireless or satellite scenarios). For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead.
When a number of small-packet flows share the same path, bandwidth can be saved by multiplexing packets belonging to different flows. If a transmission queue has not already been formed but multiplexing is desired, it is necessary to add a multiplexing delay that must be maintained under some threshold in order to grant the delay requirements.
The BoF aims for the creation of a WG in order to specify the protocol stack, signalling mechanisms, and maximum added delay recommendations for tunnelling, compressing, and multiplexing traffic flows (TCMTF).
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf
Outcome: Opinion was divided regarding the clarity and completeness of the problem statement and whether or not to create a working group to address this. More work is required to understand the potential side effects of using something like TCMTF beyond satellite links.
DNS-SD Extensions (dnssdext)
Description: The proposed WG will develop solutions to provide scalable DNS-SD (Domain Name System-Service Discovery) services in multilink, routed networks as found in academic, enterprise, home, and mesh radio networks. This was the second BoF on this topic, following the mdnsext BoF held during IETF 85.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-dnssdext
Outcome: A good meeting with strong support shown for IETF work on this topic and people willing to contribute. More work is required to refine the charter, but this is likely to proceed.
IPv6 over networks of resource-constrained nodes (6lo)
Description: This BoF discussed a proposed working group that would focus on adaptation layers for constrained node networks, working closely with the Internet Area working groups and other IETF WGs focused on constrained node networks.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-6lo
Outcome: Very strong support for IETF work on this topic and lots of people willing to contribute to reviewing, editing, and implementing documents. Further scoping discussions are required, but this is likely to proceed.
Active Queue Management (aqm)
Description: Internet routers, lower-layer switches, and other middleboxes include buffers or queues to hold packets when they are not immediately able to be forwarded to the next hop. These queues are intended to absorb bursts of traffic that may naturally occur, and to avoid unnecessary losses. However, queues also cause latency and jitter in the eventual arrival times of packets. This can cause issues and complications for interactive applications.
The Active Queue Management and Packet Scheduling working group (AQM) is intended to work on algorithms for proactively managing queues.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-aqm
Outcome: A very productive discussion with strong support shown to form an IETF WG on this topic. Lots of people are interested in contributing.
DTLS in Constrained Environments (dice)
Description: There is an increased use of wireless control networks in city infrastructure, environmental monitoring, industrial automation, and building management systems. These wireless control networks comprise many electronic devices, sensors, and actuators that are connected to each other, and in most cases Internet connected. The CoRE working group has defined a framework for resource-oriented applications intended to run on Constrained Node Networks (CNN) (see I-D-ietf-lwig-terminology). The Constrained Application Protocol (CoAP) can be used to manipulate resources on a device in a CNN.
Unsecured group communication for CNNs is enabled by using CoAP on top of IP-multicast. However, it must be secured as it is vulnerable to the usual attacks (e.g., eavesdropping, tampering, message forgery, and replay). Datagram Transport Layer Security (DTLS) has been chosen by CoRE to protect CoAP unicast communications, and it would be beneficial if the same security protocol can be used to protect CoAP group communication as well.
This WG combines expertise from both the IETF Application and Security areas in order to develop the appropriate security solutions.
Proceedings: http://www.ietf.org/proceedings/87/minutes/minutes-87-dice
Outcome: A well-organised meeting that detailed the problem statement, scope of the proposed work, and relationships with other Working Groups. Lots of enthusiasm for starting a WG on this topic and people with energy to contribute to doing the work.
Secure Telephony Identity Revisited (stir)
See pp.XX-XX for our article on this topic.