* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Timeframe IETF 89 (London)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, January 17, 2014. The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconferece, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before January 31.

Applications

ACE (approved)

  • Name: Authentication and Authorization for Constrained Environments (ACE)
  • Description: Currently, a problem with constrained devices is the realization of Authentication and authorization operations. The aim of ACE is to form a working group that will focus on providing 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.

    Note: DICE (DTLS In Constrained Environments) WG aims to define a DTLS profile that is suitable for constrained environment; The objective is to secure message exchanges at the transport layer, and it does not address authorization. ACE aims to enable authorization to access specific resources and thus enables constrained devices to verify the valdity of a given authorization. ACE will employ security properties of DTLS whenever possible.
  • Status: WG Forming
  • Responsible AD: Barry Leiba
  • BoF proponents: Kepeng Li <likepeng@huawei.com>, Stefanie Gerdes <gerdes@tzi.de>
  • BoF chairs: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Kepeng Li <likepeng@huawei.com>
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): APP area (especially core), Security area (especially dice, saag, jose,

oauth), lwig

DBOUND (approved)

  • Name: 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 DNS name space.

    The inferences are used for several related but different purposes:
    • establishing acceptable inter-domain cookie use
    • establishing relationships for TLS/SSL certificate issuance
    • display of domain names in URL bars in an effort to highlight phishing attempts
    • locating organizational policy documents (for DMARC) in the DNS
    • establishing "same origin" for acceptance of content
    • HSTS and public key pinning
    • linking domains for purposes of reporting and so on

The DNS root is expanding rapidly, and the existing mechanisms -- primarily the public suffix list (http://publicsuffix.org/) and related systems -- are unlikely to be sustainable in the medium term. Most of the existing mechanisms are managed semi-manually, and there are good reasons to suppose that the limits of such management are either about to be exceeded, or already have been. Moreover, the existing mechanisms are made without regard to the semantics of domain name boundaries, and sometimes miss subtle but important parts of those semantics (in particular, the public suffix list has sometimes failed to take into account so-called empty non-terminals). Perhaps most importantly, the public suffix list puts the control of policy assertions about a given name outside of the control of the domain operator, and in the hands of the operator of the list.

There have been some proposals to improve this state of affairs:

The purpose of this BoF is to identify as completely as we can the cases in need of addressing, to identify the necessary lines of work to address each case, and to determine whether there is sufficient interest and energy to set up a working group to complete that work.

Discussion on this topic has heretofore been undertaken in the APPSAWG, but that working group asked the participants to hold a BoF on this subject to determine whether it ought to be undertaken in its own WG.

General

RFCFORM (approved)

  • Name: non-ASCII characters in RFCs and other format updates (rfcform)
  • Description, including whether the BoF is intended to form a WG or not. This will report out on the intended guidance around the use of non-ASCII characters in RFCs. The responsible Area Director (AD)
  • Area: General
  • BoF Chairs (or the ADs as placeholders): Heather Flanagan
  • Number of people expected to attend: 75, + or - 25
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): Ted Lemon's and Jari Arkko's WGs, and if we can avoid IPFIX and EMAN

