AltitudeCode Logo

Thoughts on IETF 119 in Brisbane

 Published on Mar 22, 2024 · 2728 words (13 minute(s) to read)

I received an invite to IETF 119 Brisbane which is my first IETF event (thank you to APNIC, Supply Nation, Department of Infrastructure, Transport, Regional Development, Communications and the Arts, and Department of Industry, Science and Resources of the Australian Government for the ticket). This blog post will detail my experience as someone who is the new attendee to one of these events.

Sunday 17th of March 2024

I arrived, registered, grabbed my lanyard with “New Attendee” on the bottom of it and heading to the first session the IEPG aka Internet Engineering Planning Group.

IEPG

Was great to hear from Geoff Huston on ipv6 and DNS.

Dual Stack DNS

There was a lot of robust and collaborative discussion. In terms of the content, 25% of packets being from for ipv6 DNS. There is a map here for IPv6 Fragmentation Drop Rate worldwide.

More info on IP fragmentation and DNS here. To quote the article

IP fragmentation is the process that breaks packets into smaller pieces (fragments) so that the resulting pieces can pass through a link with a smaller Maximum Transfer Unit (MTU) than the original packet size.

In summary, firewalls at a lot of ISPs have not enabled UDP 53 for IPv6 which is leading to fragmented UDP packets.

Last session was An IPv6 Topology Measurement aka A Bit of a Sad Story from Randy Bush.

Looking at BGP RIB Dumps from past 320 years. looking at all AS-Paths and number of prefixes. ASes in v6 are rising and v4 are plateauing. Number of v6 edges (not in v4) have increased.

The session content was from RouteViews. Main take-away is that v4 and v6 number of ASes is diverging not converging.

Bonus session from Brian Carpenter. His topic Make Firefox visit an IPv6 Link-Local address.

Zelect

Here is the GitHub code for Zelect to test.

At this point I had a break and had some time to pop my head in to the Hackathon which was hitting the crunch period with the presentation and results scheduled for this afternoon.

IETF Hackathon participants

IETF New Participants’ Overview

IETF New participants

Funding comes from registration fees, donations, corporate contributions and The Internet Society. IETF chair works on rough consensus model. Working group chair.

IETF Mantra:

We reject kings, presidents and voting. We believe in rough consensus and running code.

Everything the IETF does, meeting minutes, where you are with a particular document can be find in the Datatracker. You can see who is the chairs, mailing list, previous meetings, published documents, all the documents in draft state. Note: my Datatracker profile is here.

For new work the steps are:

A lot of different meetings happen at an IETF meeting week e.g. Working Group sessions, Birds of a Feather sessions, IRTF sessions (research), etc.

The biggest part of the week are the Working Group (WG) sessions. The formal record of IETF stuff is via email. The face to face meetings are for people editing the documents to say “here are the things that have changed”. You should read the documents beforehand so that you aren’t lost. For example my first session tomorrow afternoon is wimse so I should pre-read that document, Workload Identity in a Multi System Environment (WIMSE) Architecture, so that I have the context and can contribute to discussion as appropriate. That document was published 13 days ago. There are two other documents also listed for the WG which I should also read. There also appears to be an agenda posted as well as the slides so plenty to pre-read before the WGs tomorrow given I have three WGs tomorrow.

Hackathon Results Presentation

At this point I went and found some food, chicken skewers, rice etc. and an ice cream. Then headed on over to the Hackathon results presentation.

Second presentation was on Augmented-by Addition into the ietf-yang-library.

Third presentation was on CBOR Serialization/Determinism. CBOR = Concise Binary Object Representation. CBOR used in IoT.

Like JSON it allows the transmission of data objects that contain name–value pairs, but in a more concise manner. This increases processing and transfer speeds at the cost of human readability Source

Next up was Comprehensive hardware emulations for multicast traffic. MSR6 TE. IPv6 Multicast Source Routing Traffic Engineering.

Next, HTTP Signature Authentication Scheme. Provide authentication HTTP resources without telegraphing you are doing so. Un-probe-ability. Three server and two client. Two implementations from Guardian project.

Next was the Network Attestation for Secure Routing (NASR). Problem: traditional routing security does not guarantee predictability and auditability of forwarding behaviours. Security sensitive clients want to use trusted devices. Re-use draft-ietf-rats-ar4si, then expand to path level trust. Security proof, collects and proofs, then have a path level security proof. Then verify the actual forwarding complies to the above attestation. Out of band management plane as well. NASR Use Cases.

Next was PQC in X509 aka Post Quantum Cryptography. Has been running as a hackathon group since IET 115. Goals working on a large number of drafts (over a dozen), anything post-quantum to do with certificates. Testing Composite KEM implementations. Continue to built compatibility matrix.

