HotRFC @ IETF-104, Prague
Sunday, March 24, 2019, 1800-2000
Info: https://www.ietf.org/how/meetings/104/hotrfc/
Materials: https://datatracker.ietf.org/meeting/104/session/hotrfc

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

1. Collaborative Automated Course of Action Operations (CACAO) for
   Cyber Security

Bret Jordan <jordan.ietf@gmail.com>

To defend against threat actors and advanced attacker toolkits known
as intrusion sets, organizations need to manually identify, create,
and document prevention, mitigation, and remediation steps. These
steps when grouped together into a course of action (COA) / playbook
are used to protect systems, networks, data, and users. The problem
is, once these steps have been created there is no standardized and
structured way to document them, monitor them for correct execution,
or easily and dynamically share them across organizational boundaries
and technology stacks.

This talk will highlight a proposed standard to to enable cyber
defenders to use a standardized language for mitigating and
remediating cyber threats in machine relevant time.

A BOF on CACAO is scheduled for Friday at 9:00 - 10:30.

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

2. Briefing of the recent SD-WAN and Network to Cloud DCs initiatives
   in IETF

Linda Dunbar <linda.dunbar@huawei.com>

The digital transformation and wide availability of Cloud DC
resources/services are forcing enterprises re-think their networks
when they have workloads & applications & data split among hybrid
Cloud & on-prem data centers, especially for those enterprises with
multiple sites that are already interconnected by VPNs (e.g., MPLS
L2VPN/L3VPN).
 
Over last year, there are several proposals (WG adopted drafts and
personal drafts) in IETF Routing, Security, and Ops Areas to address
the protocol works that IETF can tackle.  The goal of this talk is to
get more IETFers aware of the current work in SD-WAN & Cloud DC space,
to get more people review and contribute to existing drafts (WG
adopted and individual drafts), hopefully stimulate more contributions
to IETF for this space.
 
For people who are interested in this space: please come to RTGwg,
BESS, I2NSF and OpsareaWG discussion, either in person to the WG
sessions or join the mailing lists. Or contact Linda.Dunbar@huawei.com

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

3. Signed HTTP Requests (SHREQ)

Anders Rundgren <anders.rundgren.net@gmail.com>

The SHREQ specification describes how the JSON Web Signature (JWS)
specification combined with the JSON Canonicalization Scheme (JCS),
can be utilized to support HTTP based applications needing digitally
signed requests.  SHREQ is specifically tailored for Web applications
using JSON as data interchange format.

This work builds on JCS which already have an IETF mailing list:
https://www.ietf.org/mailman/listinfo/json-canon.  Anders will be at the
IETF from Sunday-Wednesday and is readily available for discussions

Presentation, I-D in development, code, author contact information:
https://cyberphone.github.io/ietf-signed-http-requests/

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


4. Braid: Synchronization for HTTP, with CRDTs

Michael Toomim <toomim@gmail.com>

Come to the BarBoF: Tuesday evening at 6:30pm
More info at https://braid.news

HTTP was initially designed to transfer static pages.  If a page
changes, it is the client's responsibility to issue another GET
request.  This made sense when pages were static and written by hand.
However, today's websites are generated from databases, and
continuously mutate as their state changes.  Now we need state
*synchronization*, not just a state *transfer* protocol.

We built a prototype that extends HTTP into a state *synchronization*
protocol.  A GET request not only returns the current state, but also
subscribes the client to all future updates, until it issues a FORGET.
Each change is versioned, and expressed with a minimal diff.
Conflicts are resolved automatically with a CRDT.

We find dramatic benefits.  Every <textarea> becomes a collaborative
editor, automatically.  Web apps get an offline mode for free, and
synchronize perfectly when they reconnect.  Caches are kept perfectly
in sync, automatically, and the reload buttons in web browsers become
obsolete.  Diffs make the network more efficient.  Consistency is
guaranteed without a central server, enabling a distributed web.
Programming dynamic sites becomes far simpler -- our web apps require
about 70% less code to build, because the protocol automates
synchronization logic.  As a result, programmers put state on the
protocol itself, which makes it open for re-use on the web, without
building a separate API.  We think this protocol can make the web far
more reliable, powerful, open, and distributed.

We seek other individuals interested in a distributed web, CRDTs,
HTTP, synchronization, or web frameworks, to examine our prototype,
evaluate our claims, critique its design, and find room for
improvement.  We eventually hope to form a working group.

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

5. Fast Congestion Response for Data Center

Roni Even <roni.even@huawei.com>

