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

Timeframe IETF 101 (London)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, 2018-02-02. 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 teleconference, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before 2018-02-16.

Applications and Real-Time

General

IETF Administrative Support Activity 2.0 (IASA20) - APPROVED FOR IETF 101

Description:

The purpose of this non-WG-forming BOF is to continue discussions from IETF 98, 99, and 100 and the iasa20@ietf.org mailing list regarding refactoring the IETF Administrative Support Activity (IASA). There is currently legal work underway to analyze the range of options in which the community expressed interest at IETF 100. That analysis should be available for community discussion well in advance of IETF 101, so this session will provide an opportunity for high-bandwidth exchange about that.

The responsible Area Director (AD): Alissa Cooper
BoF Chairs: Jon Peterson
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): mtgvenue, all of sec area, stir, modern, tram, sipbrandy
Mailing List: ​https://www.ietf.org/mailman/listinfo/iasa20
Draft charter: n.a.
Relevant drafts:

BCP 101 is the key document that already exists in this space and that may be modified. Entirely new policies or documents may be required in the future depending on the outcome of the discussions.

Internet

IP Issues and Associated Gaps in Fifth Generation Networks (atick) - NOT APPROVED FOR IETF 101

-- Introduction to problem space – new network concepts require new approaches (Chairs)

-- Issues with and specifics of current tunneling approaches as e.g. 3GPP GTP (Alex)

-- Proposed approach in terms of basic framework for flexible path optimisation based on an extensible ID-Loc split protocol, e.g. ILNP (Saleem)

-- Essential features to be addressed in future steps (Arash) -- Proposed charter and milestones (chairs) -- Q&A -- Discussion

  • Full Description of BOF

-- Within future converged (wireless/wireline) communication systems based on IPv6 which attempt to provide revolutionary new network concepts (e.g. slicing) traditional approaches as Tunneling is still foreseen. Such protocols may create too much overhead and hide important information required for service-specific handling of data packet flows. Not only may the tunnel overhead exceed the payload by orders of magnitude (e.g. for some IoT messages) and result in MTU size issues and packet fragmentation but also create signaling related to tunnel management such as establishment, maintenance, and tear down, as well as tracking the state of the tunnels in all layers (see e.g. https://tools.ietf.org/html/draft-ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-intarea-tunnels%5D>).

-- Currently discussed Id-Loc split approach (e.g. LISP, ILNP, ILA) could be advantageous here especially with regard to simplifying routing by keeping Identity stable during a session/flow, allowing integration of multiple heterogeneous access technologies, being flexible to add functionalities only on-demand, and intrinsically supporting mobility. Such approaches also well fit to work in virtual environments (SDN/NFV) and can react dynamically to changes of locations of processing resources (e.g. for virtual machines executing VNFs).

-- Most Id-Loc split solutions need mapping server to look up efficiently for changes in locators of Identities as e.g. provided by DNS. Scalability and performance of such mapping systems will be in scope of future work.

-- Existing Id-Loc split approaches require extensions to allow for optimization of the routing path which could be derived from the mapping records if properly constructed and distributed.

-- As a first step, atick will address an analysis of the features the alternative protocol has to provide (e.g. what currently is built-in in GTP).

-- Specification of the complete protocol enhancements to support e.g. charging and policy enforcement, but also interoperability and migration from existing network structures will be in scope of future work items. Also the ultimate evaluation of a comparison to GTP in terms of performance and effort etc. can be reliably achieved only once the alternative protocol framework is fully specified.

-- Main scope of this BoF is to agree on a proper sized problem space and start on researching the solution space.

  • CONFLICTS you wish to avoid, please be as specific as possible: INTarea, dmm, lisp, 6man, nvo3, sfc
  • Expected Attendance (figures from the previous IETF meeting are included in the message that is sent when scheduling opens):100
  • Special requests:none
  • Number of sessions:1
  • Length of sessions: 1 hour

Identifier Locator Addressing (ILA) - APPROVED FOR IETF 101

Description:

ILA is a protocol to implement transparent network overlays without encapsulation. It addresses the need for network overlays in virtualization and mobility that are efficient, lightweight, performant, scalable, secure, provide seamless mobility, leverage and encourage use of IPv6, provide strong privacy, are interoperable with existing infrastructure, applicable to a variety of use cases, and have simplified control and management. While many solutions have been proposed, none seem to meet all these requirements.

ILA is a type of identifier/locator split that partitions an IPv6 address into identity and location components. Unlike previously defined identifier-locator protocols (e.g. 8+8, ILNP), ILA is wholly contained within the network layer. It is not required to be used end to end and requires no changes to transport layer protocols or applications. ILA modifies destination addresses in flight, however, unlike in NAT, any modification is reversed before delivery. Since ILA does not use encapsulation, issues with in-network tunneling-- such as MTU and fragmentation, ECN and diffserv propagation, zero UDPv6 checksum handling in UDP encapsulations-- are not relevant.

Identifier Locator Addressing use cases include mobile networks, datacenter virtualization, and network virtualization. A recent trend in the industry is to build converged networks containing all three of these to provide low latency and high availability. A single network overlay solution that works across multiple use cases is appealing.

There are two aspects to ILA: a data plane and control plane. The data plane includes the ILA address transformation mechanism and ancillary protocol support. The control plane’s main focus is a mapping system that maps identifier to locators. Major problems to be solved in a mapping system include 1) scaling to support billions of entries 2) securing privacy sensitive data about users. A task in this effort will be to evaluate the use of key-value store databases in a mapping system.

