Agenda IETF106: hotrfc
agenda-106-hotrfc-17

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 tpauly@apple.com

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 Liu liuzhw3.16@sem.tsinghua.edu.cn

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 sm@smcquistin.uk
Marc Petit-Huguenin marc@petit-huguenin.org

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 phill@hallambaker.com

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 savyovm@gmail.com

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 richard.li@futurewei.com

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 gengliang@chinamobile.com
 
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.
 
The related drafts can be found as follows,
 
https://datatracker.ietf.org/doc/draft-geng-rtgwg-cfn-req/
https://datatracker.ietf.org/doc/draft-li-rtgwg-cfn-framework/
https://datatracker.ietf.org/doc/draft-gu-rtgwg-cfn-field-trial/
 
A side meeting on CFN is also scheduled on Thursday (21st Nov) morning
at 8:30 in Room VIP A. If you need more information, please do not
hesitate to contact gengliang@chinamobile.com

=====================================================================

8. Localized Optimizations On Path Segment (LOOPS)
 
Yizhou Li  liyizhou@huawei.com
Carsten Bormann cabo@tzi.org
 
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 design
issues, including encapsulation and retransmission operation; sketch a
FEC version; and then clearly outline the work to be done in LOOPS.
 
Both transport area and tunnel encapsulation protocol designers are
welcome to join us.
 
Side meeting info: 8:30-9:45 Tuesday, Room: Orchard

=====================================================================

9. Off-the-Record (OTR) v4

Sofía Celi cherenkov@riseup.net

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 rgm@labs.htt-consult.com

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 paul.congdon@tallac.com

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 n.p.hart@lancaster.ac.uk

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

Mauro Cociglio mauro.cociglio@telecomitalia.it

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 ietf@dkutscher.net

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 jholland@akamai.com

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

=====================================================================

16. Pluggable Transports

David Oliver david@guardianproject.info

Not everyone in the world has access to an open Internet, as many are
negatively impacted by censorship and surveillance.  People working in
the area of Internet Freedom are constantly developing new techniques
to circumvent Internet blockages, but it's a cat-and-mouse
game. Pluggable Transports are a way to implement new anti-censorship
technologies so they can be more easily deployed into a
constantly-changing network environment.  In this HotRFC talk we
provide an update on active research and developments in this area
since IETF105.

This work is sponsored within the IETF by the Privacy Enhancements and
Assessments Research Group (PEARG).  An Internet Draft - describing
the Pluggable Transports specification - is available.

Presenter David Oliver is available by email at
david@guardianproject.info for discussion here at IETF106. Hit me
up!

=====================================================================

17. On Decentralized Finance Technology

Shigeya Suzuki shigeya@wide.ad.jp

The Internet is a global and borderless communication
platform. Decentralized Finance Technology, which will be work on top
of the Internet, will have similar properties to the Internet. To
create a healthy eco-system, we need to discuss the architecture of
the technology, with multiple-stakeholders. We are currently seeking
people who want to join the effort. I can provide up-to-date info on
our activities if there are people who have an interest in this via
any format during IETF 106, and on the mailing list, which we'll
create (finally).

=====================================================================