The high link speed (100Gb/s) in Data Centers (DC) are making network
transfers complete faster and in fewer RTTs.  The short data bursts
requires low latency while longer data transfer require high
throughput.  Current congestion control is re-active, ECN marking are
going all the way to the receiver and back to the sender, looking at
proactive congestion control by letting the network do the analysis
and control directly to the sender and shorten the notification cycle
time.  The objective is to present the topic
(https://www.ietf.org/id/draft-even-fast-congestion-response-00.txt)
and see if there is interest to work on a solution at the IETF and in
which WG.  No plan for a special activity in Prague. If you have an
interest please contact me directly at roni.even@huawei.com .

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

6. The 'payto' URI scheme for payments

Florian Dold <florian.dold@gmail.com>

Payments on the Internet have only recently started to get attention
from standard bodies with the W3C's Web Payments working group.  As a
complementary standard to payments on the Web, we present the the
'payto' URI scheme, which represents payment targets, as well as
auxiliary information to make payments.  Just like 'mailto' URIs allow
users to click on an email address to open their email application,
payto URIs open banking applications to send money to a payment
target.

We're inviting further discussion on this topic on the
uri-review@ietf.org list or in person at IETF 104, especially from
folks with banking/FinTech experience.

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

7. Multipath transmission for UDP or IP

Markus Amend  <Markus.Amend@telekom.de>

Multipath network protocols for transmission of TCP, UDP or even the
IP layer over multiple paths or accesses is not fully standardized
yet. While MP-TCP is a standardized solution for TCP traffic, no
technology for at least UDP multipath transmission is
foreseeable. Specified multi-connectivity network architectures like
Hybrid Access and 3GPP ATSSS require an IP or TCP + UDP coverage
though. In particular this is demanded by the QUIC introduction which
causes an increasing UDP share in the worldwide traffic mix.

The recently submitted Drafts

https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-dccp/
https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-framework-mpdccp/
https://datatracker.ietf.org/doc/draft-amend-tsvwg-dccp-udp-header-conversion/

provides a solution for at least UDP multipath transmission.  A
discussion at the tsvwg mailinglist has already started and a time
slot during one of the tsvwg's sessions at IETF 104 was
requested. Catch me after the meeting is another option beside the
tsvwg activities to start a discussion.

===================================================A==================

8. Performance Implications of PATH Characteristics (PIPC)

Spencer Dawkins (spencerdawkins.ietf@gmail.com)

The PILC ("Performance Implications of Link Characteristics") working
group produced a number of BCPs providing guidance for protocol
designers working with links that were slow, error-prone, and
asymmetric, for subnetwork designers, and for Performance Enhancing
Proxies (PEPs), between 1999 and 2004.

Networks and protocols have changed significantly since 2004.

I believe it's time to revisit this topic, and to focus on PATH
characteristics, rather than first-hop link characteristics.

I'll be hosting a side meeting in the IETF Code Lounge at 16:20
on Thursday.

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

9. Localized Optimizations On Path Segment (LOOPS)

Yizhou Li  <liyizhou@huawei.com>
Carsten Bormann <cabo@tzi.org>

Transport performance enhancing proxies (PEPs, RFC 3135) is coming to
an end with increasing deployment of encryption, and at the same time
network nodes including virtual nodes are becoming powerful, viable to
trade processing power against path/segment quality.

LOOPS (Local Optimizations on Path Segments) attempts to capture
opportunities opened by these developments, enabling optimizations
within segments of an end-to-end path. Typically, these segments are
located between overlay nodes (tunnel endpoints), which allows a local
optimization protocol to run between these nodes.

Local recovery (retransmission and/or FEC) is main feature of
LOOPS. Local measurement and interaction with e2e congestion control
are two building blocks of it. The draft
https://datatracker.ietf.org/doc/draft-li-tsvwg-loops-problem-opportunities
provides problems and opportunities introduction and solution impact
of LOOPS.

A side meeting on Wednesday 13:30 @ Athens/Barcelona is scheduled. We
want to discuss the feasibility to have a BoF in next meeting. Catch
me during the meeting week or join the side meeting if you are
interested.

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

10. Hyperscale HPC and RDMA

Paul Congdon <paul.congdon@tallac.com>

Traditional High-Performance Computing (HPC) and Remote Data Memory
Access (RDMA) networks have been relatively small scale, custom,
isolated network clusters involving careful tuning and manual
configuration.  Recent efforts have allowed RDMA to run over TCP via
iWARP and UDP via RoCEv2, however, the networks still often remain
isolated and relatively small scale.  What would it take to run HPC
and RDMA networks at hyperscale on cloud-style infrastructure?
Research efforts have focused on addressing gaps in congestion
management, scheduling incast traffic and improving the orchestration
and manageability of supporting protocols, but standardization efforts
appear stalled.  What is next and what can be done in the IETF to
support running HPC and RDMA at hyperscale?

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

11. Web Packaging

Jeffrey Yasskin <jyasskin@google.com>

Web Packaging, https://github.com/WICG/webpackage/, is a collection of
tools including "Signed Exchanges" and "Bundled Exchanges" that allow
website and webapp authors to package their sites and apps so people
can share them peer-to-peer in a trustworthy way. Web Packaging can
also help fix AMP, optimize downloads, provide some useful security
guarantees, wax your floors, and top your desserts. We're hoping to
start an IETF Working Group to own, polish and standardize the
component specifications. We'll be talking to DISPATCH and HTTPBIS
this week, and holding a dedicated side meeting Wednesday afternoon,
15:00-17:00, in Athens/Barcelona.


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

12. DNS Service Discovery

Ted Lemon <mellon@fugue.com>

The goal of the DNSSD HotRFC talk is to raise consciousness within the
IETF about recent improvements to DNS Service Discovery.  DNS Service
Discovery is a mechanism for discovering services by looking them up
either using Multicast DNS or using regular DNS.  Historically, most
DNSSD deployment has happened automatically, using multicast DNS.  The
advantage of this is that it requires no configuration—as long as
multicast works, mDNS works.  It’s always been possible to discover
services using DNS rather than mDNS, but setting up a DNS server to
advertise services has been a manual process, which only makes sense
on large, managed networks.

The DNSSD working group has had as its goal the development of
automatic service advertisement over DNS, rather than mDNS, so that
services can be discovered outside of single subnets.  The result of
this is that rather than configuring your authoritative name server,
e.g. BIND or Unbound, with a static zone file, you can set up a
Discovery Relay.  This supports multi-link local area service
discovery by translating DNS queries to mDNS queries.  We’ve also
developed a specialized version of DNS update which allows for
first-come, first-served DNS service registration using public key
cryptography, without requiring pre-shared keys.

As a result, it is now possible to configure DNS service discovery
over DNS automatically.  The Homenet working group will be using
Discovery Proxy to solve the problem that you can’t find your printer
when you have two access points and you’re connected to the wrong one,
for example.  But this also provides a scalable, reliable, automatic
solution to the problem of local-area naming in enterprise and small
business environments.

Those interested should come to the hackdemo happy hour and look for
Stuart Cheshire or me.


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

13. DOGFOOD

Ted Lemon <mellon@fugue.com>

At present, the IETF meets in person three times every year. This has
some substantial problems.  It privileges participants from wealthy
countries, gives wealthy companies greater influence, reduces
diversity, selects in favor of professional standards writers, has a
truly substantial carbon impact.

I think most importantly, it appears to be limiting attendance for
younger participants, with the result that we are having trouble
filling leadership roles and the long-term survival of the
organization is at risk.  It also sets a bad example: other SDOs and
similar organizations see the IETF meeting in person three times a
year and assume that if the IETF can't meet effectively online,
neither can they.

The IETF has considered this problem in the past, but has failed to
make progress on it.  I think the problem is that as incumbents, we
haven’t yet realized that the generational shift we are experiencing
is an existential threat to the IETF that may severely compromise the
work we are doing, and also that the work was all done by a small
subset of the “usual suspects” in IETF leadership, and didn’t really
have any grassroots participation.  The point of this talk is going to
be to try to motivate that grassroots participation, first by getting
a quorum of participants to support a BOF, and then using the BOF to
raise consciousness and develop a way forward.

Interested folks should meet at the Mezzanine bar at 8:30PM on
Tuesday.

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

14. Reinventing IETF meetings

Wes Hardaker <hardaker@isi.edu>

Our current method for meeting three times a year is exclusionary,
destroying the planet, disrupting family life, and wreaking havoc on
our life expediencies.  To fix this, we need to hold less face-to-face
meetings and figure out how to adapt the IETF to virtual meetings that
don't cause life disruptions. To achieve this we need to involve new
people, come up with entirely new ways to handle meetings, and very
out of the box thinking.  This talk will be about pushing toward
starting a serious brainstorming and experimental effort.  If you're
interested in participating in this discussion, please come to the
Mezzanine Bar at 8:30pm on Tuesday for a wider discussion.
Additionally mail hardaker@isi.edu to ensure if a list is formed
you'll get added to it.

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

15. Technology Deep Dive on Modern Router Design

Alvaro Retana (aretana) <aretana.ietf@gmail.com>

Coordinates: Wednesday, 15:00-17:00 in Grand Ballroom

The intention here is to provide the broader community - not just RTG
- with an improved understanding of modern router design, and to -
together - work through the implications of modern router design for
protocol designers inside, and outside, of RTG. Please come, prepared
to do some thinking, not just learning.

This is an experiment, but we hope for improved cross-area
communication on topics that are consistent sources of Late Surprises
at Last Call or IESG Evaluation time.

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