(Nevil's WGs) that would be helpful

  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? Yes, this is likely to be of interest of people unable to make it to the meeting.
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.: rfc-interest@rfc-editor.org

IGOVUPDATE (approved)

  • Name: Internet Governance Update (igovupdate)
  • Description: A session sponsored by the IAB to talk about (1) IANA matters and the new framework draft and (2) 1NET
  • Area: General
  • BoF Chairs: Marc Blanchet
  • Number of people expected to attend: 150
  • Length of session: 2 hours
  • Conflicts to avoid: Jari Arkko's WGs, all area meetings
  • Does it require WebEx?? No
  • Does it require Meetecho? Yes
  • Links to the mailing list: http://www.iab.org/mailman/listinfo/internetgovtech

Internet

DNSE (approved)

  • Name: Encryption of DNS requests for confidentiality
  • Status: Not WG-forming
  • Description:

At the IETF meeting in Vancouver, there have been a lot of talk about pervasive monitoring, the attack it is (draft-farrell-perpass-attack and draft-barnes-pervasive-problem) and the ways to "harden the Internet", to make such mass surveillance more difficult and more costly.

Among the protocols that can reveal a lot about the users and their activity, the DNS is one of the most widely used (draft-bortzmeyer-dnsop-dns-privacy). Existing security solutions (like DNSSEC) do not provide confidentiality of the uers's traffic. There have been proposals to encrypt DNS requests, to prevent sniffing by a third-party, both inside IETF (draft-wijngaards-dnsop-confidentialdns) and outside (DNScurve).

Some of the foreseen solutions for DNS confidentiality imply a change in the protocol and therefore do no fit well in the existing dnsop working group.

So, the idea of the BoF is to start from the problem statements in draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality, and to find out if something can be recommended to improve DNS traffic confidentiality against sniffing. The recommendation could be an existing solution (such as IPsec) or a way to map DNS requests into a general-purpose security solution (such as DTLS) or the development a new standard for DNS encryption, possibly based on DNScurve/DNScrypt or draft-wijngaards-dnsop-confidentialdns. In the last case, it may require a new WG.

  • The responsible Area Director (AD): Brian Haberman
  • BoF Chairs (or the ADs as placeholders) Brian Haberman
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5
  • Conflicts to avoid (whole Areas and/or WGs): Perpass, DNSOP, DBOUND BoF, IPsec, TLS, DANE, SAAG, TRANS, WPKOPS
  • Does it require WebEX?: No
  • Does it require Meetecho?: No
  • Links to the mailing list: no mailing list
  • Draft charter if any: This is a non-WG forming BoF
  • Relevant Internet-Drafts: draft-bortzmeyer-dnsop-privacy-sol and draft-wijngaards-dnsop-confidentialdns

Geonet (not approved)

BOF full name and acronym: Geographic Networking [geonet]
Area: Internet Area
BoF Chairs (or the ADs as placeholders):

Agenda summary:

  • note well, agenda-bashing, blue sheets
  • status update
  • use cases
  • problem statement
  • charter discussion.

Description, including whether the BoF is intended to form a WG or not:

IP routing and addressing are done without knowledge of the geographic location of participating nodes. Standardized, interoperable mechanisms are needed to provide authorized source nodes anywhere in the internet to disseminate packets to nodes based on geographic location, while preserving the privacy of senders and receivers. Scenarios under discussion include the sender sending to nodes in a given geographic area while not knowing their identity, senders knowing the identity of the nodes receiving the packets, and nodes communicating their location to senders. The goal of this BOF is to clarify which scenarios will fall within the scope of a working group, assess interest levels, and identify potential contributors.

This is a working group-forming BOF.

Conflicts to avoid (whole Areas and/or WGs): 6man, v6ops, opsawg, lisp, geopriv, ecrit.
Responsible Area Director (AD): Ted Lemon
Number of people expected to attend: 100
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Does it require WebEX? If so, why?

Yes. We have active contributors who will not be attending in person, as well as remote subject matter experts.

Does it require Meetecho? If so, why?

Yes. Please see above.

Mailing list: ietf.org/mailman/listinfo/its
Problem statement: https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt
Internet Drafts:

Operations and Management

hiaps (not approved)

  • Name: Host Identification, Address and Prefix Sharing in Wi-Fi Access (HIAPS)
  • Description:

Host identification is an issue in many use cases, e.g. emergency calls. To identify the terminal sending an emergency call from inside the visited fixed access network a suitable identifier should exist for the service provider receiving the emergency call to query a location information from a location server in this access network. Such an identifier is not available when the hosts are behind a gateway using NAT or when the communication is tunneled such as using VPNs or IPSec. In most of these scenarios, the hosts access the network using Wireless Local Area Networks, aka Wi-Fi access. ETSI Technical Body E2NA (End-to-End Network Architectures) is developing an architectural framework about delivery and transport of an emergency caller’s location. As an IETF-based solution is considered promising to ETSI a liaison statement has been sent to IETF recently to ask for a solution enabling signaling of information to provide the emergency caller's host identification to be developed.

Host Identification, Address and Prefix Sharing in Wi-Fi Access (hiaps)

Nowadays typically for end-to-end provision of a dedicated application a plurality of administrative entities responsible for networks, domains, and related services, each representing independent enterprises, may be involved. Within this context an unambiguous identification of both session endpoints, especially that of a mobile user terminal as host is not always possible. This arising host identification issue shall be solved in hiaps working group.

The assumed scenario is that multiple hosts access a (voice or multimedia) communication service via e.g., an intermediate Wireless Local Area Network, aka Wi-Fi access provided by a (visited) access network operator. To identify the location of a terminal sending an emergency call from inside the visited access network a suitable identifier should exist for the service provider receiving the emergency call to identify the access network and query a location information. Such an identifier is not available when the hosts are behind a gateway using NAT or when the communication is tunneled such as using VPNs or IPSec. ETSI Technical Body E2NA (End-to-End Network Architectures) is developing an architectural framework about delivery and transport of an emergency caller’s location. As an IETF-based solution is considered promising to ETSI a liaison statement has been sent to IETF recently to ask for a solution enabling signaling of information to provide the emergency callers location to be developed.

The approach to be investigated involves NAT or Carrier Grade NAT or the tunnel endpoint injecting the host identifier on every packet the host sends to the emergency call server and then the call server querying the location server and receiving location reference (not the host's location) from the location server. NATs employed in Residential Gateways will not be required to deploy hiaps solution because in home networks, only the external address of box (and thus the location of the box) needs to be visible, i.e. the location of the box can serve as the location of the host.

It should be noted that the host identifier to be sent will be only valid in the visited access network to which the host is connected and not valid outside of this network and in the emergency call server's network.

Approaches to enable authentication of location, management of the service URN namespace, and augmented information that could assist emergency call takers or responders are already dealt with within ecrit wg and therefore strictly out of scope of the new activity.

Also representations of location in Internet protocols as have been developed by geopriv wg and the correspondingly identified and documented requirements with respect to authorization, integrity, and privacy of the location information during creation, storage, and usage are out of scope.

The solution hiaps will develop is expected to be used by any application layer protocol enabling call setup (e.g. XMPP or a proprietary protocol used by OTT players) and possibly not including SIP.

Specifically, the HIAPS WG is chartered to deliver the following:

1) Requirements: This document will analyze and eventually enhance requirements that need to be fulfilled from the issues to be addressed in case of host identification in address / prefix sharing and tunneling scenarios.

2) Solution Analysis: This document will provide an analysis of the solution space with the aim of helping the working group to have a closure on the solutions to be selected.

