Session Date/Time: 18 Jul 2026 08:30
[00:00:11] Hackathon Organizer: Oh, again. Yeah? It's so deep inside here. It gave him a little Yeah. Say hello. Sorry. I just had 100% CPU during the Yeah. Just wondering. Okay. I like to share slides. No documents available. But I go here. Oh, it's not pulling from the data tracker. Yeah. So this is what I let me refresh. And then report all this. Yeah. Load this then. It should it can load it directly. But Yeah. I mean, that's I guess you try putting it there again. You could try that as a worker. I don't know. Oh, yeah. I found oh, sorry. Yeah. Can you help me? Upload many slides. Oh, it's showing yeah. Here, you don't see that. No. It's a big file, 20 megabytes. Yeah. So good morning. Good morning. We will start to kick off in a couple of minutes. So this is an a heads up that I will be talking in a couple of minutes for only ten minutes. I'll try to keep it short so we can start the hackathon and you know the logistics. Thank you. Excellent. Alright. Yep. Yes. They're there. Yep. Excellent. Thank you. Okay. Thank you. So I will only take five, maybe ten minutes of your time. So this is the hackathon kickoff. It's a crowded event for sure. It's normally crowded, but the room is a little bit smaller than, we had in the past, past, years. But please be kind to each other. Make room for each other. Combine projects with one table. I think we'll manage. I hope. There's some room around the corner. It's just sitting in a corner, and there's electricity and Wi Fi. But first of all, let's start. So welcome for the for the IETF hackathon this Saturday and Sunday. This is always what we ask. For who is this the first IETF hackathon? Because it's a great way to start the week. Excellent. Thank you. Yeah. Make use of this time to connect with other people to discuss how things are going. Happy to be to have you here. Of course, who is also we're asking this question always. What's the is this for whom is this the first IETF event? Also, great to see you. Yeah. Yeah. So I hope this is a good start of the week. You find your way. There are some introductions for the newcomers tomorrow morning. Yeah. Ask people if you want to find your way and if you, want some information. Good. So why are we here? I want to keep it brief. IETF, is about standards, but it's all about running code. And that's that's the import it's really important in to have good standards. Right. And the IETF started with that ID. So with to support our standardization work, we can also start with working in the group the weekend before the IETF and start implementing code, discussing drafts, etcetera, etcetera. So besides all the other things we mentioned here, we also want to attract developers. It's super important and new other communities. But in the end, we believe in rough consensus and running code. So this this is why the IETF hackathon is that important and so successful. So thanks again for joining us this weekend and in the past years. It is an IETF meeting, so you're supposed to be aware of the note well. I won't go into the details, but there's something that what you discuss here with your colleagues is an IETF contribution. I'll just go fast forward. The code contribution, the code you write, is not an IETF contribution. So that's your own proprietary or your own IP, your own licenses you can apply on it, etcetera. So we make a distinction. Things you discuss and you present tomorrow is IETF product contribution. So the IETF note well applies, but the code is yours and stays yours. So that's important to remember. Yeah. There are more details. You can always download the slides. Ask me about details about licenses and copyrights and IPR, but I want to skip this here. The projects. So I've, oh, I've looked at the projects in the Wiki. They're 40 plus. That is great to see. Here we are. So if you haven't done yet, it's really great to have your project on the project wiki. So this is also our history, who has worked on which project, and, yeah, it's good to see. And it's also good for your own exposure of your project. If you're not sure you want to join which project you want to join, have a look at it. Have a look at the project pages. There are the the the champions. These are the people that the contact person of the project. You can approach them. Or if you're not sure, you can go to the hackathon lost and found. You can put your name, your expertise on the wiki, and people that running a project, can find a match, and vice versa. People that run a project and looking for people can advertise that they're still looking for expertise. And that's the great thing of the hackathon. It's just meeting people, talking, exchanging IDs, going from one table to another table and contribute. Good. This is for today. We are now at the hackathon kickoff at 10:30. Next is from Teams, if you haven't done so, and it will be around 01:00 will be lunch provided. We ask everyone to be very specific about if they would join lunch or not because of, well, our planning. We we don't like to waste food, so I hope everybody has truthfully entered, correct, that they would join for lunch or not. The same for the dinner. Okay. So, okey dokey. So at 07:30 06:30, this the dinner provided for today, and the room closes at around 08:00. Again, next time. So this is important to remember. So because of lack of well, this this little bit this room will be used tomorrow around 04:00. Normally, we end at 04:00. So we moved the whole Sunday schedule, I'm sorry, one hour earlier. So instead of starting at 09:30, we will start at 08:30. We have a early lunch at 11:30, and we will start our presentation at 01:00. Not 02:00, 01:00, and we run into 03:00. So I will re remind you to well, later this today and tomorrow morning, 08:30, we will start again here. The presentation or the Gather. Yeah. I will skip that. People are using Gather. If you have not enough seats, just come by me. Charles is over there, and Barry is in the back of the room. Yep. There at the right corner for me. You can always ask us, about support, about hackathon, about other things, network requirements you have. Good. I will skip this. So we have together space we can meet. This is important. The presentations tomorrow at 01:00. So I guess we will have around 40 ish presentations, two hours, so that doesn't give much time. So we have to really to streamline all the presentations. First of all, submit your presentation before 01:00. That really helps us in organizing and coordinating. And the other thing is keep it brief, around ninety seconds, and that's difficult. I know. Maybe I'm already talking longer than the, promised five minutes or ten minutes. It's really difficult to be stay within time, so be very aware that limit your number of slides and try to present your project on a high level so everybody in the room can understand what the contribution is, how relevant, and what's the follow-up steps. That's important. Good. How to do that? Data trackers. We use the same procedure as working group. So submit your slides via the data tracker. It's integrated with Meetecho. It's fully streamlined nowadays. We have really great features in Meetecho to go to next slide without clicking too much buttons, which we did previously. Yes. We still have GitHub available for PowerPoint templates and HTML templates. People want to use that. So if you go to the GitHub repo of the IETF hackathon, you will find some information or some templates for for your presentation if you want to use that. This is important. So if tomorrow, if you start uploading your slides, the easiest way is to go to agenda, find the hackathon at 01:00. There's the upload materials, and then you see the pop up. Make sure you see the slides tab, and then upload slides, and everything goes smooth and automatic. And we will accept the slides. Be sure you upload them for the proper time slot, Sunday, 01:00. So that's the right stop. Double check that. I think I've said this 01:00. PDF format, please. And if you want to upload the revision after that, please use the exact name. So data tracker Meetecho will replace that to a new revision, and don't don't place a copy. Sometimes we have two, three copies of the same presentation or small changes. But if you use that's the case. People change the name in version one, version two, version three. Don't do that. Use the same name, and then everything goes well for us. And presentations will be made in order if which they are uploaded to the data tracker. So you can follow the the flow of presentations. And when you're up, so you can already walk up to the microphone with the presentation if your presentation is about to start. So that also helps in time. Good. The hackathon, this is from two hackathons again, ago, IETFs ago. This is the the GitHub. Instead of the IETF hundred twenty four, you see now IETF hundred twenty six. You can click on that, and there you find the templates if you want to use a PowerPoint or the HTML. Right. Good to know. In data tracker, if you have drafts of other work and you want to well, the work you have worked on during the hackathon, who that associated with your drafts, you can use additional resources. If you're the author if it's individual drafts, you can do it yourself. If it's a working group document, you have to ask the chair. And then you can have different text, and you can add different resources to your draft. It's a very useful feature of data tracker. Thank you, Charles. It was idea of Charles, and it's it's very useful. Monday is really the last thing I will mention. Monday, we have the HEC demo happy hour at 06:30 at at the same place where the registration is. It's a great way to present your resource to the broader IETF community. So if you want to present your project, you can register at the Wiki before 01:00. Is there an okay. It's on the Hackathon Wiki. Look for the hack demo happy hour, and then you find a link. You can fill in your name in the Wiki so we know how many tables we have to make room for, how many re tables we have to reserve. Good. That's it. That's it. We don't have a a code lounge this time, so please use the lobby bar. Probably a great place to meet other people to hang out and work on codes and discuss stuff. Good. Want to thank ICANN for sponsoring this event, and that's it. Any questions, you can find Charles, myself here in the front, Barry at the at the very back end, and success. Enjoy. Bye.
Session Date/Time: 19 Jul 2026 11:00
[00:00:06] Speaker 0: This one is looks so complex. This is a video. They're over here.
[00:01:33] Facilitator: Hi. Hi. Can I have your attention? Can I have your attention? We're not ready yet, but I want sorry. Can I have your attention, please? Some people that submit their slides to session one and session two. So can you make sure you submit to session four? I cannot manage this. I cannot download to upload. It is too much work. So I can mention the project names, validate YANG-Push to message broker is in the wrong session. So if this was your presentation, make sure you go for session four. The other one is DRIP End-To-End Implementation with DNS. And vCon, I already mentioned. Another one that needs to be rescheduled is let's see what we have here is I think we're fine. Green measurements, but maybe I've seen it also in let's see. Yes. It's done. Can you double yeah. It's done? Okay. Thanks. So then we're all in the same session. Otherwise, you won't get scheduled in Metekov. So make sure session four. Thanks. I think we can start. So Here we go. Okay. So some logistics. We lost some time, so we ask everyone to keep their presentation in ninety seconds. It's a challenge. You can do it. I'm sure. We have done this before and we did it and we finished in time. And again, we have a hard stop at 03:00. I am asked again, stop at 03:00. So excellent. We do that. You see the order of presentations on data tracker. So as you go to the hackathon data tracker, you see your presentation one, two, three, four, five, fifty plus. So if you see your next, you line up here and we switch places and slides and we do the dance and we run the show. Thank you. There you go. You're the first. Take, well, ninety seconds.
[00:05:49] Anton: Hello. My name is Anton. I'm from TKI Institute Estonia. I prepared seven slides, but sorry. Ninety seconds. So an AI agent pays an invoice on your behalf on whose authority and within what limit. Today, the answer is API key. No principle, no scope, no limit. Just copy it or prompt inject the agent and the action still looks valid. So we put a mandate in the EU digital identity wallet and selective disclosure job verifiable credential with key binding issued over OpenID for VCI, presented over OpenID for for VP. And it binds who the agent acts for, what it may do, pay invoice up to whatever amount, and the hash of this exact action. The wallet is the EU reference implementation and the Verifi is the commission itself. So under it is RADS Remote Attestation Procedures, a TPM quote appraised by Verizon and endorsed service type results live at sea, trusted list. So the implementation QR code is on the slide. I will not read the whole solution to you. One agent, three rounds.
[00:07:23] Facilitator: Thank you. Thank you. Thank you very much. Next is right. Right. Okay. Yep. Thanks.
[00:07:52] Ajuan: Hello. I'm Ajuan from from. I want to introduce the service affinity solution based on TLS. Here is the scenarios. You know, while we want to deploy the one service in several locations, we often use any cost of this. And the one customer want to access such service, then the network router will select the best optimal server for each service. If the overall packet destination, you need any custom address, the new one's network, the following packet, we all maybe locate the alluded to other services. Then the we call the service affinity will be broken. So we want to solve the service or affinity problem based on the TLS. We also exploit several current solutions under there are all the service shortage. I I will note the info here in details. The the details of the solution for our for the detailed procedure for our solution is shown here. We just after the it's not based on the first assessment, we the server will notify the client has a new address and let the client new accept the new system based on the new address. They they have also the implementation. Okay.
[00:09:30] Facilitator: Thank you. Thank you. Okay. Thank you for your support in the room. Right. There we go.
[00:09:45] Elliot: Okay. Hi. I'm Elliot. I I had a team of one really just to start working on some stuff relating to manufacturer usage descriptions, r t eighty five twenty, and some changes to TEAP. Briefly, what we did with TEAP really was, we me, was just to scope changes between the implementation and the draft or spot differences between the implementation and the draft. I won't have any more slides on that. For MUD, manufacturer usage description, it's been around for a while so we're reopening it a little bit to do some extensions, one of which is to clear up the use of IP addresses in MUD files. The other is to look at multicast that might transit off of the the local segment, which is a a device requirement, and the goal of MUD is to describe what the device requirements are, and to look at directed broadcasts as as well. And to demonstrate this with a visualization, in fact, you can drag and drop PCAP files now on MUD Maker to generate one of these files, which is sort of cool. So, you know, mostly what I what I did is I tested you know, built out the code. I have a a test load. I would have run a demo here if we had any additional time. And I found a bug in the spec, so that's standing by to be corrected and talked to Michael about actually adding a few things into the spec. And there's no time for the demo, and there's there is a slide information. But if you wanna see the demo, come see me at some point soon. Bye.
[00:11:11] Dan Petrie: Thank you.
[00:11:16] Facilitator: So so now we give Elliot applause of ninety seconds because he kept in time. Okay. Next, AI agent discovery.
[00:11:31] Yihan: Hello, everyone. I'm Yihan, and this is my my new version about about AI agent discovery and the invocation and protocol. It's mainly focused on the intent based agent selection as application layers. Is the most important about this review, the semantic routing. It means intent based agent selection here. And the draft used the term descriptively for selecting suitable agent as application layer. It's really different from the traditional the traditional routing in the network layer, and it means task to agent selection. It includes task intent, execution context, and selection constraints to rank the candidate's agent set. It helps a client host agent or coordinator describe the task force, and then receive candidate agent before invoking any specific agent. And the intent should describe the desired outcome while constraint bending one and the suit. It is a capability of discovery that produced candidates before normal invocation. And this draft draws a clear boundary around met routing, entered intent based selection answers which agent is suitable for a task, not how network traffic reaches a destination. Just thank you. You.
[00:13:08] Facilitator: Thank very much. This goes great. Okay. Yeah. Hello,
[00:13:16] Linzhou: everyone. I'm Linzhou, and then our project is about cope task resources for DDoS defense. And this is related to the draft, the cope task resources for DDoS cope task resources. This draft improves coping mechanism for long running operations by defining a common task resources patent for accepting, discovering, monitoring, observing, and canceling assault tasks. We defines we enable servers to accept the long running request first and expose task resources for our clients to curious status, observe progress, update pro parameters, or cancel the tasks. Here is what we have done in this demo. We did end DDoS defense demo based on code task resources and the model, the policy deployment as an a a synchronized task. And we also defend other sub operations for different steps. In this demo, we can see the every step we can see. We can know the task is ongoing or has finished or a failure happened. So what we learned from this project, it can make the collaboration of the equipment more efficient and more scalable. So here, it it is a brand new draft on call working group, and we will give a presentation on Thursday. So that's all. Thank you.
[00:14:54] Facilitator: Thank you. Next one request many credentials. There you go.
[00:15:03] Presenter: Okay. Hello, everyone. Okay. So the this project this project is on the broad context of agent identity security and specifically is on the heterogeneous credential verifier. So the context is one agent actually can have multiple different credentials within one single request Because each credential will have their own format, their own standards. For example, all the VC, VP, the x five zero nine, the agent JSON card, all or they are all different. So we need a mechanism that can detect, identify each of them and and verify each of them and eventually combine them into one single result. Okay. So our implementation, first we will have many different scenarios. Each scenario with different combination of different credentials. These are all real life stories that we will encounter. You can also choose your own scenario so you have free you are free to come to our booth at the back and play around it. Okay. So after that, we will detect, identify each of the credential, verify them, and in the end, combine them into one single result. Okay. So lastly, actually, you can see, this demo fits our overall broader picture on agentic security is on the credential and life cycle. What we did here is based based on all odds, actually, we have 12 different blocks all on agentic security and we map them to the all what's called agentic top 10 application. Okay. So if you are if want more information, you can scan the QR code there for our overall plan. Okay. Thanks.
[00:16:35] Speaker 9: Thank you. Thank you.
[00:16:44] Facilitator: AI agents.
[00:16:52] Speaker 0: From China Mobile.
[00:16:56] Facilitator: That is fine.
[00:16:58] Speaker 0: From China Mobile. It's our Hexen project is the AI agent security evolutionary part. The evolution framework here is we have six dimension with 64 metric here, and after step two, we will able to four dimension and 55 metric. And this sure agent, we do the test and give out the results score here. So we can see the evolution result here is not so high. It means that they have many security programs. So we have the king fighting and the risk analysis here in two of the three critical programs and two high risk here. Our platform architecture with four core way tool and six self development entries and the six four process metrics with two modes, remote and see the model here. And our platform will continues with the evolution. We are just in step two, and we will walk to step three. This is our platform, which name is a gensentino interface and road map. Okay. This is the last one. Thanks.
[00:18:32] Facilitator: Thank you very much. Thank you. Again, so next up is OpenEdge. Yeah. In HP.
[00:18:41] Speaker 10: Sorry.
[00:18:41] Greg: On HP. Yeah. Hi, everyone. Yeah. So I'm here to propose a new access model to defend against AI driven attacks. We all know that AI model is getting more and more powerful and faster on attacking tasks, and human just don't have enough time to to defend. And the traditional access model is authenticate after connection. So we propose a new protocol. It's called NSP, network infrastructure hiding protocol, to make the order service by default invisible until you are authenticated. So it's authenticate before connect. So with this way, AI have no means to to attack your service until the it's authenticated. So, basically, we are testing the default deny visibility and authentication before the connection and early access cycle. And here, we have a lot so all the details, it's in a in a in a IT document. And we have a live demo on open source website, opensource.lst.org at and /demo, and you can try it out. And, yeah, I also have a recorded video on on this website, and you can you can see how it works. And we we have a so the the Hexon the purpose of Hexon is to is to welcome everybody to to break the protocol. So the the whole protocol is based on is is based on photography. Yeah. Thank you.
[00:20:23] Ferenc Fejes: You very much, Greg.
[00:20:26] Facilitator: Excellent. I'm really impressed by everyone keeping this ninety seconds. It's difficult.
[00:20:34] Presenter: So, we added composite attestation support into open source project where I'm to talk about we added support for composite attestation support in, project where I can. That's the GitHub link. These are the my so when a tester become composite, you have multiple components coming together to form an attester. So we need to collect component evidences. So we need a leader tester on on the device, And the leader tester collects tokens from individual components and packs it and sends it to the verifier. We worked on a composite evidence token library in Verizon Redstee, support generation of composite evidence using a concise message wrapper as a collection. And, it collect claims from, it also collects claims for the leader tester and supports leader tester signing and verification. Library library also supports signing and verification. So it's a fundamental building block where you can do multi verifier verification of multiple components. So this is the GitHub link for the library, and there's associated IT of draft reference. CMW is RFC nine nine nine, and the composite retester is the draft link below. So we learned that challenge handling, when there are multiple components, each may have different challenge requirements. And to mesh that together is a bit of a challenge, but we worked around that challenge. Feel free to contact me later. Thank you so much.
[00:22:18] Facilitator: We go.
[00:22:21] Presenter: Ninety seconds marathon. Welcome, everyone. So you know who I am. And, basically, it's in the news that was the motivation of all of this work that the core mechanism for it confidential computing has broken down, which is basically the attestation protocol. And so many news other than that, like the critical flaw discovered the same, and confidential computing, the proof where it comes the authenticity, basically, that is the attested TLS protocol. And how it's broken, basically, that's in another news, which is the Attested TLS by the formal analysis all acknowledged, all recognized. What we did, basically what is the substantial technical concern behind all this media news is that all of the all of the the vulnerabilities that you see are maximum up to 5.9. And the one here that we have found is 7.5. It needs no access whatsoever, no physical access whatsoever to that physical machine. And that's why it's the most vulnerable that it sits the the the man in the middle or the adversary sits in between, and it does all the magic, and nothing is required to be in there at the place. So I want to thank all the people who have been contributing to this work, and that includes a larger list which will come later. But what we have learned in short is that the three drafts which are mentioned here are actually vulnerable to this particular CVE, and we will report accordingly to the working groups. And intra handshake is not a suitable option for standardization. The next steps are that we will have we will discuss the code and have side meetings.
[00:24:04] Facilitator: Hello,
[00:24:09] Ying Soo: everyone. I'm Ying Soo from Meng Soo Lab. I will briefly introduce our project, a publication point based incremental validation procedure for the API client party. As we all know, API always repeats a full top down objective validation. However, repeating validation for unchanged objects introduce unnecessary validation overhead. So to improve validation efficiency, we catch validation states for each publication point during initial synchronization, and the reuse PPCatch states when relevant validation inputs are unchanged. We model RPU validation as a function that rapidly validate publication point for CA. And after initial full validation, each valid CA publication can get a sage say can get cache entry, can buy, say, ID, and the storing effect resource and the poor project validate validation state. So during initial validate update, if the say is unchanged, so we can perform p p level cache reuse. Our implement results show that p p level hit rate can reach 99%, and the incremental update time can reduce to 49% to 90%. Thank you.
[00:25:31] Facilitator: Thank you very much. This goes really well.
[00:25:35] Ferenc Fejes: Success. Okay.
[00:25:38] Facilitator: Oh, yeah. The the arrows. You can use these arrows.
[00:25:41] Manu: Yep. Okay.
[00:25:44] Wang Dong: Good afternoon, everyone. I'm wondering from Huawei. Today, we present the agent networking infrastructure. Here is our plan. When the agent are working in in different across, How does agents discover a route agent and route the request? This is the architecture. You can see that the three gateways synchronize to discover each other. Each gateway has a agent registered with a clear, advanced scale, and physically, except for the mobile phone, other devices are inside a room. There are four phases. The first is the radar detect a fall for event. And finally, the family member will receive a message and video call from the family smart screen. Here is the demo and the results. What did we learn? The gateway based routing and agent has skill registration and the skill description are very important about the cloud domain. Thank you very
[00:27:25] Facilitator: much. Yeah. Here we go. I'll be success. You can do it. Great.
[00:27:34] Salim: Thank you. Hi. My name is Salim. I'm working with Rod Grimes and Alastair Woodman with support from the ICANN grant program, and thanks to the NOC team as always for their patient support in setting up connectivity. I'm working on ILNP. This uses an end to end addressing architecture with new data types. And so these data types have to be built into DNS and work with existing I p v six applications. So that's what we've been doing. We've got an implementation in PreBSD. The DNS records are already supported in various DNS software. So I have an authoritative DNS server serving from ilnp.net set up in Saint Andrews and a modified lib c, which fetches these new data types, l 64, the locator and the node identifier, and massages them into a 128 bit values that look like addresses so that existing I p v six applications can work. Here's the configuration we had. We had a server at Saint Andrews and a client here that was four way multihomed. If you run equivalent of dig on the both the client and the server, they look up names that resolve not to quad a's, but to l 64 and mid records. And if you run other applications, they get transformed into a 128 bit values. And so that's iPerf running fine with some ILMP goodness, which is some multipath connectivity. Thank you very much. These are all available as drafts.
[00:29:07] Facilitator: Thanks a lot. Yes. It's yours. Excellent.
[00:29:13] Chu Fang: Hello, everyone. This is Chu Fang from Huawei. So our Hexagon project is about the it's in the observability for network management operations. So the Hexagon plan is we would like to prototype agent observability platform of a network management agent, and this could provide the informational from foundation for the engine as in the benchmarking, the policy control, and the runtime intervention. So what have done is that we have finished the architecture design and implementation for network diagnosis as in observability platform, and we implement the collector to using GRPC to collect the raw data. And this raw data is converted further into the structured metrics and traces, and those information are displayed on the user interface. So what we have learned that the agent observability is very different from the traditional software observability. So and also the we also have a very common nondetermined issue and also the telemetry bandwidth bottleneck. So thanks a lot to all of our team members, and we have some specifications related to this work. So if you are interested, feel free to reference. That's all. Thank you.
[00:30:41] Speaker 9: Thank you.
[00:30:48] Facilitator: Yes. Yours. Okay.
[00:30:53] Jia: Hi. I'm Jia from laboratory, and we build an open PPPD prototype for the draft RPCA based validation with prioritized resource data. As far as the draft, API care remains a global sign baseline. However, operators may also use their own local or supplement data. However, there is no consistent rule for which data wins when there are conflicts. So we introduce priority and to the routers to decide which results it necessitate. In this hexel, we build three models on open to realize it. And model a uses source separated tables and on the routers, and we can validate the route table by table. And model b, we use multiple RTL sessions and merge them into one priority or one table in OpenVGPD. And in model three, we use one RTL session with experimental priority metadata. And the deployment trade off is clear that model requires no protocol change, and model b and c will need some changes. And our our lab test confirms that all three models can perfect can perform as we expected. And as far as the scale test, we can find that model a minimized the changes and the model b and c more minimize the configuration. And so we humbly require feedback from the RP developers and return vendors. Yes. Thank you. Sorry? Oh,
[00:32:34] Facilitator: the next is oh, excellent. Oh, there you go. It's super efficient. Okay.
[00:32:39] Jia: Thank you. And we also build a prototype for the draft as per base as per verification for BGP export. Okay. As per is a kind of data, and they send records authorized providers relationships between AS. And as per base as pass verification is use the data to verify a pass as right invite or unknown. The existing verification is performed at the ingress, and they stop as is to the egress. So the verification follows the outbound pipeline after the output policy and OTC leak gate and the local as pretending. We will use the proper algorithm and do the verification. We reuse the existing aspect engine of the OpenGPPD and add a new outbound call site to realize it. And the function is config per neighbor with three modes off, monitor, or enforce. We check the final pass after export processing and live as part updates trigger outbound revalidation without the recession resetting. Yes. And in our experiments, all five function and to uncheck passed. And so in this hacksaw, we realize the basic egress verification. In the future, we plan to extend it to cover more complex scenarios. And this draft and the last draft will be presented of Tuesday afternoon during the set of group meetings. So if you are interested, we can discuss more on Tuesday afternoon. Thank you.
[00:34:23] Ferenc Fejes: You very much.
[00:34:26] Facilitator: Yep. Okay. Oh, didn't use the arrows. Yeah.
[00:34:35] Presenter: My project is lightweight, long term validation for JWS. And extends JWS about archiving and the trusted time. Archiving means it extends the period and renewal refresh algorithm. Maybe it is PQC. So and this project is to use reference implementations, Java verifier, and test vectors. So how got So we are successful by the signature base and the sequence timestamp and any other test vectors. So some people so interesting the gist specifications about and also some people interesting the implementation of gist specifications. So maybe next time is a full spec test about this. So we are my draft is here and the code and the test vector is also here. So feedback welcome, so thank you.
[00:35:58] Presenter: Hi everyone. We studied how to implement TIP agents on real heterogeneous TEs. Background, TIP is an IT standard for managing trusted applications inside TEA's security. TIP Agent installs, updates, and removes TAs. Our question was how can we implement TipAgent on real TAs? Design consideration. A TipAgent must manage as TAs but different T architectures provide different capabilities. In Intel SGX-one application enclave cannot manage peer enclaves. In Opti, a pseudo trusted application can provide management authority, but this increases the native trusted computing base. Our faster design integrated the TIP agent into the native Wasm runtime. Wasm applications run as trusted applications inside a single enclave. This avoids peer enclave management. However, more native runtime code becomes trusted. We then moved the TIP agent into a signed and privileged WASM applications. The native runtime still enforce policy and provides privileged host functions. This makes the TIP protocol logic more portable across different TEs. Sorry. We will demonstrate this work on Monday, and we will also present the actual insight. Thank you. Yeah.
[00:37:44] Facilitator: It's very good. So you can ask more during the hack hack demo. Happy hour on Monday. Thank you. Right there. Get privacy. Yeah. Okay. So we follow the meet echo, so maybe there's some shuffling. We'll make sure that you're not scared. Yeah?
[00:38:05] Elliot: Oh,
[00:38:05] Presenter: okay. Hello, everyone again. So this is basically a quite cool demo. Basically, you can do image recognition in ciphertext. The context is that currently, a lot of times the users, we may have some sensitive data we want to send to some server. For example, it can be a MCP server or something. We want to invoke certain tools, help us to process the data, but we also want our privacy being preserved. In this situation but currently, let's say all the MCP tools, usually, we process data in plain text. To have the the data completely privacy preserved, a solution can be to process the data in ciphertext. That's why fully homomorphic encryption, FH tree will be a solution. So in this demo, what we implement is a homomorphic inference, which we have a neural network in ciphertext. And we can do image recognition web. The image recognition here is you can recognize whether your image is a cat or not. Okay. So we do this in fully ciphertext. Basically, it's encrypted. We implement it in OpenFHG. So what will happen is we have two MCP tools built. The first one is a Crypto tool. You use a Crypto tool to encrypt your image. You send it to the remote MCP tool. You will refer you will inference whether your image is a cat on the fully cipher text and will return you also the encrypted result and only you, the user, can decrypt it and see the result. The link here, we have our repo and also this this draft will be presented tomorrow in the this this patch as well. Okay? So please welcome Xiaopo to try your own cat image, Aiyo. Go ahead. Thank you. Here
[00:39:46] Facilitator: we go. Okay. The next page is the Yeah. Next page. Yeah.
[00:39:50] Speaker 23: Okay. Yeah. Hello.
[00:39:53] Speaker 24: Right. So this Hexong project is about how to identify and detect the incidents and issues. Both are have drafts. By the way, issues is a new draft. We just submitted. The solution to the problem is try to use agentic AI and the knowledge graph to solve the problem. So what we have learned oh, sorry. Is that what we have done is we build a framework that put pieces together. Mainly, there's a a set of agents trying to do cognitive reasoning And we build a knowledge graph that is a a basic single source of truth. And we report incidents and the issues once we identify the using young models. And just a to test the framework, we build a optical network of six nodes, and we tested some detect some incidents and then using cognitive reasoning. And then we can report the incidents using a young model that's generated auto generated by the AI. I forgot to write what I learned, but there there's a lots I I learned a lot. I mean, it it work the the AI based solution works to some extent, but there's a lot to do if you need to discuss offline.
[00:41:33] Facilitator: Yeah. Alright. Yours? Yeah. That's success.
[00:41:38] Speaker 10: You can use the
[00:41:39] Facilitator: the arrows.
[00:41:40] Yunsoo: Okay. Okay. Okay. Hello, everyone. I'm Yunsoo from Tsinghua University. I know and I I'd like to share our recent updates on our Hexagon project, AI assistant network protocol testing from certifications. Protocol testing is very important, but has still been intensive. Therefore, we propose an AI assisted network protesting framework with six stages to improve the efficiency. You know, current implementation, have six types of AI represent protocol representations that includes message formats, data machines, event action rules, algorithms, and the computations, error handling, and also local data structures. Each tab with these own semantic and some key fields. We also capture the the the relationship between errors, and we also make a cover scoping from the test requirements, testing environment, and also DOT documentations. After that, we generate test points, test cases, and also execute and analyze the results of what happened. Yes. And our next steps includes connecting the specific the the protocol knowledge with the with the device knowledge and also bridge the pre the protocol intent and the vendor specific models through a shared information or ontology on ontology. We sincerely welcome your feedbacks and comments, and we also have a draft and a report in the MLP. Thank you.
[00:43:08] Presenter: Thank you.
[00:43:11] Presenter: Here
[00:43:16] Facilitator: you go.
[00:43:19] Speaker 23: Hello. I'm going to present our results of Hackathon to add the support of post quantum algorithms in SSH. Our participation in Hackathon is supported by European grant, Quark. So we were trying to implement two drafts. One for adding JSS API key exchange with hybrid MLChem, And the second, support for pure ML, they say keys in SSH. We have four implement four open source implementations of some support pure ML, say in SSH. See the links? We have a container. Please ex please make experiments yourself. But trust me, we have interoperability on the wire. For JSON API exchange, we extend the the existing specification for JSON API replacing with MLChem. We have two implementations also compatible on the wire. We identified one problem. Private key format is not specified. We need to to discuss it at the SSH session. Come there. I will have five minutes. They are not ninety seconds, and we'll speak about it. Thanks.
[00:44:56] Facilitator: Hi. There we go. It's yours?
[00:44:59] Greg: Yes.
[00:45:00] Daniel: Hi there. My name is Daniel. XMPP is an ITF protocol for federated instant messaging. Like most instant messaging protocols, XMPP has a way to deliver read receipts to let me know if a contact has read my message. This specification is actually widely implemented. There are more than 29 known implementations. This can technically be used to also think the read states across my own devices because outgoing messages would be carbon copied to my other connected clients, but this obviously only works when it's switched on and most clients have a privacy setting to disable read receipts. So there's a different specification called message displayed synchronization. This is deliberately only about syncing the read state across your own devices, so it decouples syncing the read state and letting your contact know. Status quo be before the hackathon was that there are only eight implementations, so a lot less than the other extension. So during the hackathon, we we implemented, like, this in two more clients. We we revised the security considerations of the spec, and then also we discussed some potential traffic optimizations in this. And if this caught your eye, if you're now in XMPP and want to learn about XMPP 2.0, join us for our site meeting on Thursday at 3PM. Thank you.
[00:46:43] Ittaka: Okay, I'm Ittaka from IST here, presenting Secure Hybrid Network Monitoring. Today we don't have so much time, so for detail, please you have the previous slide. But we are in short making a protocol for monitoring the past security for the, how to say, multiple operator networks. So we have published two Internet draft at this moment. On this time, we implementing the latest draft into the demo systems. And okay. So so okay. So
[00:47:27] Speaker 29: okay.
[00:47:27] Ittaka: So in this setting, we have a VPN connection, but VPN goes through the some other countries so or regions so. And in user trace route or something like that, we cannot detect that. In this system, our system properly detects that even protected by VPN, the connection goes into the unexpected regions and correctly raises a lot for that. But this is customizable, so if we put the condition that VPN is okay, it will become clean. And this time I have a comment, I need a comment for input for how to express this kind of restriction in the ITF standard. So if you have any idea, let me know. Thank you.
[00:48:29] Roland Bless: Yeah. Hi. My name is Roland Bless. I'm here for the Kira hackathon. Sorry. Kira is a zero touch routing protocol for resilient control plane connectivity. We have our implementation in Rust, and we are using Nest, the network stack tester. So the plan was actually to test here on the larger network topology. And I brought eight Raspberry Pi with me. And plan is now to run 20 to 50 nodes on each Raspi and then couple them interconnect them. So this is basically a small test bed. And what we got done, Julius also supported me, was to fix a QRS DHT and do some stuff there. We were able to create topology files for the raspies, run nest on every raspie, but there's too much time, this hackathon, actually, to get things finished, unfortunately. So, yeah, thanks to Julius, who is here for his first on-site hackathon. And, yeah, there's more information. We'll be also at the site meeting on Thursday. So if you're interested in Kira, then please stop by. And I'm here for questions. Thanks.
[00:49:58] Greg: Yeah. Sure. Thank you.
[00:50:00] Speaker 31: Good afternoon, everyone. I'd like to begin with a story, but I won't. CoServ sits in this part of the RATS architecture, this conveyance pathway for to to the verifier. Our plan was basically to take the output of the previous hackathon and to upgrade it with all of the running code. We use Vorizon. We wanted to just update all of the drafts, all of the specs, and get that into the implementation and demonstrate some new query types in CoServ as well. What we got done, that's a picture of the architecture. We did manage to re spin everything and get everything upgraded. We dealt with some breaking changes. We got everything working end to end again. Some experimental code towards some new CoServ query style, but we need to take that further with the Vereison community to make an upstreaming plan. What we learned, I won't talk about Stanford Airport, but basically, there are no issues with any of the relevant drafts. That's all fine. Brazon server side stack has some catching up work to do, and supporting the new CoServ query style is going to require some follow-up with the Brazon community, and I've put some comments into the issue there. And that's the team, including my good self, and the picture of the truck is a joke that I don't have time for. Thank you very much.
[00:51:24] Facilitator: Thank you. Thank you. It's also a good practice to write and release codes in the airlines. The same thing we do actually.
[00:51:33] Elliot: Here we go.
[00:51:37] Yincheng: Okay, everyone. I'm interesting from. Our project is about using a sketch based algorithm to compress and exchange the network device network states from network devices and the a AI agents. The motivation is very simple as a network agents needs to have a comprehensive review of the whole network states. But the full flow records, controls, and the logs are very expensive and costly to move. So we proposed a draft to discuss the requirements of how the network state should be is com compressed and is changing between network devices and AI engines. Now we also build a a demo to to to show that we we use our company sketch to compress and merge the network data from different network domains and produce agent facing reports. The way or simulate a overall net sound of flows and achieve a compare conversion ratio of four four hundreds. In this demo, we learned that agent need the even the same information, the sketch compare compression is very useful. And let's say that these changes should be separated from action authorization. In future, we we plan to standardize our state artifact information model, and then maybe our accounts will treat the sketch as a reference solution. Now we will pass now drops on an at our MOP on on Thursday. Thank you.
[00:53:21] Facilitator: NTP. Oh, there you go.
[00:53:23] Presenter: Success that. Thanks. I'm here on behalf of the NTP working group showing what we did this weekend. We worked basically on the three main synchronization drafts that are going through the, working group right now, which is work on NTS pools, which should work on NTP v five next generation of NTP, work on rough time. Focus was on interrupt testing, getting people to engage with the pool experiments they're running. So for the pool, we found a bug in how it handles I p v four, especially with I p v six mapped I p v four addresses, which was fun. But we also helped
[00:53:57] Speaker 10: two people to get their servers
[00:53:59] Presenter: on the pool. We got a few more people to use the pool as clients, so that was a lot of fun. If you want to try it, the link is on the screen. For n t p v five, an interrupt harness was created, since, which was used to do a bunch of interrupt testing on initial implementations. There's a spreadsheet with results linked. We found some interruption issues between existing implementations and, of course, the standard problem of, oh, we don't implement the same versions of the draft. But we also found some combinations to work already, so that's good. This is still missing NTS, so we want to fix that in future. And the plan is to spend some more work during the week to fix some of the interrupt bugs. Finally, for a rough time, the interrupt testing was extended to measure both UDP and TCP. TCP is not yet widely implemented, and we found another bunch of version issues, basically. That's what we did. All the links here. Contact us if you have any questions.
[00:55:00] Facilitator: Thank There you go. Yes.
[00:55:08] Speaker 33: Hello. The goal of this framework is to define a canonical way to manage and share authorization policies. We use YAN to define these policies and distribute them in a matching, readable way. However, the policy logic itself is written using policies code languages, while YAN carries this logic to predict with this metadata. And this is approach is designed to support interoperability across domains, while different kind of policy engines, typically, PDPs can consume and enforce the policies. What we brought is a poly policy artifact model in the end, including a description, the policy language use, the declarative policy content, the owner, the author who created it, and the origin, what it derives from, the area, and the provenance. What we actually demonstrated, we have a an an scenario with two domains, step layer one, map it to open number one, and layer two, map it to open number two. Each one acting as a independent independent PDP and as a separate domain. In the demo, we submit a policy artifact model in YAN to the pub, which commit the policy and routes it to the corresponding PDP instant matching each area. And we check it with some queries to verify that which policies are currently stored in each domain. And then we play with it. We update the policy, delete them, and restore previous versions. We implemented the Jam based policy sharing. We demonstrated that area of most you have a very good and thank you.
[00:56:48] Facilitator: Okay. Thank you. Success.
[00:56:50] Xin: Thank you.
[00:56:50] Facilitator: Can you say that?
[00:56:51] Jia: Oh, okay.
[00:56:54] Xin: Hello. This is Xin from CAICT, and the name of my project is young based network management agent, a two u interface. So we are trying to focus on implementing a two u interface based on risk conf between a non agent OSS to network management agent. And there are two related drafts. One is about the NMA framework, and the other is about the NMA young model. So we want to solve the problem that the NMA capability is poor, intense submission, task monitoring, and human in the loop confirmation. So what's we have got done. So we implemented working a two u demo to exercise the draft a two u workflow end to end. So we've implemented OSS UI controllers simulated the controller, and you can check the code on on GitHub. And here are some screenshots of our simulated system. This is the OSS, and this is the confirmation card, which is very important for network management scenario. And you can try all the a two u a APIs. And I think we we we believe a two u is really useful, and you can just response to us or or comments give some comments if if you are interested. Thank you.
[00:58:37] Facilitator: K. Yep.
[00:58:44] Presenter: Alright. Thank you. So our hackathon project was looking at the MTL benefits independent of the network transport. We started with a new m MTL draft on DNSSEC that is self contained and uses MLDSA as the underlying signature scheme. This new draft also has additional IPR updated. The first thing we looked at was the zone size benefits. We signed zones of different sizes and measured the output to see how they grow, and we see the the MTL signed zone grows much more like the current ECDSA than the, than the, underlying algorithm. This reduces the memory to load and serve the zone. It also reduces the cache needed for the zone, and it may be helpful for zone transfers as well.
[00:59:30] Speaker 36: Oops. Wrong way.
[00:59:31] Presenter: We also looked at the PTC operations. Overall, we were able to speed up signing and reduce the calls to the HSM and the crypto libraries for signing and for verification. Again, if you look at the charts, you'll see that the MTL version performs much more like Elliptic curve than it does just as the raw underlying algorithm. Now how often do you need to do these operations? We did a simulation of this using a tool that looked at the hourly updates and a query rate, and it gave us a model that shows how often you would need to use those bigger signatures. There'll be more on that at the PTC side meeting this Thursday. Thank you.
[01:00:12] Facilitator: Okay. So next speaker is from the Spanish football team. We'll give two presentations, one about the project and one about the team tactics for tonight. So go ahead.
[01:00:27] Presenter: Thank you. For today, we have three minutes because we are presenting two projects. The first one is the the updates of the draft provenance, updates of encounter signatures, and our collaboration with Jamfus. First, the provenance, as we have seen in several hackathons is to assure the integrity of a model in young. Mainly, the use cases is the device configuration, integrity, and telemetry. What we wrote is, as always, in the last hackathon, you may have seen Kafka workflow for from us, but we are also adding the COSI counter signatures so we can enable multiple entities to sign the same content and allow the traceability of this integrity of this data. So the integrated and the integration details of this Kafka are the same as always. We have a producer that sends telemetry message data to the to the Kafka. We sign it first time with the signatures and and close it as the reference in the draft. And now the update is that we add two a second signature with COSE counter signatures. And lastly, we can validate with their digital signature, a selected counter signature or all of them to provide this traceability of the integrity of the data.
[01:02:05] Presenter: Okay. Hello, everyone. We did this for the Interop. So three different companies did the Interop for YangPush Kosei signatures. We had dMAP, which with a simulated device shuffling data towards our data ball collector and then trying to validate that with Telefonica's provenance library. So what we learned was that there's a lot of work to be done here with the interrupt, which we will continue to do. Thanks. And
[01:02:42] Presenter: lastly, we achieved a apart from the reference implementation update with the counter signatures, we have this collaboration with another reference implementation with this hackathon project. We have find new use cases for provenance. For example, the agent evidence package from the first presentation of the hackathon. And that's it. Thank you very much.
[01:03:13] Facilitator: Thank you. It's a success tonight with the final. Let's let's next one. Sorry. There you go.
[01:03:27] Yuto Nakano: K. Hello, everyone. My name is Yutu Anakano, and I would like to present to the So the Rock IS is the the authenticator encryption algorithm designed for the high performance requirements or app applications use cases. And the plan for this hackathon is to see if the performance of the encryption algorithm has any impact on the performance of the communication or throughput of the communication. So the two PCs are connected with 100 gigabit Ethernet and sending side will encrypt the data with Rock IS or AES and send it to the receiver side. Receiver side will decrypt the data with ROCIS or AES and count the decrypted bytes bits per second. And this is the result. So as you can see in the graph, ROCIS can achieve roughly 94 gigabits per second. So the same performance as the without any encryption. But if you use ASGCM, you can only achieve 30 gigabits. So the performance of encryption algorithms are very important when the two PC or in high throughput communication scenarios. And, yes, that's it. Thank you.
[01:04:57] Facilitator: Thank you. Thank you. Next up, API balls. There you go.
[01:05:11] Speaker 23: Hello,
[01:05:14] Tim: my name is Tim. We worked on the Happy Eyeballs web tester, tested different versions. There's the stable one for FOUR one and FOUR two, and some FOUR3 test cases. The dash is important in the domain. And there's also the staging version, which we are actively developing on. So it works most of the time, and you can find there more Happy Eyeballs version three tests and can test your ligand. This looks then, for example, like this, where we apply varying delays on different protocols, in this example on IPv6 and on QUIC, and Firefox then produces these test results with the different delays. Yes. Then in the Hackathon, for example, we added HTTPS resource record stuff with here alias mode and service mode, and as you can see Firefox in this version does not follow the alias mode, but does also for the service mode, and the port is also considered. Thank you.
[01:06:28] Facilitator: Thank you.
[01:06:32] Speaker 41: Yes? Yes. Cool. Yes. Hi,
[01:06:36] Presenter: everyone. From the University of Murcia to this hackathon, we have brought project focused on COPIP. Our goals have been to rise awareness of this recently standardized authentication service and to show a demo. We have developed the first COPIP implementation to have deployed to have been deployed, sorry, in a physical IoT scenario. The most important part is that the only resource constrained device in this image is the mode from Nordic that represents the IP peer. We have achieved very good reliable results in terms of number of my of bytes transmitted over the network or time measurements. You have version of the code in GitHub to anyone who wants to test our work. We have also improved this implementation with with an additional Wisehack dissector. Thanks to this hackathon, we have taken into account how we can reduce even more the number of bytes thanks to Cheek and apply copier COPIP in a different of use cases scenario where cryptographic materials is needed in advance. Thank you very much to my colleagues and.
[01:08:14] Speaker 41: Yep. Okay.
[01:08:16] Presenter: Thank you, everyone. We've been working first time at this ITF event and the hackathon, thanks to the support from European Commission to making post quantum on application level a reality. So we came we have two projects. One of them is a new ACMA server that also implements Merkle three certificates, and we were working on interrupt testing and found some bugs. We also improved a bit the Miracle Tree certificate support, and there will be some screenshot of that and explored the ways of doing the new algorithms through the libraries stacks. So we got the FNDSA, for example, issued certificates with FNDSA even though OpenSSL doesn't have support for that yet. And here is an example of how a tree timeline visualization could look like. And the second thing is the PostQuantum Kerberos PKNET support.
[01:09:29] Presenter: Hello, everyone. So very quickly, PKANET is an extension of Kerberos for supporting authentication based on x five zero nine certificate. We have a draft providing support for MLChem and MLDSA. We also have an implementation based on MIT Kerberos. And we, as part of the hackathon, I wrote, we are shocked this sector for it. It's available in this APM report.
[01:09:58] Facilitator: Thank you. Okay. So this is a challenge for everyone here. Still 37 presentations to go. So I promise to close at three. So you still have ninety seconds, but maybe the rest should already prepare mentally for sixty seconds. I'm sorry, but I want to give everyone an opportunity to present. Yeah. Thank you.
[01:10:25] Speaker 45: Hi, everyone. We have my team to introduce our project. First, I will introduce what problem were we working on. The first is felt hard to pinpoint across different domains like IP and optical networks. The second is large scale production configuration make configuration translation and validation time consuming and complex. And the third, network con changes may introduce hardened risks and the latent felt why their potential device impact is difficult to access before deployment. So we aim to build an intelligent network operation systems. It including three main functions. The first is cross domain failed to localization, highlights IP and optical network data to identify root causes and effective device using troubleshooting skills built from expert op operational experience. And the the second is automated configuration, translation, validation. The third is network change risk that detection. And the architecture of our system consisted of five core companies. That's all. Thank you.
[01:11:52] Facilitator: Thank you. Okay. Are you up for it? Sixty seconds. Yeah. Oh, I'm impressive. Hi
[01:12:09] Speaker 46: everyone. Our project is SRB6 SFC architecture with SRWR function. The objective is to realize comprehension management and control of SRB6 SFC through our architecture proposed in the spring. This is the implementation we use and this slide shows our implementation overview. We implemented a user and operator application, BGP prospect extension in the free telnet VFX and OpenPCC, a Linux based PCC implementation. The application receives user or operator intent and orchestrates the SRBX SSC development. Manager configure VMs and end to end functions, while controller compute SFC segmental risk and distribute flow classification rules. Finally, the SFC traffic sharing become ready. We also implemented WebGUI based, sorry, Eta for example.
[01:13:31] Wang Dong: Yep.
[01:13:33] Abhudai Hegri: Hello, everyone. Very good afternoon. I'm Abhudai Hegri. I'm an undergraduate at, National Institute of Karnataka, Swarthgar. And, this is my first time at IITF. I'm with my professor, Mohit P. Teliani. So for the hackathon objectives, we had the objectives as performance evaluation of FQPY and FQCodal queue management algorithms over mobile hotspot and QQ I w two zero five. And, also, we tested the integration of PicoQuick and s three. So these are the topologies, and these are the couple of graphs that we obtained. And this is the one for the access point. So we'll be discussing more about that in the TSVWG working group sessions as well as the CCWG ones, so please, feel free to attend them. And this is the result of PICOPE Kinester integration that we have done, followed by a couple of things that we had done, prior to ITF one twenty six. And, yeah, thank you for your time.
[01:14:44] Facilitator: There you go.
[01:14:56] Presenter: This is our haircut first. Is our haircut first. We show how Lingual receives natural language intent and execute actions. This is the eye to eye share frame framework. The controller creative policies and RIMU executes them. Our goal is to run natural language intent into robot actions. This is the previous framework. We added natural language translation and robot control. This is our demo setup. We converted natural language into those two actions. Next, we will improve the framework with lower less better let latency and early time with your load detection. Our code is on GitHub. This is our Ecotone team. Thank you for everyone.
[01:16:05] Facilitator: I'm really impressed by your flexibility. Thank you for so much. There you go.
[01:16:12] Speaker 49: Yeah. So sign is a new password where secure Internet routing protocol. First of our project was to actually get native sign connection for the IITF meeting that pretty much succeeded. So if you want to try it out, use the QR code for some examples. Almost because we do actually have to tunnel from here to one of CyberLink's sign notes in Vienna, but from then on, you're on a public sign Internet. Unfortunately, we have to take down the note after the meetings. We have to try out before, but we try to get it back up for the rest of the meeting from Monday on and so on.
[01:16:49] Speaker 10: Thanks. Well, we're not quite done. We also have a local testbed that we set up that you could join. If you want to try this later, there's a link. It's on GitHub, and we did some experiments. Thank you.
[01:17:05] Facilitator: Thank you. PQ. It's the
[01:17:15] Speaker 50: right person.
[01:17:16] Ferenc Fejes: Yeah. Hi.
[01:17:18] Speaker 51: Yeah. So we continue our PQ interoperability testing project. This is like the tenth one. So we're testing PQ algorithms, signatures, giving feedback to graphs. Saw a lot of them there. Don't have a lot of time. So what got done since March, this project continues. We have monthly meetings. So we continued composite signature and chem testing. We actually have six implementations of the composite chem now, 13 of composite signatures. A bunch of people added new artifacts for those things. So it's great to see that. We have added OIDs for ProtoChem and Mechelisa algorithms, cause those are testable now. And yeah. So so we had the first interop testing of those for FrodoChem. We also had defined artifacts for Jose and Jose, and the first interop testing of those, Lucas Prabo was doing those. I did a little bit on certificate discovery in the last interim we had. We did peak kicks interoperability testing. We had done some extra. Carl Wallace had done some things with that. So that's there, and we've done
[01:18:21] Speaker 24: a few more. Come join us. Yeah.
[01:18:23] Yuto Nakano: There's a
[01:18:23] Speaker 24: lot that we do. Thanks.
[01:18:36] Presenter: Hi. Good afternoon. Acme Rats.
[01:18:38] Presenter: What does it do?
[01:18:40] Presenter: Acme Rats traditional Acme, you verify that you have identifier that's connected that's related to your HTTP or DNS. Acme Rats, it actually verifies if you are tested. The if you're using Wi Fi, using EAP TLS, this will make your life much easier. And for this ITF, we have implemented the Acme client and the Acme server. So the Acme client, we extended the the Go implementation of the Go Acme client. We added a new challenge type. And for Acme server, we have a demo server for to end event demonstration. So we have the full end to end expected behaviors. You store, all all parts of it. And we have some insights from the implementation that could be helping update the draft. And we'll be also presenting the Acme working group session.
[01:19:35] Speaker 53: If you're interested, please come. Thanks.
[01:19:44] Facilitator: It
[01:19:46] Presenter: is my honor to present you Eine Klein Flopmusik by Wolfgang, Mozart. A demonstration bringing YangPush UDP Notebooks to into the Lay three VPN service model. First, next. Yep. We spent all of yesterday on implementing YangPush UDP Notebooks platform so that it can now receive unchanged telemetry from the Cisco NCS 5,500 device that you see in the middle of the picture. So in this demo, we have a MIDI keyboard that controls the BGP speaker. Pressing a key clears a BGP session. The XR device reacts, sends UDP notification over the wire. StrataWeave receives this, reacts, and ultimately updates the dashboard. The latency is imperceptible. StrataWeave is a declarative orchestration platform with fantastic telemetry support. It is open source, hosted by the Linux Foundation. Layered abstractions are first class, so you can push config down, get telemetry up. Dashboard. This is us. Oh, sorry. That's done. That's doing. This is us. Thank you.
[01:21:00] Facilitator: Music. Oh, no. Quick. Sorry. Yes. Yeah.
[01:21:04] Speaker 29: So for thank you to everyone who helped for this hackathon. So here, the objective was to see how we could extend Quick to implement multicast inside this, but with as little changes as possible. So the approach was to have this extension to send a simplistic, unreliable data over this multicast QUIC extension. And the objective was really for it to be implementable during this hackathon. Of course, if we want to do things further, we have to consider other stuff like the two drafts we have here. But for the Akathon, we managed to implement this in multiple implementations. And we had this setup where we use the ITF Hotel Wi Fi, and we had a video stream over RTP, and we managed to make it work on laptops and even iPhones even with this simplistic implementation. So thank you. Excellent. Thank you.
[01:22:07] Facilitator: Hi, V. Hackathon. Yeah. There you go. You can use Hi.
[01:22:12] Speaker 36: Hi. I'm Nigel Lewis. That's the team. That's the AI generated poster. It won't scroll on. Yeah. Okay. So we IV's interface transferring equipment inventory information between controllers and to orchestration imaging systems, get some good good preparation. Key thing in the preparation period is we got operator endorsement for the work we're doing, which is critical. Otherwise, we wouldn't be here. During the activity, we put together a number of different configurations of Cisco and Sienna product using the ID interface. We got some good good interoperability. Enjoyed the power down yesterday. It was fun. And we've got some key findings which we can feed back to the Ivy team on things that are missing, especially compared to the TAPI interface, which is the interface we use on the optical controllers. So after this session, we'll be feeding back to Ivy and making progress and advancements. Thank Yep.
[01:23:22] Facilitator: Yours.
[01:23:31] Tianyi: Hello. I'm Tianyi from China Unicom. Our agent road is a prototype built around agent gateways. First, agent capabilities and instance date are registered with the controller. The system then analyzes the user request and the the required workflow. For every step, it is like the agent instance and works it through an agent gateway and passes the output to the next step. The goal is to validate the complete path from request to workflow to result. Registration produces a semantic fingerprint for each instance. A user request can then be matched against registered capabilities and as an old data workflow. For example, drafting, polishing, and reviewing a document. We also tested our experimental agent awareness option for all. Thank you.
[01:24:45] Mitro Ochkas: Hello, everyone. My name is Mitro Ochkas. I'm from EMTA Atlantique in France. And the goal of this year's hackathon, it was to implement the draft where we proposed lightweight cryptographic suite for COSI. And based on this draft, where we proposed ASCON AAD with 128 bit tag and 64 bit tag, 32 bit tag and for COSE encryption and for for the for the hash and we used for HMAC and HKDF operations. And we contributed to three different open source library libraries from Kornbergsang, Kosei Working Group, and Microscore library. Benefits of OSCON is that it's a lightweight pro cryptographic suite standard type by NIST, and it has single permutation model, and 32 bit tech can be used in very constrained environments. Yeah. These are the achievements. Thank you very much, and join the QOSI meeting on Thursday.
[01:25:58] Speaker 57: Hi, everyone. I worked on ECH tool these days. It helps you to customize your ECH handshakes. You can even use it to contact ECH servers that do not publish ECH configuration in HTTPS records. There's the CLI tool, and I also built a quick website where you can tamper with it. Please check it out, ask any questions. And if you want to learn more about how you can use this method to discover ECH deployments, then go to the TLS session on Friday.
[01:26:41] Greg: Hello.
[01:26:45] Joseph Ba: I'm Joseph Ba from Korea's SKTU. I'm talking about the five g I 20 s f. And this is our poster and our goal of the project is to make the edge based security system in five network with the I 20 s framework. And this is the basic function of the connecting our system with the five core functions. And you can see the flowchart of the each of the functions. And this is the detail of the our whole system. As you can see, when the UE handover triggered the NSF, which already installed on the source s server can be also inserted and activated on the target edge server. Before that, the SCF function can be migrated the policy to the target server. We learned about integrating the i2s framework with the five gs server. This is demonstration and this is open source and video clip. And next, we will elaborate the ongoing policy migration and we apply AI agent to our system. Thank you very much.
[01:27:55] Facilitator: This looks like a trial. Success.
[01:28:01] Speaker 59: Hello. We are working on the IPW assessment project. This poster gives an overview of the IPWASS project. This figure shows the IPWASS in reference scenario. Our goal is to identify pavement challenges in satellite NTN environment. TSF and TPD are late works for our prediction based forwarding approach. This simulation computes early relay passes from London to Cape Town. We are compared to terrestrial terrestrial and earlier relay passes. In the demo, we use MATLAB to generate a large satellite concentration. Prediction helps make earlier relay passes more stable. Next, will extend prediction aware forwarding analysis. The code or materials for the IPWA same projects are labeled on GitHub and you can watch the demo video on YouTube.
[01:29:13] Facilitator: Hello.
[01:29:16] Ekwee: I'm Ekwee. There's a draft in six man that describes a new mapping of an I p v six multicast address into Evernet. This is gonna be presented tomorrow in the six man session. And for this hackathon, I tried implementing this for the Linux kernel. The result of that is literally on this slide. It's 31 lines of code. That's all of it. This might be presented tomorrow afternoon at the hackathon demo, and that's it.
[01:29:41] Facilitator: Thank you. Okay. We have a new record. Thanks a lot.
[01:29:54] Speaker 61: Yeah. So our our project concerned in network in network telemetry aggregation using IOM aggregation trace and template options. Essentially, are concerned with aggregated telemetry data as a package reverses the network. And in this hackathon, we were comparing actually different alternatives, extending two of the POCs that exist for this with different transport options and actually adding a new capability to also combine this with a a path phrase. For this, we introduced a new a new option. You see this displayed here. There was actually some feedback as an outcome and so forth that we pulled back into some of the other options which are in some of the Internet drafts. There is a POC for this. We are happy to show this to you. And you'll find more information in these drafts. Thank you.
[01:31:10] Speaker 62: Hi. We've been working on RPP, which is the, restful provisioning protocol, which is used for managing domain names between registries and registrars. So we've been working on actual running code by prototyping a registry and a registrar API in order to see if we can try to, develop a secure way for transferring domain names, without using insecure tokens. Also worked on implementing other RPP specs and had some good discussions. This is an overview of the dummy registry that we created. This registry contains a few test registrars and domains, and this is the transfer request from a registrar that wants to reg or transfer a domain name, gets redirected to the registrar where the domain name is hosted. The registrant has to log in and approve, and after that is returned to the registrar where the request was originated, and the transfer is completed. So success.
[01:32:20] Facilitator: I made a call. There you go. Hello. Hello.
[01:32:24] Christian Amsüss: My name is Kristin Amsys. I've been working with the team of Embedded Call for the last month in order to build an interface by which we can have easily portable access to the cryptographic accelerators, but just as well to formally verified cryptographic libraries that can be used for the various cryptographic higher layers that are specified at the ITF. It's COSI, TLS, and named information hashes. And as part of the hackathon, we integrated that with an actual example thereof. That is the Lakers library that is implementing the protocol and also built an example where the operating system is providing the cryptographic accelerators that are supported by the platform in order to do a co op exchange efficiently.
[01:33:11] Speaker 53: Thank you.
[01:33:12] Facilitator: Hi
[01:33:21] Nikolay: everyone. I'm Nikolay, and together with some colleagues from and Harvey Hamburg, we've worked on new co op implementation for for RiotOS. The initial design and code has been produced by Carl in as a thesis project, and the goal of this hackathon was to advance the integration into upstream. So we already had the messaging and parser merged upstream. But what and what we achieved this time was testing the server implementation, and it's right now in the merge queue, actually. And we also managed to, like, implement some new features, like group communication, and started to think about a design for OSCO integration into Unicorp as well. Thank you.
[01:34:17] Presenter: Great. Yes?
[01:34:18] Javier: Hello. My name is Javier from Huawei. I present this on the long of the whole group. This is for the group activity. The objective of the work was the measurement and the special of energy data. For that, we have a setup lab in Madrid remotely with one traffic generator, a couple of routers, and a video. So we can compare the measurement coming from the PDU and the tester and the routers. We have created a a dashboard in the hackathon so we can compare what we are receiving. The solid line is from the PDU. The that it is from the router. The difference is not so big. It's about 5%, but due to the scale, we can see that that. We need to investigate anyway how is this happening. And, also, we need to work this using Jam model. For more details, you can go tomorrow to the session. Luis Contrera from Telefonica will give you more data. Thank you.
[01:35:07] Facilitator: Thank you. You. Right. I saw the logo. Yeah. You're the one.
[01:35:23] Speaker 53: Hi. So we are trying to put the robots in the lake or actually the other way around. So our problem is that we want to deploy IETF protocols in a test bed of up to 1,000 robots that we built. So the thing is that we have Lakers formally verify the Rust implementation of ad hoc, which is lightweight lightweight authenticated key exchange for IoT devices, and we want to run it on the test bed. So the idea was to use the the test bed, a few robots that we have here, to test. We don't have 1,000, but we have, like, two in my desk and a few more. I may show them tomorrow. And then the result is that it worked. So we proved it. Demonstrated running ad hoc there, And that's it. Can talk later, and we are looking for funding. Thank you.
[01:36:18] Speaker 9: Thank you.
[01:36:22] Speaker 29: Yep.
[01:36:25] Greg White: Hi. I'm Greg White from CableLabs. This is the ninth iteration of the l four s interop at the IETF hackathon. There's the team. Thanks to everyone who participated both here and remotely. We also had a couple of new hackathon participants this time. In terms of what we focused on, we're testing it was testing done on the libweb RTC implementation of the integration of the screen congestion control algorithm interacting with a l four s bottleneck. I just take a step back. If if you're not familiar with l four s, it's an architecture for the network to provide real time feedback to an application in order to allow the application to make use of the network with with minimal delay and and zero packet loss. Digital testing was done with the Netflix congestion controller as well and with the Apple responsiveness test with l four s functionality integrated. Picture of our test bed. Thank you.
[01:37:32] Speaker 9: Can a demo?
[01:37:33] Presenter: Can you take a demo?
[01:37:34] Facilitator: Okay. Oh, no demo. Sorry. Young SID extensions. Yep. Okay.
[01:37:51] Alejandro: Okay. Hello, everyone. My name is Alejandro. So the work we did was related to YANG SID extension. It has useful data to YANG SID files. So type and key mapping, which help to convert into, for example, CBOR for CoreConf. So this is a use case. We are doing, for example, a SID query like a DNS. So, yeah, the problem is that the SIFT file currently does not match the young data model, so we are doing some maintenance there. So, usually, it's only the SIFT number, and now we add the data types, which help us convert to and from SIVOR, for example. So, yeah, we're just doing repo maintenance. Thank you.
[01:38:49] Facilitator: Thank you. I think yep. Okay. So that's Yang? Yeah. Okay. Thanks. Thank you. Hello,
[01:39:07] Speaker 68: everybody. So this is about Yang push to message broker integration. We are testing interoperability between the YangPush publisher receiver and also message broker producer and consumer in the schema registry. This is the schema repository. The architecture overall, we have the subscriptions, the notifications, and also some packet captures, especially this time on DTLS and CBORE recording. Also the RPCs we get from the system capabilities and the young library. And here, the comparison between the different network operation system implementations, see we're having more green ticks. Also on the subscription side, now we are going towards the ITF and IEEE Yang models. That's progressing as well. And then the message will kick out. Thank you very much. Thank
[01:40:05] Facilitator: you. Okay, next one. Success. This is your first time. So
[01:40:10] Speaker 50: Yeah. I got thrown
[01:40:11] Ekwee: in front of
[01:40:12] Speaker 50: the bus here. I'm representing the entire DNS table, which did a bunch of DNS related work. I'm trying to summarize it here and also the draft names. And I forgot the organizations that these people represent. You will have to do your own research to find out. Three different Delegate track sort of implementation work to your favorite DNS libraries, and also a custom authoritative server and then some additions to zone signaling from authoritative servers and the serial zone version. Some details here, some implementation work being done to your favorite, DNS servers, will be available soon, and you can also play around with those zones and ask queries for their authoritative name servers to see some new, transport signals. And also here is some custom software that implements the latest changes to Delek, and also this back end serial zone version being added. Excellent.
[01:41:16] Facilitator: So rest of the week will be easy peasy for you now. There we go. Benchmarking.
[01:41:26] Olivier Pozzobon: Hi. I am Olivia Pozzero from Industrial System Institute. Our work to today, this hackathon was to try to benchmarking different post quantum authentication method for Edgehook. Well, we base it in our open source implementation for both PQ signature and base authentication, and we try to see suitability for constrained IoT devices in both simulation and real world conditions. We make it, we simulate, for, three different, from signature based and chem based with different algorithms. And also, we're running in real boards and in a real open thread network using the PQM4 optimized implementations. And what we learned is that both methods are functional on Cortes M4 with the authentication basic method to be significantly faster in point to point real devices and similar transaction times under same packet loss than Falcon.
[01:42:36] Facilitator: Hi, Tiffany. It's yours?
[01:42:40] Raghav: Hello, everyone. I'm Raghav. We've been working on the SCORN protocol at the hackathon. So SCORN's a mechanism that allows middle boxes to advise applications of the expected throughput, and it can be used in adaptive bit rate video streaming. So the so a good rate of video can be selected. So at the hackathon, what we've been doing is testing Scone using dominant over emulated networks with low RTT parts, high RTT parts up to six hundred milliseconds. And we've also created a Wireshark sector, which we're hoping to make public soon, just a bit of testing. So what we learned, you need to choose your Skone advisory signal very well very carefully because the benefits are at specific sweet spots. You have policy enforcers, can also add additional complexities. And then that's that's our team. We do need help. So if you have any help, please contact us.
[01:43:52] Steven Mi: Hey, everyone. Steven Mi from Action Group, and I'm from San Francisco. First time here. Agent action capsule is assigned content address record of what an agent actually did. It's anchored in skip and verifiable without trusting the operator or increasingly another agent. When action has four or more verdicts, what may happen, what, did happen, who's behind it, and is it on record, each from a different party's receipt. And today on this, we have 31 formats, more coming out every week. They live longer than ones die. And so pairwise, that's 465 bindings. With one shared digest, it's only 31. This weekend, we got four things accomplished, one with one log, four projects, Microsoft, Murray's PR for RFC ninety one sixty two profile in Pysit, and, tested on our vectors by identical one statement to transparency services. MIT Media Labs and Nanda Index, Mahesh, Ved, and Ankit, thank you so much.
[01:45:03] Facilitator: Okay. Someone in the room?
[01:45:06] Speaker 72: Hi.
[01:45:07] Facilitator: Hi. Oh. Hi. Please go ahead.
[01:45:09] Speaker 72: I'll go very fast. So we have an established startup in India, and we are working on assessing the side channel as well. I'll go can you go forward fast a bit to the next slide?
[01:45:27] Facilitator: Yep.
[01:45:27] Speaker 72: To the next one. So we are basically working on testing the hardware wallets using automated machine learning approaches. And next yeah. So we proposed a solution where we used automated machine learning approaches like neural architecture search in order to simulate real world attacks on hardware wallets and test the vulnerability using the vulnerability score. Can you go next? Next. Yeah. So these are the results on the datasets that we use. And now we are going to apply them on the commercially available datasets, and that's it.
[01:46:09] Facilitator: Thank you very much for your remote contribution. Thank you.
[01:46:16] Yuto Nakano: Hi.
[01:46:19] Dan Petrie: My name is Dan Petrie, and I'm the author of the vCon core spec. We had the goal this this time of doing some updates on some of the tweaks that happened in the last two two draft updates. And, yeah, we also got into a kinda CDDL revival discussion. And bunch of people were part of the discussion. And, basically, what what we got done, we you know, by looking at CDDL, actually, it was useful because we kinda looked at the at the text in a in a in another dimension and identified a couple of ambiguities and things like that that will go into the next draft. We also validated some of the some of the things that that we we had defined. Open source is available here. I hope you will have a look and see me tomorrow at
[01:47:19] Ittaka: Hack Day demo. Thank you.
[01:47:23] Facilitator: You. So we just got five minutes extra, so we can finish it in time. Please go ahead. Thirty sixty seconds. Manu?
[01:47:39] Manu: Oh, this is not me. Sorry. Ah, this is the last one. Yeah.
[01:47:43] Facilitator: Okay. Who is presenter of this?
[01:47:47] Wang Dong: Nope?
[01:47:53] Facilitator: Yeah. Time is ticking. I go to the next presentation. Payment that cannot overspend. Those are the remote presentation. You're in the room? No? Is it you remote? No? Okay. Then we go to the next. Drip. Yeah. Please go ahead. So
[01:48:28] Speaker 41: good afternoon, everyone. I will present to you our contributions to the Drip working group and especially our end to end implementation regarding DNS and DNSSEC. So I will skip to our experimental setup. So we have our DNS server that is working, our drone emulator, which is working on a Nordic semiconductor card, and our Node server, which is running on an Android smartphone. So here are our key contributions. Basically, what we try to do is to be fully RFC compliant regarding the RFC ninety three seventy four and the 90 RFC ninety eight eighty six to to keep interoperability. And here are few examples of drones identification using the the observer application. Here is a drone which is not trusted with no signature and no DNS validation, and here is one that is trusted with a proper broadcast, HDA endorsement, and DNS validation. Thank
[01:49:28] Facilitator: you. Thank you. Okay. Who is remote or in the room? It's you. So
[01:49:52] Speaker 9: we have this draft for management of network tester, which is the last stages. And we have been going on with the hackathon participation for a while. This is usually the plan. And testing the sender side is quite heavy, so we don't bring that equipment anymore. But for this hackathon, we decided to do a Wireshark x cap module that can do capture functionality based on the NetConf model that is part of the draft. So this is how the model is managed, and this is the type of information that you can get from a device that implements it. So this is what we did.
[01:50:52] Facilitator: Okay. Here we go. QMesh pie. Remote.
[01:51:01] Manu: Yeah. This is Manu here. Yeah. Can I go
[01:51:03] Facilitator: ahead? Yes. Go ahead.
[01:51:05] Manu: Fantastic. Yeah. Hi. This is Manu. We are planning to develop a solution solution for QMesh that is distributed quantum services using left b two p. Our focus is on essentially developing a decentralized quantum orchestration using a peer to peer transport fabric for resource discovery, planning, and remote execution. The idea is basically to understand when to be a classical computing exercise and when to be a quantum computing exercise. We also are presenting a let me to be a draft at MAPRG group on Thursday. I'm looking forward to having to seeing you over there. We have made some key enhancements in intelligent routing, discovery, and also secure communication channels. Move on, please, to the next slide, sir. Thank you so much. So what we have been able to accomplish is a planning logic, a node discovery system, an execution system, an optimization integration, and also verification logic. Also arriving at a very clear clarity on where it can be used, like, for example, in drug discovery, material discovery, and financial modeling. Yeah. Just go next, sir.
[01:52:03] Facilitator: Thank you.
[01:52:05] Manu: And, yeah, this is just the last part. Basically, these are the resources.
[01:52:11] Facilitator: We have to close. Sorry. So we we have to we have to go to the next press release. Thank you.
[01:52:16] Presenter: Sure. Thanks.
[01:52:18] Facilitator: Yeah. No more decks. So one to go. I skipped by accident. SRP six.
[01:52:30] Speaker 49: Right. Right.
[01:52:42] Facilitator: S o v six at the start. There we go with the timing. Oh, here. No. Can you walk with me? The start is at the very end.
[01:52:57] Ferenc Fejes: Generally, we can start. Yes.
[01:52:59] Facilitator: Oh, this one.
[01:53:00] Presenter: Okay.
[01:53:01] Facilitator: There we go. Sixty seconds.
[01:53:03] Ferenc Fejes: Hi, Ferenc Fajes from Ericsson. And here I implemented sorry. Ferenc Fajes from Ericsson, and here I implemented SRE six redundancy seed in XDP with Linux. And we have two drafts. They are adopted for work group, so the details are there. Right now, they only support IPv6 flow labor based flow identification. So at the ingress node from the talker, the packets are identified by their flow labors only. And here, I implemented with AI the small CBPF interpreter within eBPF. So libpcap compiled the TCP dump filter expression to CBPF and CBPF compiled and interpreted inside EBPF for each packet. And here are the open source implementation and the drafts. Thank you.
[01:54:09] Facilitator: Super. Thank you. Okay. Thank you all. So I have to I want to thank Aiken for sponsoring this event. Further, I want to thank you everyone for, well, your efforts, your understanding. And the last question I have are two. Tomorrow, the hack demo, please register if you want to present your project in more detail to the to the wider IGF community. And finally, ask everyone to pack their stuff and run out of this room as soon as possible because this room is needed by by another meeting. Thank you. Thank you all for your understanding and see you next time. Lot of adrenaline.