**Session Date/Time:** 19 Jul 2026 08:00

[00:00:08] **Warren Kumari**: So are you gonna do the introductory bit? Yeah. Good

[00:00:13] **Jen Linkova**: morning. Welcome to the IEPG. If you don't know what the IEPG is, it's a small informal session just before the ETF.

[00:00:28] **Warren Kumari**: Or a large informal session this time. Yes.

[00:00:32] **Jen Linkova**: And we're normally talking about operational issues, not drafts. Please keep this in mind. And actually, I will read over time because this time we have zero time for our slides, and we have a really packed agenda. It means that I'd like to presenter I'd like to ask presenters and people asking questions to be on time because we cannot allow to run over. This time, we do have one presentation in the time permitting category, which unfortunately unlikely to happen. Sorry, Philip. You know how much I would like to see I p v six presentation here, but, but, as far as I know, Philip will be presenting at v six ops on Friday, so you're not missing much this time. So just join v six on Friday. Okay. And the first presentation today is Andre. I'll it will take a few seconds.

[00:01:26] **Warren Kumari**: And Andre is super organized and up here already. So

[00:01:30] **Andrej Surý**: thank you so since you have zero minutes. You know?

[00:01:33] **Jen Linkova**: So Obviously, my fault. Yes. Hold on.

[00:01:36] **Warren Kumari**: Always Jen's fault.

[00:01:37] **Andrej Surý**: I am Andre. I see DNS. Okay. So there's a question on the slide. Think of a number. Hold on.

[00:01:46] **Jen Linkova**: It takes time to give you a slight control. Yes.

[00:01:50] **Andrej Surý**: Okay. So do you have a number in mind? So here's my number. Is your number any time close? Anywhere close to my number? Okay. I'll show you what's what's going on. So all numbers come from BIND 9 with cold cache. We count queries and we add up complexity. And there are free delegation side. I I'll I'll explain them. I gave this talk at right meeting. If you saw that, I made this one shorter because this packed agenda and updated the numbers because some changes happened. There are also CNAME chains that that makes things worse, how much DNS it costs, and the PTR, the damn PTR. So recursive resolution in thirty seconds, or if you if you know DNS, this is your bread and butter. But we go to root, we go to TLD, we go to the ultra new zones, and that should be simple. Right? So and every arrow is run through time, and the cache hides it until it doesn't. So this is the naive floor. In ideal conditions, the number of the queries should be free. I'm guessing you already know that it's not. This is how it looks like. For just www.example.com. There's a great tool from VeriSign trans-trust.verisignlabs.com. It will show you all the dependencies. And this is quite normal. This is not large large one. So delegations, you have three types. In domain, the nameserver names lives in the zone itself, and the glue is mandatory. There's no extra cost. If it's in Bailiwick, the name server names lives in the part of the zone. The glue can be used or not, and the extra cost could be something like zero to number multiplied by two. If it's out of the bailiwick, this means it's unrated zone. The glue is not allowed, and the extra cost is always there. So examples. In domain, wikimedia.org is delegated to ns0.wikimedia.org, and the glue must be there in the parent. Otherwise, they

[00:04:26] **Tim Bruijnzeels**: have a

[00:04:26] **Andrej Surý**: chicken and egg problem. And there's no change over the baseline because you can go one after other. Couple of top 20 domains does this, and there's a reason for this. In Bailiwick, there's a sibling glue, which means that the ripe.net name servers are in APNIC, APNIC, LACNIC, ARENN, and they are all in .net. The parent can ship the glue. It's authoritative for the sibling. And whether Resolver can or will use it depends on the policy and on the number of the CVEs. So if if the glue is always trusted, which was before the CVE, there's zero extra cost. If the glue is ignored, then there's smaller sub resolution because we are still in .net. There's also reason for for this, but it's not technical. Out of the bailiwick, for example, example.org, it lives in .com, in Cloudflare, and parent has no authority over .com. And Glue, if present, is untrusted, and resolver must just go and resolve everything. So and even if in this case, there's also reason for this, how, why to do this. So it's just, you know, the graph how to how to do that. And what does it cost? The teams of microsoftcom was picked because it's quite large. This is this is just the first c name. So with different versions of the bind, you can see we improved a lot in in the last one. It costs somewhere between 88 to 142 queries on by $9.18, which just went end of life. With $9.20, we already used the number, so it's half of that. With $9.21, it's eight plus. I measured the lock entries in the in the bind. I can share the script if you want. Just give me an email. And this is, you know, 10 measurements, and it just differs widely. But teams.microsoft.com is not an a record. It's a c name to another and to another and to another. There's, like, four c names if you ask for teams.microsoft.com. And each c name target is a fresh resolution, and each target may have yet under out of the delegations. And each NSF may spend multiple TLDs, so it just explodes. It just doesn't doesn't add few of them. It just ex it can explode, and it often does explode. So counting the whole Microsoft Teams resolution, again, DNSSEC off, DNSSEC on. So in the worst case, we are somewhere in 182 queries sent out for the single incoming query for .teams.microsoft.com. Again, nine twenty one improved a lot. Now the fun with the reverse records. The reverse DNS is everywhere even though it's hidden because, you know, users don't use it, but the systems use it. Mail servers, SSH, Traceroute, NetFlow, monitoring, access logs, everything just tries to resolve the names to to name. And RiverZones originally have out of bailiwick delegations on every level. Like, the regional registry, local ISP customer, and there's it is separate infrastructure from the from the forward zones. And it's not that uncommon that there's a broken or missing glue and TTLs that nobody ever looked at. So I p v six PTR, that's even worse because there's 32 labels, and every of them can be delegation. Just don't do that, but you can. Every level of the I p v six PTR can be delegations. That could be 32 delegations. Just an example for a name two one two dot in Ada Arpa. So the first level is root servers. It's strict bailiwick because the you know, everything lives under root. For in other ARPA, that's the sibling because it lives in dot ARPA, but it gets more complicated if you really look at this. Then we get go to to the, you know, the level where we get the all the regional registries, and then it starts exploding because it's not a bailiwick. It's out of the bailiwick, and the resolver needs to do the full full thing. So I'll skip this because there's a time. And the number of the queries is very large. So few examples. So this is the one I I showed you at the beginning, 329. Again, the picture for this domain. It's clickable. If you download the slides, you can click and and you can look of what what you can find what all the domains you can find in this graph, there's a lot. So there are two different approaches in the resolver. So one is that you should resolve everything and resolve bare minimum. And NADR is really viable because it needs to be something in between to preserve resiliency of the DNS system. So we limit the number of DNS resolved, limit the number of the IP addresses to some reasonable number, which is around 20. So what went wrong? If you look at the difference between 09/2013 and 09/2014, it just explodes. That's when the CVE came. Cache poisoning using sibling glues. So by 09/2014, just has to ignore the sibling glue. We've we improved a little bit with the latest version where we reduced the number of the upgrade queries. So what went well in 09/21, which is a development release. We switched from the child centric to parent centric, and these numbers are more reasonable. So what you can do, prefer in domain delegations where you can. If you must use managed DNS provider, pick just one or two, not for each across different TLDs, or did the scene in-depth. Every hop is a fresh chain, and, again, it can explode. Key PTR delegations, boring, in domain, in Baylor, GLUT. Manage DNS providers. For LoveDoc, do in domain delegations for the client name servers, and resolver operators use the latest version of the software. It improves. Enable aggressive NSEC if you haven't, and that's it. So the takeaway is you didn't expect this number. Review your domains and, you know, having multiple TLDs in is not resiliency. It's makes it worse.

[00:12:04] **Jen Linkova**: Okay. 15. The next.

[00:12:09] **Jan Ruth**: I

[00:12:12] **Andrej Surý**: have time. Oh. I still have time.

[00:12:17] **Warren Kumari**: Maybe we have time for for managing to get your thing done in half the time you expected. So questions? And also, if anybody has an open chair next to them, can you stick your hand up and wave it about because there are people in the room looking for

[00:12:30] **Job Snijders**: I was kind of surprised to see

[00:12:32] **Andrej Surý**: so little time, but no.

[00:12:34] **Warren Kumari**: I'm assuming people have questions about this. There you go.

[00:12:43] **Peter Thomason**: Hi. Is this how I speak? Hi. This is Peter Thomason. So you just said on the previous slide that people shouldn't be picking name servers under multiple TLDs. And if you had, for example, an external hosting provider that had four different TLDs, then you would have more resolution queries. But in practice, you don't start from a cold resolver cache. You also said that for any thing you've seen the access log for PDR queries, the resolver will redo the whole thing. But there actually is a cache. So what's the practical impact?

[00:13:17] **Andrej Surý**: The practical impact is that people start when we when we did this, people actually started complaining that there because there's a hard cap of 50 or 100 outgoing queries in the resolver, then people start complaining that some of the PTR don't resolve. And the mail mail delivery fails because mail servers handles are fail, like, hard error or something. So it is visible on at least in the PTR space. Also, I've seen reports of the, you know, exactly the teams microsoft.com when the server restarted. And there's an impact, maybe not in the common case because, you know, the root gets cached and the TLDs get cached. But if you if your top number is 300, then when TTLs expire, then you are, again, in the area of doing, you know, 150 more when you don't have to. So it it is visible. It it's not like a huge problem, but there's a small place where this is causing operational problems.

[00:14:37] **Geoff Huston**: Jeff Houston, I'd I'd like to press on with that because I think this is fascinating. But at the same time, the cold start problem is actually quite rare. And the realistic question is, to what extent in a world where resolvers are warm and, in general, the best caches are hot caches that are full. To what extent is this a problem, and can we measure it? What would be an approach that instead of doing a cold start and doing this, how we'd look at resolve occasions that are actually running and in progress? And for something like teams.microsoft.com, which in theory is gonna get flogged a few million times a second, Is this a problem?

[00:15:22] **Andrej Surý**: I don't know. I don't know. But there's There's a draft with Willem and someone else, I'm sorry, called Poisonlicious, which is about priming cold cache from the other resolvers. It might help here. So but it was visible, like, on the mailing list. So it means it is visible by the users. And the the cold cache might not be a problem for huge operators where where they can have a you know, they can keep the caches hot. But someone who just runs a single or two name servers and has has to upgrade then because of the older CVEs with the LLMs now, then they have to restart at least once a month or something. So it is causing a little bit of problem. I'm not saying this is a huge problem, but it was surprising to me, so I wouldn't

