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. ===================================================================== 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. =====================================================================