**Session Date/Time:** 15 Mar 2026 10:00 **Speaker 1:** All right, come in, sit down. Welcome everybody to HotRFC at IETF 121. We have 16 speakers here, and I'm reliably informed that at least one of them is not talking about AI. All right, shall we skip through the compulsory slides? These are the rules. They apply even in this session. The Note Well is in force, so note it well. You're going to see this a lot of times throughout this coming week. So if you read one word in each session, you will have read the whole thing by the end. All right. If you want help with some new work, whether you're one of the 16 people here or anything else, there's a new work help desk. There's a couple of times that this will be, right outside in the registration area, so you already know how to find it. All right, so the rules of HotRFC. This is where you make a request for—I'm just going to read this, it's down there. It's a good way to find people to talk to, and this is where you find collaborators, where you find supporters, where you find someone to review your work, hopefully. Everyone gets four minutes from the start of their time to the end. There's 16 of them, so plenty of people. That means we're going to be pretty strict. We'll set a timer. When we get to the end, the "Please Applause" slide is going to appear, and you are going to applaud so loudly that they can't keep talking and they leave happy with what they've achieved in that four minutes. There's no questions here. You can ask follow-up questions from people outside. If you do want to ask follow-up questions straight away, go outside too, so the next speaker's not being overridden by them. We're using Data Tracker. We don't force people to log in for this one, do we? Because they're not asking questions. Yep. All the slides are in Data Tracker. You can go read them later. All right. Now, this is your chance to practice. Applause, please! [Applause] **Speaker 1:** That was okay, but I think we can do better. So, I'm just going to rewind. Three, two, one, go! [Loud Applause] **Speaker 1:** Oh yeah, that is how it's done. All right, thank you. And with that, I believe we are onto our very first speaker. So come on up. Yeah, thank you, please. The only time not to applaud is when they're actually speaking. You can keep clapping the whole rest of the time. --- ### [01 Enhancing Multi-Agent Collaboration Context and AuthZ](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-01-enhancing-multi-agent-collaboration-context-and-authz-01) **Jingyang Li:** Okay. Hi, everyone. I am Jingyang Li, and this is Shaoyi Yang. We're coming from Huawei. And today, we want to talk about two practical problems in multi-agent collaboration and our proposal about how to fix them. Imagine an OS-level system agent on your phone orchestrating multiple app agents: travel planning, media processing, and everything is automated. No friction. That's our vision, right? But the reality is harder. Terminals face strict limits on tokens, battery, and latency. The current protocols like A2A and MCP will not be fit for this. Two problems keep coming up. The first is context fragmentation. Just imagine status plain text exchange cause massive token overhead and execution failures. And the second is AuthZ friction, reactive, concerned prompts, break workflows, and exhaust users. So, here we have two proposals. The first one is when an OS agent coordinates across maps, weather, and booking agents. Today, every handoff resends everything from scratch. No shared task state, no dependency tracking, and a very high overhead, a very high latency, and task losses. So, our fix is: replace the plain text exchange with a structured semantic schema that natively tracks context boundaries, dependency, and execution states. And the work is detailed in our first draft. **Shaoyi Yang:** Okay. And for authorization, MCP handles OAuth 2 reactively. A simple email plus calendar workflow triggers separate consent prompts multiple times mid-execution, and thus consent fatigue and broken automation. So our fix is: record security requirements up-front in resource metadata, aggregate all required scopes, and fire one single authorization flow before execution begins. That's our second draft. Please see more details in our draft. And for summary: terminals are constrained. Today's stateless reactive protocols cannot support complex multi-agent workflows. So we are proposing a shift to protocols that are structured, stateful, and pre-authorized. We're here for feedback. Catch me after this session or catch—or send our email. Thank you. [Applause] --- ### [Agentic Network Knowledge Graph](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-agentic-network-knowledge-graph-00) **Mingjie Xing:** All right. Our next speaker on knowledge graph for network management. Do we have Mingjie? Yes. Cool. Okay, everyone. I'm Mingjie Xing from Zhongguancun Lab. The topic I'd like to share with you is about using Knowledge Graph to assist network management. The network data is facing some challenges including the—like the data overload. For example, the network analysis is becoming more complex by its high volume data with complex correlations. And the second challenge is vendor-specific silos, such as the YANG model will describe the same concepts but with different structures and syntax. And the data heterogeneity also increases the difficulty in correlating the diverse operational data like the configurations and logs. To tackle these challenges, several knowledge graph drafts have been proposed at the NMOP working group. But they are discussing about how to define and construct the knowledge graph. In this session, we want to discuss more about how to use network knowledge graph. Given a well-constructed knowledge graph, the engineers should interact with the knowledge graph with some structured query language like the Cypher. But it will introduce a higher learning barrier, and the graph and the YANG schema is continuously evolving, and we need to translate the abstracted intent to some actionable query language. So we want to introduce an intelligent interface. It can converting human intent natural language or domain-specific language to queries. And it can unify the heterogeneous input and ensure the security and compliance, and ensure the accurate translation from the intent to query and finally synthesize the query result. This framework consists of three layers. The first is the input and interaction layer, the second is the unified intent gateway, and the final one is the data and knowledge layer. For the input and interaction layer, it can receive two types of input. The first is natural language: the operators can describe their intent with natural language. The second is a domain-specific language. And this interface is responsible for providing a unified APIs and deliver the queried results to the user. For the unified intent gateway, it first receives the incoming request, then it performs some necessary authorization, and then it parses the intent into an intermediate representation and then generates the actionable graph query language. In the last layer, for the graph database layer, it is responsible for executing the query language and returning the derived results. Here are some use cases. For example, an operator may want to investigate if the server is attacked by HTTP flood. He can describe his intent and generate the Cypher language and return the results. Here is another use case. We also launched a Hackathon project where we built a network knowledge graph and provided a retrieval interface where users can use the natural language to [applause cuts speaker off]. Thank you. [Applause] --- ### [Alternate marking usage for loss location in per-packet load balancing networks](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-alternate-marking-usage-for-loss-location-in-per-packet-load-balancing-networks-01) **Speaker 1:** All right. Our next speaker on alternate marking for the loss location in per-packet load balancing networks. **Kepeng Li:** Hello, everyone. My name is Kepeng Li and I'm coming from China Mobile. Today, I'm going to introduce the use cases for alternate marking for the loss location in per-packet load balancing networks. Many per-packet network load balancing schemes have been proposed to achieve near-optimal network performance. For example, NVIDIA Adaptive Routing, Broadcom Dynamic Load Balancing Global Load Balancing, and China Mobile Global Scheduled Ethernet. These schemes spray packets onto parallel paths to eliminate load imbalance. However, packet spraying brings many challenges for loss location. In flow-based networks, packets with the same five-tuple will traverse the same network paths. While in packet-spraying networks, packets with the same five-tuple may traverse different paths, and replaying the dropped packets for loss location can result in incorrect conclusions. So, packet-spraying networks require real-time loss detection and location on switches. And alternate packet marking is an efficient way for switches to precisely locate loss in real time. And this slide introduces the workflow of alternate packet marking. Firstly, packets are periodically and alternately marked at the traffic entry points, such as the source network interface cards or the source top-of-rack switches. And secondly, in each period, each switch calculates the difference between the ingress and egress packet counts in the previous period. This step is to accurately determine the total packet loss count. And the alternate marking ensures that the packet count in the last marking period remains unchanged. This allows for an accurate loss counting. And this method can accurately detect nearly all packet loss in switching, including silent packet loss. Note that the silent packet loss cannot be detected by the traditional switch loss count. And this slide shows the three use cases in per-packet load balancing networks. And the first use case is to use alternate marking to monitor all packet loss on switches. And by marking all packets alternately, we can accurately detect all packet loss in the switching process. And this method enables precise switch loss rate monitoring for every switch in the cluster. And with this metric, we can monitor the abnormal switch. The second use case is to monitor packet loss for loss-sensitive services. Not all services are sensitive to packet loss. Some services are highly sensitive to packet loss, such as AI training and AI inference, and these services have very severe barrier effects. While other services are not—maybe not loss-sensitive. So for the loss-sensitive services, we need to focus on every loss event. While for the services that are not sensitive to loss, we need only to focus on the severe loss events. So by merely marking packets in loss-sensitive services, we can focus on packet loss events only in loss-sensitive services. And the third, the last use case, is to locate packet loss in network probing systems. By marking probes alternately, we can accurately locate probe loss, and we can locate the abnormal switches. And that's all for my today's presentation. Thank you. [Applause] --- ### [Agent Communication Gateway for Semantic Routing and Working Memory](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-agent-communication-gateway-for-semantic-routing-and-working-memory-01) **Wang Zan:** Hello, everyone. I'm Wang Zan from Professor Cui Yong's group at Tsinghua University. Today, I will present our project, OpenGateway. It's an open-source agent gateway for cross-domain collaborations. [Technical issue with slide advancer] First, let us see why an agent gateway is needed. Today, many real-world tasks need multiple agents to work together to solve a complex task. For example, this happens in DDoS defense, conference traveling, and smart factories. These scenarios have common challenges like heterogeneous agents and complex tasks. We also look at the existing gateway products. They already provided useful capabilities, but there are still gaps for our target scenarios. Some products doesn't support general connection between heterogeneous agents. Some are more focused on connection control than organization. So we proposed our solution, OpenGateway. It has four main parts. The first part is heterogeneous connectivity. The problem is that different tools and agents often use different protocols and interfaces. This makes connection and collaboration difficult. Our system supports capability registration and automatic protocol translation. And the second part is task orchestration. In long and complex tasks, one-shot generation is often unstable. This is because there are dependencies, tool constraints, and uncertainty in steps. Our approach is to support replanning with feedback and routing by vectorized agent profile. And the third part is working memory. In long-horizon tasks, the system may accumulate too much temporary information. This can lead to circular logic and loss of focus. We use a zoned short-term memory to maintain agent status, and we also use a KV cache to avoid redundant computation. The fourth part is security assurance. The security risks include untrusted inputs, over-permissioned actions, and memory competitions. Our approach includes pre-execution capability assessment and heartbeat monitoring during execution. We also support sensitive information guarding and rewriting. And for deployment, OpenGateway is designed for edge servers and cross-domain enterprise services. It supports private protection, local models, and external APIs. We also expect that it can have a better efficiency and lower token cost. Right now, OpenGateway is an open-source project on GitHub. Task orchestration and working memory are already to use. More functions are coming soon. We have published the code on GitHub and submitted the active IETF draft. We welcome more people to join us. Thank you. [Applause] --- ### [SAFE Sealed, Algorithm-Flexible Envelope](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-safe-sealed-algorithm-flexible-envelope-00) **Nick Sullivan (Remote):** Hi, hello from remote space. I'm Nick Sullivan, and this is SAFE: Sealed, Algorithm-Flexible Envelope. SAFE is an encrypted container for large files that combines multi-recipient keying, multi-factor credentials, and random access authenticated encryption. The goal is to make one format that works for modern encrypted data handling without forcing a trade-off between performance, flexibility, and cryptographic structure. The motivating gap here is simple: today's formats do some of these things well, but not all of them natively combine large file framing, streaming decryption, random access reads and writes, multi-factor recipient unlock, and algorithm agility all in one place. SAFE is an attempt to fill that gap with one container format that's designed from the start for large files, multiple recipients, and all these sort of things, as well as cryptographic evolution over time. The core abstraction here—it might be hard to read, but the slides are available—is the "lock." Each lock independently wraps a content encryption key, and any one lock is sufficient to decrypt the file. That means that you can have one recipient path that is simple, like one HPKE X25519 key; you can have another that combines an elliptic curve and a password; and you can have another that combines a post-quantum key with a classical key and a WebAuthn PRF, such as a passkey. The important point here is that the format does not need a special mechanism for every one of the combinations; it composes them through a simple step model inside each lock. And this is what gets you multi-recipient access, multi-factor unlock, and algorithm agility all in one framework. It also gives you a clean path to post-quantum and hybrid deployments without changing the container format itself. And if you want key privacy, identifiers can be omitted, so decryption works by trial rather than explicit labeling. The second big idea in this draft is RAAE, which is Random Access Authenticated Encryption. This extends a protocol called STREAM with per-block AEAD—there's a lot of acronyms here—but in any case, it extends the streaming protocol so that you can seek to a block, read it, or rewrite it without decrypting or re-keying the rest of the file. And this matters if the encrypted object is large and you don't want a tiny change to force a full rewrite. Integrity across all seeks is handled with a snapshot accumulator, so SAFE is not just a transport envelope; it's designed for encrypted data that may need selective reads and in-place updates. The deck points to a formal analysis of the definition of this RAAE construction as part of the basis for this design. On the wire, SAFE separates cipher tag, ciphertext from framing. There are three data section encodings that are currently defined. First is an armored mode, which is a text-safe encoding that works in email, config files, CLI pipelines, and yes, agent-to-agent communication. Secondly, there is a binary linear format, which is the straightforward streaming profile. And the third is a binary aligned format, which is a minimal editing profile where metadata is front-loaded and padded so you can seek directly and rewrite that block and only affect, only interact with certain things. This is meant to be a practical system, not just a format sketch. This shows two concrete format profiles: one is a FIPS-oriented profile, and another is a high-performance one using modern cryptography. There are ongoing cross-protocol implementations. The claim is not SAFE replaces every existing format. If you're building encrypted storage, large file formats, agent tooling, or anything that needs rewritable encrypted containers, please reach out to me. Thanks. [Applause] --- ### [AI Agent Discovery and Invocation Protocol](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-ai-agent-discovery-and-invocation-protocol-00) **Yihan:** Hello, everyone. I am Yihan from Zhongguancun Laboratory. Now, let me introduce our draft: AI Agent Discovery and Invocation Protocol (AIDIP). Now, let me introduce the motivation about why we need AIDIP. AI agents are everywhere in our world, from translation to summarization or the code generation. But every framework has its own API. Integrating agents across platforms means writing custom code for each one. There is no standard way to discover or invoke agents. It may have three main problems: the first one, platform silos; and high integration cost; and no interoperability. Now, let me introduce the four core components about AIDIP. The first one is agent metadata spec, standard JSON schema describing any agent capabilities, endpoints, and so on. Think of it a machine-readable business card for agents. The second one is discovery mechanism. Agents register with a registry. Both modes can be combined in one request. The third part, invocation interface. We use HTTP POST and JSON to write the field. And the final one is security framework. We use OAuth 2, API keys, and TLS for authorization. And now is the system architecture. First, the agent registers in agent registry. Then, a client searches the agent from the discover service. The registry sends the result back to the client. And the fourth step is client invokes AI agent, then the final step is AI agent's response. And in our draft, we have two optional parts: the semantic routing platform and gateway. Now is the detail about agent metadata and discovery mechanism. The metadata fields include ID, name, capabilities, tags, and so on. And the attribute filter and semantic NLP search is, as I have said, the two ways about discovery mechanism. And in our draft version 01, we have a new part about agent semantic resolution. It solves the problem: which agent is best suited for the specific task right now? This use case is about summarizing an English legal document to Chinese. First, we search it and then select which agent is suitable, and then invoke the agent, and finally response. We have solved the five problems: unified agent metadata, and then two mode discovery, and uniform invocation interface, and agent semantic resolution, finally we concern about the security framework. And we hope the discussion with us to let our protocol better. Thank you. [Applause] --- ### [Long-Term Persistence of Attacker Infrastructure Across DNS Intelligence and Honeypot Observations](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-long-term-persistence-of-attacker-infrastructure-across-dns-intelligence-and-honeypot-observations-00) **Yuanyuan Zhou:** Hello, everyone. My name is Yuanyuan Zhou, and I'm from University College London. And today, I want to share you with a very initial results and a very short talk about the long-term persistence of attack infrastructure across its DNS intelligence and honeypot observations. And so, here is a general motivation for this work. So initially, we are trying to do the measurement on the security different layers. And so, we have these two different sources. And so firstly, we have this very large honeypot collection supported by the Global Cyber Alliance. And also we have another DNS threat intelligence that is supported by the Infoblox. So with these two enrichments, we are going to have this attacker behavior and also have the infrastructure reputation at the same time. So the security system observes the attacker infrastructure could from the different perspectives. In this case, the honeypot captures the interaction behavior, while the DNS security threat intelligence captures the infrastructure roles. So the aim is to understand the persistent attack infrastructure. And so, here is a result from the threat intelligence side, which is going to show the attacker infrastructure persistence. Our observation period is around 60 months, but the lifetime of the persistence in the system is going to be longer, which could be over 10 years. And so the initial finding is that the most attacker infrastructure is short-lived. And however, there's a very small fraction persists for very long period. And we also noticed there's another phenomenon: like this IP address may be used for the mailing list at the initial stage, but after several months, it may change to a web service. So we do such measurement based on this OSR entropy where we found the infrastructure ecosystem becomes more functional—functionally diverse. So the more infrastructure roles emerge over time. And this is a finding from the honeypot view, which is going to show their behavior. So we do such evaluation in two different dimensions: the first one is from the unique behavior patterns, and the other is to check their reuse ratio. So this is going to separately to clearly show the separation of three different regions. And so what we found in general is that the persistent infrastructure exhibits different behaviors. So they could have some automated scanners which shows the repeated simple behavior. And also we have some semi-automated attackers which seems to be the botnet scripts exploration frameworks. And also the most complex one, which is going to be the interactive attackers, and which could have some manual sessions and some command execution. And so, the key takeaways here with this initial finding is a small number of infrastructure node drive many attacks. And this long-lived infrastructure may evade this detection if the threat intelligence visibility is too short. And also we found like combining these two different sources could actually provide a richer view to see different levels of these attackers. And so we are actually looking for the feedback and discussion with researchers and operators working on the DNS abuse internet measurement and attack infrastructure. And if and also open for anyone interested in this topic. So I'm happy to take any questions and discussion afterwards. Thank you. [Applause] --- ### [Verifiable Agent Conversations Records](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-verifiable-agent-conversations-records-00) **Henk Birkholz:** Hi. So hi, I'm Henk. Um, yeah, unfortunately we are on the hype train here. That's a problem. Verifiable Agent Conversation Records. What does that mean? At least two entities talk to agents. It's humans, agents, or mixed as a third alternative. A few authors here. That's me, I'm presenting. I'm Henk. Tobias is our AI agentic expert, and Aubrey doesn't like to be called the Verifiable Credential expert, so I will not call him that. And so, what are we doing? There's a problem. We have agents. Agents communicate. It's very obvious. There are a lot of records for these communications. They are claiming to have done something, and then they're actually doing something, and then the auditor has no idea what happened because that's all gone, because this happened in a very short time frame. So you don't only have the chain of thought, you have all this conversation. We call them "Convos" right now, I think. Verifiable Agent Conversation Records is a mouthful. Yeah, please improve on that, dash that. But in the end, all these logs from the agents are very different. They are not tamper-evident, they are not authentic, they're just there. And then at some point, they disappear. And then—but for regulation, you need them, right? So there's this nice guy on the right side, it's like "huh?". It's just a very current state at the moment. So, so we want to improve a little bit on that, and that is what the IETF is for: interoperability and all these schemas and things. So, we have this mouthful of things. So we have the agent sessions I was talking about that. They give us a lot. They have the message, they have some records of this, they have tool calls, there's a lot of things they sometimes fetch from the internet and then ignore the robots.txt or whatever, and then everything happens. So we press out all these heterogeneous agent-specific stuff into a CDDL schema. We put that into a COSE sign-one. That's surprising because all of this is JSON, but it can't stay for long. JSON becomes very big. We want it to be a bit more concise. And maybe there's a transformation thing there. In the end, we want to make this all auditable. So we put this in a transparency log. That's work done in the IETF. It's basically concluded. And then, we hope with some technical support, the auditor's happy now because it has all the things after the fact. But also, we could do this live. There's this thing called the Security Event and Information Management System (SIEM), and they process pattern analysis at a vast speed already. So maybe this is also an input to a live analysis system to stop things from happening before they derail schemes or break some safeguards. But I think the most important thing is to have the conformity and the uniformity and the standards. So at the bottom, you can see that there's a compliance alliance mapping. We use it as information model, and there is an internet draft. It's just hard to read, but it's basically the name on the top. And we have a GitHub implementation to sign everything and to write to you. So my ask is just have a time, take a peek, look at it. Tell us where we're wrong, because at the moment we are not, for example, retaining the original source of truth. This is the actual thing generated by the agent. Maybe that should also be authentic and a provenance path to the unified thing. But ideally, this isn't that bad, and this is a 00, to be honest. And it's a good 00, I think. But ideally, this could be the standard that we are going towards for every agent to use, and then we lose a lot of the complexity, and that would be so great, right? So look at it. Thank you. [Applause] --- ### [Does the End-to-End Argument still matter?](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-does-the-end-to-end-argument-still-matter-00) **Carlos:** Hello, I'm Carlos from the Federal University of ABC, Brazil. And today, I'm talking about the end-to-end argument, a principle that shaped the internet architecture for decades. And I have a simple question: is it dead? The concept is very simple: the intelligence at the endpoints, a simple network in the middle, and the application semantics outside the network. However, at a certain point, we started to introduce middleboxes: firewalls, NATs, proxies, CDNs. And then at a certain point, the network basically said, "Hasta la vista, end-to-end." And today, we're witnessing something new, because with this IoT, Internet of Things, we have like a continuum of processing stages from devices to the cloud, where data is filtered, aggregated, processed, interpreted, analyzed. So the semantics of the application are partially migrating inside the network. And to better design these applications, we developed IoT architectures. This is an example of a five-layer IoT architecture. And multiple applications with multiple services—they have the services in certain layers of the architecture that must be mapped inside the stages of the continuum to do the deployment. And there are multiple ways of doing that. This is an example of agriculture for smart irrigation. We actually implemented this. And here the multiple services that compose this application. So, considering the networking architecture, the OSI layers, you see that at a certain point, like for LoRa, there are no IP. And for others, you have multiple end-to-end connections, multiple point-to-point connections along the path. And where does it break? In multiple places inside the network. So the question is: does this continuum erode the end-to-end? Yeah, the original end-to-end, it does erode. Is it—is it good, bad, or ugly, or even somewhat else? But then, if you consider this networking end-to-end argument that goes multiple ups and downs, ups and downs, ups and downs, obviously it's broken. But then, maybe we should consider a new end-to-end based on the IoT architecture that the endpoints are different, and maybe they are upside down. And this is the view of the continuum from the end-to-end data path. So, I believe that the end-to-end argument still matters. And I'm looking for collaborators to develop the ideas and eventually write an internet draft. If you feel like collaborating, please drop me an email. And thank you very much. [Applause] --- ### [High Performance transmission over public and shared networks (HP-WAN)](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-high-performance-transmission-over-public-and-shared-networks-hp-wan-00) **Dengyue Huang:** Good evening. I'm Dengyue Huang from ZTE Corporation. And I'm going to talking about the high-performance transmission over shared and public networks, which we would like to call it the HP-WAN. And we'd like to define HP-WAN as the type of wide area network designed specifically to meet the high speed, the low latency, and the high capacity needs of the scientific research, education, and data-intensive applications. As far as the scope is concerned, contrary to the dedicated networks, we are going to focus on the public and shared network. That's why we call it the HP-WAN. Requirements is simply about the multipath data transmission across wide area networks, which demands the high throughput, low latency, high reliability within a designated completion time. We want to talking about the problem of the existing mechanisms, such as congestion control algorithms such as BBR and Cubic, as well as the transport-related technologies such as RDMA, iWARP, and RoCE v2 may not be sufficient facing the challenges such as the poor convergence speed, unscheduled traffic, long traffic feedback, and something like that. And here's the HP-WAN framework. It's designed to enable the host and network collaboration, particularly enhances the congestion control and facilitates the functionalities for the host to collaborate with the network to perform the rate negotiation between the host and the network. That's a quota-based resource reservation, admission control, and traffic scheduling. And we will put specific mechanisms in place such as the maximum transmit rate, which is designed to guarantee the avoidance of the congestion, and the minimum transmit rate is put in place to guarantee the designated completion time. And actually, we have made a Hackathon in Shenzhen meeting. And here's the prototyping results. We have an end-to-end solution and we set up the testing environment with our partners and we do some simulation on the topology of the public networks. And focus on some service scenarios based on the HP-WAN framework and related functions, such as the rate negotiation, admission control, and traffic scheduling. And we do—do the prototyping with the RSVP-TE extension. Here's the some results I'd like to share. We employed the RSVP signaling with the rate negotiation of the minimum and the maximum transmission rate between the host and the network. So we can see from the second and third figure, the traditional seesaw effect from the transport algorithms, which contributes to the unreliability and instability of the large data transmission over the network. Well, under the HP-WAN prototyping, actually we can see the seesaw effect has been largely flattened out. Yeah, that's all. Any comments and suggestions are welcome. Please feel free to reach out to me, as well as we also have a HP-WAN mailing list. Thank you. That's all. [Applause] --- ### [Open Cloud Mesh – Recent Developments](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-open-cloud-mesh-recent-developments-00) **Mickel Grönvall:** Hello, I'm Mickel Grönvall. I'm with Sunet, and I'm going to talk to you a little bit about recent developments for Open Cloud Mesh. So, Open Cloud Mesh is a server-to-server federation protocol across administrative domains. That means that you as a user on System A can share files or applications or other things with a user on System B without moving the resource or requiring a login on System A. OCM works on the coordination layer, but the actual access is delegated to the protocols beneath, such as WebDAV or other things. It was adopted by the IETF OCM working group in November 2025, and the current active working group draft is version 3, that we published in February. So, we came in with a OpenAPI specification, which was rewritten in an IETF internet draft style in 1.2.0. And then we have added different features: so we have the .well-known OCM discovery point; we have requirements and tokens; we have added a directory service concept; we have a way of discovering servers; and we have formalized things such as how does an invite string look and how do you pass information between the systems. So, the most recent specification has added more things, such as an object model with functions and roles to make it easier to architecture a new implementation. We have added SSH or SFTP as a share access method. We have removed the older data transfer protocol in favor of an access type, so you can now use different transports for different access types. And we have cleaned up the token exchange so it's more in line with OAuth. And we have also modernized the message signatures that we use in line with HTTP message signatures RFC 9421. Yes. So, we are currently working on adding a resource discovery and request for share. So if you know that a resource exists, you can request access to that resource without somebody giving it to you. So it allows you to advertise datasets and things like that. So we're looking for people to review our draft, especially if you're focused on security—that would be great. Come and talk to us. We have a mailing list: ocm@ietf.org. And we have a GitHub and you can read the draft in the Data Tracker. That's it for me. Thank you. [Applause] --- ### [Feedback Optimization Framework for BGP FlowSpec](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-feedback-optimization-framework-for-bgp-flowspec-00) **Yujia:** Okay. Hello, everyone. I'm Yujia from Zhongguancun Lab. And the topic of the HotRFC is about the feedback optimization framework for BGP FlowSpec. The BGP FlowSpec is widely used in carrier network for traffic handling or the DDoS attack mitigation. But the recent FlowSpec only provides one-way control where the successful route propagation does not imply effective enforcement. So the FlowSpec rule may become ineffective due to policy conflicts, installation failures, or lack of traffic matching, and many—many persist without timely resolution. And for the control plane, operators may find the information through the FlowSpec routing table. But in the data plane, the enforcement result—results are not visible. So we think the operators need execution feedback to understand real enforcement behavior and continuously optimize the traffic handling strategies. So we propose a feedback optimization framework for BGP FlowSpec. The framework contains three layers, which are the intent, control plane, and data plane. And for each FlowSpec route, it may carry a feedback identifier. Upon the device receives the rules, it may confirm the status and update the state machine and also configure the telemetry protocol. And then the router can use the telemetry protocol to report rule installation status and also periodically send hit statistics collected from the data plane. To achieve this framework, it may have a lot of extension of the existing protocol, such as the definition of the state machine and the FlowSpec extension of the feedback action and the payload filter. And also we need extension the existing telemetry protocol. Here is the definition of the state machine of this framework. We give different status such as IDLE, RECEIVED, or the ACTIVE or EFFECTIVE. It contains a life cycle of a FlowSpec rule, and people can check the status through this machine. And here is the feedback action we proposed in IDR working group. It's encoded in the community container and help the routers to—to check the—definition of the feedback function. And we will introduce in detail on the Friday's IDR meeting. And in the future, we are hoping to gather the community feedback to optimize the framework and also looking for the collaborators and suitable deployment scenarios. And also we will propose a telemetry extension protocol. If anyone interested in this topic, please feel free to contact me and I will—on this meeting during this week. Thank you. [Applause] --- ### [Access Line Chaos](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-access-line-chaos-01) **Christian Giese:** So. Yeah, my name is Christian Giese. I'm an access protocol engineer at Artbrick, responsible for all the protocols that have to deal with access line attributes like PPPoE, DHCPv4, v6, L2TP, and RADIUS. And therefore, I would like to get a bit more order into the attribute chaos we have today. So, access line attributes are separated into identification attributes like agent remote and circuit ID—most of you know this as DHCP option 82, but they are also used in other protocols like PPPoE and RADIUS. And there are characterization attributes like actual data rate upstream and downstream, or min and max rates, or DSL types. And these attributes are used—are very useful in the DSL time because of the dynamics of the bandwidths, but still in the fiber world today they are—they are very important and they become more important since more and more countries do open access, share their networks, and these attributes can pass network boundaries. So, the problem here is that all the attributes are defined in multiple RFCs, even in expired drafts but used in production, in Broadband Forum technical reports. And across all the protocols, we use the same number space, which means that if we define a new attribute in DHCP, we use the same attribute also in PPPoE and RADIUS without explicitly documenting this. This causes a lot of problems because as a user as well as a vendor, you have to first figure out what attributes are all defined going across all these standards, creating your own merged list of attributes defined across everything. And you have the high risk of having a number conflict, as we already had before. And another problem is that since we have a mix of Broadband Forum and IETF drafts in IANA, we have one number space which is at the same time managed in the IANA and managed in the Broadband Forum, also causing a lot of troubles here. If you would like to add new attributes and in the process of defining new attributes, we had already a number conflict in the last updates. And yeah, I would like to get a bit more order into this. So I'm really looking for people also impacted by this or interested in this topic, or vendors implementing or having the same troubles with access line attributes. I would like to ensure that all the attributes which are currently in use in production networks are reserved, which is not the state today. So I'm very happy that IANA has a BoF here. And I plan to work on a draft doing a final overview of all the attributes from all the different documents into one single draft explaining the usage of the access line attributes across all the protocols. Because they are defined fragmented, but they are used transitively: so sent from PPPoE to L2TP, and from L2TP to RADIUS. So we need one document defining all the attributes and how they are mapped between the protocols instead of forcing everybody to read and merge all the documents. And yeah, this is what I plan. And if you are interested in this topic, just reach out to me. You can find me with my email address or you can see me here around. So, thanks. [Applause] --- ### [Formal Proof of Insecurity of Intra-handshake Attestation](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-formal-proof-of-insecurity-of-intra-handshake-attestation-00) **Usama (Remote):** Yeah. Hello, everyone. I'm Usama from TU Dresden. Oh, I hear a lot of echo. Should I start? Okay, I'm hearing a lot of echo. Anyway, so welcome everyone. I'm going to talk about how in TLS we can incorporate attestation. There are three main ways in which we can do that. And before I go there, so there is the motivation is that, for example, if the TLS key is leaked, then all of the security argument for TLS breaks. That's the thing that basically protects all—all of the security arguments there. And in order to protect that better, we have these trusted execution environments and a process of attestation. And there are now three ways in which we can extend TLS protocol with remote attestation to provide the two roots of trust: such that if the TLS key is leaked, the other one protects it. If the other one, that is the remote attestation key leaks, then the TLS key will still protect us. So that's the kind of the complementary guarantee that we need from attested TLS. And in order to achieve that, three different approaches have been proposed: pre-handshake meaning that before starting the TLS handshake protocol, attestation or the evidence is signed already; intra meaning that that is done between the handshake protocol; and post meaning it's done after the TLS protocol—TLS handshake protocol. So we did a formal analysis of the intra-handshake attestation back in January last year. We reported to the TLS protocol, "Hey, actually there are diversion attacks in the protocol that was proposed for attested TLS attestation." And then by the end of last year, that was already exploited in a number of ways. So I have slides forward next. But on the relay attacks: then we did some work on the relay attacks, that meaning that if there is some adversary in between, it can get some data from a malicious endpoint and forward it over to a genuine—genuine attester and get back a genuine evidence and show it as its own. And by that, it can actually do the man-in-the-middle attack or the relay attack as we call it. So the proposal we have is to use post-handshake attestation, which is this draft: `draft-saati-suit-exp-atttls`. And basically, it's based on simply RFC 9261, which is the exported authenticators, and it extends the certificate message with the CMW extension, which is the conceptual message wrapper in which you can add that evidence. And with that, it can just use that and build the security argument that is used for RFC 9261. These are the diversion attacks that I said. They are practically exploited: Batterram, wiretap.fail, and more recently like te.fail. That's the DDR5. So all of these practical attacks are practical and only five to ten dollars, so anyone can do that. There is no magic that you actually need to do that. The second and more recent one I talked about for intra-handshake attacks were the relay attacks. And basically, this link will lead you to Cocos-AI, who claim to be the best in the world, that we have designed such a secure protocol that nobody can break it. And we were the first to actually show them that that's—the protocol they have designed is actually a broken one. And they have publicly acknowledged it, our email which we sent over to the list. Roughly like just rephrasing all of the things that we have said in that email. So basically, they are acknowledging all of that—the attacks that we pointed out. So we are looking for implementers to implement our post-handshake attestation. We are looking for contributors to contribute to the formal analysis we are doing in ProVerif, but we would love to have other tools being used as well. And we are looking for collaborators knowledgeable in TLS, remote attestation, formal methods, and confidential computing. Thanks a lot, everyone. [Applause] --- ### [AI Agent Authentication and Authorization](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-ai-agent-authentication-and-authorization-00) **Yaroslav:** Hello, everybody. I'm Yaroslav. **Brian:** I'm Brian. **Yaroslav:** And two of other co-authors, they chickened out; they decided not to travel to China. So today we would like to give you an exclusive preview of a session that we are going to present tomorrow at Dispatch. So the draft that we've put together is about AI identity. So we believe that there is a tendency to invent new AI protocols quite often without good reason, and we have decades of reasoning about identity, authentication, and authorization of things. And these standards that we've been building, they do apply to agentic AI in the very same way they do apply to workloads and many other stuff that we are used to be working with. So we are looking to build a framework document that would guide implementers to use the right set of standards when they reason with AI identity, authentication, and authorization. We may find missing pieces in existing standards that we would need to surgically address. But we, with our framework, we believe that we don't need to build something dramatically new. **Brian:** And as Yaroslav has said many times, one of the major "aha" moments through all this is that agents are in fact workloads, and they can be represented as workloads and authenticated as workloads. Right. **Yaroslav:** So there are building blocks that we identify in our draft. There are identifiers that we need to—we need to have in order to identify individual agentic workloads. They have certain credentials that need to be formatted. They need to carry some kind of attestation evidence. They need to be provisioned. They need to be able to authenticate themselves when they speak to external things. They need to have authorization and, of course, human-in-the-loop is a very important aspect of it. And they need to be observable and they need to be monitored, so we would need to be able to go back and see what did go wrong and how can we make sure that it doesn't happen again. So there are a few key standard building blocks, and vast majority of them actually belong in IETF. So there is WIMSE for identifiers, for credentials, authentication, authorization. There is OAuth with its avalanche of different standards for authorization and delegations that fit really well, surprisingly well, into this whole agentic AI thing. And there are OpenID Foundation-based set of standards for monitoring and observability that also fit quite well here. And with that, the outcome we're looking for here is for folks to come to Dispatch tomorrow and hear us basically go through the same presentation. And please contact Yaroslav for... [Applause] --- ### [Bridging the Transparency Gap: Distributed Remote Attestation](https://datatracker.ietf.org/meeting/125/materials/slides-125-hotrfc-sessa-bridging-the-transparency-gap-distributed-remote-attestation-01) **Yuning:** Good evening, everyone. So I'm Yuning, I'm here on behalf of my colleagues from Huawei. And we are exploring a practical deployment solution for remote attestation, and we're looking for collaborators to work with. So the background is that, in practice, remote attestation often happens across domains. And in each domain, it has its separate remote attestation servers or services, and it would have its own policies and separate verifier inputs. And this—this will create like two recurring problems. The first problem is cross-domain attestation transparency, because one RC from one domain may need attestation artifacts such as endorsement or reference values from another domain. And on the other hand, many verifiers may need to collect artifacts from multiple endorsers or multiple reference value providers. And those endorsers and providers need to further distribute those artifacts to multiple verifiers. So this brings the need for a public mechanism where we could have those attestation artifacts produced, distributed, and reused in an effective manner. So this is the problem we are trying to solve: it's a scaling problem if we don't have this kind of publication mechanism. So to solve that problem, we have the first architecture: that is to have a distributed ledger publication with off-chain attestation and verification. In this architecture, the attestation flow and verification flow are largely follow the existing RATS architecture, while we have the endorsement and reference values published to a distributed ledger. So very simply, we would have reference value providers and endorsers to publish those artifacts onto the distributed ledger or the remote attestation service. The verifier or another authorized entity would issue a freshness challenge to the attester. Then the attester would send such attester evidence back to the verifier. The verifier would further fetch the input such as those shared reference values already stored on the distributed ledger to be able to evaluate the attestation evidence and produce an attestation result. And such result could be used by a verifier or another relying party under policy. And another architecture we develop is to have distributed ledger publication with optional on-chain verification. So the difference between this architecture with the first architecture we discuss is that the distributed ledger would further host registration logic or verification logic, for example, through smart contracts. So the first step or the zeroth step would be similar: so reference value providers and endorsers will publish their artifacts onto the distributed ledger, maybe through registration smart contracts. And the distributed ledger would do verification on-chain through verification smart contract. And then relying party or verifier could obtain such result for decision. We also have this whole process implemented. And if you are interested, please come to discuss more details or how to implement it in a more scalable way. Thank you. [Applause] --- ### Closing Remarks **Speaker 1:** That was our last speaker. Can we please have one more round of applause for all the speakers today! [Loud Applause] **Speaker 1:** Just a reminder: if there was anything you were interested in tonight, you didn't have to take notes. All of the slides are available in the Data Tracker. You can go through there, extract everyone's email addresses. You can run an LLM over the whole thing and try and figure out what we should actually do. Please prepare your ideas for HotRFC next time in Vienna, IETF 126. See you there. Have a great evening. [Applause]