[00:16:14] **Geoff Huston**: Oh, I'm interested in trying to quantify it in real terms because like I said, the cold issue is, oh my god. That's terrible. But in reality, you kinda think in in in reality, in a normal case situation, how much is this an overhead for things like facebook.com, google.com? The answer really is, yeah, really.

[00:16:31] **Andrej Surý**: No. No. But but but, you know, facebook.com and google.com got it right. So but also we got a report from someone with reverse record complaining that it fails every time the TTLs goes out. So

[00:16:49] **Petr Špaček**: Patricia, I see. I will add that the problem is nondeterminism that once in a while, the TTL expires. Perhaps the TTL is half a minute because it's a crazy CDN with long chain. And then it occasionally fails, users complain that, oh, Teams, the Microsoft, whatever, don't work, which don't work most of the time. Right? But whatever. The nondeterminism is the problem because then it doesn't work for some people at random times. You cannot really bug that because it depends on the state of the cache. People complain, and you spend time debugging it for basically nothing.

[00:17:28] **Jen Linkova**: Okay. I put myself in the queue to relay the question from David Lawrence, who is somewhere in the room and couldn't get to the mic. He asked, do those count in counts include DNS well DNS validation queries?

[00:17:42] **Andrej Surý**: I'll go few slides back. I did the measurements if both of them. So this is the difference.

[00:17:57] **Jen Linkova**: What I'm doing, I'm doing the talking

[00:17:59] **Andrej Surý**: But the huge numbers usually does include DNSSEC. And queue name minimization doesn't help. And Warren asked me at the right meeting if the if the mirror roots, mirror zone Oh, that help. It it does

[00:18:12] **Jen Linkova**: help. Okay. Would I need to just

[00:18:17] **Andrej Surý**: But I couldn't fit it in the slides. Okay.

[00:18:20] **Unidentified**: That's it.

[00:18:21] **Andrej Surý**: So I saved you two minutes.

[00:18:22] **Warren Kumari**: Excellent. Thank you very much and we really appreciate it.

[00:18:26] **Jen Linkova**: I'll change the net.

[00:18:27] **Warren Kumari**: And we should do that in the future. We should tell everybody they've got fifteen minutes and only put thirteen on the thing. Next, we have Carlos Martinez on BGP ORIGIN. Okay. We couldn't see you back there. And Jen is busy bringing up the slides.

[00:18:52] **Jan Ruth**: Okay.

[00:18:57] **Carlos Martínez**: Morning, everybody. I I have I don't remember seeing a room this packed for IEPG in decade decades, I think.

[00:19:04] **Tim Bruijnzeels**: Oh, good.

[00:19:05] **Warren Kumari**: Yeah. Time

[00:19:05] **Tim Bruijnzeels**: is over.

[00:19:06] **Andrej Surý**: Yeah. Yeah.

[00:19:07] **Jen Linkova**: I told you.

[00:19:08] **Carlos Martínez**: Sorry. I'm gonna

[00:19:09] **Andrej Surý**: lie now.

[00:19:10] **Carlos Martínez**: So I'm I'm presenting on behalf of Celsa Sanchez from Nick Chile. So I take absolutely no credit for this work, but I I I saw her present this in LACNIC a couple of months ago, and I I thought it will be interesting for this group. So what Sensei did look into was the use of BGP origin. Who remembers BGP origin? I I actually have forgotten about it. It's something that it's already been there. We seldom use it or we seldom pay attention to it. It's essentially an one of the one of the original BGP attributes where it sets three values, one is EGP, EGP, and incomplete. The originals idea behind this is that in a world where BGP and EGP coexisted, it was important to know where a particular route was injected from. There is it it is one of the attribute that is evaluated earlier in the in b BGP decision process. Sorry. And it's that there is a decision order there that you can you can see. EGP is preferred over EGP and is preferred over incomplete. So it's it sits around the third place in the decision decision process. First, you have highest local pref, shortest day as path, and lowest origin type. So what does the RFSA RFC says? Forty two seventy one says that origin is one of the original well known mandatory attributes. This value is set by the originating router, and it should not be changed by any other speaker. And we'll see how that goes. So the idea is if you have an router that it's injecting a particular prefix, the value of origin should be unchanged throughout the Internet. It is not. And it's quite interesting. So what Celsa did Celsa did was take a bunch of files from different BGP collectors. Celsa focused on our region for for yep. She was she was trying to deal with a particular operation problem that had to do with how some prefixes Nick Chile was using was being, you know, announced and routed around the region. So this this this is actually the the graph that convinced me that it goes with this could be interesting to share in a wider audience. So you have there four BGP collectors, one in Chile, one in Mexico, and two in Brazil, one in Fortaleza, and one in Rio De Janeiro. And you see how widely different the distribution of origin values are, and the prefixes are more or less the same. So what is going on here? This is a methodology slide. Basically, what the sales are it was take four road view collectors, the four that I mentioned before. She took one RIB file per month, and then she sort of, you know, crossed that with the the files that we at LACNIC produce every day with the state of the registry where you can see who has where I'm sorry. Which prefixes have been allocated to different organizations from the region. You have there are some some examples, I guess. I I sorry. I'm not very clear about this one. But I want to get here. And this is this is this is really interesting. You have the the same prefix, the same one, with the same origin a s, but it's seen with different origin values in different collectors. And and this is weird. This is really weird. Right?

[00:23:32] **Jen Linkova**: Was.

[00:23:32] **Carlos Martínez**: So sorry. Remember that the recall that the value of mixed in the study means that you are seeing the same prefix with different origin values. Right? So we get our four, you know, collectors here, and then you get this 7% incomplete for the the Chile collector and 97% incomplete in a collector in Mexico. Sorry. Not complete. Mixed. Mixed. Right. So you get the same prefixes, but you have this really different and varied values of origin. So are some cases that are this is really interesting as well. You have the same prefixes, and you have the three values of origin for the same prefix and the for the same origin AS. So this is also quite interesting, my opinion, that this this have not been happening forever. This was a signal that appear around early twenty twenty three for reasons. You guys tell me what you think about that. This so this is this is essentially an attribute that had not been actively used for, I don't know, thirty years. And suddenly, around early twenty twenty three, some operators decided that is, you know, we have this little note here that is evaluated early in the process. Mhmm. Why not override it? So Celsa did a very interesting job, in my opinion, trying to contact individual operators because since this was a study focusing on the LACNIC region, you

[00:25:20] **Eric Vyncke**: we sort

[00:25:21] **Carlos Martínez**: of know each other. And he tried to contact people, and there was only one operator that answered her email. And this is we we are not you know, I can tell you in private who it is, but I prefer not to say in public. They say we have rather distributed across multiple countries, and one of the main metrics is, you know, origin. What we did was rewrite the origin for routes learned from other peers to EGP so that routes from the more distant routers will not be preferred. Interesting. So the main takeaway from this presentation, and I and I agree with Celsa's view on this, is that origin doesn't mean what it used to mean anymore. Right? So maybe this work here for the ATF. So sorry. We may want to, you know, redefine origin. Yeah. It means that it means a different thing nowadays, and it's used for a different purpose. It's already implemented everywhere. You don't need to redefine anything, but maybe, you know, some documentation, you know, documenting this kind of use will be will be nice. It's not specific to the LACNIC region. We are aware at least of one more person, James. Maybe James is here by any chance? Okay. No. Who has been working on on, you know, a similar measurement for the for the right for the right bridge. Again, it it doesn't mean any longer what we used to mean. Maybe we should redefine it or at least explain what people are try to describe what people are doing with it. Thank you very much.

[00:27:05] **Warren Kumari**: Great. Thank you. And I think I'm first in the queue with questions. Sure. Jeff Haas is behind. Jeff's probably going to tell me why what I'm doing is wrong or dumb. But back in starting, I think, the early 2000s, think actually the year of 2000, I had an issue where I would connect from a location to two different ISPs and changing AS path was too big a hammer because too much traffic would move. So what we would do is we'd use the same AS path length instead of prepending and just change origin and then that would give us like an extra knob that is less large. And I thought it was actually described I think I did a presentation at Nanog in like 2001 or 2002 or something, basically being like, This is how we do traffic engineering. AS path length is too big. This is the further down knob, and it's the only other knob that I have. But yeah, maybe Origin's just a bad name for it at this point.

[00:28:03] **Jeff Haas**: Yep. So two sets of comments. Comment number one, there's been talk in IDR about, you know, should we deprecate this thing? Because it does not mean what it used to. And, you know, one set says, yes. We should deprecate this. No. Make it go away. The other set is, no. No. We use this thing. So if you have opinions, one of the things for people to watch operationally for this is we're doing an update to forty two seventy one for core BGP. We wanted it to reflect reality, so please contribute. The second piece is I have dirty laundry that I will not fully expose. So for the LACNIC region particularly, it has become somewhat common to run optimal route reflection because the reflectors are not necessarily located where you think they are within the region. And this is partially because of the size of the geography and also the organization. The operators can out themselves if they so choose, but the consequences you had on there is that IGP distance is already being tuned to try to actually move traffic around the appropriate way. Exactly as Warren is saying, you know, there's only so much you can do with moving the AS path around before it starts perturbing, more importantly, traffic coming back to you. You can't make it longer. You can't make it shorter without necessarily changing the downstream. So this origin gives a way to try to yank it around a little bit. So it's this combination of you can't manipulate the s path, and operators are doing optimal reflection, which changes what IGP distance means. I think you're going to find, when you get around to doing your studies, there's a little bit happening in the right region, you know, very fairly small. The one that I'd be interested to see is specifically out of the Near Middle East areas. I think you'll probably find some interesting statistics there.

[00:29:57] **Carlos Martínez**: Thank you, Jeff. I am thinking about, you know, large geographies. Maybe Asia Pacific would be an interesting case for such a thing. So thank you very much to both. I I I was really surprised when I saw this presentation, to be honest. And, yeah, I think we all agree that the the operators felt that they they needed some an extra knob that didn't they didn't have another attributes. So maybe it's, you know, high time for documenting this behavior and that people use this, you know, without guilt.

[00:30:29] **Jen Linkova**: Yep.

[00:30:30] **Carlos Martínez**: Final comment. Neither Celsa nor I were trying to say that this is wrong in any way. Right? This is, you know, operator reality, and they feel they need it and they use it, and that's fine. What we feel is it will be useful for the community at large to document this kind of use. Last last comment. If you scan the QR, you are going to get the GitHub repo where the scripts and some of the source data files are.

