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

Birds of a Feather Meetings (IETF Pre-WG Efforts)

This page provides one common place that lists "possible IETF pre-WG efforts", known as Birds of a Feather ("BoF") meetings. Anybody who proposes a BoF is strongly encouraged to register the BoF effort here at such time as appropriate; e.g., during steps 1 and 2 in RFC 5434. Also see https://www.ietf.org/wg/bof-procedures.html.

The IAB will also attempt to provide BoF Shepherds as described in their document on the subject only on request from the IESG. If you feel that your BoF would benefit from an IAB BoF Shepherd, please discuss this with your Area Director.

To allow the Secretariat to schedule a BoF slot if it is approved, each entry MUST include the following items:

  • Long name and abbreviation
  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs (or the ADs as placeholders)
  • Number of people expected to attend
  • Length of session (1, 1.5, 2, or 2.5 hours)
  • Conflicts to avoid (whole Areas and/or WGs)
  • 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.

Template for BOF Entry - Please do not edit the BoF Example Page directly.

Timeframe IETF 103 (Bangkok)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, 2018-09-21. 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-09-28.

Applications and Real-Time

NONE

General

WGs Using GitHub (Approved for IETF 103)

  • Long name: WGs Using GitHub
  • Abbreviation: WUGH
  • Description:

At IETF 98 there was a non-WG-forming WUGH BoF organized to discuss IETF-wide documentation about how to use GitHub effectively in WG processes. At that time, it seemed premature to try to achieve consensus around common practices for using GitHub within IETF WGs. Since then, more WGs and document authors have started using GitHub to facilitate IETF work in different ways. Some WGs and participants are interested interested in having their working groups use GitHub, but they are unfamiliar with how to get started or they are unclear about which conventions to follow.

This BOF is proposed for IETF 103 to foster community discussion about establishing administrative processes and usage conventions to allow WGs and authors to get started using GitHub for IETF work in a more uniform way. The point of the proposed discussion is to explore whether there might be rough consensus in the community about processes and conventions to make it easier for more people to start using GitHub for IETF work. It is explicitly not to change how existing WGs are already using GitHub.

The goal of the BOF is to determine whether there is enough support in the community to warrant more detailed discussions with the IETF Tools Team and the IETF Secretariat about functional requirements and process details to support integrating GitHub use into WG work. Some proposed conventions are described in draft-cooper-wugh-github-wg-configuration.

Removing offensive terminology in RFCs (Not Approved for IETF 103)

  • Name: Removing offensive terminology in RFCs (ROT-RFC)
  • Description: This BOF is an opportunity to constructively build on hrpc@ and ietf@ mailing list discussion about the use of offensive terminology in RFCs such as "master/slave", "white/blacklist", "man-in-the-middle". While the debate continues on the mailing list, key voices in the debate would like to move the discussion forward by hearing from the community its reactions to concrete proposals for ensuring that offensive terminology *could be* removed from *future* technical documentation and protocol specifications to increase understanding by readers, implying no loss of meaning or rigor. The objectives are to 1) propose a general area informational draft, 2) constructively discuss the proposed draft, 3) define clear next steps, and roles, to progress work on the proposed draft.
  • Status: not WG Forming
  • Responsible AD: Alissa Cooper
  • BoF proponents and chairs: Mallory Knodel <mallory@article19.org>, Niels ten Oever <lists@digitaldissidents.org>
  • Number of people expected to attend: 25
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): hrpc

Internet

NONE

Operations and Management

NONE

Routing

NONE

Security

Handling IPsec configurations in large scale SD-WAN deployment with constrained resources (Not Approved for IETF 103)