Scope of this BoF is to identify the problem and get direction on the proposed solution.

Responsible AD: Suresh Krishnan
BoF Chairs: TBD
Number of people expected to attend: 50
Length of session: 1 hour
Conflicts to avoid (whole Areas and/or WGs): INTarea, dmm, lisp, 6man, nvo3, sfc, idr
Draft charter: https://mailarchive.ietf.org/arch/msg/ila/zteb1NSpqBO22zwyQGjK6K4dYos
Mailing List: https://www.ietf.org/mailman/listinfo/ila
Agenda:

  • Problem Statement & Motivation
  • Supporting Drafts & Technical Solutions
  • Discussion
  • Wrap-up & Chair Questions

Relevant drafts:

Operations and Management

Common Operations and Management on network Slices (COMS) - APPROVED FOR IETF 101

Description:

A network slice is a set of infrastructure resources and service functions that has attributes specifically designed to meet the needs of an industry vertical or a service. Network slices may be instantiated in a single domain or across multiple domains, and they may use heterogeneous technologies. The goal of this group is to produce and promote a technology-independent and resource-centric management plane for network slices.

COMS will describe an overall architecture for network slicing, work on information model which further guide the design of service delivery interface (SDI) and customer service interface (CSI). COMS will also specify network slicing OAM, as well as management requirements and functionalities data plane entities as needed to enable the operation of network slices. However, COMS will not attempt to replicate existing device models and data plane technologies.

Status: Non-WG Forming
Responsible AD: Benoit Claise
BoF Chairs: Adrian Farrel, Gonzalo Camarillo netslicing-chairs@ietf.org
Number of people expected to attend: 150
Length of session: 2 hours
Conflicts to avoid (whole Areas and/or WGs): teas, detnet, sfc, nov3, opsarea
Mailing List: https://www.ietf.org/mailman/listinfo/netslices
Draft charter: https://mailarchive.ietf.org/arch/msg/netslices/-UeKDF3rPsBOsya1m6ytINKi4v4
Relevant drafts:

Agenda:

  • Admin [5 mins]
  • Problem Statement & Motivation [30 mins]
  • Supporting Drafts & Technical Solutions [20 mins]
  • Charter Discussion [30 mins]
  • Wrap-up & Chair Questions [35 mins]

YANG data model is one of the key existing practice in terms of modeling language in this problem space. New practice is required in the context of network slice operation and management. This may also lead to new protocols and modifications of existing protocols for the purpose of slice-level OAM.

Routing

Routing In Fat Trees (rift) - APPROVED AS A WG 2018-02-08

  • Description: WG in Formation (placeholder)
  • Responsible Area Director (AD): Alvaro Retana
  • Proposed WG Chairs: Jeffrey Zhang, Jeff Tantsura
  • Number of people expected to attend: 50
  • Length of session: 2 hours
  • Conflicts to avoid: babel, bier, idr, isis, ospf, lsr, rtgwg, rtgarea, bess, nvo3
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

https://datatracker.ietf.org/wg/rift/about/

Link State Vector Routing (lsvr) - APPROVED FOR IETF 101

  • Description: WG in Formation (placeholder)
  • Responsible Area Director (AD): Alvaro Retana
  • Proposed WG Chairs: Gunter Van de Velde, Victor Kuarsingh
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid: babel, bier, idr, isis, ospf, lsr, rtgwg, rtgarea, sidrops, opsec, spring, bess, grow, nvo3
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

https://datatracker.ietf.org/wg/lsvr/about/

Security