[00:31:00] **Warren Kumari**: Cool. Thank you. But yeah. Thank you. You're like, that's right. The name is very confusing because, like, this comes from the EGP protocol. Like yeah. Yeah. Exactly. We'll document it.

[00:31:10] **Carlos Martínez**: I I I was trying to get Celsa to come here and present herself. She's very young. I think she wasn't even born when you give birth.

[00:31:23] **Warren Kumari**: Thank you very much. Thank you

[00:31:24] **Andrej Surý**: very much. Thank you.

[00:31:25] **Warren Kumari**: And next. Thank you. Next, we have observations of of Asper in the Wild by Tim. Jen is busy getting your slides organized. And thank you, everyone, for managing to stick within your time and being so good about that. And people in the back, there are still one or two empty chairs over there if you want to sit. There's one there as well. Or you can stand. Your legs.

[00:31:58] **Tim Bruijnzeels**: All right. I think I got a yes. I think I got a fairly large share on the agenda. I'll try to be quick. The Wild. Before going into this, I want to talk a bit about ASPA. Some of you will know how this works, others may not. So I think it's worth trying to explain it in eight minutes. Let's see. There's a clock. We can check. So ASPA is an object in the RPKI. It's fairly similar to ROAS in terms of how it's all done, like signed, published, checked and fed into routers. The difference, of course, is that it's about a different subject. In this case, an OSMA object is an object that allows a holder of an AS number to say, I my AS can be the customer AS to a listed number of providers. The fundamental function in evaluating paths is this. So looking from one AS to the next, you would end up with a result that says the next one is a provider, meaning it was listed. It is not provider, meaning others were listed, not this one. Or there can be no attestation, meaning there was no project. If we then look at routes that are received from customers, because I'll get to that, there's two different ways to evaluate the path, but regards to customers. Evaluated this way. So on the left hand side here is what would be plausible. On the right hand side is not plausible. The idea is reject what is not plausible or accept what is plausible, whichever way you want to phrase it. Now, last most is the case where we don't have any aspects at all. So we have no information, meaning it's all unknown. It is fine. We can also have partial adoption. So some of the hops have presence and they're actually good, others don't. As a whole, the path is still unknown because you don't know for sure what happened, you know, for the whole stretch of it. But it is still possible indeed. And that can also be fully covered, meaning that they all have to be valid provider in this case. Sorry. From the to the max, then the result is valid. Invalid happens when there's any occurrence of a customer to not provider. No matter whether there were other other customer to provider occurrences, that doesn't matter as long as there's one or more that says the next hop is not provider, then that path received from a customer would be invalid. For other routes, so routes received from peers or providers, it's using the concept of value free routing. So the idea is that a route goes up to a peak, let's say, and then it goes down again or could go up from the other side. And when there are leaks, we have what we call valleys. And this is a problem because it cause latency congestion. Actually, of course, possibly, data security could be an issue because packets go where you don't want them to go. And the way that ASPA deals with this is that essentially, it uses the customer to provide analysis from both ends of the path. So first, you try to go as far up as you can from the origin. You do the same from the other side. And then there can be a couple of situations that can be overlap, especially when there's not not enough information because you can go all the way from one site to the other and vice versa. They can meet in a single shared provider or there can be an adjacency for peering, which is also good. But if there's more, then it's considered invalid. So this is how that could look graphically. So in this case, you know, there is a bit of information there on the on the left hand side, but not much. So actually, if you go up ramp from the origin, you can go all the way the other side and vice versa. So it's all good. In this case, there's one in the middle that actually made a statement saying, have a provider. It doesn't really matter which one it is, but it's not either one to the side here. So that means that going up, you end there. Up ramp ends there. Down ramp ends there as well. It meets at one point. It's good. In this case, we have peering. So these two ASMs have other providers. Didn't declare each other as their provider, but they are appearing. I realize I yeah. Well, I want to update the slide with a comment, but I'll say it. When I first looked at the Asper algorithm, this was very confusing to me. Like, why would it be okay if something isn't valid? But it is very much used as a feature. If this wouldn't be the case, then all the peers would have to be declared and operationally that is not feasible. So that's why this exists. And this would be a case where we have an additional, a peer to peer to peer. So this one would be invalid. But it gets complicated, especially when you think that a well, when who you think is a peer may not be a peer, as we have have had in the in the right meet meeting network. The last right right meeting we were doing as well validation. And we had a case where actually, two, they sensed, thought that six nine three nine was their peer, but in fact, it was also providing transit. So Aspar flags this. They said, well, you told me this is not a provider. So in this case, it's invalid, so it gets rejected. And it got fixed by one of them adding 6939, in this case, to the Asper object, and then things started flowing again. Asparta doesn't really care whether it's intentional or not. It just flags like this is not what you declared. So in that sense, it's invalid. It could be a misconfiguration. It could be an actual leak. You don't know. As far as Aspera is concerned, it's invalid. So the fix could be two things. Add a add the provider or the peer that is actually not a peer but a provider as a provider or tell them to stop doing this. Oh, yeah. And importantly, if there is a mixed relationship, then please have a look at RFC nine nine two three four at BGP roles. So there's a thing in there only to customer that would actually allow you then on a pre per prefix basis to say, okay, this one is actually only to customers. So that can help somewhat in the more complicated cases. Now the curious case of AS0. We like to overload things, right? So AS0 cannot be used in BGP. So we can use it for other things. Like, in particular, we can create an OSCAR object that only has AS0 and that means no providers, none of them. It can be used by tier ones, transit free networks, but it's also used in other ways. I've heard people mention that I have an AS number, but I don't actually use it today, so I'll just create an AS0 aspect for it just to indicate that, you know, I'm not using it. And then my other cases where you can use it, like, for transparent route servers that are not supposed to end up in the path. How we would it look then? So it's pretty similar to the the the previous pictures except that, you know, here, let's say 65538 is a transit free network, they wouldn't have to say at some random AS as my provider, but they say AS0, meaning that everything stops there. And in this case, here, what I try to display is like a leak to a transit by a peer. So there's a provider here on the on the oh, sorry. There's a network here on the right hand side. They have their providers. They also have a peer. But their peer leaks this up to a transit free network. And and then OSPA actually catches this case. Because if you go up from the origin, well, you can't go to the 65,539 in this case. So it ends there, from the other end, ends in the transit free network, and the parts don't meet. There's a bit in the middle, so it gets rejected. And this is another example where there's a leak from one transit, you know, route received from one transit provided to and that's leaked to another, So that's also flagged. And yep. Sorry. In conclusion, did I say that here? Yeah. So one observation here is that transit free networks making a zero Ausma objects really helps quite a lot in in flagging Ausma invalid parts. Now, the more interesting bit, I guess, or the other interesting bit, uptake. So we'd like to do some measurements. And the easiest thing to look at, of course, is what what appears in signing. So we're looking at this for a while. And if we look at the I think there's actually a number of customer ASs even, but yes, same difference. We see that the uptake really started last year. Sorry. Before July last year, OSMA signing was available in Krill. And there were a number of people using delegated CAs, like non hosted by the RERs that were using Krill that were issuing us for objects and especially also in Brazil because that's where members actually have to run their own software. So some of them go went like, okay. What does this do? Let me use it. And that increased when the support for it was added to the UI. You can't really see it in this graph anymore because since then, more happened. So at RADMCC, we enabled this in November. And that's the bright blue line, let's say. So that went up quite quickly. Aaron also deployed. So the line for LACNIC, that includes Brazil. And then hard to tell here, but bottom right is APNIC. They've just enabled it as well and are now almost at the level of, Lechnic actually. If you look at is zero as per objects, there's been a pretty steady increase as well. We're now up around 60. And that got me thinking, can we use this information to learn something? So we have risk, route collectors, pretty well known, I guess. And what may not be well known, so I wanted to point people out of here as well, is that we also have a place now where you can get essentially all the information of our collectors for a day in a parquet file format. You can query this with a tool like DocDB, which is the one I use, but guess there's different ways to do this. You can have a look at all these different routes that are collected. So that's that's quite interesting, I think. Have a look if you if you want. So I used this and then, well, got the data out. There's some settings to stop my laptop from, you know, running out of memory. Especially, you need to do a trick where you don't get it to resort things and stuff like that because Well, anyway, ask me later if you want to know. That spat out all the paths that were seen And then I started looking at, okay, can I find the ones that leads to an AS0 issuing network? Something like a transparent route collector wouldn't be there, right, because they don't appear in that list. So the assumption here that is an on use ASNs. So the assumption here is that that would be mostly transit free networks and that I could analyze the path segment leading to such a transit free network as using the customer to provider algorithm. And then I can have, well, validity, ASPA path validity really only has three states. It's valid or it's invalid or it's unknown. But in my case, I want to differentiate for the unknowns a bit because I'm also interested to learn, okay, is it somewhat covered? So is it partially covered? When I did that so first of all, this is the development over time of the unique path segments that I can find. So this is mainly, well, closely correlated, I think, with this graph. Like, more is networks issuing ASIO. ASIO objects gives me more information. And then when I analyze these, I get to this. So partially valid here means at least one of these hops in these past segments were covered and they were okay. Crucially, they were not invalid. Invalid means there's at least one occurrence of something that is from customer to not provider. And there are, well, a fairly low number, but there are also parts that are fully valid. So that means that all every hop in that segment is covered and they're all good. So that brings me to, yes, these percentages. Another interesting thing to look at here is this. So what if we consider how common are invalid paths out of all the paths that we see some coverage for? Right? And then we get a number that is around I should have written this down. I think it's 7%. No pun intended, actually. But something in that order. I can look it up if you want to know it exactly. But, yeah, is this high? Is this low? I don't know. For comparison, I remember that for root origin validation, we had about a 90% match before people started doing root origin validation extensively. So there were tools that helped people do the right thing, but, you know, you could create objects and if they didn't reflect operational reality, you weren't really punished for it. And that number changed drastically once people started doing validation because then you have a pretty strong signal to to fix your ROAS, right, because things are dropped. And and the same might happen with ASPA that if you create an ASPA object that doesn't reflect the reality, today that has not so much impact. But when people start doing validation, then it will have impact. Right. But, you know, what can we do in the meantime? I think from our side as an RAR and providing an interface to our users, we can try to use maybe this analysis that I showed you to give people some insight in. We believe that these might be your providers, so help people in case they would forget. It may also show to people that some of the networks that they might believe are peers may actually act as providers. Another thing that I haven't had the time for, but what I'd also like to do is look at all this risk data and and and do a different kind of analysis. We do have no local knowledge about these collectors. So in principle, we could determine which of the two validation algorithms to use in each case. And by doing that and then really also applying like, okay, if I toggle the state of this ASM that you're looking at right now, doesn't have any impact on on validity, then we can get a better picture of, you know, who might be acting as providers in this case. Beacons are, of course, interesting. I know that Antonis, Sheraton is is running one that I heard of, and I'm not sure of others yet. Validation is happening, not at large scale, but it has been done at the Calgary Internet Exchange since 2023. We did it at the RipeMeeting Network. Well, that would maybe that that's not noticed in the wild, but it was noticed at the at the right meeting, of course. Other things, measurements could be interesting. I see Jeff here. I mean, maybe you can do something with ads. I don't know. That would be interesting.