Next was SAV-based Anti-DDOS architecture. SAV = Source Address Validation. SAV-D = SAV-based anti-DDoS architecture. From what I can gather IP spoofing mechanisms have not been widely adopted.

Next was SAV Open Playground. Implemented Signed SAVNET-Peering Information (SiSPI). Had one configuration for all the components. Link Manager implemented for gRPC, TCP, QUIC. GitHub repo.

Next was Antagonist Anomaly tagging on historical data. Network anomaly detection. This talked about the YANG model to standardise the way anomalies are described and knowledge of what went well and what not. Enable Antagonist to support two use cases:

  1. A network operator tags symptoms and network issues (ground truth)
  2. A network operator validates anomaly detection generated by AI algorithms

Next was Extended YANG Data Model for DOTS. The hackathon demo images showed reduction in support time for DDoS event by 43%.

Next was Validate Configured Subscription YANG-Push Publisher Implementations. Pushing YANG into Apache Kafka. Showing the state change in a network.

Next was Ultra-Low Latency Cryptography. Areion can be applied to encryption and hashing. Secure low-latency crypto. Based on AES instructions.

Next was RPKI ASPA rpki-rtr support. Working on Resource Public Key Infrastructure (resource - IP and routers) information from RP validators, which routes they accept or reject. Client - GitHub. AS_PATH verification. Tested with Routinator.

Next was Fake Conversation Generator. vCONs. Redacting and Detecting PII. vCons carry conversations across networks. Enable responsible management fo the most personal of data. Parties, Dialogs, Analysis, Attachments. GitHub vCon repo.

At this point I left to go Tutorial: Technology Deep Dive (An introduction to the Border Gateway Protocol (BGP) for protocol developers). It was a great overview of why is BGP what it is from a history of standard protocol development with some humour and interesting history and tips for new protocol developers.

Monday 18th of March 2024

Day 2 (for me, day 3 for everyone who started on Saturday).

First up - alldispatch - IETF-Wide “Dispatch” Session.

There was a session on extending YANG for DDoS attacks. 50% of DDoS attacks are using more than two vectors. Needing collaborative mitigation. Fast flood attacks, coming from network operators to enterprises - need faster information exchange DOTS (DDoS open threat signalling) client on enterprise side and server on operator side. The data model of DOTS currently not enough (re: attack features, etc.). The client needs to know the mitigation capabilities apparently according to the presenter but this goes against the BGP session earlier mentioning they pass packets transitively regardless if supported e.g. extended attributes like BGP communities.

Tim Bray then presented on some unicode character issues with JSON.

Unicode Characters

Seems most of the chat was about whether the running of these presentations was being performed optimally, whether the presentations should be up for Dispatch (i.e. sent to a BoF or WG) or not. This presentation as an example was recommended to be sent to a PRECIS profile. More info on Preparation and Comparison of Internationalized Strings (PRECIS) Parameters here.

Modern Network Unicode

Next up, Modern Network Unicode. Again, similar people were concerned about giving bad advice etc. Seems like PRECIS profiles were the way to go here as well.

It was at this point I went and got a photo with the APNIC team and the other Australian Internet Standards Ambassadors.

APNIC Foundation

Workload Identity in Multi System Environments (wimse)

I used the agenda provided to structure the notes below. The slides are available here for Transaction Tokens and Welcome and Chair Updates.

There are three related documents for this WG in order of publish date are below as are my notes from reading them.

This is the first WG meeting for this particular WG. My first WG also so that’s nice.

Workload

In ART, not SEC. Security focused working group.

Transaction Tokens: could be machine or human, context (e.g. IP address, device) remains immutable. Pass the transaction token with the invocation of the next API or service. Transaction token. Draft of a WIMSE architecture document.

Workload Population

A lot of discussion around SPIFFE. SPIFFE and SPIRE provide strongly attested, cryptographic identities to workloads across a wide variety of platforms. The overview from the website:

SPIFFE and SPIRE provide a uniform identity control plane across modern and heterogeneous infrastructure. Since software and application architectures have grown substantially, they are spread across virtual machines in public clouds and private data centers. Security models for the organizations that manage them must keep up with these infrastructure technologies. And this is where SPIFFE and SPIRE come in. With SPIFFE/SPIRE, developers and operators can build software using new infrastructure technologies, while allowing security teams to step back from time-consuming security processes.

At this point we started talking about the deliverables mentioned in the charter.

Service-to-service Traffic

JOSE based tokens.

At this point there was a lot of discussion about do you do the architecture before the standard etc. It was generally agreed that the architecture for WIMSE should exist first to document what already exists out in the wild.

WIMSE Architecture. At this point we voted on whether we should adopt the WIMSE architecture and then the token distribution document. Token exchange was discussed but there was no document. And that was about the end of the session.

webtrans - WebTransport