3) Solution for Address Sharing: A document to provide host identification to an external server in address sharing/tunneling scenarios.

HIAPS will not work on roaming cases, i.e. HIAPS will not deal with any cases that requires a persistent host identity during roaming. Mobile hosts are in scope but a different non-trackable identity will be assigned separately per each point of attachment.

HIAPS problem space brings the issue of persistent identifiers visible to on-path observers. This problem will be given special attention both in the requirements and in the solution development phases. First it has to be ensured that the server on the receiver side is well justified to receive the information. Next it will be granted that the communication is not visible to on-path observers using the most state-of-art ways of securing the communication.

HIAPS WG will work closely with other working groups in OPS or other areas as needed. Deployment issues require cooperation with the operations area working group. Privacy issues in the solutions require close cooperation with the security area.

Proposed Milestones May 2014 Submit to IESG Informational document(s) defining the location identification use case, architecture and the requirements for HIAPS

July 2014 Submit to IESG Informational document analysing possible solutions for HIAPS

Jan 2015 Submit to IESG Standards Track document specifying the host location identification protocol for address sharing/tunneling scenarios.

March 2015 Recharter or close down.

RAI

Routing

scale

  • Withdrawn

Security

trans (approved)

  • Long name: Transparency
  • Description: Placeholder
  • The responsible Area Director (AD): Stephen Farrell
  • BoF Chairs (or the ADs as placeholders): TBD
  • Number of people expected to attend: 50
  • Length of session (1, 1.5, 2, or 2.5 hours): 1
  • Conflicts to avoid (whole Areas and/or WGs): saag, dane, wpkops, dnse, websec, tls
  • Does it require WebEX? If so, why? no
  • Does it require Meetecho? If so, why? no