[00:50:45] **Geoff Huston**: Not with ads, but we're we're we're looking at ads.

[00:50:48] **Tim Bruijnzeels**: Alright. And that really brings me to the end of this, actually.

[00:50:57] **Jeff Haas**: Hi, Tim. Jeff Haas. Two quick comments. You'd mentioned the complex relationship for 9234, the only to customer thing. Espa doesn't let you do the same sets of things. So one of the things that's gonna be an interesting mix is how do people let the two interact. What we're likely going to see is that this is sort of adults doing consensual things at a very small portion of the network. So this probably won't affect things Internet wide. And it sort of overlaps the second one, which is people do occasionally do looped networks where your AS will have an extra hop in the middle because you're taking a backdoor into your own network. If you know, and we're Shigarama is trying to get this in the next ASPA document. If any provider is going to be doing that sort of thing, they have to plan ahead and make sure that's listed in their ASPA records because they'll be surprised otherwise.

[00:51:53] **Job Snijders**: Job Snyder's BSD. To to help the crowd understand the the scope of this effort, the CIDR ops working group has been working on ASPA for a number of years now.

[00:52:08] **Andrej Surý**: Mhmm.

[00:52:09] **Job Snijders**: And this, in our minds, is the really the next step in helping improve operations in the global Internet routing system. So it it represents a lot of work by a lot of people. There's a lot of running codes. It currently is in working group last call. So, you know, ASPA is is up and coming. There there's already thousands of objects in the global routing system today. So ratifying this as an RFC is a nice cherry on the icing, but, of course, a necessity in moving this forward. If you happen to use OpenBSD that provides fully integrated solution for validation, both the validator in the base install and the BGP daemon in the base install supports ASPA validation. But, you know, there there's many other projects that that support ASPA validation. I think FRR, BERT, and then the commercial off the shelf vendors. I think all of them have plans to to support this in in the, you know, next twelve to twenty four months. So, yeah, I I'd say if if this area interests you, pay attention. It's it's happening now. The the momentum is arriving. And as they say, godspeed because we also we don't really know the scaling properties of ASPA. To to draw an example to ROAS, if a ROAA comes into existence and it it it invalidates a part of the tree, you you can use a Patricia tree to quite efficiently figure out, like, which part of the routing tables is affected by this new ROA. Whereas the the appearance or disappearance of an aspect object can potentially make large, like, half of your routing table plausible or or implausible. So how this will work out in practice is an area of ongoing study in the production environment. So, yeah, this this is all very interesting. Thank you for the the explainer, Tim.

[00:54:28] **Geoff Huston**: Jeff Houston, look, Tim, this is not directed at you. But as someone who works in this routing space and has looked at it for many, many years, I suppose the headline comment is, what's plan b? Because I think the issue is right. The origination validation without path protection is a joke. It's a really expensive way of fixing up some forms of route leaks, but it does nothing for anything else. Because as long as I keep the origination right, I can fake the path and bad things happen. So we need something to protect path. But this presentation certainly scares me. And the reason why is we're a simple minded bunch of folk, very diverse, who even have a hard time with BGP origin, and trying to introduce stuff which has really complex side issues. And some of your graphs sort of illustrate that this partial blending of partial topology and partial policy with partial uptake makes most of our collective brains or mine, at least, explode. There are some really tricky corner cases. And as Job has pointed out, the side effects of getting this wrong are unpleasant. And and I suppose my question to not you, but the broader room because I'm over time is, what's our plan b? Because if it doesn't get uptake, we're back to the same old problem. Origination without path is not quite a waste of time, but it's not very good. We need something. But is there any backup into the ASPR work? And I don't really want a response from you. But to everyone else, it's worth some thinking that if you found this talk confusing as I did, that says something quite deep about how complex is this topology and how deployable is it over the global Internet. Because if we've gone way too far in terms of deep computer science without understanding this, I think we're outpacing operators. And that to me is is a difficult problem. That's gone rather than blinking. I'll shut up.

[00:56:40] **Tim Bruijnzeels**: Yeah. I do have a comment, but well, yeah, I think you're right. What's plan B? But also, well, OSPA may give limited security benefits, but it's mostly policy. It doesn't stop people from faking paths. It does make it harder to create a path that is still plausible when people have enough signing going on, but it doesn't protect in itself against that. That is true. What happens next? We have BGP SEC plus plus, I don't know. Yeah. I mean, I'm as curious as you are. Do we find a way to make the things that we have in BGP SEC better usable? For our part, we're actually now finally, and I've been saying this a couple of times, but we're now finally in the stage of making BGP sac router key certificates a thing in our in our interface or in our API, actually. So that's coming. So we're trying to do what we can to help people there, but there's definitely more work that needs to be done on that side on using that information.

[00:57:57] **Jen Linkova**: Here. Okay.

[00:57:59] **Warren Kumari**: Like, fifteen seconds.

[00:58:01] **Unidentified**: Okay. Good. I believe is plan b. There is a Yes. Because there is a difference between ideal solution and deployable solution. ASPA is a deployable solution. Thank you.

[00:58:19] **Warren Kumari**: Okay. Thank you. Thank

[00:58:20] **Nalini Elkins**: you. Thank you very much.

[00:58:22] **Warren Kumari**: Next, we have okay. Great. Thanks for being organized.

[00:58:28] **Jan Ruth**: Okay. Hi, everyone. From routing, we can go directly to TLS or more specifically to encrypted client. Hello. Clicker.

[00:58:37] **Jen Linkova**: Few seconds. Yeah. So Okay.

[00:58:42] **Jan Ruth**: First, let's get a common understanding of what encrypted client hello actually does. So encrypted client hello aims to hide sensitive plain text information from the TLS client hello. More specifically, it tries to hide mostly the SNI information. And how it does that is that each client must obtain an ECH configuration that it does via DNS. In there, it finds a key to encrypt the client hello and an ECH public name, which it will put in a normal TLS client hello, and this encrypted client hello lives as an extension. It's now the encrypted version aside of this client hello. And in case the client, for example, use an outdated ECH configuration or key, then there's a retry mechanism. And so the server will send you a new ECH configuration, and the client can then establish another connection, use that configuration, and can then establish a secure ECH connection. What's the consequence of this? It is that a lot of domains will share one ECH public name. And to not make those ECH requests stick out because you can just see the ECH extension, you are supposed to send all of the TLS clientelos with an ECH extension that's called the grease grease ECH. And ECH is actually enabled by default in Firefox and Chrome since 02/2023. Now what happens if ECH is actually widely deployed? Network monitoring becomes more challenging because information carried in the SNI is less useful. You'll find a single value for one large ECH provider usually, so it's kind of similar granularity to AS information. And the consequence of that is that if you rely on the SNI somewhere, so for example, like firewalls and other middle boxes too, they no longer can do their work based on the SNI. Okay. And it is common knowledge in at least TLS working group that there's one large ECH deployment, which is Cloudflare. But we were wondering if there are actually other ECH deployments, How does a typical ECH configuration look like? How do operators handle ECH? Is there a latency impact because of some additional cryptography? And how stable is ECH support? Now different from related work, what we do is we do not rely on the ECH information in DNS, but instead, we perform active ECH connections. So we send it to your last client header with an ECH extension. And in response, we get a retry configuration. What's our input set? We use multiple tranqo and crux lists, so large clopless, and establish connections with all of the target domains from those lists aggregated over the past month. And then in the response, we get the ECH configuration as well as the ECH public names. And, yes, we will not discover all of the ECH deployment but everything that is on the top list at least. And what we discover is there is actually 5,500,000 domain names from the top list that enable ECH. And when we break this down to second level domains because we don't want to overweight domain names that have a lot of subdomains in the top lists, then we come down to 4,100,000. Pay attention. In this graph, there's a logarithmic access access. So yeah. The largest deployment is indeed Cloudflare. They host on TCP and TLS. We also tested QUIC around 4,000,000 ECH capable domains. And the next largest is actually graph.facebook.com, so the meta services, which are around 4,600 domain names. And what's interesting here is that as clients are supposed to use the ECH information from DNS, a lot of those ECH deployments do have this entry. So most have it, but 34% do not have any ECH configuration in DNS. And let's look at this a little bit more in detail. So we look at especially the meta case. They don't have any ECH configuration in DNS. And we are wondering, are they actually using ECH? Are they able to use ECH somehow? And what we did is we performed we used an iOS device, browsed a little bit on Facebook and Instagram, and captured all the traffic that they sent. And we found ECH extensions both for TCP and TLS TCP and TLS quick connections. And when we now look at those, yes, those could be Greece, but we were able to look at also the ECH configuration ID. That's another parameter of ECH configurations and the ECH public name, and they match what we are extracting from them via the retry configurations. So we are pretty sure this is actual ECH connections, not just greased ECH connections. And we also saw that Meta actually does not do grease or at least they do not send an ECH extension with all TLS clientelos. Now let's look at how the deployment actually evolves. Here, the first graph shows actually the development of our input data of our input list. And you can see it grows up to around 24,000,000 unique second level domain names. And then we here, we have the two large providers, Cloudflare and Meta. You can see that, for example, for both of them, the TCP and TLS plus QUIC connections are basically they have the same domain names that support TCP, TLS, and QUIC. And now last, let's look at all other deployments, so the smaller deployments. And here, we find actually a very low number of there's only two fifty different second level domains, but we do see 3,000 different ECH public names. Why are those so many? Well, there's one deployment that uses random subdomains to example.com, which is not Cloudflare. And they use this, but they only have a single second level domain in use. Okay. And what we don't see here in the graph is there's no large increase because some other CDN has decided to enable ECH for all of their customers. So unfortunately, the deployment is still not very diverse. Okay. Let's look at some parts of the ECH configuration. Most ECH configurations actually carry just a single ECAH configuration, so it can provide multiples. But we do see cases where there's a lot of ECAH configurations, like up to 30. And most of the ECAH configurations are actually very similar. So KEM and Cypher suites are identical, just the public key, and sometimes the public names change. So if you have any idea about why that is, I'm happy to talk about this. Next. You can also see here the key rotation intervals that we discovered. We actually only see this from Cloudflare, and they rotate the ECH configuration and key every hour. And last, what we also found when we inspected ECH configurations is that there's a maximum name length field that is used to patch all the ECH extensions to the same length That is commonly actually using the length of the ECH public name. Yeah. If you have any further information on this, I'm happy to talk about it. So we have talked about key rollover. Now what happens in the case of key rollover, actually, and how would you best handle this? We did measure this, so we perform our normal ECAH intake, retrieving a retry configuration, and then we just use that retry configuration multiple times again at fixed intervals. And then at some point, we find, oh, we get another retry configuration because the configuration we are using is no longer working. And when we do this with Cloudflare, we find that they accept an expired key. So something that has been removed from the DNS already four hours earlier is still accepted within this time frame, but after four hours, this old key does not work anymore. Why do they do this? Well, that prevents clients from having to perform another round trip because they have to then use the retry configuration to another handshake. Just saves a bit of time, and it also allows them to repair some key rotation issues. And now ECH is often also framed, like, as a anti censorship device. So accepting ECH handshakes with an arbitrary ECH public name would make it less stick out because there's not this one ECH public name that you know, oh, it's definitely an ECH connection, but there would be many. And we tested this with those providers, and we found that none of the large ECH deployments actually accepts such modifications. So custom names as the ECH public name instead of the one that is provided in the configuration. What this does is it prevents domain fronting, so you can only do ECH with the domain that the provider is configuring. And yeah. And this using this would also break the retry mechanism because the client relays relies on the server having the certificate for the ECH public name in case it has to use a retry configuration. Okay. Next, let's look at the latency impact of ECH. And how do we do this? We look at this from the system's perspective, so from the client, and we look at the delay differences between when the client starts the TLS handshake and when it considers that TLS handshake done. And shown here is the difference between ECH and normal TLS connection. And you can see it's slightly shifted to the right, but the number really can change or can can differ. I've seen different numbers, so be careful. There's a slight difference, but it's not that large. So definitely, usually, sub millisecond. Okay. Last, let's look at ECH stability. So what we do is we look at ECH deployments at one moment in time, and then we revisit them in all of our later measurements. And what we find is that the deployment is actually relatively stable. Yes, it decreases here, but most of those decreases actually come from domains that are no longer in use, so name a resolution failure. So I would say still a relatively stable ECH deployment. Okay. Let me conclude. We've seen that ECH deployment is actually emerging. There's not only Cloudflare. There's other large providers with large content networks. We've also seen that small deployments are existing. What we find is that there's only up to 55 domains. Yes. We don't know if that is the complete list of target domains behind one ECH public name, but that's the maximum that we discovered, so very limited benefit. And then whenever you do ECH and, for example, rotate your ECH configuration, make sure you have an adequate grace period configured so you don't burden the clients with more round trips. And, yes, we have seen ECH has minor latency impact. Okay? Open for questions.

