Skip to main content

Filter by topic and date

Filter by topic and date

Five working groups meeting for the first time at IETF 108

15 Jul 2020

Several new working groups are scheduled to meet for the first time during the IETF 108 Online meeting held 27-31 July 2020.

While possible new work is being considered in Birds of a Feather (BoF) during IETF 108, four technical working groups are currently spinning up and one is aiming to address administrative issues around moving IETF meetings online.

Automatic SIP trunking And Peering WG (ASAP)

Deployment of a Session Initiation Protocol (SIP)-based infrastructure has increased over the last few years leading to increased peering between enterprise and service provider networks. However, the sheer number of standards related to direct IP peering often makes it unclear which behavioral subsets, extensions to baseline protocols, and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP service provider network. The ASAP working group will define a descriptive capability set to be populated by a SIP service provider which makes it easier for an enterprise network to set up SIP trunking with the service provider network. This will avoid current interoperability issues and the resulting significant amount of time spent by enterprise network administrators in troubleshooting. 

A collection of working group deliverables will be collectively referred to as “SIP Auto Peer”, which will include the descriptive capability set itself, a data model for the capability set, a service discovery mechanism and a transport mechanism for the capability set. This work will be coordinated with the existing IETF SIPCORE working group and the SIPConnect efforts carried out by the SIP Forum.

Grant Negotiation and Authorization Protocol WG (GNAP)

This new working group was formed to develop a protocol that will allow an authorizing party to delegate fine-grained access to client software through an authorization server, expanding on use cases currently supported by OAuth 2.0 and OpenID Connect. The protocol is intended to support authorizations scoped as narrowly as a single transaction, to provide a clear framework for interaction among all parties involved in the protocol flow, and to remove unnecessary dependence on a browser or user-agent for coordinating interactions. The approach outlined aims to avoid the security concerns and technical challenges of OAuth 2.0 while providing a non-invasive path for supporting future types of clients and interaction channels.

The initial work plan is focused on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary objectives.

Multiplexed Application Substrate over QUIC Encryption (MASQUE)

Many network topologies lead to situations where transport protocol proxying is beneficial, for example to enable endpoints to communicate when end-to-end connectivity is not possible, or to apply additional encryption where desirable, such as a VPN. Proxying can also improve client privacy, for example by hiding a client's IP address from a target server. However, existing proxying technologies have shortcomings, such as inadequate encryption in the case of SOCKS and being limited to TCP in the case of HTTP CONNECT.

The primary goal of the MASQUE working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection. The group will specify HTTP and/or HTTP/3 extensions to enable this functionality. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with the Internet Congestion Control Research Group (ICCRG) and Transport Area working group (TSVWG) on congestion control and loss recovery considerations, and Internet Area working group (INTAREA) for IP Proxying.


The Privacy Pass working group is being formed to develop a protocol that defines a performant, application-layer mechanism for token creation and anonymous redemption. Servers (Issuers) would be able to create and later verify tokens that are redeemed by an ecosystem of clients, such that an Issuer can not effectively link a particular redeemed token to any individual token from a group created with the same cryptographic key. The proposed work includes three parts: 1) specify an extensible protocol for creating and redeeming anonymous and transferrable tokens, 2) describe and develop protocol use cases and their properties, 3) specify a HTTP-layer API for the protocol. 

The group is expected to work closely with the Crypto Forum Research Group (CFRG) in determining acceptable cryptographic ciphersuites and parameters that satisfy the security and privacy properties of the protocol. The PRIVACYPASS working group is in the initial stages of chartering and is currently being shared with the IETF community for comment.

Stay Home Meet Only Online WG (SHMOO)

Building on community discussions underway, and with the disruption to the typical IETF meeting in-person schedule caused by the COVID-19 pandemic, the SHMOO working group has been formed to document high-level guidance and principles the Internet Engineering Steering Group (IESG) and the IETF LLC can use to plan online meetings. The SHMOO WG will not address detailed operational plans or financial aspects of online meetings, except for providing guidelines about whether and how to set a registration fee for fully online meetings. The expected outcome is documents that provide guidances about: 

a) determinations of when a previously scheduled in-person meeting should be canceled and replaced with a full online meeting; 

b) factors such as time zone selection, meeting length, and other high-level scheduling aspects related to planning a fully online meeting; 

c) functional requirements for technologies used for fully online meetings; d) guidance about meeting fees for fully online meetings; and 

e) the cadence of meeting scheduling once the disruptions caused by the pandemic have subsided.

While the disruptions caused by the COVID-19 pandemic may have been mitigated by the time this group completes its work, the experience of handling meeting planning during the pandemic has proven that having community consensus guidance at hand when dealing with novel conditions in the future would be beneficial.

Share this page