HotRFC @ IETF-106, Singapore Sunday, Nov 17, 2019, 1800-2000 Info: https://www.ietf.org/how/meetings/106/hotrfc/ Materials: https://datatracker.ietf.org/meeting/106/session/hotrfc ===================================================================== 1. Adaptive DNS Privacy Tommy Pauly While using HTTPS to encrypt DNS is becoming more widely used to improve privacy, the policies for how and when to use this protocol aren't standardized yet. Adaptive DNS Privacy is a proposal from the client operating system perspective, aimed at creating a scalable ecosystem for encrypted DNS that works with many providers, both locally-provisioned, and on the web. It allows deployments to designate DoH servers to be used for their zones; local network providers to prove authority over certain names; and also allows clients to discover more capabilities of the server deployments. Drafts are available here: https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh ===================================================================== 2. Abstract of Deadline-aware Transport Protocol (DTP) Zhiwen Deadline-aware Transport Protocol (DTP) is a transport protocol that provides deliver-before-deadline service and has following features: * Support the block-based deadline delivery. By mapping block to QUIC stream one to one, DTP supports the timeliness and dynamic of block delivery very well. * Prefer timeliness than reliability. The deadline means the block completion time. DTP will optimize before-deadline delivery instead of reliability, which means some blocks may get dropped. * Support HTTP/3 based on its unreliable transport mechanism. DTP makes several extensions to QUIC and HTTP/3 stack. One block is mapping to one QUIC stream and one HTTP/3 stream. DTP reuses handshake, encryption and some other features of QUIC as well as adds deadline and timestamp to each stream frame. Feel free to contact me by sending email if anyone wants to talk about DTP:) My email address is liuzhw3.16@sem.tsinghua.edu.cn ===================================================================== 3. Formal languages in IETF documents Stephen McQuistin Marc Petit-Huguenin Formal and structured languages have seen slow and limited adoption in standards documents. We believe that this is to their detriment: documents often contain inconsistencies and bugs that could be detected using formal approaches. To encourage the adoption of such approaches, we must understand their social and technical limitations. We will be holding an informal side meeting about this topic, which we encourage interested people to attend, to discuss how to take work forward. ===================================================================== 4. MathMesh Phillip Hallam-Baker The mathematical mesh proposes a user-centered Public Key Infrastructure (PKI) that uses cryptography to make computers easier to use. The mesh aims to address three concerns that have proved obstacles to the use of end-to-end security in computer applications: device management, exchange of trusted credentials, and application configuration management. This proposal was discussed during the Security Dispatch (SECDISPATCH) session at IETF 105 where the community recommended bringing it to a BOF. ===================================================================== 5. MUD extension - fast response to vulnerabilities Sávyo Morais The Manufacturer Usage Description [RFC 8520] is an important tool to prevent IoT devices infection, but when a new vulnerability is discovered and its communication is over the “normal” traffic as descripted by MUD, the device needs a firmware update or a new MUD version to protect the devices. The both options can take a long time and depends of the manufacturer - and not ever this is interesting for it. This proposal creates an security authority - managed by SOCs or CSIRTs - that describes the network signature of new vulnerabilities and botnets, and the MUD Controller can use these descriptions to find the exposed devices and block unwanted traffic, preventing new infections, scans, communication with C&C (in case of botnets) and attacks like DDoS. To keep in touch, you can contact me by savyovm@gmail.com or savyo.morais@labnet.nce.ufrj.br ===================================================================== 6. The Internet beyond 2030 Richard Li The Internet is one of the most successful technical achievements of our time. However, it is reaching the limits of what it could support in the face of emerging applications such as tele-driving, tactile internet, and holographic type communications. This Request for Conversation presents a few use cases, analyzes technical gaps, and identify some requirements for IETF/IRTF to consider. In particular, the talk will stress on high-precision communications, very large volume and tiny instant communications. We are exploring the possibility of setting up a New IP Research Group within IRTF. For this purpose, we are going to have a side meeting this week. The side meeting place will be announced as soon as it is allocated. All future questions are please addressed to rli@futurewei.com for now until an official email list is set up. ===================================================================== 7. Computing First Network (CFN) Liang Geng|耿亮 Edge computing is considered one of the key enabler for future mission-critical applications. As more and more computing resources are deployed in a distributed manner across the internet, network will play a key role for edge to edge and edge to cloud coordination. It is required that routing path can be optimized for most efficient or cost-effective traffic engineering solution according to demand for preferred computing resource and capabilities. However, computing resource status is transparent to traditional network. It is unlikely for the network to be optimized according to the status of the reachable computing resources. Computing First Network is designed to tackle with this challenge, where the network is aware of the computing status of particular edge computing site. Hybrid routing using information of both network and computing can be achieved by CFN. As a result, the traffic can be steered to preferred path accordingly with joint optimization of network and computing resources. A side meeting on CFN is also scheduled on Wednesday (20th Nov). ===================================================================== 8. Localized Optimizations On Path Segment (LOOPS) Yizhou Li Carsten Bormann Path over long haul network can be partitioned into multiple path segments that some of them are using network overlay tunnels. LOOPS aims to provide local in-network loss recovery over specific segment to optimize packet delivery. We had a BoF about this at IETF 105, and there was quite a strong feedback and interest showing standardization of the work was required. We'll have a side meeting in IETF 106 to discuss more detailed encapsulation work and then to clearly outline the work to be done in LOOPS. Both transport area and tunnel encapsulation people are welcome to join us. Side meeting info: 8:00-9:45 Tuesday, Room: Orchard ===================================================================== 9. Off-the-Record (OTR) v4 Sofía Celi Cryptography is commonly used to secure private communications over the Internet, or to solve the secure messaging problem. It is commonly used to solve this problem because that is the most fundamental privacy problem that one can work on. Working on this question addresses the idea that the Internet, while at the beginning used mostly as a medium for the transfer of technical information, is now manly used as a communication tool. One of these types of communication is what is often called ”casual personal conversations”, that mimic the idea of casual non-digital world conversations. The difference between non-digital and digital conversations resides in the fact that, on the latter, privacy is diminished, as third parties can always be listening without the knowledge of the participants in it. There are some protocols that have tried to improve this situation by providing encryption and digital signatures. Often times, though, the encryption keys used are long-lived and subject to compromise; and the digital signatures are not deniable. In order to tackle this problem, the Off-The-Record messaging protocol (OTR) was created. It achieved two core properties: perfect forward secrecy and deniability. Nevertheless, OTR is a protocol that was created in 2004, and, since then, protocol properties have changed to adapt to new forms of communication, to new cryptographic primitives and properties. For this reason, a new version of the OTR protocol, OTRv4, has been created. This new version of the protocol provides end-to-end encryption, different types of deniability, and stronger notions of forward and post-compromise secrecy. It has higher security properties than other protocols, like the Signal protocol. In this short talk, we will discuss the properties of OTRv4, its privacy by design thinking and how it is necessary to have this kind of thinking. If you are interested, an RFC is been prepared for OTRv4. You can reach around it to otr-dev@lists.cypherpunks.ca or to sofia@otr.im. ===================================================================== 10. Trustworthy Multipurpose RemoteID (TM-RID) Robert Moskowitz This talk is a status update on Trustworthy Multipurpose RemoteID (TM-RID). It reflects current drafts goals for IETF106. To mitigate the risks presented by Unmanned Aircraft Systems (UAS), the US FAA and other government agencies internationally soon will require, and various bodies are drafting standards for, remote identification. All such proposals hinge on a unique ID for each UA, a method whereby this ID (along with operator contact information etc.) can be registered, and a method by which a subsequent ID assertion can be authenticated by authorized parties. For more information,see: https://datatracker.ietf.org/doc/draft-card-tmrid-uas/ Broadcast RemoteID uses Line-of-Sight (LOS) broadcast media to transmit UA Identities and flight vectors. Network RemoteID uses the Internet to map current UA locations to identities. To avoid being deceived by malicious spoofing of these critical mappings, we need strong authentication. To maintain privacy (from unauthorized eavesdroppers, not from legitimate authorities), we need strong encryption. We propose to leverage the Host Identity Tag (HIT) of HIP as a Trustworthy RemoteID. Prototyping and experimentation has commenced at the New York UAS Test Site. This project will: 1. Update HITs to allow for Hierarchical HITs (HHIT) that will accommodate a 2-tier HHIT registry structure that will faciliate management of HHITs and simplify HHIT-based lookups. 2. Use of the Internet Domain Name System (DNS) as a RemoteID registry. 3. Provide strong authentication of not only Network RemoteID but also Broadcast RemoteID messages. 4. Rapid establishment of authenticated and encrypted communications with any observed UA that is suitably equipped. Join us at the Hackathon Demo Monday evening and the TM-RID BOF Tuesday at 10am in VIP A. Read our drafts: https://datatracker.ietf.org/doc/draft-card-tmrid-uas/ https://datatracker.ietf.org/doc/draft-wiethuechter-tmrid-auth/ https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/ https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ ===================================================================== 11. Data Center Congestion Control – Where’s the best fit in IETF/IRTF? Paul Congdon Discussions on Data Center Congestion Control, in one form or another, have been taking place since at least IETF-103. Recently there have been some chatter about where to take this group and what activities should spin out from it; should we expand the current focus in ICCRG or are these topics appropriate for a new research group in IRTF. At IETF-106 there are several topics that people would like to discuss. Where can the IETF/IRTF discuss how NICs can be designed for CC in HPC/RDMA/AI DCN and how can the network participate to improve performance. A side meeting has been scheduled on Tuesday, November 19th from 8:30AM – 9:25AM in the VIP A room. The plan is to provide feedback on several drafts on the topic and to share results of tests mixing RDMA and TCP traffic in the same network. If time permits, we would also like to discuss appropriate performance metrics for HPC/RDMA/AI networks. For questions and comments, feel free to contact me as well. ===================================================================== 12. PIR — Programmable Internet Routing Nicholas Hart This is a request for feedback, sense checking, advice and support resources (mostly just anonymised BGP configurations and current transit ISP topology, dimension, scale and routing load data). ===================================================================== 13. Explicit Measurements Cociglio Mauro We propose a lightening talk on “explicit measurements”, in particular RTT and RT Packet Loss on a client-server data flow. Spin bit for RTT measurement was the first case of explicit in-band measurement inserted in QUIC protocol (https://www.ietfjournal.org/enabling-internet-measurement-with-the-quic-spin-bit/). The spinbit idea is to create a square wave on the data flow, using a bit, which length is equal to RTT. Whatever is located on the path an observer can measure the end to end RTT only watching the spinbit. Our idea is to define a new measurement, the Round Trip Packet Loss, that maintains the same properties of spin bit measurement. Our proposal introduces a mechanism to evaluate also the packet loss together with the delay measurement. This can be achieved by introducing the loss signal, a single or two bits signal, whose purpose is to mark a variable number of packets (from live traffic) which are exchanged two times between the endpoints realizing a two round-trip reflection. A passive on-path observer, placed on whatever direction, can trivially count and compare the number of marked packets seen during the two round trip and estimate the loss rate experienced by the connection. We will participate at the hackathon project “QUIC Measurements”. The reference draft is: https://tools.ietf.org/html/draft-cfb-tsvwg-spinbit-new-measurements-00. On Monday (18:10-19:40, Moor/Morrison) we will be at the Hackdemo Happy Hour. Our software implementation will be shown inside the Ericsson Spindump monitoring application. The Round Trip Packet Loss idea will be presented in TSVWG on Thursday (10:00-12:00, Canning) in the draft-cfb-tsvwg-spinbit-new-measurements slot. The TSVWG mailing list (tsvwg@ietf.org) may be the right place to continue the discussion on this topic. I can be contacted directly at mauro.cociglio@telecomitalia.it. ===================================================================== 14. Systems Considerations Dirk Kutscher Abstract: In the post-Snowden years, the IETF has made an effort to ramp up communication security and privacy for protocols work. Meanwhile, platform concentration and surveillance-based business models have shown us that encryption is a necessary but not a sufficient means for privacy, which has led us to start thinking about extending the threat model. What are the options for IETF/IRTF when some of root causes and enabling technologies for problematic data collection/abuse are not under our control or are not even of technical nature? Is there a conflict between encryption and data control? This talk will make an attempt at framing these questions and suggest some options for architectural, technical and methodological work. ===================================================================== 15. Multicast to the Browser Jake Holland Now that [DRIAD] is close to shipping and unicast tunnels for multicast traffic from a provider can be auto-discovered, the next big problem for multicast over the internet is receiver deployment. This effort is about making it so anyone can port their receiver to WebAssembly and subscribe to traffic with a Javascript API from a web page or embedded browser. Doing that safely requires the sender to publish standardized metadata about the traffic that can be auto-discovered by both the network and the browser, to provide all the necessary guard rails to prevent abuse. This proposal builds those guard rails from 3 major pieces: - DORMS: how to get metadata about multicast groups from senders - AMBI: how to authenticate the traffic and detect losses - CBACC: how to limit the rate of subscribed traffic We'll be presenting more about this in mboned, and looking to get some drafts adopted and/or dispatched. Here's the WICG proposal: https://discourse.wicg.io/t/proposal-multicastreceiver-api/3939 Here's the IETF drafts: https://tools.ietf.org/html/draft-jholland-mboned-dorms-01 https://tools.ietf.org/html/draft-jholland-mboned-ambi-04 https://tools.ietf.org/html/draft-jholland-mboned-cbacc-00 References: [DRIAD] https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-09 =====================================================================