[01:11:12] **Warren Kumari**: Sure. Questions.

[01:11:13] **Unidentified**: Just out of curiosity, you do ensure that the inner e c a the inner certificate is valid. Right? We

[01:11:22] **Jan Ruth**: Do you try to catch deployments actually in early stages, so we do not verify the inner certificate. But we send another the the second ECH request that we do to verify that ECH actually works, contains in the inner clientele the the target domain.

[01:11:39] **Unidentified**: Yeah. I see. So you

[01:11:41] **Jan Ruth**: So we try to catch them as early as possible.

[01:11:43] **Warren Kumari**: I see. Okay.

[01:11:44] **Jan Ruth**: We could do this with certificate validation yet.

[01:11:47] **Warren Kumari**: Thank you.

[01:11:53] **Unidentified**: Hi. Great work. Quick question on the latency measurements. Are these latency measurements with the retry or without the retry?

[01:12:04] **Jan Ruth**: They are without the retry. This is the second connection.

[01:12:08] **Unidentified**: Did you also do this with the retry? How much is the latency impact when you do only the retry?

[01:12:13] **Jan Ruth**: I mean, it's just should be just an additional round trip. I we we didn't look at this.

[01:12:18] **Jen Linkova**: Okay. Thanks. No more questions.

[01:12:23] **Nalini Elkins**: So Excellent.

[01:12:24] **Warren Kumari**: Very much. Thank

[01:12:25] **Unidentified**: Thanks. Thank you. That was

[01:12:31] **Warren Kumari**: Okay. This is Osama.

[01:12:33] **Jen Linkova**: Here. What?

[01:12:35] **Warren Kumari**: The second slide.

[01:12:36] **Jen Linkova**: Do you mean? When you upload new slide that you override the previous ones, so there's only

[01:12:40] **Warren Kumari**: Well, just just open it and see what it Yes. Make sure it's the right one. Does that seem

[01:12:46] **Osama Gharib**: No. That's not

[01:12:47] **Warren Kumari**: correct. Did you upload the new one through the or did you send email? Did you upload it, or did you email it?

[01:13:05] **Osama Gharib**: I I uploaded it. It's there in the data. So

[01:13:09] **Warren Kumari**: just bring up the list again.

[01:13:11] **Joanna Morin**: Yeah. I'll

[01:13:12] **Warren Kumari**: We're gonna send it.

[01:13:15] **Jen Linkova**: Is this Over there. Over there. Okay.

[01:13:17] **Warren Kumari**: Ah. There

[01:13:17] **Osama Gharib**: we go.

[01:13:18] **Jen Linkova**: All good. Yay.

[01:13:21] **Warren Kumari**: Yep. Thanks. Great. Thank

[01:13:23] **Osama Gharib**: you. So welcome, everyone. This is intrahandshake.fail, which is I'm going to explain you what that is. This one to proceed together with Yadislav and Jan Mary, we have found a high severity vulnerability, which I'm going to describe in this talk very quickly. I don't see the timer yet. Okay. It's there. Thanks. So the use case is that you have a you have a highly regulated data. Let's say that's a medical data or government data or, for instance, financial data, and you want some compute resources where you want to run it, let's say, on the cloud. So you offload that computation to the cloud, but you still want to be to ensure that the data remains secret. That is it's not available to the attackers and so on, and you fulfill all the regulations. Sorry. So the process that we have in addition to the TLS that's, of course, required for the secure channel establishment is the attestation process, which means that, basically, you attest or ensure the trustworthiness of the other party before giving over your secret data. So from a RADS perspective, that's the left entity is acting as a verifying line party, RFC nine three three four, and the right party is acting as an attester. That's the entity under test which you want to ensure and then send over your data. From the TLS perspective, the left is the client and the right is the server. So you want to authenticate the server as well as you want to attest the server before sending over the data. Theoretically, that should be more powerful than TLS alone that you are not only attest You're not only authenticating the server, that it's the right entity that you wanted to talk to, but also ensuring that the software which was running on the server was actually as expected before sending over the data. So you have two types of technically two orthogonal guarantees that you have authentication and you have attestation of the software and the hardware and the firmware where where it is running. What happens in real so so the claim of confidential computing so this domain is called as confidential computing where you have hardware based trusted execution environments and so on. Confidential Computing Consortium is one of the biggest organization which is running this whole thing. And the claim here is that deploy AI in government without any sovereign risks. That's what we analyzed, and we found that the reality is that's already the older research which I show here, which is from the previous published research, y tab dot failed, d dot failed, which made big headlines in the news. So all of you remember that. So there were no CVs for that specifically. The CVs which were created so Intel and arms Intel and AMD basically said that, hey. This is out of our threat model. This doesn't apply at all. And just to be clear for this audience, so the measurements for us, for the security researchers, actually mean these kind of measurements. I don't have the nice graphs to show you. So these are actually my measurements, which is to say that we measure the severity of the attacks by having CVE. And the CVSS code, which is a standard way to measure the severity of the scores severity of the attacks or the vulnerabilities, that's our measurements. So what happens here is that in all the literature that exists, the all the listings that I have provided here until now, that's the maximum score is 5.9. And according to CVSS CVE score version 3.1 up to seven so up to 6.9 is the medium severity, and from 7.0 starts the high severity. So the CVE that we found from 7.0, so it's 7.5, that means that's a high severity attack. And that's what now I'm going to describe you how we found that and what the attack is and how we can protect the society and what the next process is. As I said, TLS is the protocol that we have used as transport. It could be ad hoc. Could It be any other protocol. It doesn't really matter that lot. Like, I mean, you just change the key schedule and all that, and you you will have the same attack. We in another work we have for the test taker talk, that is another work in the lake working group. But without going into that direction, so what I want to say here is that AI agent, which the confidential computing computing computing consortium, I'm sorry, proposed is the we have taken as the motivational use case. That's also the motivational use case in the use cases document in the RATS working group. And the formalization tool we use here is Proverif, which is the state of the art tool for symbolic security analysis. So the right so sorry. The left top is showing you the system model that we take the any kind of TEE can be classified as either a layered or a composite attester. We we cover both of them. On the right side, we have the tested TLS protocol. We took many, many binding mechanisms from all the discussions that happened in the RATS working group as well as all the deployments which were available. We take practical implementations, real world implementations used in the deployment today. And from that, we build the former model. On the left bottom, you see that agentic AI as the use case. From that, we form the security goals. We define three binding levels, which I will describe you, and we define novel correlation properties. And based on that, for any security analysis, of course, you need a threat model. And based on that, we did the formal analysis from these relay attacks, proposed mitigations, and the CV was created. So the idea here is now I'm going to describe one by one each of the components. The main main components, of course, within limited time. The potential binding mechanisms was one of the blocks right on the top there, and that's what I'm going to now describe. So three specific binding mechanisms are used in the practical live systems, which are Meta's AI, WhatsApp. Most of you might be using WhatsApp. So that's the protocol which is used in Meta's AI binding number one, which is to say that the binder, there is a user defined value that you can put in. So the right column is basically showing the the last column here in the table is showing what you put inside that field. So that's the only kind of the parameter that you can change, and everything else is mostly derived by the hardware itself. So the the number six binder is used in Edgeless Systems Contrast. That's an German startup which is using it, and Copos AI claimed in the confidential computing consortium there that they are the best in the world. They have the best tested TLS protocol in the world, and we showed it's one