This is a placeholder, as WG chartering has started https://datatracker.ietf.org/doc/charter-ietf-trans/

Transport

taps (approved)

  • Long name and abbreviation: Transport Services (taps)
  • Status: non-WG Forming
  • Description, including whether the BoF is intended to form a WG or not: Conjointly, transport protocols such as

SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For an application programmer, using protocols other than TCP or UDP is hard: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost. It is the intention to identify the services provided by existing IETF transport

protocols and congestion control mechanisms as well as network requirements of common APIs that applications use to communicate. By finding a mapping between these two lists, the a later WG will define services that a transport API should offer. Then, it specify 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.

  • The responsible Area Director (AD): Spencer Dawkins, Martin Stiemerling
  • BoF Chairs (or the ADs as placeholders): Murray Kucherawy <superuser@gmail.com> and Michael Welzl

<michawe@ifi.uio.no>

  • Number of people expected to attend: 80
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5
  • Conflicts to avoid (whole Areas and/or WGs): Level 1: All Transport Area WGs and transport BOFs; irtf iccrg,

appsawg, mif. Level 2: httpbis, hybi

tsvwg-transport-services]


VNFPool (approved)

  • Long name and abbreviation: Virtualized Network Function Pool (VNFPool)
  • Status: WG Forming
  • Description:

A Virtualized Network Function (VNF) provides network function (e.g., packet filtering at firewalls, load balancing, etc) and is typically implemented as software instance running on commodity hardware server via 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 server, 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 a 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. For a single VNF, it typically would not have built-in reliability mechanisms on its host (i.e., a commodity hardware server). Instead, there are more factors or risk such as software failure, server overload, and instance migration that may lead to VNF failures.

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. For example, when a "live" VNF pool member goes out of service, how do adjacent entities learn

which pool member will replace it? How do VNFs learn the state of adjacent VNFs to support reliability mechanisms like load sharing and switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances and other members of its pool? Ideally, the reliability of a VNF set means that the services provided by such a VNF set will continue throughout an interruption and the outages of one or more VNFs will not be visible to the users of the VNF set. In the current charter, the WG focuses the work around several mechanisms supporting the reliability of a VNF set: redundancy across a VNF set and stateful failover among pool members.

The overall problem space can be further broken to include the following items: 1) Signaling within and between VNF pools for transition (e.g. state change, scaling, moving) notification, backup advertisement; 2) Identification and evaluation of state sharing mechanisms, including distributed shared memory, gossip protocols, pfsync, and state check pointing; 3) Exchange of reliability related information between a VNF set and the underlying network (e.g. interfacing with ALTO, I2RS); 4) Identify and analyze reliable transport characteristics for control plane traffic; 5) Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model;

The initial work will include a problem statement, VNF pooling architecture, use cases and requirements analysis, and an evaluation of existing technologies against the architecture and requirements. It is our expectation that the WG will be able to rely heavily on existing IETF technologies but that gaps will be found around problems like state transfer and trust/security, which will need to be addressed. Particularly, the WG will work closely with SFC WG to develop mechanisms complementary to SFC approaches, based on identified reliability requirements.