EAP Method Update (emu) - APPROVED FOR IETF 101

  • Description: Placeholder: looking to form a WG before London based on SecDispatch? feedback
  • The responsible Area Director (AD): Kathleen Moriarty
  • BoF Chairs: TBD
  • Number of people expected to attend: 30
  • Length of session: 1.5 hours - need to confirm
  • Conflicts to avoid: Will update
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc. https://datatracker.ietf.org/wg/emu/about/[[BR]]

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Trusted Execution Environment Provisioning (teep) - APPROVED FOR IETF 101

  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs: Dave Thaler and Nancy Cam-Winget)
  • Number of people expected to attend: 100
  • Length of session 2 hours
  • Conflicts to avoid: First Priority: suit ace core mile oauth, Second Priority: t2trg lwig saag tls opsawg anima, Third Priority: v6ops 6man intarea
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Security Dispatch (SECDISPATCH) - APPROVED FOR IETF 101

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Messaging Layer Security (mls) - APPROVED FOR IETF 101

  • Long name and abbreviation: Messaging Layer Security (MLS)
  • Description, including whether the BoF is intended to form a WG or not
    • The intent of this BoF is to form a WG
    • Several Internet applications have a need for a group key-establishment and message-protection protocol with the following properties:
      • Asynchronicity - Keys can be established without any two participants being online at the same time
      • Forward secrecy - Full compromise of a node at a point in time does not reveal past group keys
      • Post-compromise security - Full compromise of a node at a point in time does not reveal future group keys
      • Membership Authentication - Each participant can verify the set of members in the group
      • Message Authentication - Each message has an authenticated sender
      • Sub-linear scaling in the size of the group
    • Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard security protocol so that applications can share code, and so that there can be shared shared validation of the protocol (as there has been with TLS 1.3). It is not a goal of this group to enable interoperability between messaging applications.
  • In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary protocols deployed within apps:
  • The responsible Area Director (AD): Kathleen Moriarty / Ben Kaduk
  • BoF Chairs: TBD
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid: TLS, DISPATCH, SECDISPATCH, SAAG, ACME, QUIC, PERC
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Application Transport LAyer Security - NOT APPROVED FOR IETF 101

  • Long name and abbreviation: Application Transport LAyer Security (ATLAS)
  • Description, including whether the BoF is intended to form a WG or not
    • The intent of this BoF is to form a WG or to use an existing working group
    • There is a need to offer application layer security where communication establishment is followed by an exchange of an arbitrary number of application data. This application layer security mechanism requires authentication of the endpoints, and a modern a key exchange protocol. The result of a positive handshake will lead to the establishment of keying material and negotiated algorithms for confidentiality, integrity and replay protection of application data. There is precedence for embedding TLS in "applications" and this group will develop specifications that define embeddings for different application protocols, such as CoAP, and HTTP.
  • The responsible Area Director (AD): Kathleen Moriarty / Ben Kaduk / Eric Rescorla
  • BoF Chairs: TBD
  • Number of people expected to attend: 70
  • Length of session: 2 hours
  • Conflicts to avoid: TLS, OAUTH, ACE, HTTPBIS, QUIC
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Cleartext JSON Object Signing and Encryption (jose)

  • Withdrawn

Transport

IAB Sessions

HotRFC Lightning Talks

Title Speaker
'Lossless Data Center Networks ' Authors: P. Congdon
'QUIC over Satellite ' Authors: J. Border, C. Su
'' In-band signaling and its applications'' Authors: L. Han, Y. Qu, T. Eckert, P. Esnault, R. Li
'hotRFC: Network co-existence and coordination in future wireless environments ' Authors: L. Feeney, V. Fodor
'Who is needing a (sec) Clock synchronization on the Internet? ' Authors: J. Alvarez-Hamelin
'How can we use ICN, VPP, or SDN to build scalable video conferences?' Authors: C. Jennings
'' Web Packaging'' Authors: J. Yasskin
'Requesting Comments: Enabling Readers to Annotate RFCs ' Authors: Y. Sheffer
'A role for Machine Learning and AI in networking' Authors: M. Montpetit
'The case for passive measurement in QUIC ' Authors: A. Ferrieux, I. Hamchaoui
'Practical three key cryptography' Authors: P. Hallam-Baker
'PATIENT: Protect v Attacks Tunneling In Encrypted Network Traffic' Authors: B. Witten
'Opportunistic DNS' Authors: D. Gillmor
'Nōtifs: User-managed Notifications' Authors: J. Fenton
'Which is the evolution of the BGP?' Authors: J. Alvarez-Hamelin
'Digital Tokens: A candidate for standardization' Authors: B. Rajendran
''Matrix: a new(ish) protocol for decentralised secure communication'' Authors: M. Hodgson