[01:19:59] **Warren Kumari**: of the

[01:20:00] **Osama Gharib**: worst. Confidential computing proof of concept, that's an adopted project of the Confidential Computing Consortium that they use the same binders. And there is number seven, there is the there was actually a draft in the TLS working group, which was proposed for adoption. The version six of that used this binder, and we showed that, you know, all of them are vulnerable, actually. Right. So one of the things was the binding levels. How do we define that? How do we actually characterize what is, how strongly that evidence is bound to that specific connection? This is what it now technically defines formally, which is to say that on the client side, client as a verifying client party, how how much surety it would have that I am still talking with the same entity which is being attested and the same entity which is being authenticated. That's the that's the kind of the property. And the way we formalize it as a correlation property, which is to say that if I see the same evidence being used by accepted by the client and the same evidence being authenticated or provided by the server. That's EV in both client XEV, client, server XEV, and then they should have the same keys. So x and y are representing the keys. They can be different keys. In the table, I'm showing what the values of x and y can be. So the idea here is that it could be g x y. So there are three main of course, like, the key schedule of TLS is a big one. Like, there are, like, 26 or something like that keys, at least 26. And from that, the unique keys or the most important keys are three of them that we define as the levels. GXY is the Diffie Hellman shared secret. We are, like, not using any cams at all, so all the fancy things still apply if you if you transition to that. So nothing changes at all in the results. But for this specific work, we just focused on the Diffie Hellman based key exchange, And the handshake state that it actually contains is the g x and g y. The second one is the client's handshake traffic secret, which is basically containing the complete client hello message, everything in the client hello, not just g x, as well as, the server hello. All of the complete message goes as input to that specific key derivation. Then there is the client's application traffic key, and there is a subtle difference between the two keys that's really important to understand, and I will explain to you in the next slide, which is to say that from a derivation perspective, basically, it's taking in addition to client hello and server hello. It's taking all the messages all the way up to the server finish. So the server is fully authenticated by this point in time, and it takes into consideration all of the keys. So then we actually proved in cryptographically by paper and pen method that g three representing the ATSC key. So we keep changing the x and y's, and from that, we have three levels. Like, for let's say for three, we replace x and y by the ATSC of the client and the server. And by that, then we have three properties. We show that g three strictly implies g two. G two strictly implies g one. That's the property we prove. So now this is a bit of a devil in the details, and that's why it the attack remained for several years in the wild. And the main difference here, I want to explicitly explain about HTSC and ATSC. The key idea to understand is that HTSC, handshake traffic secret of the client, is basically irrelevant for security. It's only being used for the encryption of these messages, which is to say it has nothing to do at all with the security. It's related to privacy of the messages. Even if you remove all of these encryptions, which are done by the HTSC, which means

[01:23:51] **Jen Linkova**: These ones? Oh,

[01:23:54] **Osama Gharib**: okay. Cool. So if you remove all of these encryptions all the way down to the finished message, nothing at all will change in any security property at all. It's all related to just the privacy, which my colleague was already showing in the ECH. So it's only related to privacy. Remove all these encryptions. Nothing changes in the security. HTSC is completely irrelevant to the security goals. Second point, server is not yet authenticated at the point when HTSC is generated. At this point in time, you see that this is the key exchange part still at this point in time when HTSC is generated, from that, KCH is generated. So we don't exactly know which server we are talking to, and that's the key point for the relay attack that it relays it over. You don't know that server that you authenticated. Was it the same that generated the evidence or not? So coming to now ATSC contrasted with the other key that I described, which is to say this ATSC is basically taking into consideration all the way up to server finished. Server is fully authenticated now, and we are really sure that this is the server which we are talking to, and this is the one which is authenticated as well as which will be attested. So there is no possibility at all so as to do a relay attack in this case. So that's the real relevant thing for the security goal. So I quickly will show you two attacks at a very, very abstract level. The first attack needs no key leakage at all, no assumption at all, and it's simply just man in the middle, which is to say that the adversary sits in between, forwards the t or relays the TLS nonce, gets back an evidence from a genuine AI agent, and just relays it back. And the adversary and the client, sorry, or the verifying line party from that's perspective very happily generates a connection with the adversary rather than the server itself. So the attack number two is requires the PREV e k, the private key of the of the server, which can be obtained by several ways. Keep in mind that we are talking about confidential computing, not the conventional, like, TLS protocol. So, of course, like, for TLS, if one key leaks, then everything everything is broken. But this is not the promise of the confidential computing, which is claiming that you don't trust anything other than the hardware at all, and then still it should be should not be compromised. And that is to say that there are several ways which I have written on the slide, like, if someone has access to that key or it is leaked via vulnerability in code and so on, so many reasons, so that you can have this attack, which is to say that you have this private key. You run everything that you would do. The evidence is adding absolutely zero security protection to the original TLS at all. The key leakage single key leakage should not be the point of failure for two protections, which was the whole point of adding attestation in addition to authentication, the attestation point. So CVE has published three of the drafts. This one is expired. The two active drafts are still vulnerable to this CVE, which are the RATS early attestation and RATS facts. And the core problem, as I said, the binding evidence to an unauthenticated peer, that is the server, is the real problem. And the summary of the analysis so far is that we have for prehandshake attestation, replay, and diversion attacks. In this specific talk, I talked about the intra handshake diversion and relay attacks, the three drafts I already mentioned. And for post handshake attestation, we are still do doing the formal analysis. As a disclaimer, I'm one of the authors of this draft. And for intra handshake, we can at most achieve level two binding. That's our finding. And there is a lot of unnecessary complexity. This gentleman already talked about in another talk. So there is a lot of complexity being added by the IntraHandshake without providing any security benefit at all. There are several security CVEs which are under disclosure. Three of them are critical severity. After 9.0, it's critical, and that they are all of 9.1. There are two more, which are 7.5, and that's under disclosure. With that, I have the proposal for the confidential computing research group, which should tackle this problem rather than having a working group before solving these problems because they are research based problems. And all of you who are interested are very welcome to that. We will have a site meeting on that. We have a paper, and the link for the paper and artifacts is there. And I really want to thank all the people who have contributed over several years for this, and I welcome any con contributions. And I would love to see your names also here. Thanks very much.

[01:28:32] **Jen Linkova**: Thank you. Timing. Unfortunately, do not have time for questions, but I guess if people who have questions might find you later. Sure.

[01:28:43] **Osama Gharib**: I will be here.

[01:28:44] **Jen Linkova**: Okay. Thank you.

[01:28:56] **Warren Kumari**: Thank you for being organized.

[01:28:58] **Jen Linkova**: Okay. Hold on.

[01:29:01] **Warren Kumari**: And thanks to all the presenters for staying within their time and being organized and knowing what they're doing.

[01:29:13] **Jen Linkova**: So I'm I'm giving you the clicker.

[01:29:18] **Nalini Elkins**: Yeah. I don't know what's going with that. And hi. Can you guys hear me? Yeah. This I don't know what happened to the what do you call it? So I'm gonna talk about post quantum stuff.

[01:29:35] **Jen Linkova**: Okay. So

