Agenda IETF104: hotrfc
agenda-104-hotrfc-12
Meeting Agenda | Hot RFC Lightning Talks (hotrfc) Team | |
---|---|---|
Date and time | 2019-03-24 17:00 | |
Title | Agenda IETF104: hotrfc | |
State | Active | |
Other versions | plain text | |
Last updated | 2019-03-24 |
agenda-104-hotrfc-12
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. =====================================================================