Next session was on Web Transport. A lot of discussion around Flow Control and blocking. Web Transport working draft. Info from the MSDN docs:

The WebTransport interface of the WebTransport API provides functionality to enable a user agent to connect to an HTTP/3 server, initiate reliable and unreliable transport in either or both directions, and close the connection once it is no longer needed.

Interesting and need to read up a lot more on WebTransport, sounds cool and can see a lot of applications in the IoT and gaming/chat space. I joined a little late and was a little distracted so not much more to offer on this.

scim - System for Cross-domain Identity Management

Next up SCIM.

SCIM

I’ve blogged about SCIM before specifically using it for Azure AD now Entra ID as the external identity provider for an AWS SSO now AWS Identity Center.

Here’s the agenda:

Chairs Intro - 5min - Cursor Pagination chairs update - 5min - SCIM Use Cases - 10min - Pam (Paulo remote) - SCIM Events - 10min - Phil and Mike (remote) - Delta Queries - 20min - Anjali and Danny - SCIM Device Model - 15min - Eliot (remote)

Current Active Internet-Drafts:

There was a discussion around the use cases but no slides to share. There was talk about the WGLC i.e. moving the SCIM event tokens I-D (Internet Draft) to Working Group Last Call i.e. the last chance to offer feedback.

Was listening a lot to the discussion. Some questions re: Dynamic Query. But the IoT device provisioning GitHub code looks interesting.

SCIM IoT

At this point I had to leave for the APNIC dinner. On the way I got to meet Anjali Sehgal who presented on Delta Query for SCIM and ask some questions re: timestamps and token (e.g. how to ensure, depending on when the delta query was issued that you only the modified records without giving a timestamp - Anjali clarified for me that it is up to the SCIM client implementers to track that i.e. some use timestamps, some use their own token record, the diff on the timestamp or token determines the range for the changed records per implementer of the standard). At the dinner I got to meet some interesting people from CSIRO and Keio university.

Tuesday 19th of March 2024

First session of the day for me, bpf - BPF/eBPF.

bpf - BPF/eBPF

To be honest, I don’t have enough of a baseline knowledge or BPF or eBPF to contribute much to this discussion. Purely attending due to I know this is an area used for performance monitoring of container workloads (e.g. Kubernetes).

A lot of discussion around callx instructions and bits etc. Way too low level for my current understanding.

spice - Secure Patterns for Internet CrEdentials

At this point I made my way to spice which was my first BoF:

Birds of a Feather sessions (BoFs) are initial discussions about a particular topic of interest to the IETF community.

That evening APNIC hosted us at APNIC house.

APNIC House

Wednesday 20th of March 2024

First session of the day oauth.

oauth - Web Authorization Protocol

A lot of talk about SD-JWT i.e. selective disclosure.

At this point wasn’t feeling super well so went home for the day.

Thursday 21st of March 2024

First session for the day suit.

suit - Software Updates for Internet of Things

Quite a stacked and well documented agenda.

Discussing SUIT Manifest Format AKA draft-ietf-suit-manifest-25, SUIT Manifest Extensions for Multiple Trust Domains AKA draft-ietf-suit-trust-domains-06, Firmware Encryption with SUIT Manifests draft-ietf-suit-firmware-encryption-19, Secure Reporting of Update Status draft-ietf-suit-report-08, Strong Assertions of IoT Network Access Requirements draft-ietf-suit-mud-08, Mandatory-to-Implement Algorithms for SUIT Manifests draft-ietf-suit-mti-05, Update Management Extensions for SUIT Manifests draft-ietf-suit-update-management-06.

Jam-packed.

First draft discussed:

This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata.

Discussion about using IRI references in RFC 3987 as opposed to URI references in RFC 3986. e.g. in the draft it mentions:

8.4.3. suit-reference-uri: suit-reference-uri is a text string that encodes a URI where a full version of this manifest can be found. This is convenient for allowing management systems to show the severed elements of a manifest when this URI is reported by a Recipient after installation.

So it would be replacing URIs with IRIs.

Some of the docs, e.g. the SUIT encryption one are ready for IESG aka the Internet Engineering Steering Group:

The Internet Engineering Steering Group (IESG) is responsible for technical management of IETF activities and the Internet standards process.

Next up, SUIT report v08. More discussion on IRI vs URI mention that IRI is for display purposes only and if you’re not required to display (e.g. like in a browser’s address bar) the you should us URI’s as they don’t have the compatibility issues that IRI’s have.

Summary

Overall it was great to see behind the curtains at how the sausage is made so to speak. The amount of effort and care that goes into the proposed implementation of these Internet standards is impressive. In terms of contributing, I am subscribed to the wimse mailing list and will be re-reading the draft internet standards to see where I can add value. Thanks again to APNIC for the invitation to attend.