Title: Handling IPsec configurations in large scale SD-WAN deployment with constrained resources - sdwan-sec
Description: This BOF is for discussing the risks associated with various simplification of IPsec protocol by utilizing SD-WAN central controller. The traditional IPsec scheme requires that in a fully meshed network, each device has to manage n2 key exchanges and (n-1) keys. As an example, in a 1,000-node network, 1,000,000 key exchanges are required to authenticate the devices, and each node is responsible for maintaining and managing 999 keys. In addition, when an edge node has multiple tenants attached, the edge node has to establish multiple tunnels for tenants. For example, for a network with N nodes, a node A has 5 tenants app attached to it, then the node A has to maintain 5*(N-1) number of keys if each tenant needs to communicate with all other nodes. Therefore, simplification facilitated by SD-WAN controller is needed for large scale deployment. However, it is necessary identify the associated risks, so that the industry can make the informed decision on risks that can be tolerated for their specific environment.
Status: not WG Forming
Responsible AD: Benjamin Kaduk or/and Eric Rescorla
BoF proponents: Paul Wouters, Yoav Nir, Frank Xia and Linda Dunbar
BoF chairs: TBD
Number of people expected to attend: 100
Length of session 1.5 hours):
Conflicts to avoid (whole Areas and/or WGs): ipsecme, i2nsf, idr, saag, dots, rtgwg, spring

Problem statement:
Because of the property of providing secure communication over any networks including Public Internet, IPsec is the protocol used by SD-WAN, which, according to ONUG (Open Network User Group), is to aggregate multiple connections between any two points by utilizing IPsec overlay paths.  
Some SDWAN deployments require many (thousands) of nodes, some of which are resource constrained.  Many of the SD-WAN edge nodes need to communicate with many sets of peers and require isolating communications for peers belonging to different tenants. When setting up IPsec connections, especially to many sets of peers, many of those nodes do not have the resources to maintain large number of IKEv2 and IPsec Security Associations lifecycle management. 
Those SD-WAN deployment have some special characteristics that can be utilized to simplify the processing, such as:
-	All those nodes are coordinated by Controller(s) (a.k.a. SD-WAN controller)
-	There is Secure Management Channel between the SD-WAN controller and the SD-WAN nodes for the purpose of authentication, provision, monitoring, etc. 

While the SD-WAN Controller might have the resources to assist, it is undesirable that the SD-WAN Controller assists in a way that gives it access to the private IPsec session keys used for the IPsec connections between all nodes.

Currently, there are three proposals going around:
1.	Have the SD-WAN controller provision security policy (SPD and PAD in RFC4301 language) and maybe also credentials, and have the endpoints use IKEv2 to derive the IPsec session keys and set up tunnels.
2.	Have the SDN controller provision IPsec session keys to the IPsec endpoints.
3.	Keep the DH exchange (through the SD-WAN controller) but eliminate the rest of IKEv2 so the controller doesn’t get the IPsec session keys

Details of those proposals are described in detail in https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ and https://datatracker.ietf.org/doc/draft-carrel-ipsecme-controller-ike/. 
Note: those are only possible solutions, but that we are not yet decided on that as the solution. 

The draft-i2nsf-ipsec-flow-protection focuses on the IPsec data models between Controller and endpoints, under the assumption of having a secure management channel between the Controller and the endpoints, covering two scenarios: 1) Using Controller to pass the needed IPsec configuration data to endpoints; 2) for some special environment, such as secure environment (e.g. in one physically isolated data center) or some resource constrained IoT deployment that can tolerance some risks, using Controller to assist the IPsec key computation and pass the SA attributes together with its IPsec session key to the pair-wise Nodes via a secure management channel.  
 
draft-carrel-ipsecme-controller-ike proposes a key exchange method managed by a SDN controller (e.g., a management station) to assists the private pair-wise IPsec SAs creation without IKEv2 or any other direct peer-to-peer session establishment messages. 
The BOF session is to identify the problems,  the constraints for large scale SD-WAN deployment, and the associated risks for a special type of IPsec solution that fits within the common constrains of large number low power nodes managed by controller(s) via secure management channel. 