[01:29:37] **Nalini Elkins**: so at IETF and NIST, there's a lot of algorithms and so on being developed. Lots of arguments people are having. So the problem, of course, is that people think some at some point, there'll be a quantum computer that will be able to break all our private key, public key encryption, and people are developing various ways to combat that. So there's three things in particular that I have been looking at and that people are discussing. So there's both the key management, the KEM kinds of stuff. And then there is the DSA or the signature kinds of stuff. And the KEM stuff is much more mature. And I'll show you some real world implementations and how people are actually using it. The DSA stuff is in certificates and that's still very much being worked on both in TLS and also in the LAMPS because there's lots of implications as to the size of the certificate and also what happens to the certificate transparency logs. So the problem is, as far as signatures and, the MLDSA stuff, is that used to be when you have the ECDSA, RSA, those kind of things, you'll see that the public key is pretty small, say, 65 or 97, whatever, going all the way up to sorry about that square, five twenty six. But with MLDSA, which is the quantum safe algorithm, the keys and the signatures get a whole lot bigger. And so people felt like this was gonna be you know, it's gonna extend the TLS handshake, make the certificates really big. There's all kinds of downstream implications because if you have to save all the logs and so on, this is kind of the fundamental problem that people are looking at. And so one of the big things that's being worked on is something called Merkle tree certificates. Essentially, as I say, I'm being somewhat reductive here. But essentially, the idea is is that you don't transmit those big old keys and big old signatures. You put them somewhere else, and you transmit a hash or a Merkle tree. A Merkle tree is as I said, I don't I don't wanna go into a whole thing of what a Merkle tree is. Get chat GPT to help. I'm sorry. And so so it it essentially, you're passing a hash. There's a tree structure and so on. So what I was interested in is if you have enterprises. Let's say you have the financial industry, health care, whatever hospitals. They use certificates for lots of other things. For example, they have the subject alternate names. Some of them have tons of them. For example, if a bank has bought five other banks or combined or whatever, they'll have the names of all the other banks as possible subject alternate names. Or you might have, like, m dot whatever or for the or teamsters dot whatever for the teamsters to use the certificate. Anyway, their certificates have lots of other things. They have enterprise OIDs. So the concern is is like, are we going to be able to use the Merkle Tree certs in the same way? And it's an open question. This is all being worked on. Do we have all the information that we need along with the triage? And also too, if things like certificates are used in prosecution as forensic evidence and I'll show you a case of that. Then how exactly is this going to work? I mean, is the judge going to accept a tree hash from ten years ago to say this is evidence and authentication? As I say, these are all open questions. And so how do we do all this? And then if you have a private PKI, which is a financial institution or a government agency issuing their own certificates for their internal use, do we still need Merkle Tree certs? And then do we still I mean how is this all supposed to work? That's basically the question. So let's take for example Stuxnet. I'm sure you guys all remember that. And part of the forensic evidence that was used with Stuxnet is that the device drivers were signed with an x five zero nine certificate, albeit stolen certificates. But that was part of the forensic evidence and that's how Windows trusted it. So what I did is I started looking at real world adoption of PQC. We have an active monitor. We did actual TLS handshakes asking for a particular named group or a set of named groups. Named groups is how you say you want a particular kind of PQC algorithm to be used. And I did it both horizontally and vertically. So I did the financials horizontally. Let's say, like, the top 50 banks in The US, 50 in India approximately, and 50 in Latin America, and then health care vertically. Because things are in it's kind of an ecosystem. So you might have like in The US, we have private health insurance. Private health insurance and then the hospital chains who connect to them. And then, for example, Medicare. We have the for old age or for senior citizens. We have Medicare or health and human services, which are also part of the ecosystem for the health care industry. And the reason I was looking at this traffic, and this is all traffic going over the Internet, is I measured websites only, not inside the enterprise. And the reason that I'm looking at these particular industries, vertical and horizontal, is because if a quantum computer is to be developed, what is it likely that they're going to go after? It's not likely that they care about Nalini's Google search history or if I watch cat videos. But it's potentially more interesting to go after military secrets or classified information, that kind of stuff. Now, clearly, army.gov or army.mil or whatever is not going to put secrets on their web server. I hope. However however, chase.com is an attractive target or, you know, whatever. Merrylynch.com. That's an attractive target for gathering many things. So so let's look first at TLS, and let's see what we got here, interestingly. So The US financial, 7% are doing TLS one two only. So interesting because the problem with that is that TLS one two is frozen. You cannot do any, upgrades to it, meaning you cannot do PQC. So first thing you probably wanna do is go ahead and get rid of that. Even worse, if what you support is TLS one two and one one. One one having been deprecated quite a while back. And then but we've got 90% which are doing very well. Same same kind of thing. Latin America actually doing quite well quite well. There's no nobody doing TLS one two and one one and a great deal. You know, this is maybe a little bit, you know, worse than you'd like to see it. India is is not doing quite as well. They but then I compare it to the the the large Internet facing companies. I think I think 20 or 30 of those. And one of the interesting things about that is that they have to support TLS one three, one two, and one one because, you know, you never know. You don't wanna turn away anybody. And if they're using old devices, they're going to let them in anyway. And so on. It is interesting. You know, the difference is you see. Health insurance in particular is potentially lagging in The US. So and then we start looking at PQC adoption. Because PQC, this is KEMs only. Because that's all out there. There is a lot of adoption already for PQC KEMs. Again, you'll see the Internet companies, probably 63% support that. And one of the reasons this is kind of interesting is that what I'm hearing from people when I bring this up is why are you talking about PQC, PQC adoption? Everybody doing already? Everybody not doing already? And who doing already is the Internet companies, The internet based companies doing already. I mean good for them. But like I said before, there's a great deal of information that is quite sensitive which is not at the internet companies. So but you can see some people are doing very, very well. Latin America with 52.4% of the financials. I think that's a very nice number. Hospitals are doing quite well. As I say, it's it's interesting. The other thing that's interesting to look at is potentially who's doing this. Who's in charge of doing said encryption. It's not to say that if the thing if the server resolves to your own ASN that you're necessarily doing it. But probably. Probably. So like, for example, for the Internet companies, they're they're they own the ASN that that web server resolves to and they probably are doing all that encryption. But you'll notice like of The US financials, a 100% of them their web server is hosted by someone else. And this will have real implications as we get into certs too. So if you're hosted by whatever cloud provider or CDN or whatever, probably they're doing your encryption. So potentially, it gets harder to change that particular thing. Or possibly, it gives you more options because that provider may have more sophistication in what they're able to offer. So let's look at certificates because that's actually what's currently under scope right now. There's a window of opportunity where we can get some things possibly into the spec or changed. So one of the reasons that I was looking at this is that in the old days, there's a lot of other stuff except for the public key and digital signature. Remember we said that the keys were going to change. In the past, the public keys were not taken up a huge percent of of the certificate real estate. In fact, you'll see here across all the across all the groups I measured, you'll see probably about, say, somewhere between 60 to 67% was not the key. Of course, that's gonna change. That's gonna change. When you have these bigger keys, then the those keys and and signatures are gonna take up a whole lot more of the certificate. But then I was like, well, I mean, that looks terrible. But how long is it does it really take to transmit? And so I started comparing. And this is in the old days. This is in the old days. So the certificate transfer time and you'll see this the TLS one two, TLS one three, you know, calculations all below. So we're talking about say maybe a quarter of the time was spent on the certificate transfer time. And but now with the new signatures and keys, again, this look bad. It's like now we've gone up to maybe 50% of the handshake is the certificate transfer time. But if you look at the absolute numbers, we're we're talking about maybe an increase of a 150 to two hundred milliseconds. I mean, it depends. Right? It depends if you're on a slow connection, connection, but you always were on a slow connections. I know some stock trading companies in particular who have nanosecond transfer times for the reasons you might speculate on. And the other thing I saw, I started looking at too, is like, well, so like what are we doing here? How many certs we sending out in a chain? Because you don't just send out one certificate, you can you send out the leaf certificate which says this is me, know, merrill Lynch dot com, whatever. And then you have the root. So you got the second one which is that it's signed by whatever, Google and Digicert, whatever. Name your CAs. So you got at least two, but then you can have intermediate certs for various reasons. And so overall, we're looking at, let's say, the the Internet companies. They're doing a lot of two cert, know, two only two in the chain. Latin America, I'd say, is doing very nicely, in my opinion. It's like, you know, 60 almost over 50% only two. Because what I was thinking then is, well, do we have some options here? So I think what the next thing we really need to do is because I can't I can't really look at Merkle Tree certs in the wild yet because we don't have nobody got them. So we need to put it up. We need to put it up. We need to see exactly what are certs being used for. Do we have everything in the payload with a Merckletree cert that we would with a with a regular CERT. And then also to like do we need some other options? Maybe instead of Merkle Tree CERTs, which as I say make my head spin, maybe we get rid of one or two of the intermediate certs. Do we buy back a hundred milliseconds? I don't know. I mean, maybe, you know. What about certificate compression? In the old days maybe it wasn't buying us all that much. But now maybe could we try certificate compression? And then if we can set up our own private PKIs, does that become more attractive now? I'm going to say. Because I can tell you like, I know like ANSI, ANSI X9 or there's other people. Like there's other groups who have their own PKIs. If we need if a Merkle Tree cert doesn't give us everything we need, is that incentive to set up a private PKI? I don't know. I don't know. And then if this all goes through, do we have a split world? Do we have the browsers all doing MTC and then the enterprise control certs not doing MTC? And what are CDNs gonna do? I mean, as I said, these are all I have no answers. So my my question really to the group is, is this interesting? I mean, do we do a countdown clock? It's like to twenty twenty eight, twenty twenty nine, twenty thirty, or whatever to see if we can get to a 100%, you know, or are we gonna still have laggards in implementation? And who's who's a laggard? Yeah. And do you have comments on the methodology? We can post it on our website. Anybody wanna help? Please. We'll discuss this in LAMPS also. Yeah. That's it.

[01:49:21] **Jen Linkova**: Thank you very much. Unfortunately, we do not really have time for questions. So

[01:49:29] **Nalini Elkins**: okay. No questions

[01:49:30] **Jen Linkova**: in here. Hold on. Hold on. Ah.

[01:49:37] **Warren Kumari**: Time mixed. We have the t t p

[01:49:44] **Jen Linkova**: And I think, John, try to yeah. John, I'm gonna try to request the control of the slides again. I will give you control. Yes.

[01:50:08] **Warren Kumari**: Okay. Oops.

[01:50:13] **Jen Linkova**: I did pass here the slides control.

[01:50:24] **Warren Kumari**: Should be working soon. It says that it's being shared. Should be asking you to click up up now. Do we have the slides otherwise? We have the slides.

[01:50:39] **Joanna Morin**: Hi.

[01:50:41] **Jen Linkova**: Let me do this. Let

[01:50:43] **Unidentified**: me share

[01:50:44] **Warren Kumari**: There we

[01:50:44] **Manu Gupta**: go. Patch.

[01:50:45] **Jen Linkova**: Hold on.

[01:50:46] **Warren Kumari**: Now Oh, hang on. Works now. Yay. Technology.

[01:50:52] **Joanna Morin**: Perfect. Hello, everyone. Can you hear me okay?

[01:50:58] **Jen Linkova**: Yes. Yes. We can hear you.

[01:51:03] **Joanna Morin**: Brilliant. Okay. Hello, everyone. My name is Joanna Morin. I know it says Rooney on here, but my working capacity is always Morin. Apologies. I'm also accompanied by my esteemed colleague, Manu Gupta. We are both contributors to the libp2p peer to peer open source project. And today, we're gonna be talking about operating and measuring agent networks across and to the early operation left lessons from agency, over libp2p. So this talk focuses on how agent networks communicate and why measuring their underlying network behavior is becoming critical. As AI agents become distributed, network performance directly affects reliability, user experience, and and we'll explore why LipiDP provides a strong foundation and what new operational metrics we should be tracking. So first off, a little bit about sorry there. Excuse me. So, open agents, should communicate across organizations and platforms instead of being locked into proprietary ecosystems. So standards like a two a and MCP define agent interactions while libp2p provides the transport layer, and together, they create an interoperable in Internet for autonomous agents. So a little bit about LibbyDP. So LibbyDP is already a mature networking stack used across large and decentralized ecosystems, and it has secured billions of dollars in assets and powers numerous production deployments. Rather than inventing new networking protocols for AI agents, and we, we can build upon this proven foundation. So a little bit about the agent stack. So agent systems have two distinct layers, reasoning and networking. And in today's discussion, usually, focuses on prompts, tools, and orchestration while networking receives little attention. So reliable communication, rating, discovery, and security are equally important for production deployments. So scaling, agency across multi ecosystem landscapes. So agency in LibbyDP acts as a common networking substrate supporting multiple AI frameworks simultaneously beyond a single enterprise. Different agent ecosystems can coexist while sharing the same underlying communication infrastructure, and this avoids fragmentation and encourages interoperability. So agents are evolving into distributed systems. Modern AI agents rarely operate in isolation. They continuously interact with tools, databases, and other agents, cloud services, and users. So once distributed, they inherit all the challenges of distributed systems, including latency, failures, and coordination. Sorry. Excuse me. I'm going to the next slide. So so agency as an operational environment. Think of agency as operating environment for distributed agents. libp2p provides the networking substrate while higher level agent frameworks build on top. This layered architecture separates networking concerns from application log logic. So the hidden discovery tax. Before agents can collaborate, they first need to discover each other. Discovery delays often become invisible bottlenecks that increase over response time. So measuring discoverancy discovery latency helps identify inefficiencies early. Connectivity across heterogeneous networks. So agents may operate across cloud providers, enterprise networks, mobile devices, and edge environments. Network conditions differ significantly between these environments, and measuring connectivity success helps understand deployment reliability across diverse infrastructure. So direct connectivity versus relay relay dependency. So direct peer to peer communication offers lower latency and reduces infrastructure costs. However, NATs and firewalls often force traffic through relays. So tracking relay usage provides valuable insight into network efficiency. So application excuse me. Sorry. Application failures begin as network events. So many application failures originate from networking problems rather than application logic. Discovery failures, connection drops, and transport issues eventually surface as a user visible errors. So better network observability has faster diagnosis and resolution. CIDs enter the agent network. So content identifiers, CIDs, provide immutable references for shared agent data. Agents exchange verified content instead of relying solely on centralized storage, and this enables reproducibility, caching, and verifiable data exchange. Oops. Excuse me. My slides are a bit slow. Apologies. Are you excuse me. What slide? So the are you still are we still on CID's enter agent network?