This BoF is intended to form a WG.

  • The responsible Area Director (AD): Martin Stiemerling, Spencer Dawkins
  • Number of people expected to attend: 150
  • Length of session: 2 hours
  • Conflicts to avoid (Whole area and/or WGs): All Transport Area WGs and Transport BoFs?; SFC WG
  • Does it require WebEX?: No
  • Does it require Meetecho?: No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.:

Mailing List: https://www.ietf.org/mailman/listinfo/vnfpool

Draft Charter: https://www.ietf.org/mail-archive/web/vnfpool/current/msg00161.html

Internet-Drafts:

Problem Statement: https://tools.ietf.org/html/draft-zong-vnfpool-problem-statement

Use Cases: https://tools.ietf.org/html/draft-xia-vsnpool-management-use-case

Applicability of RSerPool: https://tools.ietf.org/html/draft-dreibholz-vnfpool-rserpool-applic

TRAM (approved)

  • Long name and abbreviation: TURN Revised and Modernized (TRAM)
  • Description, including whether the BoF is intended to form a WG or not:

Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. Until recently the protocol had only a rather limited deployment. This is primarily because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245). This inherent dependency on ICE combined with the fact that ICE itself was slow to achieve widespread adoption because other alternative mechanisms were historically used by the VoIP industry were the causes of the initial lack of interest. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, which is a set of technologies developed at the IETF and W3C aiming to enable Real Time Communication on the Web.

Because of the ubiquity of the Web and of the new opportunities created by the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by the recent work updating the ICE framework, as well as standardizing the URIs used to access a STUN [RFC7064] or TURN [RFC7065] server.

The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN, including the definition of new transport, authentication mechanisms, and extensions, that make STUN and TURN more suitable for the WebRTC environment. The Working Group will closely coordinate with the appropriate Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.

TCMTF (approved)

  • Long name and abbreviation: Tunneling Compressed Multiplexed Traffic Flows (TCMTF)
  • Status: WG Forming, 2nd attempt (1st was IETF-87 in Berlin)
  • Description:

RFC4170 (TCRTP) defines a method for grouping packets when a number of UDP/RTP VoIP flows share a common path, considering three different layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP and reduces the amount of packets per second at the same time. However, in the last years, emerging real-time services which use bare UDP instead of UDP/RTP have become popular. Due to the need of interactivity, many of these services use small packets (some tens of bytes). Some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets in sensor networks). In addition, a significant effort has been devoted to the deployment of new header compression methods with improved robustness (ROHC).

So there is a need of replacing RFC4170 with an extended solution able to optimize these new flows, also using improved compression methods. The same structure of three layers (header compression, multiplexing and tunneling) will be considered.

New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified into:

  • Multidomain, the TCMT-TF tunnel goes all the way from one network edge to another, and can therefore cross several domains.
  • Single Domain, TCM-TF is only activated inside an ISP, from the edge to border inside the network operator.
  • Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows.
  • Mixed Scenarios, any combination of the previous ones.

The BOF will discuss the proposed charter, with the aim of the creation of a Working Group 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.

  • The responsible Area Director (AD): Martin Stiemerling, Spencer Dawkins
  • BoF Chairs (or the ADs as placeholders): Brian Trammell (trammell@tik.ee.ethz.ch) and Mirja Kuehlewind (mirja.kuehlewind@ikr.uni-stuttgart.de).
  • Number of people expected to attend: 80
  • Length of session: 1 hour
  • Conflicts to avoid (Whole area and/or WGs): All TSV WGs, TSVAREA, 6lowpan, avtcore, avtext, rtcweb, mmusic, l2vpn, l3vpn, softwire
  • Does it require WebEX?: No
  • Does it require Meetecho?: Yes, will have a number of remote participants
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.:

Mailing List: https://www.ietf.org/mailman/listinfo/tcmtf

Draft charter: ​http://www.ietf.org/mail-archive/web/tcmtf/current/msg00493.html

Relevant I-Ds: ​https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/