BOF should discuss questions like: 
-	Is there real security difference between #2 and #3?  What are the risks of sharing the IPsec session keys with the controller? Are there any circumstances that can tolerate the security risks associated with those approaches?  
-	Are there really devices that are unable to perform full IKEv2, but can perform TLS for a secure management channel to the controller?  
-	etc

The output of the BOF is to document those risks in an IETF draft. 
  • Solutions

Remote Attestation Procedures (Approved for IETF 103)

  • Name: Remote ATtestation ProcedureS (RATS)
  • Description:

The goal of this BoF is to start a new working group about Remote Attestation Procedures (RATS). RATS require secure and resilient network protocols to convey Attestation Evidence in order to establish trust in the trustworthiness of a communication partner (attester). Attestation Evidence is processed by verifiers - entities able to appraise the Attestation Evidence according to compliance policies or reference (nominal) values.

Traditional uses of asymmetric cryptography introduce proof-of-possession techniques that prove to the verifier that the authenticator possesses the private key. Authentication presumes some protection: e.g., that there is not an illicit copy of the private key available to anyone other than the intended subject. More generally, authentication of a system is not useful if it can readily be taken over by an attacker. Proof-of-possession techniques do not describe mechanisms for ascertaining the protection of the system and its integrity, and for conveying evidence about that (“proof-of-protection” henceforth).

