The IETF week started on Saturday with the hackthon. Diego, Pedro and I (Thomas) have been working on a variety of topics: a “STAR Requests” slide deck for the upcoming SecDispatch meeting, an architecture design for an end-to-end ACME STAR demo, and the one-bit experiment harness- reproducing and analysing a bug in iperf3 which prevents our trafic to produce reliable / precise emulation of a throughput-seeking flow. This was pretty quickly done and we got eventually absorbed by the SUIT / TEEP table. The back-story for this is I had brought from Cambridge to Montreal 40 boards with me, done especially for the hackathon by ARM – Cambridge is a very small city where everyone seems to know everyone else. Though we didn’t get to do much with the boards and the TEEP protocol, we got to know a bit better the technology, talk to people involved and, in my case, share my experience with fellow Nokians IoT folks. The QUIC spin-bit table, with Marcus, Al, Roni and Emile was also active on experimenting with 1-bit spin signal and a bunch of heuristics to reject bad RTT samples in presence of reordering. See Marcus presentations  and .) This was, as usual, very useful, ludic, extemporary and genuinely fun!
On Monday, at the SecDispatch session Diego spoke about “Generating Certificate Requests for STAR Certificates“. This complements ACME STAR and is a building block needed for closing the loop in the identity-owner controlled name delegation workflow using X.509 certs we designed in MAMI. We need to find a sensible home for this document so that it can receive a thorough security analysis. The outcome of the discussion was quite surprising but, IMO, pretty good – even though there is a fair amount of running code that I’m going to trash as a result. Martin and Ted noted that STAR request could be re-written in terms of pure ACME, provided the proof of the identifier ownership is not requested by the IdO. So, the subsequent step was to go back to ACME and discuss adoption of a STAR Request there, which is what we’ve done on Tuesday (see below). Earlier that day, at the TLS session, we discussed DTLS connection ID for 1.2 and 1.3, handling an interesting fallout from the recent major header refactoring in DTLS 1.3 on to the content type allocation (and its repercussions on the marking strategy envisaged for CID in 1.2.). The discussion is not settled yet, and continues on GitHub , , .
On Tuesday in ACME, STAR officially entered WGLC, which means, finger crossed, we should be pretty close to finalising this one. In relation to STAR Requests, instead, we were asked to produce a new version of the protocol as an ACME profile, which can then be called for adoption by the WG. So here it is, waiting for the base ACME draft to do the final adjustments to make it through IESG.
At the same time, in HTTPbis, HELIUM & HiNT were introduced. This work lead by Google and BBC R&D has some interesting overlap with MAMI in that it provides a tunnelling protocol and side channel with a proxy which might end up being useful in tuning CC for mobile networks in presence of fully encrypted end-to-end traffic. I especially liked the alternative tagline “a proxy is an honest middlebox” in Ben’s presentation.
Discussion in taps, later that afternoon, many focused on the API draft. While there are still a whole bunch of open issues, thers broad agreement on the general concepts and a lively discussion making good progress to resolve these issues. The taps working group will hold a vitual interim on September 12.
QUIC met on Wednesday morning. Work is winding up on the IETF standard version of this new transport protocol, which means it’s time to start talking about how it will interact with the rest of the Internet. Brian presented the “operations” drafts for the first time, though they’ve been under construction since shortly after the working group was chartered. The first of these, the applicability document, gives pointers on building applications (other than HTTP) on top of QUIC, and the other, the manageability document, provides an independent guide to the protocol for operators of the networks its traffic will be carried over. Discussion in the WG pointed out that this division might not be precisely the right one — pointedly, the definition of an abstract interface from the application down to QUIC is missing, and doesn’t necessarily belong in either. Work on this will ramp up in the weeks before Bangkok.
The Wednesday concluded with the tsvarea session where Brian and Ted (Hardie) presented two IAB documents defining the wire image and path signals. Further Christoper Paasch and Ian Sweet provided some insights on implementation/deployment challenges for MPTCP and QUIC.
Thursday started of with the usual maprg (Measurement and Analysis for Protocols research group) session. The agenda cover a broad spectrum of topic including reordering in QUIC, as well privacy issue of RTT measurements/bufferbloat presented by Brian and measurements of PMTU by Gorry.
Later on in LAMPS we discussed “STAR at large” for adoption. Yoav’s presentation is very neat, and does a good job discussing the non-web use cases for STAR certs (e.g., VPNs, Software defined storage, but also autonomic networks). The WG asks us to clarify a few points, in particular how to make the semantics of a no-revo cert explicit to relying parties, before taking it as an working item. So we are back to the desk on this one.
Last but not least, the Path Aware Networking (PAN) Research Group met midday on Friday, during the last slot of the meeting, for the first time as a no-longer-proposed-but-actually-chartered research group. In addition to proposed talks, discussion centered around two work items: first, a review of bad ideas in transport-path cooperation, and second, a start on answering the research group’s first question about path property definition and representation.
We had the usual amount of fun, high-bandwidth, high-energy hallway discussions that make the IETF meeting a pretty special thing. Next round, sadly the last one under the aegis of MAMI, is going to be Bangkok. Stay tuned!