Session Date/Time: 21 Jul 2026 14:30
[00:00:04] Jen Linkova: Yeah. Yeah. Please, 1. You should be doing this.
[00:00:08] Brian Trammell: 1234. Yeah. 234. If you're in the room, please log in to MeetEcho. There's the
[00:00:20] Jen Linkova: QR code.
[00:00:21] Brian Trammell: QR code at the mic stand. Just to make sure we get the accurate count of everyone who's here, these are the replacements for the blue sheets. And, also, there are probably people remote. You can see them in the chat when
[00:00:34] Jen Linkova: you do that. I should actually do the same thing, honestly. Let me go to the meeting. No. I need to come out from the agenda.
[00:01:29] Brian Trammell: So welcome, everyone. We're hold on.
[00:01:32] Jen Linkova: No. No. Yes. Okay. Good.
[00:01:37] Brian Trammell: So welcome, everyone, to PANRG at IETF 120 here in Vienna. Again, this is PANRG. BRG is next door. We have a fairly packed agenda today. We've got a talk from Shyam Krishna Khadka on AS security profiles for secure and resilient Internet paths and then four talks on SCION and SCION related research. And then in the balance of time, we are going to have a discussion about the future of PANRG following sort of the thread. I don't actually think it started a thread. I I tried to start a thread on the mailing list, but we've oh, you did you answer on the no. You answered on the IRSG one. Yes. There was a there was another. So, yeah, we'll be talking about, you know, what we've done over the past nine years and what we wanna do in the next nine plus. So oh, we don't have the note well slide. We should have the note well slide up. Note well, this is a you're at an IRTF meeting or where the IRTF has why don't yeah. Because I did the slides, and I should have done
[00:02:55] Jen Linkova: the slides. Yes. That's mine.
[00:02:57] Brian Trammell: The IRTF is not the IETF. However, they follow an IPR policy that is compatible with the IETF's IPR policy. If you have not seen the IRTF note well, please use the search engine of your choice, or as I used to say, Bing it on Google, and go check out the IRTF note well if you are not familiar with that, things that you say are contributions to the IRTF. Anyone would would anyone like to bash the agenda? Do we have anyone who would like to take notes? Excellent. Thank you, Rio. Perfect. Yeah. Can we get some help for you? Cool. Nico, thanks a lot. I mean, like, you're talking for part of it. Yeah. Yes. We got we got cover. It's good. Thank you very much. So, yeah, you know where to find the thing. It's all in in the the
[00:03:53] Jen Linkova: hedge talk. Good.
[00:03:58] Brian Trammell: With no further ado, if you are here, please log in to the MeetEco on-site tools so that we know that you're here and so that you can queue into the microphone. And with that, Shyam, could you am I pronouncing that correctly? Are you here? Oh, yeah. Oh, there you are. Good. Yeah. Can you come on up, and we will get started?
[00:04:25] Jen Linkova: Yeah. Just a second. Control.
[00:04:28] Brian Trammell: Yes. So that should work. Give it a try.
[00:04:31] Tony John: Yeah. It works.
[00:04:32] Brian Trammell: Yeah. And you will have to be very, very close to the microphone. The microphone
[00:04:36] Jen Linkova: is It's okay. Are low. Hello?
[00:04:40] Shyam Krishna Khadka: Yeah. Hello, everyone. I'm Shyam. I'm a PhD student at University of Toronto. Today, I'm going to talk about security profile of autonomous systems on the Internet. It's a research idea that our team came up with and, we believe that, this thing this concept will help in improving the security and resiliency of Internet paths. So first, let me start with the goal of the presentation. As I said earlier, this is an early stage proposal, so it's not a complete standard or mature work. So we want to have initial feedback on this concept and open the discussion about the concept. First, let me start with let me start with stating the problem. As we all know that Internet path, security depends on the security of individual ASes on those paths. As an example, I saw here, consider an enterprise which is hosting its data center in a cloud and in order to reach it to that data center, there are these three autonomous systems ASes. Consider a situation where one of those ASs, let's say AS B, which performs route origin validation, which is a mechanism to protect against prefix hijacks. However, in terms of its infrastructures such as routers, they are vulnerable. Their routers are not sufficiently hardened, and it doesn't have sufficient deducts DDoS protection. So in that case also, no matter how strong the routing security is or the security of other ASes, the path is still prone to prone to attacks or it might become unavailable. So the problem is that currently the endpoints and the network operators lack a way to characterize the security properties of ASs along those Internet paths. So there are some initiatives related to characterize the security of ASs. For example, MANRS, which is which is an initiative focusing mostly on routing specific security practices. But it but this but the MANRS doesn't have its own standard method measurement methodologies to detect whether the ASCs are actually following the guidelines mentioned by them. There is this concept of trust zones coined by Dave Clark and people. It's not directly related to the security properties of ASes. However, it's a driver to driver that helps that helps to to go for incremental deployment of routing security practices, which assumes that there might be a group of ASes that are trustee. So whenever a new security practices comes, then those ASes agree to agree to deploy those practices. And in this way, we can have a secure Internet in the future. Similarly, there are other initiatives like CableLabs, which also focuses on having a routing security profile and the CyberGreen org and measuring the services services ports that are exposed, for example, DNS and SMTP SNMP. So the gap is that all of these orgs are like fragmented, they are isolated. So there is a lack of unified security view of an ASES. So the key idea of ASes security profile is that use the existing Internet measurement methodology or maybe develop the new ones as per security requirements. So there are two types of Internet measurements work. For example, most of the works are related to routing security which takes that the routing information that is obtained from its peers are legitimate and authentic authenticated. So and the other aspect is related to the operational aspects of ASes because ASes itself needs to have routers, it's a firewall, or maybe DDoS protection devices on their premises to operate themselves. So for the purpose of defining the security of AS, we distinguish these two complementary aspects. Then the idea is to combine those two complementary aspects into a profile, which we define as an air security profile. Then we envision a few applications, how someone or how operators or how the community can use such profiles. The first one could be computing the security of parts. Consider a scenario, there are several parts and an operator can compute which part is more secure and which one is less secure. And the second one could be security over path selection. After after we have a methodology to compute the security of paths, then we might think about selecting the secure paths, which could be in BZP based Internet or SCION based Internet. And the third one is security over path selection. So consider a scenario where an AS wants to have a secure peer, secure in terms of, let's say, routing routing security or infrastructure security. So in that case, it will help to find more security conscious peer. So this service, this application could be offered via Internet access points so that members can can know about each other's security aspect. As an example here, I state the security profile of ASes. So in the left side, you see routing security which are related to the integrity of routing information. For example, that is AS B has route origin validation, has implemented ASPA, and it's all prefixes are registered in ROAs, but there might be situation where its infrastructures are not sufficiently protected. For example, it may not have DDoS scrubbing feature and maybe its routers are not hardened enough and maybe RTBH remotely triggered backhoeing is not enabled. So it's an example. So rather than providing a single score, because the scoring providing single a single score might not be a good approach. It depends on the applications or the or the users. For example, an or user or let's say an enterprise wants to have routing security feature focuses prioritizes routing security feature, but gives less priority to infrastructure security aspects. That's why we do not go for a single score. Then the natural question comes to our mind whether it is feasible. So the first requirement is that those attributes that I saw as examples should be measurable. And for that, there are already some existing works. Some of the works are done by me and my group, and there are many others. For example, there is a work about measuring the status of route origin validation. There are works related to finding unprotected or exposed BGP rotors in
[00:13:23] Ryo Yanagida: the
[00:13:23] Shyam Krishna Khadka: Internet. So this shows that many attributes are already measurable today. Then the another question is that having another question is about operational feasibility. Having having the status that the attributes are measurable is not enough. It should be deployable in the current Internet or maybe future architecture of the Internet. For that, we think about a few options. For example, there are already distributed repository, so such as IRRs, RPKIs, FearingDB, which which already contains other informations related to AS than security. So maybe we could use those infrastructures to to maintain to maintain the AS security profiles. And the another question is how can ASs actually deploy such profiles? So one example could be trust zone, as I mentioned earlier, which is a group of ASes that agree to have to have a certain security mechanism. So if you talk about SCION, I think it's equivalent to their isolation domains. So that might be a starting point to to use those profiles. And also, we had we had a work about path security scoring that we presented in ANRW 2024, where we derived a methodology to infer possible paths from an edge to a destination for a fix using the data collected by root collectors, and we showed how someone can compute the security of path. In that case, we consider only route origin validation as an as a as an attribute. So with all these works, I'm saying that deploying or using this as security profile could be feasible and it's doable. However, there are definitely challenges. Here, I would like to outline a few of them. First one is incentives. Yeah. Because the current Internet is mainly driven by money. People care less about the security, I guess. Then why would an AS care about its security profile? So one approach or one one option could be recognizing them as a trusted or security transparent network would be something to consider. And the second one is that how do we distribute and update those profiles. As I already stated, maybe reusing the existing infrastructures like, you know, IRRs or peering DV or manners could be an option. And the third one is about operationalization. So how to use it in VZP and in SCION Internet. For example, in case of VZP, maybe using add path features which which allows multiple paths to be forwarded to its peers rather than the single best path on the Internet. And another option is profiles could be embedded in path construction beacons in SCION networks. Now, I want to end my presentation leaving some discussion questions in this last slide. So one discussion question is that, would air security profiles be useful for path our networking? And what do you think which security attributes are the most valuable that the AIS operators consider? And the third one is how could such profiles be published and consumed operationally? Thank you very much for listening to my presentation. And I'm happy to discuss and maybe get some questions right now.
[00:17:55] Brian Trammell: Thanks a lot. We have an extra minute from what's showing there. So if anyone has questions, comments, etcetera, we can also take a discussion on this to the panergy at r r t f dot org mailing list. You just start a start a thread there Yeah. If there are people who would like to
[00:18:15] Ryo Yanagida: Yeah.
[00:18:15] Nicola Rustignoli: Sure.
[00:18:15] Brian Trammell: Do that as well. We'll Yeah. Leave that open for. I don't have the thing up now. Good. Alright. Thank you very much. And with that, I believe we can go into the SCION portion. So, Nico, we switched this around. So he'll be first.
[00:18:37] Jen Linkova: There's the clicker. Alright.
[00:18:47] Brian Trammell: Thank you.
[00:18:50] Nicola Rustignoli: Yeah. It's just I think it's easier.
[00:18:52] Brian Trammell: Yes. How everyone's doing it.
[00:18:54] Nicola Rustignoli: Alright. Thanks a lot. So my name is Nicola Rustinoli from SCION Association. We are, the organization that is, taking care of the SCION open source reference implementation, and we have also been working on the core SCION spec. So if you were around this working group, this research group some some time ago, you remember that we have been discussing this topic. If you're not familiar with SCION, very briefly, this is a path that we're inter domain architecture that focuses on security and high availability. So the key feature is that endpoints are able to select the path or by hope eventually based on their specific needs. SCION has been deployed for a few years in in especially critical infrastructure ecosystems. We have the Swiss interbanking network, but also other specialized networks, for example, in credit card payments. And at the same time, we also have a global public SCION network. Actually, this was even worked on during this hackathon, and you can also connect to it from the ITF meeting network. So SCION has commercial open source implementations, and two two years ago, we were discussing here, okay, where do we take this work? And one aspect is that what we have, especially in the productive networks of SCION, is already deployed, already developed. It was developed outside of the IETF process, results of many years of research at ETH Zurich. And so first of all, we wanted to document what we have in in this network. And so after some discussions, this turned out to be not researchy enough to be in research group, but also not having to provide the ecosystem to to really be in an ITF working group. So the course back ended up at the ICE, the independent submission. And so here, we tried to capture really only the core path that were part of SCION and maybe a little bit of lessons learned through deployments, especially when it comes to PKI. So the documents went through the iStream. They have been now finalized. And as as this happened, of course, they gathered some feedback that I wanted to to share. So the documents are three, and they are about the three core components. We have control plane. So this is what does all the path discovery that is based on this process called beaconing. So these beacons get, let's say, floated across the network, and then they accumulate these past segments. Then the endpoints are able to do a lookup and fetch those segments to build an actual path. When data is going over SCION, the the path is actually part of the header that you see in this figure. So in this example topology, we have a few ASs. Each one of each node here is a SCION AS, and then this this SCION header contains the full path. And so this is what we describe in data plane. And then the third draft is PKI. Why PKI and why SCION has its own PKI? That is because of the trust model that is based on these isolation domains, each one of them with an independent route of trust. And so that is what we tried to capture in this draft together with some operational considerations from the ceremony that is used to manage trust in SCION in some of the networks. So as the draft went through through the process, of course, we received a lot of really useful feedback that helped to make the specification readable, easy to understand, and and also correct and reflecting what we have implemented. So I've been trying to give an update from time to time, but then the research group did a meet recently. So a few things happened on the draft, and some key topics that we had to deal with were one of it is SEMP, which is signaling mechanism that is used, for example, for LinkedIn messages. Then we have been thoroughly reviewing all the gRPC or all the eRPC calls in control plane because SCION components talk to each other in the control plane over RPC. And implementations also moved from gRPC to ConnectRPC, which is something that we also reflected in in the draft. A question that we got a lot was, okay, where is SCION at which layer? And that was always causing some confusion, so we had a dedication added a dedicated section about the UDP underlay and a reference that brings to further documentation. The topic of time synchronisation also popped up quite a lot. This is very relevant because we have certificates and segments and they have expiration, and so we clarify in the draft what are the dependencies, how much tolerance you can have and and so on. On the PKI side, the main improvement to the draft was adding full ASN one modules for all the additional truss material that is defined by Cyan, which is all x five zero nine based. And so that is really the main change. Then also clarifications on time validity periods of certificates based on what we have in in some of the production production networks and, of course, a lot more clarifications. While doing this effort, we were trying to document what is deployed. So that means that there is feedback that we gathered that somehow didn't fit the scope of the draft, but that could be considered for future protocol evolution or for future future research. So covering the various components, key feedback on PKI was, of course, that in science, x five zero nine certificates have dedicated attributes, and this is manageable. But, of course, it requires some, let's say, adopters if you're using existing libraries. So this topic of compatibility popped up. The topic of synchronization between multiple certification authorities that are part of the PKI and also the topic of post quantum. So the mandatory to implement SET is based on elliptic curves in in the draft, but we have wording that enables to add more algorithms in the future, and this is a topic of ongoing research today. On data plane, key question is why do you have your own data plane, which I believe we even discussed here. And while there is research on using different data planes, maybe using other protocols like I p v six extension headers, this is not what is deployed. So this is also a topic that can deserve further investigation. On the control plane side, the topic of PCB policies when it comes to how these beacons are propagated, the topic of path metadata, so adding more information to these beacons. The core spec makes these PCBs extensible, but then these extensions are not defined in there. So that is something that can be further work. Closing on more general topics, interoperability. First, I would say there are gateways that are used in many networks, but there are also other research mechanisms. I believe there is one later in the agenda. Then the topic of endpoints, there is a lot of activities going on on bringing SCION closer to endpoints, and this also reflects very much the charter and even the proposed future charter from what I hear in in partner g. So this is a topic that is still where a lot of research is still going on. So wrapping up what comes next, of course, this draft document what we have today, and I believe that this Cyan early adopter experience documents that password networking is viable technically, but also from a commercial point of view. There is an ecosystem based on both open source and commercial implementation around cyan, and we see growing interest especially in specialized sectors. So this specification is offered to the ITF community as as an an example for future consideration, future evolution. And, of course, that means that more work can be done on topics, for example, on endpoints, on interoperability, on interfaces to transport. Some of these topics are active research, and we have even a few drafts. And then, of course, there is a topic of evolving this core protocol, which is something that we would be, of course, open to reconsider if there is additional vendor interest to eventually really take this to to an ITF track in the long term. Said that, I think that's it. So if there's any questions on on on these documents or we will go to the
[00:28:25] Brian Trammell: research topics. Any questions? So I'll have one comment from the chair. I I remember we had a bunch of meetings in PANRG, what, like, three years ago
[00:28:38] Nicola Rustignoli: Correct.
[00:28:39] Brian Trammell: About the the right way to bring something like SCION to the ITF community. And what we have with these three drafts is sort of like, here's the maximum separability of, like, the various components where you could consider, okay. Well, this would be a standardizable unit. This would be a standardizable unit. I think the yeah. I think you'd want to see a broader a coalition of people to, like, bring up a boff to bring any of that to the ITF. But as the PANRG chair, I'm super excited to see that we're now at the point where this is, like, a basis for a lot of other research group research work we can do in this thing, and that's, like, what the rest of the the agenda is here today. But I'm done talking. Who's first? Yeah. Ryo.
[00:29:28] Ryo Yanagida: Hello. Ryo Yanagida from University of Saint Andrews. Thank you for bringing interesting work again. It's nice to see this developing and flourishing. You hinted on maybe extending SCION to end host. And I look up lots of I tend to look on connectivity at end host side as my partner research. So I'm kind of curious as to sort of what you might have any intuition at the moment, what might bring to the end host by any chance? Like, just briefly, if you can touch on it, that
[00:30:01] Brian Trammell: would be nice.
[00:30:02] Nicola Rustignoli: Yes. This is a topic of active research, mostly with the folks from ETH Zurich and Magdeburg. I think there would be some some talks later. There are several topics around it. One one of it is, for example, a multipath transfer protocol. So for example, multipath quick is now being finalized, and that is a starting point to to the multipath, but it also doesn't really give you all the all the all the pieces that you need to do really multipath, for example, in terms of multipath congestion control and so on. So I think there would be more probably more work even within QUIC, but I think it could also fit there. So there is, I think, one or two drafts from Till over there, so maybe you can connect later. A topic is also naming for science, so there is work on figuring out what is the best way to to have the science address somewhere in in in the naming system. I think these are the the the key key topics. Thank you. Yeah.
[00:31:06] Colin Perkins: Colin? Hi. Colin Perkins. So I I'd like to mostly echo Brian's comments. I know this has been discussed in this group and in the independent stream for quite a while now. I know it's been quite a long process, but the result looks like some nice drafts from what I've seen. And I think it's been a great success. I I'm glad you brought the work and I I hope you continue to develop it and take it to the IETF for standardization.
[00:31:42] Nicola Rustignoli: I fully agree. Not sure what else to what else to say. But, yeah, of course, once once there is enough of a critical mass, this this can definitely be considered again.
[00:31:59] Brian Trammell: Any other questions or comments on this? Or then we guess we can go straight to the next presentation and into the now we've got SCION. Let's do stuff with it.
[00:32:14] Jen Linkova: Okay. Quick. Just a
[00:32:16] Brian Trammell: quick multigath.
[00:32:16] Dirk Kutscher: Right? Hold on.
[00:32:18] Jen Linkova: Yep. K.
[00:32:23] Timon Spycher: Yeah. Good afternoon. My name is Timon Spycher. I'm from ETH Zurich. And this talk is about a draft document that that provides guidelines for running multipath QUIC over Cyan. So what this is about, it's about, basically, we're looking at multipath QUIC end host libraries. QUIC runs over UDP. UDP runs over Cyan. We are specifically looking at a quick multipath because Sine is also inherently a multipath library. And, yeah, the first version of this draft was published last year or was presented at the IITF in Madrid. And the conclusion was basically that it works, basically fine, almost out of the box. But there are some things to look out for. So there was a security kind of challenge problem that we identified, But also to really make use of sign, you will actually have to modify your library. So in this talk, actually, there is a small update. So we identified that the security challenge we found is actually a non issue, but we found a more elaborate scheme that is still a security issue. And so I'm gonna present that. And so I couldn't really present the security issue in the last meeting. And then also, we're gonna have a small a small outlook into where the document could head in the future. So a small recap. So these are the signed data plane headers. There's first the common header attached to every signed data plane packet. It contains various information like version and packet lengths. Then you have the sign address header. It contains the ISD number, AS number, and the IP address of the destination and of the source of every package. Then we have the path header after that, which contains different path segments. So usually, have an up and a core and a down segment. The up segment goes from the local AS to a core AS. The core segment then across several core AS is to the destination core AS, and then down segment finally down to the destination leaf AS. We also have a current hop field counter in there, which basically is incremented by the border routers in every AS. So it always points to the current hop field of the current AS. Then we have the path segments, and each of them comes with a list of hop fields, hop fields representing the ISs, basically. And every hop field then has the ingress and egress border router interfaces for the route. And top fields also have a MAC. They are protected by a MAC, and the MACs are actually chained together over the different top fields so to prevent path forgery. Okay. So what does the actual attack look like or the challenge? So in SCION, network addresses are globally unique, as you would expect, but the IP part is not globally unique. So you see here two different network addresses. And they start with the ISD number, the AS number, and then IP address, and finally, a port. And these two numbers have the same so these two signed network addresses do have the same IP address and the same port, but they are in distinct ASes. So it's really directed at two different machines. And this is a problem in quick multipath or in quick pass generally because path validation kind of relies on an IP address changes, detecting IP address changes. I mean, it depends on how it's implemented because some libraries just use byte strings to cover the whole address, and they then it should possibly work fine. But it's a potential issue because if IPs are unique, then that's a way to actually avoid or circumvent path validation and perform an attack. So the attack is actually not that simple. So here is an example. At the bottom, you see, like, a diagram with the three blue circles. So that's the three ASs. On the left side, we have AS number three with a server. Then in the middle, we have AS number five with one of the attackers. So we need two attackers. And on the right side, AS seven with the second attacker and the victim. And, like, a precondition for this to work is that one of the attackers is collocated with the victim. Another attacker is en route to the server. And, also, the attacker that's en route to the server needs to be able to set up a machine with arbitrary IP addresses, pretty much so. And how the attack works. So on the top right, you see the messages. The attacker number one in the AS five sends, like, a handshake request to the server. And then the messages, you can see there's like a sequence of numbers after the messages. That's basically a simplified version of the path. So we have, for the first message, 53 just indicating as five a s three. So attacker number one initiates a handshake. The server reverts the path and responds to attacker number one. And then the attacker number one can send a certificate, the secret basically to attacker number two. And attacker number two then can request data. And the trick here is that attacker number two puts a source address, the IP address of the victim. So this source address then later becomes the destination address when the server answers to that. So the request is sent to the server. The server reverts the path and starts sending data to the victim. Alright. So how can we prevent that? I mean, we already had the last document mitigation. And, basically, mitigation is that the quick library needs to be adapted or if it unless it doesn't already, it needs to check that the ISD or IS number doesn't change alongside with the IP address. That's basically all that needs to be done. And that also prevented the previous attack that we had in mind, which didn't work for other reasons. Alternative is that the library remembers the first path that was used for the initial handshake. And then if any packets come later that use a different path or address, it would just drop these packets. But then again, the library just would need to be sign aware. But, yeah, we prefer the first version because, yeah, that seems like a natural place to actually do the check during the path path validation triggering. Okay. So in summary, we have a new attack. We have a mitigation, which, yeah, just means check for your ISD AS numbers when you check your address. But anyway, you would anyway probably want to modify your sign library a bit because it allows you to then get benefits from sign like the pass selection or the stable pass, which is beneficial for RTT estimates or congestion control. Okay. So outlook. The question is where what we do next with the document. And we had, like, two ideas. One is so with sign, you may get a lot of paths. So actually, in the current production network, there's one pair of ASs that we have where we get, like, 4,000 paths between the two of them, and that's a bit too much for clients. And one thing we definitely want to do on the XC is also planned that the control server, the pass servers will hand out fewer paths to the end hosts. But still, it wouldn't hurt to actually give recommendation for end hosts how to efficiently select a good path. And maybe there's other things we could do. And that would actually also squarely, I think, fall into the question here that we're going to discuss later, what should endpoints and networks tell each other, and how should they each act on it? So that would be a good fit, I think. The other thing we could do is look into spoofing protection. And here, the idea is that we establish two rules that should be implemented. And this should be implemented by all receivers of Cyan packets or all, let's say, all entities that receive and pass Cyan headers. So that could be border routers. That could be Cyan end host libraries. And the first rule is if a path if you receive a packet and the path indicates that the package originates outside of the local AS, so if it has a long path, then it should compare the underlay address underlay IP address whether it's a non border router. Because the only way a packet should enter in AS is through border router. And then if there is a transmission match, it should just drop the packet. And kind of complementary to that, if the path indicates that the package originates inside the AS, then the underlay IP address should be the same as the sign source address and the sign header. And, again, if that's not the case, the packet should be dropped. So the motivation is basically for border routers, we could prevent border routers from exporting known faulty packets to other ASs, which is just a nice thing to do, I think. And also on the nthost library side, the nthost libraries would be stopped from forwarding packets that are known to be faulty to the upper application layer or quick layer. And also, this rule is actually the first rule is already in the spec, but it's only mentioned in the with border routers on the end host libraries. The thing, though, is it kind of mixes underlay and cyan. But, yeah, I mean, we already have the rule. And, also, it's kind of additional compute effort, implementation effort. There's not really a known attack where this is really a good protection, not least because you may have IP spoofing, and then you can just use whatever underlay address you want that could you could fake to be a border router or something else. So the question I want to ask actually is, should we follow this up, or are there any ideas, opinions? But before I do that, so we have some good news because we actually this IGTF, we managed to have a Cyan almost native connection here. So if you're interested and want to try out Cyan, you can scan the acquire code, and there's a lot of examples. And one of the examples just sends a packet to something like a Wireshark website where you can look at your signed packet header and some payload that you send along. Anyway, yeah, that's the question. So if you have any feedback in general or on these additional rules or the future direction of the document, then
[00:44:02] Brian Trammell: please let us know. Thanks. While everyone else is running up to the microphones, I threw myself in queue as individual, not as energy chair. This presentation made me realize when I've thought about sort of multi path SCION in the past. Right? There are multi path transports over SCION in the past. I've been thinking of both of the endpoints having, like, being, like, endpoint native SCION. There's probably places where you're gonna end up with endpoint native SCION on the server, but not necessarily endpoint native sign on to the clients, right, where you're gonna have, like, the you'll have some sort of gateway where the client's gonna have a gateway, and that gateway is then gonna do the multipath thing. How does that change the the the spoofing, the anti spoofing stuff? Like, I haven't. It's possibly a stupid question. I haven't thought all the way through it. But I I realized that, like, there's a there's probably a large deployment area that I hadn't even considered when thinking about science.
[00:45:02] Timon Spycher: I admit I haven't really thought about that situation. Yeah. But I guess my guess would be that the server somewhere you need to translate from non SCION to SCION. And I would if this is kind of a net or something, we'll sign it in
[00:45:15] Brian Trammell: Oh, and that's gonna have all of the addresses on it. Okay.
[00:45:17] Timon Spycher: And then you could tie it to the port, and then port would change. Right.
[00:45:21] Brian Trammell: Right. Okay. Okay. That makes sense. That makes sense. Good. Good. Maybe go think about that a little bit more and make sure it makes sense.
[00:45:27] Timon Spycher: But, yeah, I mean, it's a good question.
[00:45:32] Brian Trammell: Go on.
[00:45:33] Colin Perkins: Hi. Colin Perkins. Also, probably a stupid question. But on your earlier slides when you were talking about how you have to compare the full the ISD and the AS and the IP address to avoid the issue with non unique IP addresses. Are you making the assumption that IP addresses are unique within an AS?
[00:45:58] Timon Spycher: I'm making that assumption. So of course, you could assume that IP addresses are faked or are spoofed, but then it kind of gets difficult to to do the handshake, for example. So because you also need to be able to receive on that IP address. But if you're powerful enough to be to send and receive on a victim's IT address IP address, if you're a man in the middle to the victim in the AES, then this doesn't help. But then this is also, I think, in QUIC, there's no protection against that, really. So we are not worse than quick, is is my thinking here.
[00:46:35] Colin Perkins: Yeah. Sure. So so I I I'm struggling to hear you because the acoustics in the room. You you say the you are assuming IP addresses are unique within an AS. Yes. Okay. Yes. I I don't think that's true.
[00:46:50] Timon Spycher: Okay.
[00:46:51] Colin Perkins: Because of multiple layers of nets.
[00:46:54] Brian Trammell: Yeah. I
[00:46:58] Colin Perkins: I I think it's quite common that you have multiple machines within a single AS that have the same IP address.
[00:47:04] Timon Spycher: So yeah. I mean, of course, if you think of netting, you would also be considered the port.
[00:47:11] Colin Perkins: Yeah. Yeah.
[00:47:12] Timon Spycher: Other than that, I mean, it's it's again I I don't know how quick deals with this. Basically, in the same way, there's no
[00:47:19] Colin Perkins: I I also don't know how quick deals with it, but it's something we ran into when we were doing the natural vessel stuff. And that you do occasionally find machines that believe they have the same IP address talking to each other.
[00:47:28] Timon Spycher: Okay. Okay.
[00:47:33] Brian Trammell: I mean, that's a terrifying mess, but yes. Other questions? Alright. Thank you very much. I'm gonna do the inadvisable thing while sharing a meeting and go try and get connected to the Zion network during the next presentation. So we have Lars Christian Schultz from Magdeburg talking about TCP I p v 60 and PTCB SCION bridging.
[00:48:13] Lars Christian Schulz: Yeah. Hello? Yes. So my name is Lars from Otto Von Gerrick University in Magdeburg, this is a very quick showcase of some of the work I did to bring Cyan closer to end hosts by translating I p v six and Cyan packets directly. Oh, I found the right button. So, yeah, So this is about IP translation. Idea here is that we translate directly between I p v six and Cyan packets. So my motivation to work on this was that when I first heard about sign, I was a bit confused that I couldn't use, like, standard utilities like Ping and Netcarta and so on on sign. So I started porting applications to sign, but this took a really long time. And then I tried to port something using TCP, but Sign didn't support TCP at the time. So I got this idea to build a stateless translator that trans that translates I p six directly to sign and vice versa to reuse the network stack that we already have in the operating system. So the basic approach is that I encode the ISD, ASN number that sign has and the host address part in one single I p v six address, Then you have to translate it. It does the path selection on behalf of the application with the help of some path policies. There's an implementation of that. There's actually multiple ones but one that I want to highlight here called SiTRA, the SINE IP translator. So SiTRA makes an IPv6 host or application behave in the network as if it would support SINE natively already. There's two different ways how this can be deployed. One is directly on on the host. That's what I'm going to talk about here. And the other is as a gateway in an IPv6 network. However, SiTRA, unlike a sign IP gateway that you might have heard about, doesn't use any encapsulation. It just translates the addresses and packets. So with SiTRA, there can be an asymmetric situation where, like, the server is SiTRA native and the client uses a translator to reach the server. So at the heart of, this translation, what I call sign mapped IP addresses. So I'm taking the sign address space and map it to some I p v six addresses. This can't be a one to one mapping because signed addresses can be pretty long. So instead, I focus on just a part of the signed address space, the one that is actually reserved currently for allocating global addresses. So this is more of a solution for migrating towards sign. So the the encoding is as follows. There's an eight bit prefix. In my example, it's FC00Slash8, but it could be any unique prefix that you use to identify these these addresses. There are 12 bits for the ISD number and 20 bits for the actual AS number, and the rest of the address is used for for the original host part. The sign map addresses are usually not actually used in a network, so they are only used between the application socket and the the translator that runs on the same host or very close to it. I'm I'm going over this quickly. So if you want to read more in detail about it, there there are papers referenced on the slides. So with SiTRA, we can translate UDP, TCP, and ICMP to SINE. So you can just ping a SINE host using the normal ping tool and will be translated into SINE's equivalent of of ICMP, and you get to use TCP and SINE as well. SiTRA has also a built in way to deal with name resolution. So there's a stop resolver that transforms text records that are used today in Cyan to a records that, yeah, point to design that I p v six addresses that then would get translated and connect you to the right destination. You can also try using the test router that Till has set up. So there's a script online that can install pre built binaries on an Ubuntu 24 machine for you. You just have to enter this Bootstrap server URL manually. And if you want to try this anytime later, we have a Boilerbuter in Markdeburg that is publicly available, and the script can connect you to it. So you can try this at home. Right. So now what I'm currently working on, and this is unpublished work, so this is still going on, is translating multipath TCP to sign. So multipath TCP is just an extension to TCP. So, basically, it just should just work. However, we need some way to tell the kernel the internal path manager for MPTCP about signed paths. So the the current approach is to create surrogate IPs that the translator will assign to the virtual interface it creates. So the internal path manager has something to create sub flows on as as different source addresses. After translation, these sub flows will all use the same endpoints, so the same SAN addresses and ports, and they're distinguished by the translator according to SAN paths. So in consequence, when you establish with the translator an MPTCP subflow, it's pinned to a certain SCION path. The translator changes its path. It first establishes a new subflow and a new path and then breaks down the previous one. We set this up, on the, hackathon, this, this weekend. So we had a local, testbed, and we, ran iPerf and a TCP video stream using an IceCast server, And we forced these applications with MPT MPTCPize to to create MPTCP sockets and ran them through through translation to try out different path policies like prefer the lowest RTT but keep some backup paths or just aggregate as much bandwidth as you can and so on. So my current research is really how should these path policies for MPTCP in Zion look like. And yeah, that that's the open question. So what I want to bring into the mix here is another project that I've been working on, which is invent telemetry for an inter domain use case specifically for So a way for end hosts to query information directly from Sign border routers by embedding requests into the sign packets they send anyway. These requests use message authentication codes like we use in in the hop fields we have already have in sign, and they are implemented as extension. It's as as extension headers as hop by hop extensions to SCION. And they are designed to work on the router's fast path. So this might this goes in the direction of just asking, yeah, what what should the network tell the end, also, and how should it use this information? I I don't have an answer prepared right now, but I I I really look forward to getting some input to that question. Yeah. And that brings me to the end already, so thanks.
[00:56:00] Brian Trammell: Cool. Thank you very much. Questions? So how much of this worked before you showed up at the hackathon, and how much of it works after you showed up at the hackathon?
[00:56:12] Lars Christian Schulz: Okay. So the the the basic the the TCP stuff works works, like, for a while. The MPTCP stuff works worked before Mhmm. And it almost didn't work when I showed up here for the hackathon. So a lot of time was spent just fixing Yep. Fixing things in a local test bed. And then just yesterday, I got it to work with the boarder out to the tier setup here in the hotel network. Cool.
[00:56:38] Brian Trammell: This is really cool stuff. Like, I really like seeing just sort of like the the the translation networks. I think next time, I will try to hang out at the SCION hackathon table more because it seems like y'all are having a whole bunch of fun.
[00:56:51] Timon Spycher: Cool. Questions?
[00:56:56] Brian Trammell: No questions? With that, we will go on to the final presentation.
[00:57:05] Jen Linkova: Thanks a lot. Very cool stuff. Tony.
[00:57:21] Tony John: Hello, everyone. I am Tony John from the University of Macteberburg. Oh, yeah. This is yet another application of SCION. So we did SCION transport in Tailscale. I'll talk about what Tailscale already had, what was missing, and what we learned, and what what the open questions are. A brief background on Tailscale. It is a WireGuard mesh plus a coordination server. The coordination server distributes key keys and meet peer metered data to all the peers. The control plane of, Tailscale is called MagicSock. It's a UDP multiplexer that multiplexes the direct UDP addresses or connections and also the traffic through the relay. MagicSOC does this over one socket. And MagicSOC keeps a set of endpoint addresses per per peer, and there is a algorithm called DISCO that does encrypted pings and pongs to measure the RTDs of over all these endpoint addresses. Then a function called better address selects the best candidate from this set based on RTDs. So if you see, it's already a per peer path selection loop that's running. What's missing from this is is multiple paths from a real path of our network. That's what we did here. We added cyan parts as additional candidates, and we added the cyan end host stack in process without changing how how the selection works. To make this work, we we have to make other peers aware of the sign address. So and we wanted to do this without changing the control server. We looked at adding a new configuration type called sign, but coordination server doesn't notice, so it's dropped. But there is already a field called peer API four, and it has a description field that accepts text text, and this is distributed verbatim. So we piggybacked on this, and we, used this to relay the sign in address to other peers. The whole process works like this. So we use the peer API four to advertise the sign address. The coordination server relates it to the other peers. The peers parse the sign address and kicks off a path selection, path lookup in the background, and we register each path as an endpoint address. This works over, normal tail scale and head scale without any changes. Just we you have to use our client. So, honestly, that was the easy part. The not so easy part was, with Cyan, you get many, many parts. As we saw with, Till's presentation, on average, there was around, 500 parts. So we can't measure all the parts. We can't probe it it without hammering the network. So what we did there was we filtered the parts, based on number of hops, and we chose just five parts that were most distinct. The second problem was chasing the fastest part means that that that that had a lot of path flapping. So we only took the median RTT from an eight slaughtering, and we also only changed a part when there was a 20% improvement or a or a two millisecond improvement. The third problem we faced was we have a lot of parts, but we only look at RTD. So we might be losing out on a more reliable part or a part that has more bandwidth. You can try it out today. We we have Linux binaries and an Android APK. If you have signed connectivity, you can configure it via using topology dot JSON file and the TRCs or just use the signed bootstrap URL. If you like, you could try it out with with the signed connectivity that we have today here. And SAN fail fails back falls back to UDP or or the relay traffic transparently. So you can use the SAN path, but if SAN fails, you can still pick still rely on the relay. Right. The three findings that we found was that there are in path selection loops already in many protocols like ICE multipath TCP and quick multipath, but these are all designed to just deal with a couple of path paths. But a path aware network like Cyan gives you hundreds of paths. So we have to somehow select a a set of paths from these hundreds, and that's not trivial. In the case of tail scale, signaling part was easy, by piggybacking on the peer API for description, and we do almost the same with DNS using the TXT record. The open problems here are almost all in part selection, probing, and measurements. So I want to raise these three open questions. Which part properties justify their measurement cost at at for part selection at the endpoint. And for doing probing under a budget, in case of tail scale, which is a full mesh network, the cost grows with number of peers and number of parts. The work from Lars, the inter domain in in band telemetry could help reduce the cost, but I want to raise the question of what other ongoing or prior work there is in in in this regard. And the third open question is, currently, the path selection is a preference set at the user. Should the provider have a say in it, and at what granularity should it be? And that brings me to the end of my talk. Thank you.
[01:04:40] Brian Trammell: Thank you very much. I will also ask for questions, but I also went ahead and put myself in the in the queue here because I I realized we we seem to have, in a couple of other in a couple of contexts, created a new problem for ourselves. It's like, yay. Now we have a bunch of paths. What are we gonna do with them? Right? Is it it feels like the for the multipath, you know, multipath TCP, which is really about, hey. I have two interfaces, and I don't have any say about what those interfaces are gonna do with the connectivity. Right? I'm just gonna sort of, like, try and get around problems on network by using another network. Wasn't really designed to scale for, oh, I can do the combinatorial selection of paths across things. It seems like there's sort of like a path. Your last question is sort of like, what would a path policy language look like, Right? For and I think that would be you know, this is enormous amount of research. But, hey, I'm not a researcher anymore, so y'all can do it. Yay. Which also would give you, like, the way to experiment with which path property is the most or or or the most useful. Right? Say, okay. We're gonna do this with this with we're gonna use this sort of, like, reduction function to say, here's all of the panels we have. You have a reduction function right now that I'm assuming you just chose because you needed one in order to be able to make it run. Right. Right? That's a perfectly reasonable one, but there are it'd be really interesting to sort of, like, experiment with that space. Right? And and then that would also sort of answer the question asked in the the path properties document. It's like we just sort of, like, said, here's a bunch of path properties. Go do do something with them. That's an open research question that you that you put up at the top there. It would be interesting to have a way to sort of, like, more systematically dig into it.
[01:06:26] Tony John: So I hope to do that.
[01:06:28] Jen Linkova: Yeah. That's very cool stuff. Very cool stuff.
[01:06:31] Brian Trammell: Other questions, comments, etcetera? Anybody get Zion working while we were listening to the thing? I went down a rabbit hole of trying to get Tailskill working on my computer. So alright. With that, thank you very much.
[01:06:49] Jen Linkova: Let me go ahead and bring the
[01:06:51] Brian Trammell: chair slides back up. So we are doing excellent on time. So with balance of time, I wanna put the last one of our chair slides up.
[01:07:05] Jen Linkova: Hold on. You have clicked.
[01:07:06] Brian Trammell: Oh, I have a clicker. Okay.
[01:07:08] Jen Linkova: Have clicked. Any second.
[01:07:11] Brian Trammell: Before, quit. Wait. Wait. Wait. Now? Now? Now? Why? Can I just give myself slide control on my own machine?
[01:07:21] Jen Linkova: Okay. I can take okay. Let me take it through. Okay. And then I can Now take the control.
[01:07:39] Brian Trammell: Which one of these is slides control? I I should know this.
[01:07:42] Jen Linkova: Hold on. Is it okay. Hold on. Yeah. You're okay. Yeah.
[01:07:47] Brian Trammell: Oh, okay. Cool. Yes. Good. K. That was super easy. So who here has read the message I sent off to the PANRG? I mean, okay. IRST folks can put it down. Y'all get a preview. So, yeah, so a few people have read the message I sent off to the PANRG list a little bit earlier. I'm making a suggestion here not because I believe in the suggestion as much as I want to start a conversation, and the easiest way to do that is to be wrong in public. So, like, I I went back over the talks we've had sort of in, you know, like, about three years ago, we're spending a whole lot of time on SCION and getting everything lined up. And then, you know, the SCION process went off into the ISE thing, and we had sort of other people coming and talking to us. I've had also from the researchers who have asked to present at PANRG. We already have one on the agenda for San Francisco, for example. Right? Like, looking at the topics that people are interested in this space. And there's obviously sort of like there's the base Atherware question from nine years ago, which I think SCION now is is evolving into an even better platform for doing experimentation in that space. Like, this the last couple of of of presentations were, like, super exciting to me. It's, like, seeing what's being built on top of this and the questions you can you can you can answer with it. But there's also sort of, like, broader questions that are adjacent to to to path awareness. Right? Like so I think one of the ideas, at least that I had nine years ago when when we went and started this as a proposed research group, was I was actually working on Cyan at the time. I'm like, oh, there's some really interesting interesting ideas here, but Cyan is one point in the space of places where you can have endpoints and midpoints communicating with each other. Let's be a little bit more rigorous about what that space is, and and that's where the RC ninety two seventeen, the open questions document came from. In the meantime, it looks like there's a lot of interesting work happening on SCION, but not a lot of other path aware architectures. That's probably a good thing. Right? Like, we get mind share on one one thing that we can build a lot of research on top of. But the topics that I'm seeing people propose are slightly broader. And the the best framing I could come up with for that was what should endpoints and networks tell each other and how should you act on it. Right? That might be a little too big. But I wanted to bring that to the to the research group and open the mic lines to see if anyone has any thoughts on that. So I think I'm in the queue. Right? You're in the queue. You are the first I'm Dave O'Ran.
[01:10:46] Dave Oran: So go ahead. So there's a this is a two edged sword in the sense that you want a research group to have a semi open ended broad framing so that you're not artificially limiting things come to come in. And then the the flip side of that is all sorts of artificially crazy things come in, and you spend a lot of time damping them out. So my intuitive sense is this is in fact just a little bit too broad, and maybe we should have come up with a list of things that fall under that general statement that are slightly more specific. Mhmm. So I made three proposals which didn't make it onto the Pan RG list, but I'll mention them quickly at the mic. The first one is when I talk to people about SCION who are from the sort of the conventional ITF multi inter domain routing community, I consistently hear a pushback, which we need to understand better, which is what are the trade offs and the ability of operators to do traffic engineering versus the things that are done in path oriented networks to move power and control potentially away from an individual operator's decisions about how packets are are forwarded through the network. Those you know, we don't wanna try and push a a path oriented protocol that is going to wind up not being adopted by large numbers of network operators because either a correct or incorrect belief of its effect on their traffic engineering policies. So that's one, and I think there's interesting research to be done in in that area as well as some more political positioning. The second one is we've already see how many paths are being available in a system like SCION. And my suspicion is that the actual practical difference among all those paths could be in equivalent a very number small number of equivalence classes. And figuring out how at the edge, you don't have to explore a whole bunch of equivalent paths to find out that they're all the same, more or less. And in the middle of a network where it's very dense, you're going to have to prune those paths because of the overhead of distributing them starts becoming a path explosion problem. So being able to to to algorithms that enable you to to prevent path explosion in dense networks, I think, is a interesting research area. And I had a third one, and I don't actually remember what it was from my email. So maybe somebody could read You can can
[01:13:44] Brian Trammell: sit down and send the message to the PANRG list and then read it while you're sending it and then come back up. Wait. Hold on just a second. We've got Marcus and then Dylan, but Dirk
[01:14:01] Lars Christian Schulz: has the
[01:14:01] Brian Trammell: Dirk Dirk has the email. Thank you, Dirk.
[01:14:03] Dave Oran: Right. Right. Right. The the second one was it was really a lot like this one only was for not not from the observational side, but from the control side, which is what's the power balance between
[01:14:15] Shyam Krishna Khadka: Yep.
[01:14:15] Dave Oran: What users wanna want the network to do for them and what the and what the network wants to constrain users to from from making potentially from the outside coordinated decisions that wind up either DOSing or otherwise manipulating the commercial viability of how the network's constructed. That was the third one. Thank you. And I'll I'll forward that to the panel.
[01:14:40] Brian Trammell: Please do. I had one observation I wanted to riff off there before. I'll take George's prerogative and and cut off Marcus. Sorry. The end of Tony's presentation had a point about, Okay, well, here's path selection predicate that I used to take the intractable problem and make it tractable with the tail scale. And some some of that is like the way that Tailscale does a full mesh makes that a little bit harder. You need to prune it down more than you would in maybe other places. That's a mechanism that is tied to a policy language. And I think that answers digging into that might answer the first two of Dave's questions. The first one about or the second one about how do you do the scalability? And the first one about how would you give yourself control back to be able to hand it to operators in certain circumstances? That's a very inchoate thought. I will leave it there. If that becomes a less inchoate thought, I will elaborate it on the list. But it seems like there might be something there sort of in the in the the explicit exposure of policy space. Cool. Thank you, Marcus. Go ahead.
[01:15:53] Marcus Ihlar: Alright. I'm Marcus Hilar from Ericsson. I see this text up there, and that immediately triggers me because I'm a SCONE enthusiast. And we in that's an ITF working group, and we're working on very much things around networks and applications or endpoints telling each other things. So and and this is something that is likely going to be deployed very soon. It's it's SCORN is becoming an RFC. And that is engineering. It's not research. But I think the use of these protocols is something that probably is going to trigger a lot of research. I think we will learn a lot of things and I would be very happy to have a venue for providing observations of what actually happens when we have the networks and endpoints communicating in new ways. And we not stopping at SCONE. We are considering other use cases. SCONE has a very specific use case about networks basically reporting rate limits to endpoints so that they can act upon that in various ways. We are now looking at other proposals that we might take to other working groups or research we don't know yet, where, for instance, you could use similar mechanisms to enable passive measurements of packet loss and where also networks might be able to report its view of upstream and downstream loss to endpoints and things like that. And I wonder how all of these mechanisms that we're doing in ITF, are very kind of targeted at very specific point use cases, like how do they fit in a broader ecosystem of, like, path awareness? How do they fit into the things you're doing with SCION, which I'm sorry to say I haven't paid attention, but after today, it's really cool stuff you're working on and I should probably pay more attention to it. So yeah, I think we're doing a lot of things in the ITF now. We would need some home for all of this to be discussed on a higher level. So I saw this kind of statement which might be too high level, but but it triggers me and I'm I'd like to contribute if if if you're basing something on this. Yeah.
[01:17:55] Brian Trammell: So if I could if I could reframe that into answering Dave's question. Dave's like, this seems a little bit too big, but I'm not exactly sure how. Here are some ways that we could prune it down. That feels like it might be another way to prune it down. Right? Like, so explicitly saying, hey. There's these other things that we're doing that are at the edge of path awareness in the IETF. We need a place to talk about the non engineering implications of that. Exactly. Okay. That's pretty cool. Thank you very much. Denman.
[01:18:25] Timon Spycher: Yeah. Two things, basically. One, I wanted to reiterate basically what you already said, the past policy languages. I think this is a really powerful thing that we need to look into, like communicating between the operators, between applications, users, and administrators, how all their preferences kind of can interact and can be merged, basically. And the second thing is just about the path explosion that was mentioned earlier, just to make sure this is not misunderstood. So there are mechanisms in place that kind of prevent an exponential growth. So we do have a flooding with like a controlled flooding of the network, but it's a controlled flooding. So there is a limit to how many paths. I think currently the limit the hard limit is 8,000 paths. Actually, you cannot get more than that. And again, the paths that you get are already specified in some kind of path policy language, but it's not really communicated. But there are mechanisms in place to make sure that you get a useful selection of paths, not just any. I just wanted to emphasize that.
[01:19:29] Brian Trammell: Cool. Thank you. So to be clear, I think all of that fits under the current charter of the of the research group. Right? I mean, like, if there's a lot of work to do on that and that gives us enough to do, then great.
[01:19:39] Dave Oran: I'm going to disagree on the flooding issue, which is that if the paths exist trying to control their propagation via flooding, we'll wind up not selecting the right paths to actually make it out to people and may suppress the pads that actually have the diversity you want in favor of a lot of duplicate pads that don't have that diversity. So I think you need a higher level way of preventing those pads from even being considered as opposed to damping their flooding?
[01:20:19] Dirk Kutscher: Hi. Derek Kucher, INTF chair. So PANRG, you know, has led to many useful insights on hardware networking in the past years and also helped to advance the science work in the ITF. And so thanks very much, Jen and Brian, for for doing this. And, another question is, so do we declare success, or do we find a useful direction that is also able to connect to the research committees that are working in this larger field? I think this is the actual crucial question. So in general, I agree that it could be time to move from research on like path aware architectures to, let's say, path aware internet services. So how do we expose, negotiate path properties, and what can applications do with it? And so I could imagine we could come up with a list of more concrete topics in the way that Dave proposed. But what we really have to make sure and also the SCONE connection, I think, could be interesting. But we really have to make sure that we have people who will actually come and do the work. So what I suggest is work a bit more on maybe the general framing and then a list of very more concrete topics as examples, perhaps, and then figure out, so how can we connect academic communities, ITF, are we confident that actual research will be done?
[01:22:01] Tony John: It could be good,
[01:22:02] Dirk Kutscher: I think, useful to have a working platform like SCION to do many of these experiments. But we have to make sure that people are actually going to come.
[01:22:21] Brian Trammell: Go on.
[01:22:28] Colin Perkins: Dirk is about six inches taller than me. Hi. Colin Perkins. Yeah. So I I I certainly agree that finding the right audience is critical here, making sure we have a community. On the question you have on the slide, this permits a whole bunch of policy related information to be exchanged. A common piece of policy information that governments seem to want to exchange between devices and the network is this user is over the age of 18. Is that sort of breadth of scope the sort of thing you're considering? And should it be or shouldn't it be? Because it could certainly affect the way traffic is routed.
[01:23:19] Brian Trammell: So I'll answer the question as the person who wrote this statement. No. Now I'll answer the question if somebody's reading it. Yes. That's good feedback. I think the the the point with respect to how do put it? That is a traffic property. Right? That is a property of like know, it's not like, hey, the user on the other end of this endpoint is 18. It is and the the question that you're really asking there is, this traffic was generated by an application in control of an identity that is associated with a property, which is age.
[01:24:03] Colin Perkins: Yeah. But there's a lot of properties which relate to the user.
[01:24:07] Brian Trammell: Yes. That yeah. Yeah. Yeah. Yeah. Right. Like traffic that could be expressed. But but the way that that generally in a in a Internet working context is that user property is then inherited by the traffic generated by the user. Right? Like so. And this is way that we've done the signaling at all times when you're talking about sort of, like, putting stuff in envelopes and exposing data. I I think that's a really that's a really good question for making me not like this statement. Right? Because it's I think there's still a very clear sort of line to draw around path that we're networking and that the properties that we care about are the properties of the path.
[01:24:49] Colin Perkins: The the properties of the path and the properties of the traffic, but perhaps not the properties of the user. Yes. You know, knowing that this is this is video and has certain latency bandwidth requirements, etcetera. Yep. Yes. I think that makes a lot of sense to affect the path. I'm not sure we necessarily want to be affecting the path based on, you know
[01:25:11] Brian Trammell: Yep. Could you do me a huge favor and reply to the message on the PANRG list to I mean
[01:25:19] Timon Spycher: Will do.
[01:25:20] Brian Trammell: I don't think that's a huge favor. I think that's gonna cause a gigantic discussion explosion. But could you do it anyway? Thank you.
[01:25:26] Colin Perkins: I will do so. Thank you.
[01:25:34] Adrian Perrig: Yeah. I wanted to make a comment about the statement as well. I find this extremely exciting, this research area, and I wanted to convey some of this excitement of what is actually feasible when we start looking at more rich properties and the rich problem space surrounding those. I also wanted to reflect briefly on Dave's comments, which are all really important topics, that those are also very, very important in its context. But the answer to many of those things will take a bit longer than we have here. But these are all very important questions. So to come back to this statement, when we consider richer path properties such as not just the latency, but actually the latency distribution, it turns out that you get sometimes different paths when you look at different types of latency distributions, that a different path can be the better path for your specific application. Similarly with loss, different loss distributions can result in different selections or also variance or given certainty on a latency distribution or even bandwidth distribution can again lead to different path selections. And looking at different applications, it turns out when you, for instance, look at a lot of the different AI applications, you actually, when you have richer path information, you make very different path selections and usage of these paths. So the opportunities in this space are really tremendous. And I find this particularly exciting to study what information should be passed and how to actually optimize for these things. Some people may argue applications will be too complicated for the programmer to actually make use of so much information because already many programmers are overwhelmed with the the little choices that are available today. On the other hand, AI can help us here to support more complex decision decision making. And that's also quite an interesting opportunity. So to to summarize, I find this question very, very exciting, and the problem space that it sets up is very rich. Who is collecting what information? How are you distributing it? How do applications act on it? And I just wanted to convey and say the opportunities for optimizations are tremendous. I think even that understanding what is even feasible and what kind of network quality can we get out of this is a really exciting problem.
[01:28:32] Brian Trammell: Cool. Thank you very much. Oh. Okay. Was getting ready to close it down. Are you remote? Yes. Go ahead. We are not hearing you if you were talking.
[01:28:51] Jen Linkova: We can hear you.
[01:29:00] Brian Trammell: Let's go ahead to Nicolas, and we'll come back to the root here if
[01:29:06] Timon Spycher: Go ahead, Nicolas.
[01:29:07] Nicola Rustignoli: On on the charging topic, I I support that that we consider this rechartering to be also a bit closer to adjacent communities. So I'm thinking about not only SCONE, but also L4S or Quick that will definitely have to do more work on multipath. But as as previous previously said by others, it would be important to pre to build a list of topics to also not fully ex extend the scope to pretty much unlimited. Otherwise, it it it will also have the research groups would somehow lose focus.
[01:29:42] Jen Linkova: But if we can build up
[01:29:43] Nicola Rustignoli: a list of topics, many of them already popped up, then I think that can can also improve and help also that different communities like Skohn or Multipath Quick can also find a venue to come and talk about more research y stuff. Yeah. Yep. Cool. Thank you.
[01:30:06] Brian Trammell: Shall we give Rudiger another try?
[01:30:08] Jen Linkova: Yeah. Rudiger, can you say something? Okay. Okay. Yeah.
[01:30:24] Brian Trammell: He's having trouble unmuting. Even though he's not unmuted, there's a Yeah. He's got layer one layer one audio problems. Yes. Alright. Ruger, please take the comment in the discussion to the list. That's where we are gonna continue this. I think we'll pick this discussion back up. I mean, we'll have this discussion on the list. I would hope to when I say pick it back up in in San Francisco, I'd hope to have it well sort of, like, sorted by San Francisco, and we'll, you know, bring that to to to the room there. Given that we already have people who are asking to present in San Francisco, we will be meeting there. I hope to see you there, probably even in person. And with that, thank you all very much for coming to PANRG, and see you next time.
[01:31:16] Jen Linkova: So you're playing together in person? Yeah. Probably.
[01:31:23] Brian Trammell: It's super easy to get. So I'm on can we now I have control.
[01:31:34] Jen Linkova: I disconnected.
[01:31:39] Brian Trammell: Let's see. We will close deck, confirm. Yeah. And then we can just go ahead and disconnect. Good. So