The details of these mechanisms vary between implementations, including what kinds of trust are being generated and what entities need to cooperate to create and verify this proof-of-protection. They, however, all need network protocols to interconnect the entities that need to work together. The RATS effort strives to provide evidence about a system's health and trustworthiness via the Internet. Instead of having a separate set of protocols for each set of mechanism, the RATS effort will define a common set of protocols that can be used interoperably over the Internet.

  • Status: WG Forming
  • Responsible AD: Benjamin Kaduk
  • BoF proponents: Henk Birkholz (henk.birkholz@sit.fraunhofer.de), Ned Smith (ned.smith@intel.com), Monty Wiseman (monty.wiseman@ge.com), Eric Voit (evoit@cisco.com)
  • BoF chairs: Nancy Cam-Winget <ncamwing@cisco.com>, Roman Danyliw <rdd@cert.org>
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): I2NSF, SACM, CBOR, CORE, ACE, TEEP ,SUIT
  • Agenda
    • Items, drafts, speakers, timing (TBD)
  • Mailing List: https://www.ietf.org/mailman/listinfo/rats
  • Draft charter:
    # (Introduction)
    
    Traditional uses of asymmetric cryptography introduce proof-of-possession 
    techniques that prove to the verifier that the authenticator possesses the
    private key. Authentication presumes some protection: e.g., that there is not an
    illicit copy of the private key available to anyone other than the intended
    subject. More generally, authentication of a system is not useful if it can
    readily be taken over by an attacker. Proof-of-possession techniques do not
    describe mechanisms for ascertaining the protection of the system and its
    integrity, and for conveying evidence about that (“proof-of-protection”
    henceforth).
    
    The details of these mechanisms vary between implementations, including what
    kinds of trust are being generated and what entities need to cooperate to create
    and verify this proof-of-protection. They, however, all need network protocols
    to interconnect the entities that need to work together. The RATS effort
    strives to provide evidence about a system's health and trustworthiness via the
    Internet. Instead of having a separate set of protocols for each set of
    mechanism, the RATS effort will define a common set of protocols that can
    be used interoperably over the Internet.
    
    # (Background)
    
    Attestation provides a mechanism where an *Attester* supplies a trustworthy
    assertion of a system’s characteristics such as its hardware identity, boot time
    firmware identity, compliance status or run-time status to a Verifier.
    
    This allows the *Verifier* (or other parties relying on the *Verifier*) to
    consider a system's trust properties and to better manage risk. Trust properties
    are defined by Reference Values that relate to a security policy, privacy
    policy, or other critical infrastructure interest.
    
    In essence, a trusted system is one that operates as expected, according to its
    design and operational policies, doing what is required - and not doing other
    things.
    Correspondingly, Remote Attestation Procedures enable dynamic periodic
    appraisals of a system to determine, convincingly, its trustworthiness status.
    
    Attestation has two fundamental ways of operating, Remote Attestation and Local
    Attestation.
    
    * *Remote Attestation* is where the Attester conveys Attestation Evidence to a
      Verifier that compares it with Reference Values (in order for it to be
      considered, for example, healthy).
      A Relying Party (or the Verifier acting as a Relying Party) appraises the
      verification result to assess device trustworthiness and to manage security
      risk.
      The Verifier is typically physically remote from the Attester and the
      conveyance method often involves a network protocol.
    * *Local Attestation* is where trustworthiness is determined locally on the
      device. For example, access to application configuration files may be
      predicated on the correct operating system having been booted.
    
    Local Attestation may not rely on an external conveyance method to determine
    trustworthiness. Nevertheless, a remote relying party may be responsible for
    supplying attestation policies that are applied locally.
    
    In scope are two types of attestation: Explicit Attestation and Implicit
    Attestation:
    
    * *Explicit Attestation* is where the Attestation Claims/Evidence is conveyed
      authentically (e.g. signed) by the Attester to the Verifier where a
      root-of-trust enumerates the Attestation Claims/Evidence associated with an
      execution environment.
    * *Implicit Attestation* is where the Attester conveys evidence of the
      availability of an authenticating credential that allows the Verifier to infer
      the Attestation Claims/Evidence associated with an execution environment.
    
    The Verifier knows that the availability of the authenticating credential is
    bound to certain Attestation Claims/Evidence. Inferred knowledge may further be
    conveyed as Attestation Evidence by a Trusted Third Party via a credential
    certificate or other out-of-band method.
    
    Remote Attestation Procedures have multiple facets, including but not limited
    to:
    
    * A cryptographic identity that is bound to an execution environment consisting
      of some combination of hardware, firmware, OS, applications and other
      components.
    * A conveyance method to present Attestation Evidence about an execution
      environment in a standard format.
    * A method to protect Attestation Evidence during storage and conveyance, as
      well as to prove its integrity and freshness.
    
    Attestation is scoped from small, resource-constrained devices to less
    constrained devices such as servers, rackscale systems, or services in a cloud.
    Both types of attestation may be used by any system, though it is assumed likely
    that more constrained systems that are a relying party are less likely to also
    take on the role of a Verifier (and therefore are "off-loading the burden of
    appraisal").
    Use of both Explicit and Implicit Attestation mechanisms together may also be
    done.
    
    Generally speaking, attestation is applied before data is exchanged to avoid
    disclosure to insufficiently trusted environments.
    
    # (Terminology for this Charter)
    
    The terminology used for Attestation in various industry groups and SDOs is not
    always consistent. So that this charter can have a well-defined meaning, it is
    necessary to supply some definitions.
    (This set of terms will then be refined in the terminology document discussed
    below, with the expectation that the refined terms are consistent with the brief
    definitions here.)
    
    * Assertion: Defined by the ITU in X.1252 as "a statement made by an entity
      without accompanying evidence of its validity".
    * Attestation Claim: Information about some characteristics or attributes that
      affect device trustworthiness.
    * Attestation Evidence: Proof for one or more Attestation Claims
      (characteristics, attributes, ...) that affect device trustworthiness, such as
      its hardware identity, firmware, software, configuration or composition,
      compliance status and runtime state.
      Attestation Evidence may be consolidated through the use of cryptographic hash
      and key generation algorithms.
      Attestation Evidence veracity may be augmented by Claimant signatures over
      portions of the Attestation Evidence.
      Note that Claims are non-proven assertions as opposed to Attestation Evidence.
    * Attester: An endpoint that has a root-of-trust for reporting (RTR) and
      implements a conveyance protocol, authenticates using an Attestation
      credential, collects Attestation Evidence about itself and presents it to a
      consumer of evidence (e.g. a Relying Party or a Verifier).
    * Claimant: An entity that make an assertion to a certain property regarding the
      trustworthiness of an entity. This may be the binding of an Attester to an RTR
      or any other kind of property.
    * Conveyance: The transfer of Attestation Evidence between Attester and
      Verifier, facilitated by network protocols that are reliable, secure and can
      prove the freshness of Evidence, if required.
    * Reference Values: Information that can be matched with collected Attestation
      Evidence to determine if the device's operational state complies with an
      intended/expected operational state (e.g. Reference Integrity Measurements).
    * Relying party: An entity that consumes and assesses Verifier results for the
      purpose of improved risk management, operational efficiency, security, privacy
      (natural or legal person) or safety. The Verifier and Relying Party functions
      may be tightly integrated.
    * Remote Attestation: The procedure of supplying Attestation Evidence to a
      communication partner via an Attester using network protocols for Conveyance.
    * Root of Trust: The base entity for a chain of trusts that builds up trust in
      an overall system.
    * Verifier: An endpoint that has a root-of-trust for verification and implements
      conveyance protocol, verifies Attestation credentials and may authenticate
      using Attestation Evidence or other credentials, appraises Attestation
      Evidence against Reference Values or policies and makes verification results
      available to Relying Parties.
    
    # (Problem Statement)
    
    The problem statement addressed by the working group can be segregated into four
    inter-connected problems:
    
    (1) Establishing a sufficient level of confidence that a communication partner
    is a trustworthy endpoint. This is a fundamental challenge.
    Currently, there are no agreed upon standards that define a minimal set of
    Reference Values and Attestation Evidence that distinguishes a trusted execution
    environment over one that isn't. There isn't agreement on how to convey it
    appropriately, how to appraise evidence and how to present the appraisal results
    in an interoperable fashion.
    In essence, there is increasing vendor demand for an overall communication,
    trust and assurance model to establish trust in potentially lying endpoints that
    is not currently met by other standards.
    
    (2) Current and emerging protocols oftentimes do not contain interfaces for
    trust establishment in the communication endpoints.
    Some protocols may contain extensibility features that could serve this purpose,
    but have not yet been defined.
    
    (3) There is no central alignment process or place for resolving issues related
    to the application of remote attestation techniques to existing and emerging
    IETF protocols, e.g. Initial Implicit Attestation via TLS Token Binding,
    complementary Attestation in OSCORE, YANG modules for conveying Explicit
    Attestation Evidence about composite devices (e.g.
    I-D.birkholz-yang-basic-remote-attestation), the Attestation procedures for
    virtualized network security functions in I2NSF
    (I-D.pastor-i2nsf-nsf-remote-attestation), or Time-Based Uni-Directional
    Attestation procedures (e.g. I-D.birkholz-i2nsf-tuda).
    
    (4) The lack of generic models and commonly understood terminology that would
    allow for semantic interoperability and a common understanding of
    trustworthiness inhibits the establishment of trust between endpoints of
    heterogeneous realms and limits application-specific protocols and solutions to
    specifically scoped domains.
    This includes the lack of:
    * a taxonomy of information elements that can be used as Attestation Evidence,
      e.g. EAT/CWT claims,
    * a way to consolidate and agree upon what a claim is and means, as well as
      allocate tokens under the token name space in an orderly manner, and
    * leveraging or incorporating existing semantics and namespaces, e.g. YANG
      identifiers.
    
    ## (Program of Work)
    
    This working group will consolidate the various methods for creating and
    conveying Attestation Evidence using network protocols created in the IETF, to
    enable semantic interoperability.
    This group will also establish and maintain close relationships to the IETF
    I2NSF WG, Global Platform, the Trusted Computing Group, the Cloud Native
    Computing Foundation, the Open Connectivity Foundation, the Alliance for
    Telecommunications Industry Solutions, and the ETSI NFV Industry Specification
    Group.
    
    The following is within this working group's scope:
    * Architectural components, such as roles, relationships, work-flows and actions
    * Data formats and protocols for Remote, Explicit, and Implicit Attestation
    * Protocols and new bindings of protocols (e.g. CoAP) to supply Attestation
      Policies to a Verifier or Relying Party
    * Terminology and the interconnected relationships of existing solutions (also
      as a basis for identifying gaps and new applications)
    * Attestation procedures for authentication that are based on the operational
      state of the Attester
    
    The following is outside this working group's scope:
    * Local Attestation and corresponding "in-box" APIs.
    * Attestation Policy Formats
    * Authentication procedure extension that do not convey Attestation Evidence.
    
    As Attestation has acquired many definitions, an early goal for this working
    group will be a document defining the terms used by attestation, coordinating
    terminology with the groups and organizations listed above.
    This provides the various standards a consistent set of terms for their
    subjects, objects and their relationships.
    
    # (Goals)
    
    ## Architectural Documents (informational):
    * (1.1) Terminology & Architecture
    * (1.2) Reference Interaction Models
    
    ##  Solution Documents (standards-track):
    * (1.3) Claim Taxonomy for Semantic Interoperability
    * (2.1) YANG Module for Explicit Attestation
    * (2.2) Explicit Attestation Extension to the I2NSF Architecture using EAT
    * (2.3) Time-Based Uni-Directional Attestation
    
    # Milestones
    * IETF 104+6weeks (2.1) mostly complete \[✔], WG consensus
    * (2.1) submitted to IESG
    * IETF 105+6weeks (1.1, 1.2) mostly complete, WG consensus
    * (1.1, 1.2) submitted to IESG
    * IETF 105+6weeks (2.2) mostly complete, WG consensus
    * (2.2) submitted to IESG
    * IETF 105+6weeks (2.3) mostly complete, WG consensus \[½✔]
    * (2.3) submitted to IESG
    * IETF 106+6weeks (1.3) mostly complete, WG consensus
    * (1.3) submitted to IESG
    

Transport

NONE

IAB Sessions

NONE

HotRFC Lightning Talks

Agenda and presentations can be found at the IETF-103 materials site.


Previous meeting BOFs

Timeframe IETF 102 (Montreal)

Timeframe IETF 101 (London)

Timeframe IETF 100 (Singapore)

Timeframe IETF 99 (Prague)

Timeframe IETF 98 (Chicago)

Timeframe IETF 97 (Seoul)

Timeframe IETF 96 (Berlin)

Timeframe IETF 95 (Buenos Aires)

Timeframe IETF 94 (Yokohama)

Timeframe IETF 93 (Prague)

Timeframe IETF 92 (Dallas)

Timeframe IETF 91 (Honolulu)

Timeframe IETF 90 (Toronto)

Timeframe IETF 89 (London)

Timeframe IETF 88 (Vancouver)

Timeframe IETF 87 (Berlin)

Timeframe IETF 86 (Orlando)

Timeframe IETF 85 (Atlanta)

Timeframe IETF 84 (Vancouver)

Timeframe IETF 83 (Paris)

Timeframe IETF 82 (Taipei)

Timeframe IETF 81 (Quebec City)

Timeframe IETF 80 (Prague)

Timeframe IETF 79 (Beijing)

Timeframe IETF 78 (Maastricht)

Timeframe IETF 77 (Anaheim)

Timeframe IETF 76 (Hiroshima)

Timeframe IETF 75 (Stockholm)

Timeframe IETF 74 (San Francisco)

Timeframe IETF 73 (Minneapolis)

Timeframe IETF 72 (Dublin)

Timeframe IETF 71 (Philadelphia)

Timeframe IETF 70 (Vancouver)

Timeframe IETF 69 (Chicago)

Timeframe IETF 68 (Prague)

Timeframe IETF 67 (San Diego)

Timeframe IETF 66 (Montreal)

Timeframe IETF 65 (Dallas)