**Session Date/Time:** 19 Mar 2026 06:00

This is the full verbatim transcript of the SIDROPS session at IETF 121.

**Keyur Patel:** Okay, by my clock it’s time to begin. So, we have lots of presentations that are in the "if time allows" bucket, so we need to start on time. Next slide, Luigi.

**Keyur Patel:** Note Well. Please make sure that you’re aware of everything you agreed to when you registered for this meeting. Treat each other well. It’s okay to disagree with somebody’s idea, but it’s not okay to attack the person. And please make sure you let us know if there’s any intellectual property rights associated with any of the work that we discuss today. Next slide.

**Keyur Patel:** In the room, please use the on-site tool. If obviously remote people need to use the full Meetecho. Welcome, Krishna, I understand you’re taking minutes. Thank you. This slide has the links for all of the things: the agenda, and the slides, and the notepad, and the chat room, and the audio stream, and the two full and on-site links for the Meetecho. Next slide.

**Keyur Patel:** So, we’ve gotten a lot done since we were last together. The first is that we got an updated charter approved by the IESG. We submitted manifest numbers to the IESG for publication. We’ve got three documents that are ready for Working Group Last Call: the two ASPA documents—[draft-ietf-sidrops-aspa-profile](https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/) and [draft-ietf-sidrops-aspa-verification](https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/)—and then [draft-ietf-sidrops-8210bis](https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/), which was updated to align with those ASPA documents. We’re hopefully going to get that wrapped up this month even, ready for the IESG. The [draft-ietf-sidrops-publication-server-bcp](https://datatracker.ietf.org/doc/draft-ietf-sidrops-publication-server-bcp/), the most recent revision addressed comments that were raised during the previous Working Group Last Call and it is ready to go to the IESG. We adopted Job's document [draft-ietf-sidrops-constraining-rpki-trust-anchors](https://datatracker.ietf.org/doc/draft-ietf-sidrops-constraining-rpki-trust-anchors/) about constraining RPKI trust anchors, and the Working Group Last Call on [draft-ietf-sidrops-avoid-rpki-state-in-bgp](https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/) passed; we're waiting on the shepherd write-up in order to send that to the IESG. Next.

**Keyur Patel:** So we have a lot of items here to go through the agenda. The next slide has ones that we hope we'll have time for. Is there any agenda bashes before we begin? So the one thing we told the folks who are on the overflow items is we asked them to provide slides so that they would at least be part of the proceedings. Not all of them did send slides, so the ones that did will be in the proceedings. I think that’s the last of our slides, right? Okay, first speaker.

**Job Snijders:** Testing one, two, three. Yes, this seems to work. Nice. Hi everyone, good afternoon. My name is Job Snijders, and in this presentation I want to share with you a project that makes me very, very excited because it is saving me a lot of money and will enable this working group to really do enhanced research into the RPKI.

**Job Snijders:** So, a little bit of background. In my spare time, I run a project called `rpki-views.org`. And this is a project that is modeled after `route-views.org`, and the goal simply is to archive all the world’s RPKI data. If you publish a ROA, or a CRL, or a manifest, even if it is just for a few seconds, I will find it and I will store it forever. In Route Views, they make BGP data available in the MRT format. And in RPKI Views, I take a different approach, and that approach is what I will explain in this presentation.

**Job Snijders:** There's a big difference with Route Views. With BGP, there is basically an infinite amount of BGP data because every eBGP router has its own unique perspective of the global internet routing table. So, let’s assume there are, say, half a million or maybe a million eBGP routers; that’s a lot of data. So, a project like Route Views can not really ever capture all the data. On the other hand, since the RPKI is not a routing protocol, we in theory should be able to capture all the products a CA issues, and it in theory should be possible to store the entire RPKI. It is a finite amount of data.

**Job Snijders:** There’s not many other projects that try to accomplish the same. RIPE NCC on their FTP server takes a snapshot of the RPKI on a daily basis, around midnight. That’s very cool, but it means that all the changes and fluctuations that happen during the day are not visible. So, as far as I know, RPKI Views is really unique in its attempt to capture simply everything instead of sampling.

**Job Snijders:** Now, the first generation of RPKI Views, let’s call it Gen 1—in essence, the process was: I run the validator process, it connects to all the repositories, it slurps in the data, it validates the data, and it stores the validated data in the cache directory. Then, using a simple `tar` command, we create a tarball with the contents of that cache directory. And you can see an example listing where in 2020 the cache directory in `gzip` form was 120 megabytes, but towards the end of 2025, a single snapshot was close to 500 megabytes. So, as the years went by and the RPKI was growing in size, so were the sizes of the snapshots.

**Job Snijders:** Looking at a single collector for the first few months of 2026, you can see that January, this approach consumed 1.6 terabytes, and in February, which is a little bit of a shorter month, it was 1.5. Now, RPKI Views is a multi-node initiative, it is a multi-perspective approach to capturing all the data, and my three nodes that use the Gen 1 approach collectively in 2026 captured—Benno, you're late, penalty point for you. Okay. So, in 2026 so far, they captured 10 terabytes, and the year is barely started. So, in short, this is highly problematic because I cannot afford to store all the data.

**Job Snijders:** Now, how do we solve this? This is where I came up with the idea of RPKI Spool, let’s call it Gen 2 or Generation 2 of RPKI Views. And the idea here is that I would like to publish as an informational RFC the storage approach of this project so that future researchers and fellow participants in the Working Group have a reference—a stable reference of how is this data organized, how to access it, and that should make collaboration easier. But when I wrote the first version of the draft, I copy-pasted from a previous draft and I mistakenly did not change the intended status. So, this is not Standards Track; this is just me documenting: this is what we do in this project, take it or leave it.

**Job Snijders:** You can think of RPKI Spool as a continuous log, or a tape recorder that is continuously writing out all the new data it is observing as it happens. What is the RPKI Spool approach? It is a cocktail of standardized tooling, because I would like everybody to be able to use this format—so nothing proprietary. We use tooling that either exists in the POSIX environment or is standardized through the IETF process.

**Job Snijders:** So, an RPKI Spool, in essence, is a Zstandard compressed tarball, and the members of the tarball are IETF-standardized files. Every day starts with a so-called checkpoint. The idea of the checkpoint, in combination with a log, is that if you want to replay the log, you can start at the checkpoint and then you start playing the log. And if the checkpoint were, say, on a weekly basis or a monthly basis, it would mean that if you want to replay the log, you may have to go further back in time and replay more of the log. So, a daily checkpoint turned out to be a good balance between practical access to the data without having to replay lots of the log and the storage required to host the daily checkpoint.

**Job Snijders:** So, the day starts—the day starts following the UTC timezone—and the nodes create a checkpoint. And then throughout the day, they store every new object that they discover. This is a Change Data Capture process. So, let’s look at a graph of some of the results. The green bar with the stripes is the total number of objects in a validated cache. I am trying to capture valid data. If the data is not valid according to the validation rules that we have standardized, then I am less interested in the data. So, I don't want to host people’s movies when they upload that into RPKI repositories; it has to be real, valid RPKI data.

**Job Snijders:** So, at this moment in time—this graph is the last 40 days. At this point in time, validated cache is around 500,000 objects. And then the green solid bar represents the number of objects that changed throughout that day. And a trick here is that I capture throughout the day all the data, and then when the day is finished, a compactization process is kicked off, which means that all yesterday’s data is normalized, deduplicated, and compressed. And that is what you see in these graphs. So, about 180,000 objects out of the 500,000 objects change every day. And the purple line is the number of CCRs that I was able to capture on a particular day. So, think of this as the number of photos that were captured by the validators around the world.

**Job Snijders:** Then in the lower graph, the yellow bar, you see the size of the compressed archive for that particular day. So, you can see that every day the resulting RPKI Spool file is roughly 1 gigabyte. And storing 1 gigabyte of data per day is affordable for me. Then finally, there is a green line in the lower graph, and that is the compression ratio. And the approach taken yields a compression ratio of around 98 to 99%. So, keep that in mind: if you unpack the archived files, they become quite large because I was able to capture the data in a very, very efficient manner.

**Job Snijders:** So, how does it work at this moment? There's roughly 12 nodes at this point in time, but as time goes by, I expect some of the nodes to disappear because the sponsor is maybe no longer interested or able to host a node, or maybe throughout time, some nodes are added. But as of today, it’s 12 nodes. Some of the gatherers use first RRDP and if that didn’t work, then fall back to rsync. Some of the gatherers only use rsync. Some of the gatherers have no memory of previous RRDP states, so they only use RRDP snapshots instead of RRDP deltas. Some have access to IPv4 and IPv6, some don’t. And it’s globally distributed; there's a node in Brisbane, Bangalore, Amsterdam, Zurich, and I hope that as time goes by, we can add more geographic diversity.

**Job Snijders:** All the data these nodes are collecting is losslessly aggregated and compressed because the guiding principle here is to store the raw data and allow researchers to reconstruct the raw input. And this is important because I don't know future use cases for the research. So, if I would compress the data or aggregate it in a way that I remove some metadata, we will undoubtedly become to regret it years from now when we discover that we were interested in data that was tossed out. So, this is why I really focus on capturing raw data and presenting that to the researchers.

**Job Snijders:** Now, what these files look like. As I mentioned, every day starts with the checkpoint. The checkpoint is called the initial state or `init state`. That one is marked with the midnight timestamp. And then as the day progresses, more and more data is collected, the data that changes throughout the day, the CCR files that are captured on that particular day, and those go into the RPKI Spool file. So, this means that every day is represented by two files: the initial state and the change throughout the day. And if you want to see the hierarchy yourself, then copy-paste the rsync at the bottom of the screen.

**Job Snijders:** If we look inside—I'm sorry, this slide got morphed a little bit. So, on the left side of the screen, the purple circle was supposed to be a little bit more to the left, you see the node identifier. So, on the left side you see `AMS1`, `AMS3`, `BLR1`, `BLR2`. These are the identifiers so that if you want to track or understand the history of a particular individual instance, that you—there is consistency. And then what follows is the full FQDN and path and filename of the signed objects. Now, by sorting them not by the top-level directory, which would be the node identifier, but sorting the files, the members of the tar file by FQDN and then path to the signed object, I really set up Zstandard for success. So, all the data that is very similar or maybe even equivalent is placed close to each other in the tar file, and this allows Zstandard to, in effect, store a single copy of a signed object even if multiple nodes observed that one particular signed object.

**Job Snijders:** Then let’s delve through the contents of an RPKI Spool file. All the timestamps in the tar file are not the timestamps of discovery, but they are the timestamps that are internal to the signed object using the RFC 9589 logic, the CMS signing time optimization trick that we worked on a while back. So, this is interesting because if we sort by time, it happens to be that data that is related to each other—and think, a manifest is always issued together with a CRL, and there will be data redundancy between the CRL and the manifest because they both will contain the same authority key identifier, as an example. So, by placing data that is similar to each other close to each other in the tar file, Zstandard can optimally compress the data, and this is achieved by sorting the files according to their internal timestamp.

**Job Snijders:** Now, the first file in the static directory, that is a signed object. So, it could be a manifest, a CRL, a CA certificate, something that came from a publication point. And the filename itself is the SHA-256 hash of the contents of the object. So, this allows somebody that is parsing an RPKI Spool file to verify the integrity of the file simply by matching whether the calculated SHA-256 is the same as the filename. This also means—and this is how I do the deduplication—because every object is stored by its hash as filename, and this is a very cheap way to deduplicate the same data.

**Job Snijders:** Here is a CCR file. The first portion is the year-month-day, and then a timestamp when exactly it was produced, the node identifier followed by the `.ccr` filename extension. Quick reminder: CCRs are a way to capture what goes into the validation process and what comes out of the validation process, and you take a photo of both aspects at the same time. So, a CCR contains a list of the hashes of the manifest that went into the validation process, and with that you can reconstruct the exact state of the repository because the manifest objects themselves again contain hashes of the signed objects that they reference. So, in essence, that’s like a miniature Merkle tree. And a CCR contains, like, the ROA payload state, which is the data that an RTR server would send to the BGP router. So, you have the input—like the physical shape of the input in the form of lists of hashes—and the output, as in what would be sent in an RFC 8210-compliant server. At IETF 124, I gave a brilliant presentation that is super fun to watch, and I recommend all of you to click the link and enjoy that.

**Job Snijders:** Then there’s some other files available in the RPKI Spool: a log file, which is standard out and standard error as captured of the validation process. This is not standardized, but it is useful for debugging the process if need be, but that would be by hand. And it contains an open metrics file on the metrics in terms of how long it took to synchronize various repositories, whether a repository was synchronized through RRDP or rsync, and these statistics can be used to understand how—how the synchronization process was for that particular RP at that particular moment in time.

**Job Snijders:** One minute and a half. Thank you. Then you can use `rpki-client`, an open-source package, with the `-f` feature, and you can point it at one of the files that is in the RPKI Spool archive and it will decode it into JSON, which is then something that is useful for most researchers. So, the idea is that people themselves take an RPKI Spool and then convert the data into a format that is suitable for their research—so that could be Parquet files, or Postgres, or MySQL, or whatever you want to use.

**Job Snijders:** So, in summary: every RPKI Spool contains yesterday’s data, and this is because using a one-day buffer makes for optimal compression windows, and that’s how I achieve the cheap storage. Data is deduplicated... and this is a wall of text. So, cool things I've done: I’ve discovered backdating CAs, I’ve discovered misissuances, reappearing objects that should have been revoked but were not, lack of HTTP compression, RRDP inconsistencies in terms of publication. I am debugging the RPKI for everyone using this mechanism, and it’s all public data, so you can do this too.

**Job Snijders:** Now, final remark: looking at an RPKI Spool data point that was just fun to capture, I plotted the times of the ROAs on the RPKI server from RIPE NCC, and you can see a pattern that, apparently, people do not like to change their ROAs on the weekend. I didn’t know. Okay. So, there's lots and lots of cool stuff hiding in these archives about the behavior of the CAs, and yeah, we should—we should analyze that and take advantage. No time for questions. Let me remind to everybody that when you ask for a slot, this is including the Q&A. So, if you want live feedback, please take this into account. Okay? Thank you, Job.

**Chongfeng Xie:** Hello everyone, my name is Chongfeng Xie from China Telecom. It’s my pleasure to give the latest update of the draft of MOA, [draft-ietf-sidrops-moa-profile](https://datatracker.ietf.org/doc/draft-ietf-sidrops-moa-profile/), a profile for Mapping Origin Authorization. So, in this presentation I mainly introduce our implementation and field trial.

**Chongfeng Xie:** So, first I give a review about MOA. MOA is an RPKI object for the verification address mapping announcement in IPv6-only networks. So, its goal is to ensure that IPv4 data is transmitted to the correct egress PE. This draft was adopted by SIDROPS Working Group October 2024, and the current version is 03. So, as mentioned that MOA is mainly focus on the scenario IPv6-only networks. So, for IPv4 service delivery in IPv6-only multi-domain backbones, IPv6 mapping prefixes are configured at each PE device to ensure to identify the location of each IPv4 network. IPv6 mapping prefix is considered as the mapping origin of a given IPv4 address block. So, this is easily to be understood. Here is some draft which gives the extensions about how to carry the mapping information by MP-BGP protocols for announcing the mapping relation from the egress PE to ingress PE. So, this can give the direction of IPv4 service delivery in IPv6-only network.

**Chongfeng Xie:** This is about problem. So, in this case the validity of transmitting IPv4 service data in IPv6-only network relies on the authenticity of the IP mapping origin IPv4 address block. If a attacker maps IPv4 address block using a fake IPv6 mapping prefix, IPv4 service data will be routed through the attacker-controlled route and reach to a wrong egress PE. So, which means that the routing system is deceived, which will result in a situation of IPv4 prefix hijacking.

**Chongfeng Xie:** So, we define the MOA. MOA is a cryptographic signature object that allows address holders to authorize IPv6 mapping prefix for an—for an—for IPv4 prefix mapping. Of course, we also need the validation process. So, router validate IPv6 to IPv4 mapping announcement using the MOA objects, reject unauthorized ones, and prevent IPv4 address prefix hijacking. This shows the—this is about the content type for MOA. So, MOA is a RPKI-based digital objects, which is the same to ROA and manifest. Before a relying party using MOA to validate a mapping announcement, the relying party must perform all the validation checks described in RFC 6488, as well as additional MOA-specific validation steps.

**Chongfeng Xie:** So, as mentioned, we have implemented MOA system in our—in our lab. It has the following functionality: first is has capability to—right now the system can issue MOA digital signed objects on the CA side. And the second one is that we can publish MOA digital signed objects via RRDP on the CA side. And so the system also can be capable to synchronize and validate MOA certificate on the RP side. So, it’s a end-to-end system. Next step: the MOA Protocol Data Units (PDUs) for the RPKI-to-Router (RTR) protocol will be defined in another document, which is not in scope of this document, but we think it is also necessary to define. And we also collaborate with router vendor to implement support for MOA. We will deploy it in our production network, and MOA will undergo demonstration testing and verification. So, we think that this draft is stable. So, we apply for maybe a Working Group Last Call. So, this is it. Question or comments?

**Luigi Iannone:** I have a comment. Actually on the last slide, if you go back one. As you know, by the new charter we need implementations to publish documents. And it seems that you lack one piece of this technology, which is the PDU. So maybe for going Last Call, it would be better to have the PDU and move both of them together at some point when we have the implementation report, which is lacking in the current document, right?

**Chongfeng Xie:** Okay, you mean that we need the PDU-related document, right?

**Luigi Iannone:** Yeah, you are promising a new document, right?

**Chongfeng Xie:** Okay, that’s fine.

**Luigi Iannone:** And the implementation report.

**Chongfeng Xie:** Even for this document? Yeah, yeah, yeah, okay. We can give implementation, right, to publish. Okay, I see. Yeah, thank you.

**Dima Postnikov:** Yeah, this is Dima from ZDNS, as a co-author of this draft. I would like to solicit comments from this Working Group that, since we have got MOA proposal, maybe in the coming future there is increasing number of RPKI signed objects to take advantage of the RPKI to publish their data. Shall we consider a new mechanism for RP to handle with the manifest? Because for many—for some parts of the relying party, they don't care about MOAs or GEOs or something like that. I think we should consider the incremental deployment things.

**Job Snijders:** Job Snijders, Fastly. The manifest is one of the most complicated features that we have in the RPKI protocols. And I—I do sympathize with—with increasing efficiency and, you know, I do sympathize. But I would strongly recommend against changing the manifest structure because we finally have industry-wide consensus on what it does, how it works, how to implement it safely. And it really is one of the more complicated pieces of code in RPs. So, I will probably on principle object to changing anything in that corner of our technology stack, because yeah.

**Luigi Iannone:** Job, use Meetecho to join up, please. Okay, so thank you. Let's go to the next presentation.

**Job Snijders:** Okay, two minutes, let’s go. I want to give an update on the Erik Synchronization Protocol, [draft-ietf-sidrops-rpki-erik-protocol](https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-erik-protocol/), and in this update, I’ll share with you a quick reminder of what the Erik Synchronization Protocol project is about, what changed since the last IETF meeting, what—where we are with implementation status and where people maybe can latch on and join the project, and what the next steps will be.

**Job Snijders:** So, Erik Synchronization is a mechanism to populate the cache of the RPKI validators in an efficient manner. It is based on HTTP/HTTPS because that’s, you know, how the internet works these days, so we didn’t create a bespoke new TCP-based protocol; we're using existing HTTP semantics. It uses the concept of Merkle trees, or also known as hash trees, to efficiently figure out what is the difference between my local state and the remote state, specifically between the last time we synchronized and now. And with Merkle trees, you can very, very cheaply figure out "Did something change?", and then if the answer is yes, you can very quickly zoom in on what exactly changed. And then you fetch only the difference.

**Job Snijders:** And this is a great optimization in comparison with rsync where figuring out "Did anything change?" is a very expensive component of the synchronization process. And this is also more efficient than RRDP, because in RRDP the main—the costly aspect of RRDP is that it is full history replication. So, even if states have been overtaken by events, the RP must download the full history if it uses RRDP, and this is costly. And in the Erik Protocol, you can skip over the parts of the history that are no longer relevant because of the Merkle tree structure.

**Job Snijders:** Erik Synchronization, the messages that are—the Merkle tree—use ASN.1 or DER encoding. This is because we use ASN.1 and DER in all our activities, and this way we don't need to ask the implementers to learn a new technology, for instance CBOR or Protobuf, and link in additional libraries to interact with that new technology. A key principle of Erik Synchronization is that it is a content-addressable storage system. So, all the fetching happens based on the hash of the object, not on the name of the object, because the name of objects can be recycled throughout different versions of the object. Everything is addressed by SHA-256 hash.

**Job Snijders:** And Erik Synchronization, the data structures that are exchanged—it’s all static data from—from the producer side—is really optimized for concurrent writers and concurrent readers, so you can do all the work on both sides in parallel. And this is possible because it follows the data consistency model of "last write wins." And this in turn is anchored on the manifest numbers that are monotonically increasing. Content distribution happens through a thing called relays. And that means that the clients are no longer fetching straight from the origin, because we’ve learned in the last few years that not all origins are dimensioned appropriately for the demand that exists in the internet routing system to synchronize. So, this means that if you are a smaller publication point with less resources, that using the Erik technology, if you publish new information, it gets picked up and it will distribute through a content delivery network that exists magically, so to speak.

**Job Snijders:** Changes we made since the last meeting: Previously, the way to synchronize was using the Merkle tree, and this implied hundreds, maybe thousands of HTTP requests. And this is fantastic if you are mostly synchronized. But if you have a cold cache, if—if the RP has started and has no prior history whatsoever, then it is a little bit costly to make that many requests. So, we added a feature that is somewhat analogous to RRDP snapshots where with a single HTTP request you fetch all the data. But instead of base64 encoding the data and sticking it in an XML envelope, in the Erik Protocol, the snapshot is purely concatenated DER objects. So, this simple `find` command that finds all the files, cats them together, and then runs it through gzip is literally a valid implementation of generating Erik snapshots. Snapshots don’t need to be produced in lockstep with changes. It is asynchronous. The idea is that you download a snapshot and then you perform tree synchronization. So, the snapshot is only intended to pre-populate your cache, and actual synchronization happens with the Merkle trees.

**Job Snijders:** Now you can see that we have gzip in the middle, because we’ve come to discover that in many deployments, HTTP compression is not reliably available. This is because large CDNs assume that large objects already are compressed; that is basically the running theory. We found that not all load balancer solutions and CDNs that people use support HTTP compression for larger objects. So, for instance, on Amazon CloudFront, if the object is larger than 10 megabytes, it will not be compressed at the HTTP layer. And of course the Erik snapshots often are larger than 10 megabytes. So, we made compression an integral part of the protocol, which means that it’s always enabled, that we always take advantage. But it also means that we’re stuck with gzip for another 30 years. That’s fine because we love gzip and it works on all platforms, all CPU architectures, all operating systems, and it’s pretty good bang for buck—it's like a 50% reduction. So, compressed snapshots, that’s what we’re doing.

**Job Snijders:** Then we came up with another interesting feature to reduce the number of individual HTTP requests that a client needs to make to synchronize. And here the idea is that groups of objects are bundled into time buckets, so to speak. The relay discovers new objects and puts those objects in a tail queue that is trimmed based on the time. And that means that it’s very cheap to request the relay "What are all the objects that you discovered in the last five minutes?". Now, this is about discovery time, not about signing time, because an object might have been delayed somewhere in the pipeline, or... so it’s really the discovery time. The advantage of this is it is a speculative pre-fetch. The disadvantage is that it’s a little bit complicated to reason about and you end up—because it’s speculative pre-fetch, there might be waste in that data is needlessly re-transferred because the client already had the data from say another relay. So, I am marking this as an experimental feature. We’ll do implementation work, we’ll do measurements, and we’ll figure out like "Is this actually something we like? Is the operational complexity worth keeping this feature?". Maybe yes, maybe no. As this draft matures, we’ll see. So, maybe this will be removed in the future, maybe not.

**Job Snijders:** There's a number of publicly accessible Erik relays. Here are the URIs, so if you’re doing implementation work, you can use these relays. All of them are compliant with the specification as published. So, if you find a bug, it is definitely your client-side software, not my servers. I lie. You can also access it through Tor. This is just to demonstrate that the—who operates the relay is irrelevant. This is signed data that is transferring through unauthenticated channels, and whether it comes from one relay or another relay or through the Tor network, it doesn't matter; it’s signed data and you validate it in your client.

**Job Snijders:** I have super cool news: Tom Harrison, this handsome young man with the same haircut as me and the same glasses, made a implementation of the Erik protocol. And he worked on both client and server implementation. It is open source, and we are now experimenting with "How does this behave?". Does the client—is—are the logic flows what they should be? Do we need to make changes in the draft or in the code? But it’s really nice that we are now at the point where there's multiple implementations by multiple people and we can iteratively figure out what is it that we need in the specification to help future implementers.

**Job Snijders:** Next steps: The draft needs work in terms of readability. I—it—I consider this really rough notes... so I think it contains all the normative terms you need to make an implementation, but it’s maybe not the easiest document to digest at this point in time. So, it is work in progress. Another thing that I would like to add is a method to download the trust anchor certificates, because right now your trust anchor certificate is referenced in the Tal, and that means you need to connect to the origin of the TA. And it might be nice to have copies of the TA certificates on relays available. That means we need to standardize how you can discover that trust anchor certificate, and it—it puts an emphasis on a Working Group document, the TA tiebreaker, because it could be that the relay is presenting you with an older version of a TA certificate and that means that the client needs to verify like "Okay, the relay is proposing a certificate, but is it actually something I want to use?".

**Job Snijders:** Other documentation is maybe explaining the algorithmic differences between rsync and RRDP and Erik so that people better understand "Why is Erik a very different approach and what can we expect from this protocol?". And other work is maybe something in the realm of monitoring so that we can start inspecting the health of a relay, that we come up with tools "How do we want to debug relays in a way that is easy, safe, and robust?". Next steps in terms of software: I’m working on a client implementation in C, Tom will continue working on his Perl implementation, RIPE NCC is planning to do an implementation in Rust, I saw on GitHub some activity in the RPKI Prover project, a Haskell implementation. And maybe you? Now is a great time to do implementation work because other people are also doing implementation work, and that means that there is a great virtual space, so to speak, to ask questions like "Hey, how are you guys solving this and this problem? Do you have any recommendations on that particular aspect?", and we can exchange knowledge with each other how to create robust and efficient implementations. I am available to help you implement the Erik protocol. I don't care what language you implement it in, because I will help you on a conceptual level. Your questions will help make the internet draft better, and the answers I give you will help make your software better. So, it’s win-win.

**Job Snijders:** And as we develop more software, we’re going to test if the software and the protocol is living up to the promises. Is it truly more efficient than rsync and RRDP? Does it consume less bandwidth, less CPU cycles? Does it overcome network partitions? etc., etc. So, this is data-driven protocol development. I don't know if Erik is something we actually want in the production environment in, say, a few years from now, but we will know by testing and measuring. And I think that, you know, we have time for like one compliment or remark or question. Quick. You have to be quick. All right. Please email me or the author group if you have any questions. Thank you for your time.

**Jishnu:** I hope I'm audible. Good morning, good afternoon, and good evening everyone. This is Jishnu, HPE Networking. On behalf of my authors, I'm going to walk you through the changes that we have for the YANG data model for RPKI, [draft-ietf-sidrops-rtr-yang](https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-yang/). There we go. Okay. So, this draft ideally talks about two YANG models: primarily the `ietf-rpki-rtr`, which deals with the session-specific parameters and, like, how we configure and manage the RPKI-to-Router protocol on the device, and the second YANG model talks about the RPKI table, like as to how we manage the ROA records on a router. So, in this version of the draft, like, we do have changes while addressing comments from the reviewers in the RPKI table, but there is no substantial change suggested for the `ietf-rpki-rtr` model.

**Jishnu:** Thanks to Job for taking a look at the draft, reviewing, and providing the valuable comments. We acknowledged and implemented the comments in this particular version. Ideally, like, it was suggested to have some nomenclature changes with respect to the ROA terminology and it was changed to VRPs (Validated ROA Payloads) for ASPA table, Router Key table, and the VRP tables. Along with that, like, with the adoption of [draft-ietf-sidrops-rpki-ccr](https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-ccr/) draft, we were suggested to include the CCR hashing mechanism for all the three tables—for VRP, ASPA, and Router Key tables. So, the CCR hashing is not just going to help the external monitoring tool to understand or get known of the number of counts of the ROAs that have been synced between the client and the server, but also have an in-depth knowledge about the contents of the ROAs being intact or not. So, these were the major two review comments that we received on this draft. Thanks to Job again. And we have implemented in this version.

**Jishnu:** Okay, giving a brief on what we have in the models. So, in the pictorial description as you see, like, `ietf-rpki-rtr`, like, it consists of the session-specific parameters, connectivity parameters, authentication, counters, statistics—they have been included in the model. And along with that, like, the majority, like, the changes that have been brought into, like, in this version is the RPKI-RTR table. As mentioned, the terminology or the nomenclature changes from ROAs to VRP has been addressed, and also the inclusion of the CCR payload hash mechanism has been included in all the three tables. So, for the three tables that we have, along with the total records, records added, deleted for IPv4/V6 entries, we have included the CCR hash for them, adhering to the adopted draft of the RPKI CCR. Yeah, so basically, like, after couple of reviews and cycles on this particular draft, we would be asking for a YANG doctor review or maybe Last Call, and we're open to comments and improvements on the draft. I’ll open it for the forum for any queries, comments. That’s all. Thank you.

**Keyur Patel:** Any comments? Job.

**Job Snijders:** Job Snijders, Fastly. I’m struggling to log into the thing. My apologies for not joining the queue properly. Just a quick remark about CCR. I consider the CCR draft to be stable. I have absolutely no intentions of changing the data structure. Not yet asking for Last Call because we’re waiting for an additional implementation, but just as a signal to the group, like, I think CCR in principle is finished. You are using CCR as a building block; that’s fantastic, that’s what it was intended for. So, yeah, if your draft is ready, that’s nice. I think CCR is also almost ready. This means you can depend on it. So, thank you.

**Jishnu:** Thanks—thanks Job. Like, can we go for the YANG doctor review for this? Like, as per our ask.

**Luigi Iannone:** So just a quick comment about YANG doctor review: definitely we can ask an early review as soon as next week. As for the Last Call, as far as I see, the draft is missing implementation reports. So, this must be included at some point before going for Last Call.

**Jishnu:** Okay. Thank you.

**Li-Bin Liu:** Good afternoon everyone, I'm Li-Bin Liu from Zhongguancun Laboratory. Today I will introduce a new draft called [draft-liu-sidrops-rrdp-delta-retention-policy](https://datatracker.ietf.org/doc/draft-liu-sidrops-rrdp-delta-retention-policy/), RRDP Delta File Retention Policy. So, the key idea is that in this document, we propose an adaptive delta file retention policy. The key insight is that maybe the servers can only maintain the delta files that will be used by the active relying parties. So, it has several benefits: it can adapt to the actual client access patterns and help reduce the storage requirements for the RRDP servers, and it can help improve the performance for processing the notification files. And this is one way to reduce the size of notification files as suggested in section 7.5 of the [draft-ietf-sidrops-publication-server-bcp](https://datatracker.ietf.org/doc/draft-ietf-sidrops-publication-server-bcp/) document. And it can maintain the backward compatibility with existing RRDP clients.

**Li-Bin Liu:** So, to achieve the idea, we designed three key components, including the client tracking mechanism, minimum serial number determination method, and delta file pruning algorithm. So, for existing delta file retention policies, section 3.3.2 of RFC 8182 mandates that the total size of the delta files in the notification file maintained by the server cannot exceed the size of the snapshot file, but it is free to further limit the number of deltas. So, two common methods are used: they are count-based retention policy and time-based retention policy. The count-based retention policy maintains a fixed number of most recent delta files, such as the last 500 delta files. And the time-based retention policy suggests to keep the delta files for a specified recent time period.

**Li-Bin Liu:** But they all have their problems. So they didn't consider the client access patterns; they may have inefficient server storage use, especially we can predict the size of the RPKI objects will increase along with the number increment of existing objects and the addition of more new proposed RPKI objects. Also, the count-based retention policy may discard the delta files that are still needed by the active clients, and it cannot adapt to the changing repository update frequencies. The time-based one also has the same problem.

**Li-Bin Liu:** So, to track the active clients, we propose the client tracking mechanism to track the serial numbers accessed by the active clients with the structure as shown in this slide, which records the client ID, serial number, and last access time. Then, we can use the minimum serial number determination method to determine the minimum serial number accessed by these active clients. So, then for the delta files whose serial numbers are smaller than the minimum one, we can safely delete the older delta files from the repositories.

**Li-Bin Liu:** But the client tracking mechanism may raise some privacy concerns, so we consider to take some steps to protect the client privacy. The first type strategy is to use an anonymization strategy. For example, we can use the anonymized identifiers instead of the storing the actual IP addresses. And we can only store the minimum information needed for track the clients' information and delete the tracking data for the clients that have not been seen for a configurable period.

**Li-Bin Liu:** So, in sum, this document proposed an adaptive delta file retention policy, and by tracking the minimum serial number accessed by the active clients, a repository can safely delete old delta files that are no longer needed by them, while ensuring that all clients can perform incremental updates. For the next steps, we seek feedback and comments from all of you, and collaborations are very welcome. We are also working on the simulation work code of different policies to quantify the benefits. Thank you. Any comments? Anyone has a question? Job managed to master Meetecho, so.

**Job Snijders:** Job Snijders, Fastly. I am concerned about the complexity versus the cost of storage. If you look at the largest RRDP repositories, they are a few hundred megabytes, the deltas for the last few hours is tens of megabytes. So, linking the client access pattern into a retention policy on the serving side for data that is considered static and super cheap to host seems an unwelcome complication in the ecosystem. And then secondly, the algorithm to figure out which of the pieces can be deleted—I believe that algorithms like these tend to bottom out because there are always stragglers, or maybe AI bots or something touching the HTTP resources that suggest that there is an interest in the file, and then the algorithm would end up with the maximum retention time instead of saving a few megabytes. So, I don't think that this type of algorithm achieves in practice any savings. I think you end up with a count-based or time-based variant in essence. And the complexity of linking the web server logs to the RRDP production—it should not be underestimated. Because for instance, I don't want to speak for RIPE NCC, but I know they have anycasted the RRDP endpoint through multiple cloud providers. So that means that you need to aggregate the logs in a very fast way from multiple vendors and then make decisions based on that. And I don't think anybody is interested to do that. So this mechanism, if the web server and the RRDP production are on the same machine, is maybe sort of feasible, but the moment this is a distributed mechanism, then it becomes complicated. And even keeping log files is more expensive than the disk savings that the RRDP approach might achieve. So, I appreciate the thinking that went into this proposal, but I have a number of concerns where I think the practical applicability to the ecosystem might not be worth it from a complexity perspective. Thank you for your time.

**Li-Bin Liu:** Okay, thank you for the comments from the implementation view. Thank you.

**Luigi Iannone:** Okay, thank you. No one else in the queue.

**Jeff Haas:** Hello everyone. I’m Jeff Haas, Bob Beck will be co-presenting with me, and Yingzhen Zhu is also one of our authors. So today we’re going to be talking about [draft-haas-sidrops-tls-bgp](https://datatracker.ietf.org/doc/draft-haas-sidrops-tls-bgp/), TLS authentication for BGP. And I’ll get the right slide.

**Jeff Haas:** So, motivation. Clearly, people in this room know something about BGP. Pretty much one of the headaches we have is that BGP runs over TCP, and that means that what do we do about security there? And in IETF, we hand-wave a lot of security for TCP-based protocols by saying we're going to use IPsec. You know, that doesn't happen because IPsec is painful in many cases. BGP ended up adding on TCP AO, and previously MD5, to do integrity. Authentication is sort of a property we get incidentally through pre-shared keys there. There’s a bunch of proposals running around right now that include running BGP on things like Quick. We’re not going to talk about these here. It did actually inspire a lot of other work in other areas; I believe there's actually one here for doing RPKI Router over Quick. But important detail here is that Quick is just a funny form of TLS, and that means we get a TLS handshake to get started. TLS uses certificates. And pretty much everyone knows familiar that TLS does actually use these certificates for web PKI. And that web PKI is NOT what we’re doing here. This is an important detail. What we’re talking about today is developing a PKI for BGP; this is all really about doing the TLS handshake for BGP protocols over TLS mechanisms. That’s it.

**Jeff Haas:** Why are we here? Well, part of the headache we have is this is sort of a strange piece of work that goes across several different areas. We’re here to socialize this around the security people. We’re trying to figure out exactly how this dispatches. It's probably not TLS. IDR, well, it’s sort of a BGP thing, but this is really about the PKI. SIDROPS, well, SIDROPS has a lot of expertise about security certificates. This work is very hybrid. It’s somewhere between security and routing. We are chatting with both the Sec AD and Routing ADs and we'll try to figure out exactly what we do about this. So, meat of the issue is for operations. BGP obviously runs on an AS number, and that’s what we use to represent the network and the protocol. And BGP typically is manually provisioned between routers—obviously, auto-discovery CAN be happening as well, but mostly this is provisioned. And our state is basically per neighbor. This is where I hand it over to Bob.

**Bob Beck:** So, at a high level, what this ends up looking like is every BGP session would have a certificate for a session. Each certificate would have the AS and optionally IP addresses in it. And these things should be provisionable on demand by any AS that’s using these for a peer. And they could be trusted either directly by the intermediate that created them or via the issuer of that intermediate.

**Bob Beck:** Certificate lifetimes. We want to make sure in this that we do not end up with certificate revocation issues, and as such we’re looking at a PKI that has a very short-lived certificate lifetime for the individual session certificates, and a longer-lived lifetime for the AS that issues them, so that we avoid problematic CRL issues. BGP today has effectively a notion that if we introduce each other before peering, we’ve decided to share a common shared secret, and we go ahead from that point. This doesn’t change that much here in some situations, but the desired model here is to establish introducers for the AS intermediate. The ideal introducer is just a mutually trusted third-party CA, and the third-party CA can decide to authenticate someone as controlling an AS to issue one of these intermediates by possession of a key that’s already present in the RPKI as proof of AS control. To emphasize: we are not trying to put RPKI certificates in here directly, and we are not trying to reuse keying material from RPKI. At this point, the introducer could just be used as a trust anchor itself or, once it’s validated, if you don’t wish to continue to trust the introducer, the AS intermediates could be trusted directly; this is known as intermediate elision.

**Bob Beck:** Continuing on, what does it look like in a certificate? We define a new OID to be a SAN name for an AS identifier. We use the existing OID for SAN IP address. And that’s it. It just specifies what should be in the certificate to identify the important parts for BGP. And what does it look like with a validation procedure? With two routers connected to each other with ASX and IP address 1, ASY IP address 2, if they each trust each other’s AS intermediates during the TLS handshake, you validate that the session certificate is verified, the remote AS number is checked along with the remote IP, and that’s it. It’s just about the handshake. Back to Jeff.

**Jeff Haas:** So our next steps: we do have to figure out where we’re going to actually home this stuff. We will be presenting this in SAG as well. Ideally, we do this without starting a new Working Group. You know, this is in the grand scheme of things an incredibly small thing. The trouble is, this incredibly small thing has some places where there will be some operational niceness if we do things like something like an ACME-like mechanism as an example for the end entities. And the gotcha is the minute you start doing certificates or BGP anything, we create an opportunity for land grabs and this starts piling up RFCs, you know, just to manage this stuff. If that happens, well, that means that the proposal here for this very small piece of the thing is successful; we go from there. We also know that we’re establishing some practices that other things that use TLS—Quick being, you know, the popular thing at the moment—might be useful for other IETF control plane protocols. We do mention that in the back of the draft. That’s not our primary goal here, but we expect that the practice will be potentially useful. That said, that’s all for the presentation. Any questions?

**Nangang:** Hello, Nangang from Huawei. I just a question. I wonder what’s the relationship of this document and the BGP over Quick work? Any relationship between them?

**Jeff Haas:** You are absolutely correct. So, one of the things that we intentionally did not put in the BGP over Quick document at the time that we were working on it is: "What do we actually do about their certificates that are being done?". So, this absolutely goes along with that piece of work, and it will go with any other work where we actually put BGP over anything else that looks like TLS.

**Job Snijders:** Thank you, Jeff. Job here. You said you want to avoid a new Working Group, but I’ve given this some thought when I was showering this morning, and I—you know—there’s not a great Working Group that is a fit for this new PKI, if new PKI is the direction that is chosen. To me, it would make a lot of sense to collect some interested experts from IDR, from SIDROPS, from SAG, from LAMPS, from PLANTS maybe even, and be like "Hey, we want to work on a PKI," and make a short-lived purpose-specific Working Group for this profile. Because none of the Working Groups are a great fit. It’s a bit ships in the night. So, yeah, that’s my current intuition, but you know, it’s your project.

**Jeff Haas:** Well, and your opinion’s certainly valid, and you spend a lot more time thinking about the landscape than a lot of people, and a short-lived Working Group may make sense. Being the chair of a supposedly short-lived Working Group that’s been going on 20 years now, I’m a little sensitive about such things. And we will absolutely be making you as a recommended co-chair.

**Luigi Iannone:** I see nobody else in the queue. There is only one person that should have queued up with Meetecho. Can you state your name clearly?

**Weitong:** Hi, I'm Weitong from Digitech. So, you have mentioned that you introduce a new certificate for signing that. So have you thought about how about like in SIDROPS, how about using the RSC for signing that certificate? Because the RSC can be used to sign random objects and can already can carry the AS numbers with the from the trust anchors.

**Bob Beck:** I’m afraid I only caught half the question. Bob, did you hear the whole thing?

**Jeff Haas:** I—no, I only got about half of it as well, I’m sorry.

**Weitong:** Sorry, it cut out. Yeah, so maybe you can check whether you can use the RSC.

**Bob Beck:** If—if what you’re asking is "Why aren't we reusing the keys from the RPKI?", it is explicitly because we do not want to do that.

**Weitong:** Yeah, because in the RPKI we have the RSC.

**Bob Beck:** Right. So why not use the RSC to sign it?

**Jeff Haas:** Because we do not want to give the RSC—as if you—we do not want to make it where if you get your RSC certificate, you may now in theory also make BGP connections anywhere that are trusted. We do not want to turn the RPKI into a root of trust for BGP peering sessions.

**Keyur Patel:** And we’re over time, and we’ll take this into the list. Thank you very much.

**Jia Ge:** Okay, hello everyone, I’m Jia from Zhongguancun Laboratory, and today I will introduce our updates on this draft, [draft-ietf-sidrops-aspa-verification](https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/), ASPA-based AS path verification for BGP export. And on behalf of all the authors. At IETF 122, we first introduced this draft and presented the verification procedures. And at IETF 123, we presented version 2, which contains the basic motivations and beneficial cases. And today we are presenting version 4. Since last meeting, we have had extensive and productive discussions on the mailing list and among all the authors, and we’ve also welcomed Sriram and Nangang as new co-authors. So in this version, we address the comments from the community by clarifying how egress ASPA works together with the OTC attribute and how to handle the complex BGP sessions. And we also introduce several optimization strategies to reduce the processing overhead. And also we are working on the version 5 to address several remaining open issues, which I will discuss it later.

**Jia Ge:** And so before we dive into the new updates, let’s do a quick recap. Traditionally, the ASPA-based AS path verification is performed at the ingress. And our draft proposed to apply it at the egress, right before an update is sent to a neighbor. And why do we need it? We have three main motivations. Firstly, it is crucial for partial deployment scenarios, act as a safety net when the ingress routers are not yet upgraded, ensuring no unknown invalid routes are sent to eBGP peers. And secondly, it can prevent local AS misconfigurations. For example, in AS federation scenarios or during route manipulations, just like R Origin Egress does for invalid origins. And thirdly, it can detect ASPA registration errors earlier, such as a provider AS are mistakenly omitted by some ASPA records, which could otherwise lead to unexpected invalid results.

**Jia Ge:** And moving forward to version 4, firstly we’ve added a new section 3.1 to clarifying the positioning of egress ASPA. Just as this diagram shows, there is a knowledge gap between the ingress router R1 and the egress router R2. R1 knows the exact peering relationship with the ASN from its local configurations, while R2 lacks this context and can rely solely on the ASPA record, which can be inaccurate. So because of this, the egress ASPA is designed to complement ingress ASPA verification and its core value lies in the partial deployment scenarios. In our recent discussions, some ISP operators shared that they often have some legacy border routers that cannot support new technologies and will take a long time to replace. So this makes the partial deployment scenarios within an AS a very realistic and long-term scenario. And furthermore, major ISPs emphasize their goals to never send invalid routes to their eBGP neighbors. So it is crucial for egress ASPA to act as a safety net in this interim period.

**Jia Ge:** And following up on that, since R2 lacks the context of the ingress, it is imperative that the ingress router R1 could attach the OTC attribute when receiving a route. So we’ve established a clear priority here that OTC comes first. Even if the ingress routers R1 are not upgraded for ASPA, it should ideally upgraded for OTC. And once the OTC is deployed, its outcome cannot be overridden by egress verification.

**Jia Ge:** And also we added a new section 3.2 to address a very practical operational concern, which is complex BGP sessions. In real-world networks, relationships between two AS are not always strictly customer-to-provider, provider-to-customer, or peer-to-peer. Sometimes two AS maintain a complex AS relationships. So if such complex relationships can be segregated into multiple eBGP sessions with clear roles, the operators should split them and select appropriate algorithm for each session based on its peering relation type. However, if such complex relationship cannot be segregated and exists within a single BGP session, we provide two practical options. Option 1 is that the operators could apply algorithms on a per-prefix basis. If it is not feasible, the operators could apply downstream path algorithm by default in order to avoid false positives.

**Jia Ge:** And also a common question we get is about the performance. If we perform ASPA verification as the ingress, won't doing it at egress double the router's workload? So this new section 4 addresses this concern by proposing several optimization strategies. For example, for full routing table scenarios, routers could process egress ASPA once centrally and push its outcomes to all ribs-out for all customer-facing interfaces.

**Jia Ge:** And finally, here are some open issues we are still working on. The first is about the verification procedure, especially the "prepend neighbor AS" option. Just to recap, it means that when the egress router perform the verification, it prepend the next neighbor’s AS to the AS path before conduct this verification. And in our analysis before, this can enables earlier detection of local misconfigurations and registration errors. And so we co-authors are actively discussing the trade-off between this security benefits and the potential computational overhead. And our current plan is to position this prepending optimization as an offline verification process, rather than an inline requirement. This makes the most sense and is aligned with the version 23 ASPA ingress draft.

**Jia Ge:** And the second focus is about the optimizations. We are also discussing how to reduce egress ASPA performance overhead while maintaining necessary security benefits. For example, we are planning to explore the partial verification optimizations, which means that the ingress routers could use some local signaling to send its outcome to the egress routers, so that the egress routers could reuse known results. And thirdly, we have done a lot of work on the restructuring and refining the draft itself. We are reorganizing the draft to improve its readability and, more importantly, we are detailing specific scenarios where the egress checks truly add value.

**Jia Ge:** Okay, to wrap up, we are actively preparing version 5 and here is some open issues to be finalized, so we humbly seek feedback and suggestions and technical inputs on this draft. Thank you.

**Keyur Patel:** Thank you. Anyone has a comment or a question? Nobody in the queue. So, you're presenting also the next one? Okay.

**Jia Ge:** Okay, thank you. And I'd also like to introduce a new draft to the working group, which is [draft-ge-sidrops-rpki-prioritized-resource-data](https://datatracker.ietf.org/doc/draft-ge-sidrops-rpki-prioritized-resource-data/), RPKI-based validation with prioritized resource data. Okay, let’s start with the problem statement. The real world of routing options are very complex. We face incomplete ROA coverage and sometimes even inaccurate ROA registrations. So to cope with this, operators may use some heterogeneous local data such as AI inference or historical analysis via SLURM. However, the current validation system is quite rigid. Invalid results triggers the exact same action like dropping the routes, regardless of whether this outcome came from a highly trusted global ROA or a less trusted local supplement. The reality is the local register data or the AI inference data are not always accurate. If we blindly drop the routes based on them, we may risk false positives or sometimes cutting off legitimate traffic. So this forces operators into a frustrating binary choice: either fully trust the supplement data and risk misjudgments, or completely ignore them and also lose its potential value.

**Jia Ge:** So our core idea to solve this is to introduce a priority level to every piece of validation data. For example, for an RPKI-signed ROA, it gets priority 1, representing high trust. And for an AI-inferred policy, it gets priority 2, with medium trust. And this fundamentally shifts the validation status from simple valid/invalid/unknown to granular status like invalid 2 or invalid 1. And now the validation results carries metadata about its own creditability, which could allow the routers to fine-tuning the routing policies on this specific creditability level.

**Jia Ge:** Okay, let’s look at a concrete use case. Imagine a router have two validation records: one is from the global RPKI with priority 1, and the other is from AI inference with priority 2. And now the route A comes in, and it will be validated as invalid 1 against the global RPKI. So the operators will have high confidence of it is a hijack and can apply strict discarding policies. And when the route B comes in, and it is validated as invalid 2 by a maybe AI inference data. The confidence is lower, and instead of just dropping it and maybe risk connectivity, the operator could apply a conservative policy like demoting its local preference or issuing a warning. So this approach could enable a fine-grained, risk-aware routing security policies.

**Jia Ge:** And here is the high-level framework to support this. Firstly, the relying party or cache server could aggregate data from different sources, assigns priority levels, and merges them based on a defined algorithm. And secondly, we can extend the RTR protocol to carry priority information within its PDUs to routers. And finally, the routers perform priority-aware BGP route validation, producing annotated results and execute locally configured policies based on both the state and the credibility.

**Jia Ge:** To make this work, we outline several protocol extension requirements in the draft. Firstly, the relying parties should be able to assign merged data. And second, SLURM format should be extended with the priority attribute. And as for the core RTR extension, we provide two flexible implementation models. The first model is an integrated approach, which we can extend the RTR PDU with a new field to carry the priority and it can be in a one-session model. And the second model is a segregated approach that we can use existing RTR protocols and establishes multiple RTR sessions to different caches, each dedicated to a specific priority level. And finally, the routers must be updated to parse annotated validation states and to apply policies accordingly.

**Jia Ge:** And the key benefits of this approach is twofold. Firstly, it can provide enhanced operational flexibility. It moves route validation from a binary decision to a multi-level process. Operators can define fine-grained policies that match their actual risk tolerance. And secondly, we believe this can truly accelerate RPKI deployment by lowering the barrier to entry. Operators can supplement low-coverage RPKI data with other local sources without losing the ability to act decisively on high-confidence invalid routes.

**Jia Ge:** And also here are some key feedbacks from the mailing list around our draft and I want to share and respond to them. And firstly, Maria brought up a very practical point that some software companies like BIRD have already doing this by allowing multiple RTR, multiple tables, and multiple ROA evaluations. And also she advised against complicating the validation algorithms. And actually we are very glad and very encouraged from this feedback that the operational need for this separation already exists in the wild, and we strongly agree on keeping the base validation algorithm simple.

**Jia Ge:** And here is the second feedback from Nick regarding the protocol complexity. And yes, we strongly agree that modifying the RTR protocol is a heavy lift. This is why we propose the zero modification option in our section 4.2 by using a multi-session RTR approaches, we perfectly aligns with what BIRD already does. And the core takeaway here is that the routers still need a way to differentiate the data confidence levels and to apply the policies accordingly, for example, dropping or just alerting. So we are very open to explore how to minimize the protocol changes, for example, the multi-session approaching or any other solutions.

**Jia Ge:** And thirdly, Willem pointed out that hard-coding our specific priority context to a protocol is too narrow. And we really appreciate this feedback. And involving this into a generic RTR tagging mechanism, maybe which is conceptually similar to BGP communities, is a great idea. And we believe this pivot will not only solves our specific mixed-trust data scenario, but also provide the broader community with a highly flexible tool to extensible routing policies. And we really want to hear about the opinions in this point.

**Jia Ge:** And Rolf commented that the RPKI trust should be binary and based on the cryptography. And I want to clarify that we are not replacing cryptography. However, in the real-world deployment, especially in this early-stage deployment, data gaps exist and operators need supplementary data. And in the meantime, the SLURM already sets a precedent for this. And also our approach actually increased the safety: by explicitly tagging the AI-inferred data or local register data as lower priority, we ensure that this data cannot cause aggressive actions like dropping the route, which only the signed ROAs can.

**Jia Ge:** And okay, that’s all we want to share. And we proposed a flexible framework that introduces fine-grained priority-based control to the RPKI ecosystem. And since this is the version 0 draft, so we humbly seek feedback and support from the Working Group, and we especially welcome discussions on the protocol extension details, for example, the best approaches to extend RTR. And many special thanks to those who gave us valuable suggestions and comments. Thank you.

**Keyur Patel:** Anyone has questions or suggestions, anything? Apparently not. Thank you. Really wish to discuss more on the mailing list. Okay, thank you. You surely can do this.

**Miling Jia:** Oh, good afternoon everyone, I’m Miling Jia from Tsinghua University, and today I’m going to present our work about source address validation using source origin authorizations, [draft-ietf-sidrops-bar-sav](https://datatracker.ietf.org/doc/draft-ietf-sidrops-bar-sav/), we call it SOAS. So, here is an outline of my today's talk: a short recap and introduce to the update since last presentation one year ago, and then we explain how we revised drafts based on feedback and then future work.

**Miling Jia:** Let’s start with a quick recap. SAV or source address validation is actually a very simple idea: we want to check if the source IP address of a packet belongs to its sender. In other words, we want to prevent IP spoofing. So why is this important? Because many network attacks, especially DDoS, rely on spoofing the source IP address because the attacker don't want to be caught. If we can stop spoofing, many of these attacks can be significantly reduced. However, the problem becomes much harder in inter-domain scenarios. First, only the source network knows the real forwarding path of a packet. Second, the best place to filter traffic is usually large core networks. And most importantly, those core networks don't have the information they need, so they can't cooperate finely. So we end up with an information gap: the source address know the truth, the big ASes is in the best position to act, but they cannot effectively cooperate. So this is why traditional SAV solutions don't work well across domains.

**Miling Jia:** And yesterday I listened to Geoff Huston's talk; he mentioned that some internet problems are hard not because they are technically difficult, but because they are economically misaligned. The cost is borne by one party while the benefits go to others. We believe this is exactly the case for traditional SAV. To address this, we propose a model called SAPS: Source Address Protection Service. This idea is to turn SAV into a service. There are two roles: first is the subscriber AS. This is the network that owns IP addresses and wants protection of its IP prefix. It means to protect its IP prefix from being spoofed by attackers, because such spoofing traffic is usually used to do reflection DDoS towards itself. So it provides path information and pays for the service. Second, the provider AS, typically large core networks. They use the information to filter spoofed traffic that pretend itself as sent by the subscriber. And they get paid for doing this. So why is this deployable? Because both sides have clear incentives: subscribers got protection and providers got revenue.

**Miling Jia:** Next question is: how do we make this trustworthy? We leverage RPKI for this. Because RPKI already provides three things we need: global accessibility, trust between networks, and secure data distribution. And this leads to our key object, SOA. You can think of SOA as a trusted path note. It is issued by the subscriber AS, the IP prefix owner, and stored in RPKI and tells the providers what the legitimate previous hop AS should be—that means where the traffic will come to the provider AS. So provider can use this information to filter invalid traffic.

**Miling Jia:** Now let’s move to updates. The first major update is a new draft, [draft-ietf-sidrops-soa-profile](https://datatracker.ietf.org/doc/draft-ietf-sidrops-soa-profile/). This draft focuses on the technical definition of SOA object, like what does an SOA object look like, how is it structured, and how do we validate it. We also include some basic operational guidance, for example, where to deploy SOA for better effectiveness. And the second part is an upgrade of SOA usage. We addressed several key pieces of feedback. First, some expert pointed out that incentives were unclear, so we made it much more explicit: SAPS provides security value for subscribers and financial incentives for providers. And second, about accuracy of path information. There was concern about that subscribers may not always obtain correct path data. Our response is: we just want to focus on how to securely distribute the information after it is obtained, and we leave room for future methods to get this, such as BGP-based methods or AI-assisted approaches or something else. About ACL limitations from a previous chair of SIDROPS, we improved this by integrating SAVNET. Oh, that’s another Working Group focus on source address validation, SAVNET. It has a draft about general SAV capabilities, and it supporting prefix-based interface blocklist or whitelist, and that very fit our solution. And that’s allowing aggregation of SOA prefixes. And second about dynamic routing issues, that’s from Jeffrey Haas. Routing changes quickly but RPKI is a little slower, so we propose several improvements. Subscribers should update SOAs as the route changes as soon as possible. Providers should increase the polling frequency and use on-demand RPKI fetching to reduce overhead. And we introduce real-time alerts for large-scale filtering events to check if it is true alert or wrong alert.

**Miling Jia:** Then let me briefly talk about the future work. First we will refine IANA considerations, and then we want to improve synchronization speed of path information to the next step. To do that, we are exploring a two-tier architecture. Because RPKI relatively slow, we separate the responsibilities. Tier 1 is RPKI, it’s for peer discovery, identity, and base information transmission. And the other tier, Tier 2, is the private channel. It’s for real-time updates, allowing faster responses to routing changes. So we don't transmit the routing changes through RPKI; this allows us to balance security and responsiveness and performance. And that’s all my presentation. Thank you very much for your attention, and we appreciate any comments or feedback.

**Keyur Patel:** Thank you. Nangang.

**Nangang:** Thank you, thanks for the presentation. I'm Nangang from Huawei. It seems like it's not a traditional SAV mechanism and is more like a path protection. So my question is: there may be multi-hops for the subscriber AS to reach the destination and there will be many provider ASes. So does the subscriber AS need to pay for all the provider ASes to protect its source addresses?

**Miling Jia:** Sure. If it provide—subscriber one provider’s service, it should pay for one, yeah. Every connection needs a cost.

**Nangang:** Yeah. My further question is there may be too many provider ASes and maybe one-dimensional for the protection—I mean, suppose we only use the source address to do the validation, it may not enough.

**Miling Jia:** Yeah, we need the TOA promoted by Lanzhen and ROA; we can combine them to get the source address mapped to AS.

**Nangang:** Yeah, maybe you can also consider the destination AS, two dimensions.

**Miling Jia:** Yeah, that I think maybe too complicated.

**Lanzhen:** Lanzhen from Zhongguancun Laboratory. I have the same concern as Nangang. Could you turn to the page 5? Yeah, yes. The first question is the name "Source Origin Authorization." I feel this name is improper because the content of your proposed signed object doesn't contain the source address origin. It actually contains path information, and specifically it contains a list of AS numbers, right? It’s not source address origin, it’s the which ASes will transit the traffic to you. Yeah, that source may be considered as source AS. Yeah, but I’d like to clarify that those are not source address. So I think the name should be revised. And the second question is: I think the legitimate previous hop AS information is hard to be determined by the IP owner. Because the forwarding, when traffic is forwarding from the source origin to the destination, the forwarding policy is not controlled by the IP owner. And you also clarify that maybe some AI tools can be used to find this information. But I don't think you are leveraging the benefits of RPKI. Yeah, that’s my second question. And my last question is: you mentioned that there are two ways in the future. The first way is using RPKI to store this information, and the second way is using a private channel to transfer this, right? These are not two options, they are working together. We use RPKI for first information transmission and then we establish a private channel. Yes, I understand. And my concern is that I don't think this information is suitable to be stored in RPKI. Because RPKI is a public database. Yes. But the payloads of the SOA object appears to be only useful to the verification AS recorded in the SOA object. Yes. So this information doesn’t need to be public. So I think the second way is preferred. Thank you.

**Miling Jia:** Yes, that’s also concern of me, so I split the responsibilities. If we split it to two tiers, the path information won't show in the SOA object. It will only contain the basic information of the subscriber and provider, and they can find each other and then other detailed information will be transferred by the private channel. And that’s what we think about next step. And the second question, in fact we are doing the research about difference between data plane and control plane data, so we can get the path information from control plane data. If it is identical to the data plane path, we can just use the control plane. Yeah, that’s research of now ongoing one. Yeah, thank you.

**Keyur Patel:** Anyone else in the queue? Nobody else in the queue, so thank you very much for your. So thanks to all the speakers that were very diligent. We have some time spare so we can take the first presentation which is in the overflow list.

**Sitong Liang:** Good afternoon, I’m Sitong Liang from Zhongguancun Lab. I will present our draft for ROV deployment transparency, [draft-liu-sidrops-rov-transparency-profile](https://datatracker.ietf.org/doc/draft-liu-sidrops-rov-transparency-profile/). Let we start with problem. ROV deployment remains partial and the partial deployment is a lasting reality. So, when an AS detects a hijacked route from the upstream AS, this means that the upstream AS does not deploy the ROV when the current path travels through the compromised upstream, the traffic may be hijacked even though the AS performs the ROV. Let me see the diagram 1. The original AS path is AS1 to AS2 to AS3 and to AS4. AS3 is yellow means that it does not deploy the ROV. So when the AS5 announce a hijacked prefix A and announce it to AS3, AS3 will accept the fake source and announce the route to the AS4. AS4 performs ROV and filters out the hijacked route. AS4 continues using the original path AS4 to AS3 to AS2 to AS1. AS3 however will forward the traffic towards the fake origin AS5, so the traffic is hijacked even though AS4 has deployed ROV. The core challenge is that AS cannot identify which alternative path goes through ROV-deployed upstream AS.

**Sitong Liang:** Our solution is ROV Tag, a new RPKI object declaring ROV deployment status. The core field is `ROVDeployed`, a boolean must be true. The structure includes version, ASID, and `ROVDeployed`. The validation follows RFC 6488 template. The target is for transit AS, the stub AS registration is not recommended. The ROV Tag is designed for a defensive mechanism, which is triggered only when a security problem is detected. The flow includes five steps. First, AS performs ROV validation, detects hijacked route. And then it identifies the immediate upstream AS that propagated it and recognize current path also goes through that upstream. If it continues on the current path, traffic will be hijacked. So the AS can use ROV Tag to find alternative paths whose immediate upstream has declared ROV deployment. AS may prefer this safer alternative path to avoid the compromised upstream AS3. It is noting that the defensive mechanism does not change normal routing decisions.

**Sitong Liang:** Let me see a concrete example. Without ROV Tag, AS4 cannot tell which alternative path goes through ROV-deployed upstreams. With ROV Tag, AS4 can fetch the ROV Tag objects, learns which of its upstreams have declared ROV deployment. AS4 can prefer paths whose immediate upstream has ROV Tag with `ROVDeployed` is true, avoiding the compromised upstream AS3. In summary, ROV Tag provides the missing visibility when a security problem is detected.

**Sitong Liang:** For the technical details, ASID defines ROV deployed attestation, which includes version, ASID, and `ROVDeployed`. Validation follows the RFC 6488 template and the storage can use efficient lookup, for example, hash tables. The target is transit AS, the stub AS should not register the ROV Tag because they typically have limited path choice. We acknowledge a limitation is that the ROV Tag itself asserted, no cryptographic verification that an AS actually perform ROV. But the ROV Tag is designed only for defensive use, which is triggered only when the security problem is detected. This reduce abuse incentive and the false claims carry reputation risk in routing community. We also offer an optional mechanism to record inconsistent behavior. When an AS receives an announcement include a RPKI invalid source and the upstream declare a ROV Tag on the RPKI, this is a inconsistent behavior record. AS can prefer upstreams with no inconsistency record when selecting paths. Draft 01 is submitted and we seek feedback and discussion. An optional future direction is fine-grained control. For current version, only a single `ROVDeployed` per AS is needed. This is coarse-grained. A potential extension is per-neighbor declaration. For example, ROV performed for routes from ASX, Y, not for routes from ASZ. This enables more precision path selection when an AS performs ROV only for routes for certain upstreams. Thank you, questions are welcome.

**Job Snijders:** Job Snijders, Fastly. I have some concerns in relationship to this proposal. This proposal mimics a discussion that has happened in the industry in PeeringDB—it's not the RPKI but it’s a central database for peering information—where people argued "Hey, should we put on your PeeringDB record, not only your company name, your AS number, but also do you do ROV, yes or no?". And the discussions in that community led to an outcome that they decided NOT to include a self-asserted statement on ROV because it’s very much "do, don't tell." There's intrinsically in having a data type like this in a database like the RPKI, it can be out of sync with reality. People can accidentally publish an object "I do ROV" while in reality they are not at all doing ROV. You in one of the slides you mention well, there is reputation damage, maybe. I don't think there will be any reputation damage. People will just be like "This field, this object in the RPKI doesn't mean much."

**Job Snijders:** Then there is the complication that in ROV deployment, in my experience, especially in larger networks, it is possible that in certain segments of the network you have ROV enabled but not in other segments of the network. And this can change in the span of a few hours. The ROV can temporarily be disabled because the TCP connection to the RTR server is inadvertently terminated for a number of hours without anybody noticing, and then you have a discrepancy between the actual state of the network and what was described in the RPKI. Now, enumerating each BGP session, I think is a significant complication because some networks have tens and thousands of BGP sessions times IPv4 plus IPv6 times inbound and outbound, and there’s so many permutations and flavors of ROV that trying to enumerate that accurately is guaranteed to be out of sync.

**Job Snijders:** And then finally, the what REALLY is doing ROV? Because if I use only four out of five RIR trust anchors, I will not be doing ROV for IP resources managed by the RIR whose trust anchor I am not using. So, that would be like a partial ROV deployment, but what if my legal team says "Well, you can use all the trust anchors except THAT one" for some reason? So from my perspective, it is not a partial ROV deployment, it is a very complete ROV deployment to the extent of the advice of my lawyers, for example. So in short, I do not think you can accurately capture the ROV policy of any network in a boolean data type, and it will not fit in other data types either, so it will always be out of sync with reality and that diminishes the value of a signal like this. So, from my perspective, continuing work in this direction is probably not productive and similar work in different platforms like PeeringDB came to the same conclusion. So I don't think there's no new information in that regard, so we will probably come to the same outcome. But thank you for your time and investigation in thinking of how this could be approached, that is much appreciated.

**Sitong Liang:** Thanks for your comments.

**Luigi Iannone:** Okay, thank you very much, the time is over. We have one minute left, there is not that much to do a new presentation. So thank you very much to all the presenters. For whatever question not solved here, please continue in the discussion on the mailing list, and we resume in Vienna.