[01:56:53] **Warren Kumari**: Our one shows 14 in the room. Sometimes they do get out of sync, which is Well, it's got 14 written.

[01:57:00] **Manu Gupta**: It should be a 12 slide. The 12

[01:57:03] **Warren Kumari**: One saying cross layer correlation. So the number and the now it shows structured communication, and now it's the cross layer imperative, which on the black numbers in the bottom right is 14.

[01:57:24] **Manu Gupta**: Can we go to Slide 13?

[01:57:29] **Warren Kumari**: Slide 13, you said? Yeah. The one that structured communication and coding pressure? Okay. Cool.

[01:57:34] **Manu Gupta**: Yeah. Yeah. Please go ahead. Yeah.

[01:57:46] **Warren Kumari**: It's showing 13 in the room now. I'm not sure which you all are seeing. Okay.

[01:57:52] **Manu Gupta**: Yeah. That's the correct slide. Yeah. The thirteen one. Yeah.

[01:57:58] **Joanna Morin**: Sorry, Manny. Do you wanna continue? I'm having issues here. Connectivity.

[01:58:02] **Manu Gupta**: Oh, sure. Definitely. So if we go back to the 13 slide, please.

[01:58:08] **Jen Linkova**: Do you want to get the control of this slide, Manu?

[01:58:12] **Manu Gupta**: Yeah. Yeah. That's you you can continue with the control. I'll I'll speak over here. Absolutely. So first of all, thanks so much, Joe, for presenting the first key set of things regarding CIDs, content identifiers. CBOR, as we speak, is more on the structured communication and coding pressure front. So we are using specifically CBOR 42. The focus is on ensuring that we have the efficiency measured across the entire path. We focus on this architecture of actual network bytes where we have serialization, application control, stream transport framing, security encryption overhead, as was shared by Nalini. We are specifically looking into that TLS 1.3 protocol as well as the noise protocol. So these are essentially the two protocols we are looking at as far as. Yeah. Please go ahead to the next slide. Yeah. Yeah. Please go on to the 14 slide.

[01:59:11] **Jen Linkova**: John, do you still control the slides? But do you want to get the control of the slides so you could move them, or you prefer me to control the slides?

[01:59:18] **Manu Gupta**: Yeah. You can control the slide.

[01:59:19] **Jen Linkova**: Absolutely. I'll take the control then. Just a second. Sure. Alright. K.

[01:59:32] **Warren Kumari**: K.

[01:59:33] **Manu Gupta**: That's it. Yeah. This is all good. Yeah. Let's be in the slide. Yes. Lip b two p as a shared substrate. So, essentially, we are talking of Lip b two p providing key networking primitives, allowing multiple independently evolving agent protocols. I mean, to share a secure measured foundation for connectivity and discovery. So, essentially, if you look at our stack, it's a modular stack. We have the different aspects of, like, different modules and sub modules. So at the core layer is the identity piece. This identity piece is something we have as a representation for talking for the agents also as well as for interacting with multi adders, multi formats, multi base, multi hash, multi codex, and also the the different ways through which these peers interact. That is why IPLD. So we have IPLD as the key method for interacting between the different peers. The second part is essentially the discovery part. So at the discovery front, we have a set of protocols. One specific to multicast DNS, which is specific to local search. Second is essentially the global search. In reference to global search, we have something called as the Rendezvous protocol. So So in case of that, we use something as namespace, and we are able to classify and cluster the agents according to the needs. The third is essentially random walk and which is more about how we understand, like, the traveling Sears plan problem and algorithms. Trying to map that in terms of peer discovery, and that's how agents, they talk to each other. In reference to connectivity, we have arrived at three different methods. One is Gossipsub. Gossip serve is, like, for building consensus, which means you have a peer interacting with all the peers in your network, and you're ensuring that those peers have different ways of looking at messaging, ensuring file transfer, and and also ensuring that a certain number of connections are always long lived. So the whole premise of doing a lit p two p as a shared substrate in agencies to ensure that it's a long lived network, it's a resilient network, and also it is building on a stack where you can plug and play according to your requirements. So this is where we have the network and transport layer. On top of it, we are building what we call as the application protocols. So the application protocols are essentially the protocol a, protocol b, protocol c. It can be slim for messaging. It can be OCI for storage. It can be CBOR for serialization. But, essentially, if you look at this whole stack, that is what enables the Internet of open agents at agency. Please, can we move on to the next slide? Thank you so much. Fantastic. So what we feel so agency started using let me to p, I would say, in IETF two zero two one, the last previous IET, which is 01/25. So that's when we had the first draft of agency being shared with lippie to p. We started focusing on peer to peer measurements, which means observability stack was essentially at the peer to peer level. What we have learned over time is that it's not just the peer to peer observability stack where we look at the network events, we look at recording peer identities, but we also have to look at how it works with agency at the application layer and lead p two p at the networking layer. So if you look at the invisible failures law, it is about which critical network events, the lack of workflow correlation, which is specifically when we're talking about enterprise boundaries. And we are having, like, different hyperscalers using the Internet of open agents at the same time. Second, essentially, is focusing on peer identities during time outs. This is one of the key things we observe that when we do peer to peer discovery, if we use a technique which is very relevant to a local setting but might not be relevant to a hybrid setting. So one of the key problems we face with that is that you will see certain peers coming in, going out, and not having a resilient storage system or having a resilient agent transfer system. In order to prevent that, we are coming up with a net new technique, which is essentially on recording these timeouts, having certain thresholds over there, and ensuring that if timeouts have happened on a specific peer to peer communication, we could have the next neighborhood systems to enable that kind of a communication happening. So we had some talks on the routing part, the ask for part. Essentially, a lot of it is, like, doing a transfer learning into the state of peer to peer network and network peer to peer network substrate. The the third part is essentially which latency boundaries are we looking at, and that is essentially about discovery and transport. Sometimes they are obscured. Yeah. Can we move on to the next slide? The last slide. Yeah. Mhmm. Well, thank you so much. So in if you look at the operational measurements, we believe that we should be arriving at three different key aspects. One is common events in context, which is standardized definitions for failure across diverse networks. Second, essentially, is on identity of a telemetry. So if you're talking about identity of a telemetry, it's essentially to trace the physical network parts, which are directed to high level actions. And finally, on verifiable operational data, which is ensuring that our network performance and reliability is always a it's a long lived network. It's a resilient network. And, essentially, we wish to propose resilience as a protocol for the agency using LEPIT. Thank you so much for listening. We apologize for a bit of network issues. Thanks so much, Joe. Any questions, any feedback, guys, you have? More than happy to, like, answer. Both of us are here now. More than happy to share take questions.

[02:05:05] **Warren Kumari**: We're officially out of time, but if people wanna hang around, you know, feel free to ask some questions. While Eric's walking up to the mic, everyone, think of presentations for next time. And also, Jen and I will be here for a few minutes. Please come along and provide us feedback on what you thought of the agenda, presentations, etcetera. Take it away, Eric.

[02:05:23] **Osama Gharib**: For

[02:05:23] **Eric Vyncke**: operational measurements, are you looking at the IP layer things you're using? Like, in turn like, it seems like if people really wanna deploy

[02:05:33] **Jen Linkova**: Mhmm.

[02:05:33] **Eric Vyncke**: P to p agent net networks that they need to be IPv six only, like, trying to do this with IPv four not seems doomed. Sure. I can see if people want it, like, say security wise, they don't want they wanna force everything through gateway. That's a separate event. But the things actually want group peer to peer. Mhmm. Are you looking at kind of v four versus v six usage?

[02:05:52] **Manu Gupta**: Absolutely. That's a wonderful question. And I must share that we have implementation supporting I p v six. Our key core implementations, that is the so we have implementations in 18 different languages, programming languages. And if you're talking of our core implementations, that is go-libp2p implementation in plus, in Python, in JavaScript, and TypeScript, they're all supporting I p v six. And you're 100% right that from an agent tech perspective, I p v six is the way to go. We are trying to have the same kind of a possibility in some of the newer implementations also for lighter weight implementations as well. And I would just like to borrow one specific learning from some of our friends at NVIDIA. So when they actually started working on the secure communication channel, they specifically said that at the IP level, focus on I p v six. And that is essentially one of the reasons why we have our protocol upgraded to I p v six. Yeah.

[02:06:44] **Warren Kumari**: Thank you.

[02:06:45] **Manu Gupta**: More than happy to discuss this further. We'll send out email addresses more than happy to discuss this. Yeah.

[02:06:51] **Jen Linkova**: Okay. Thank you very much. This officially concludes the session. So Thank you so much. Thank you very much for presenting. I would really love to see as many and even more talk submissions next time. This was good. And we'll be working on getting a bigger room next time. Thank you.

[02:07:12] **Manu Gupta**: Thank you. Thank you once again. Thank

[02:07:15] **Jen Linkova**: you.

[02:07:23] **Warren Kumari**: I actually have to run. I thought I was gonna be here and talk to people.

[02:07:26] **Jan Ruth**: But You

[02:07:28] **Jen Linkova**: changed your mind. Okay.