Thank you.
My pleasure to introduce the next speakers, Jordy and Tillman, who are going to be speaking
about SCION, the next generation internet. Can we get a round of applause please? Thank you.
Hello everyone. Thanks for attending the talk. Thanks to the host for having us here.
I'm a little bit of a rockstar right now. We are Till and Jordy. We both come from ETH Zurich.
We are part of the network security group at ETH Zurich. We are also part of the SCION open source implementation team.
First question, who has heard before about SCION? Okay, some people. You can skip the introduction and the overview.
Okay, so for the rest, I will start introducing what SCION is. SCION is a clean design of an inter-domain architecture that considers security from design to achieve security properties,
mainly availability, also transparency and control, reliability and scalability. So I want to make here clear that SCION has to do with an inter-domain network,
so it doesn't have anything to do with inter-domain protocols or higher level protocols in that sense. And the other thing I want to highlight on this slide is that SCION is an open source project.
So here you have the GitHub repo in which you can find the reference implementation of SCION. So in here you have also, well, Till will give more details afterwards.
Here you can find also references to documentation and related stuff.
So the second question is why does even SCION exist? So SCION comes as an alternative to our old friend, BGP IP Internet.
So yes, this was created even before I was born, so imagine how things have changed so far.
So SCION has the distinct aspect that incorporates those security aspects I mentioned before from the very inception.
Why do we need this? Because we need a network that provides availability even under the presence of malicious actors because there are people interested in harming the inter-domain routing.
So we can find some examples, current recent examples, so for example an outage caused to a Spanish ISP due to a BGP attack.
And we have several malicious actors in Internet unfortunately from nation state actors to cyber criminal groups that are interested in harming and due to different reasons.
They can be from political reasons to economic incentive, you can name it.
And yes, sometimes the trust boundaries, so trust nature of the current routing architecture sometimes doesn't make it clear enough where the trust boundaries are.
So probably some of you are hungry, maybe not enough for just running away and grabbing lunch.
So I cannot offer you food like actual food but I can offer you some yummy desserts.
In this case towards the end of the presentation we will give or we will present a couple of demos.
One is a browsing demo using Scion, second one is a Scion word first person shooter, and finally we will walk you through steps and guidelines for developers that hopefully find this interesting and want to contribute or just use what's there so far.
But first some overview of Scion.
So the whole Scion ecosystem includes different entities from different domains or from research institutions to ISPs, to vendors and integrators and users of the system.
All these ecosystems is nurtured by the Scion Association which is a non-profit organization responsible for the standardization of the Scion protocols.
They are currently pushing and they have published three or four ITF drafts and they are pushing it to RFCs.
So they are also responsible for managing the open source implementation.
So here I try to summarize Scion in five distinct aspects.
The first one is that Scion is a pathway where internet architecture meaning that end hosts are presented with path information in the network and they can make a choice of what path they use to send their traffic through.
The second aspect is that Scion designs and implements a scalable trust infrastructure.
I will go into a little bit more detail just in the next slide.
It also designs and implements scalable path discovery basically in the control plane for trying to achieve rapid global connectivity.
Then another aspect is that it has like multi-path nature.
So as I said before end hosts are presented with several paths that they can use even simultaneously.
And finally another aspect I would like to highlight in here is that there is already real world deployment of Scion.
So these I will show you towards the end or the middle of the presentation.
So first just some terminologies.
My idea here is that you kind of get the idea or the gist of it so you are not completely abstract in this.
So first term is that Scion organizes itself in trust in so called trust isolation domains or ISDs for sure.
These trust domains as the name indicates are isolated trust so are nothing else that group of ASSs of autonomous systems that share a common trust route configuration.
So they basically agree on a set of routing policies that they want to use.
And the other term here is the core ASSs which are the ones in charge of managing meaning updating those TRCs and so on.
And they also provide peering with other ISDs.
So basically they isolate trust.
This is an important point I want to emphasize.
This isolate trust it's not another kind of isolation.
Then the other part of the overview is the control plane.
So here I will explain briefly how the control plane and the path dissemination looks like.
So again this is an overview of code.
This is full of details and you will find them in the documentation and references to the books and several papers that we have about this.
So the routing information is disseminated to the network in these so called beacons which are these squads, these corals and squads in here.
Those beacons are initiated from these core ASSs that I mentioned before and they are either propagated farther down the network in the local ISD and they are also propagated between these core ASSs.
These beacons are authenticated and extended at every hop and every hop meaning every ASS on path decide how they extend these beacons.
So they do it based on only their local policies.
So yeah basically on the slide you see that they are disseminated and finally you have found some path information.
You have already those segments, sorry those beacons have been disseminated and at the very moment they reach an ASS and here we can focus on the green ones.
For example those are already usable so there is no need for convergence in that sense so this piece of information is already directly usable.
This helps to achieve rapid path exploration and scalability.
As I said before this is just a quick overview because I don't want to overrun with details but there is exhaustive evaluation on this scalability aspect of the control plane system.
One other aspect I mentioned before is the multi-path nature of SIAM.
So from the N-host perspective N-host retrieve path information from their local ASSs.
So basically they request this path information and they retrieve several paths they can use simultaneously.
So the path server, so called the servers in the local ASS that provides this information will provide to the N-host this information.
So this is different from source routing so here N-host directly retrieves the path from their local ASS.
This many paths or several paths allows applications for optimizing on different metrics so they might find some of those paths better in terms of latency than others.
Others better in terms of bandwidth and they may hopefully find a point that better suits their needs, the application or N-host needs.
So just for putting some numbers in here in the current production network, so the real fabric we are building, if you take two ASSs you will find from dozens to even hundreds of paths that can be used to reach the other endpoint.
And last slide on this overview is this control plane and data plane slides.
So the control plane is what I have just explained in the previous slides and the data plane is what I will try to explain right now.
So as I said before N-host retrieve those path segments from local service and they combine them to create a path.
So you can find here two examples of paths.
So segments are combined in one path for packet one and in another different path for packet two.
So once the N-host has encapsulated this information into the packet they send it out to the network.
And routers forward packet based on the path information, so they inspect this path information which contains information of which one is the next hop and then routers can simply forward to this next hop.
So this allows for simple routers and stateless operations.
So as you can see here, so for example those packets may belong to the same application.
For example, you send the packets or the N-host in this case send the packets using two different paths that in this case are even disjoint.
So for example this can be useful if you have an application, it has a control channel, it can use low latency path for control channel and higher bandwidth path for the real application data.
Okay, now, so I want to also convey the idea that there is already some tangible stuff so it's not, as I said before, it's not only a research project, of course there is a lot of research in it, but there is real deployment and engineering right now already in Cyan.
So for that I will basically explain these two networks.
So first one is the actual, the global Cyan internet, so the real production network in that sense, so the real fabric.
And I will just introduce briefly some concrete ISDs in this case, those color bubbles that I showed at the beginning.
And then I will also talk briefly about side lab test with network which is a completely separated network, in this case this is an overlay network that anyone can use and I will give more details afterwards.
So in general this production network again is, this is not an overlay network, it's the real fabric, it's BGP-free.
And it's currently deployed by several international ISPs, so here you have some logos, you don't have to look at them.
Currently there are over 100 ASS and they are distributed in Switzerland, you find a few of them, also in the EU, in North America or in Asia.
And the other thing about the production network is that recently also has been enabled Cyan-Claus-Bates access, in this case this is a commercial offering.
But so just for you to know that if anyone happens to have like cloud deployments, they can also access the production network.
Okay this is one of the examples, this is one ISD again, one of the, this color bubbles that I showed you at the beginning.
This is the Education and Research ISD, Sierra is the fancy name.
And here you find universities, in this case here you have some of those.
This is a growing ISD so it's not closed, so more universities may come and some are interested in coming in.
There are also other research institutions and research and education networks that also provide connectivity between those research entities.
So here is a world map picture of how they are distributed roughly around the world.
And then very shortly there are also industry use cases right now, so there is this secure, in Switzerland are those two that I'm going to introduce.
The first one is the Secure Swiss Finance Network, so they are basically using Cyan and they are going to phase out the finance IP net that they are using.
And by June this year, and by then they will have, or the network will have around 120 participants.
And the other example similar to the Secure Swiss Finance Network is the Secure Swiss Healthcare Network that provides similar service for health professionals.
So yeah, that was the real production network and this is Cyan Lab, which is the research network.
In this case Cyan Lab is a globally distributed testbed to conduct experiments and test deployments.
So anyone can join, so anyone in the audience can join this network just by downloading a virtual machine.
So with background file you run background app and then you have your node attached to one of these transit nodes.
So all of those are transit nodes, leaf nodes are not in here.
And yeah, basically I'm not that interested in the names, so they may be a little bit unreadable, but different boxes are located in different parts of the world.
So for example you have Korea, you have North American, also you.
So yeah, Tillman will also give some pointers afterwards where you can find the information for joining Cyan Lab.
So now we also have awesome Cyan project, so basically this is a compilation of projects that are related with Cyan.
So we have from infrastructure projects, so we have people implementing Cyan into Fino routers, also express routers.
We also have firewalls using Cyan and other kind of infrastructure related projects.
We also have application projects, so we have the Cyan Naval Browser extension for example in Chromium.
And we also have, so far as Cyan were, Quake 3 video game, video game client distance.
And of course we also have the libraries.
We have pointers to reference implementation again to network APIs and client and host stack in different languages.
So we have in Go, then we have this client libraries for Java that Till will give some more information and explanation just right now.
We also have client and host in Rust and bindings to other languages like C++ and Python.
Then also this list includes useful tools, so Cyan is integrated in the CIT emulator, so if you are using CIT emulator you can also bring up your Cyan network.
Then there is also escape libraries for package generation and YSAR plugins for packet capturing.
So here is the first demo I want to show to you. I will just switch to the video.
Okay.
Yeah, I guess.
So this is the Cyan browser demo and basically here you will see, so first of all this uses the production network.
So you will see this basically browsing in the production network.
This is part already, I just said, of these awesome projects in which we have projects of, so different projects using Cyan.
So in here you can find this extension.
You load one Cyan-enabled website, in this case for example the ETH website.
And the extension provides some information about the resources and where they were loaded from.
So here you see that the resources from the ETH domain were loaded via Cyan, so the green indicates Cyan and red indicates that they fall back to the GPIP.
Of course this is configurable and you could choose not to fall back to anything if they are not available.
Here you have some path information. You see that we stay within the Swiss ISD, so my client in this case is in the Swiss ISD, so we stay in there.
Because the server happens to be located in the same ISD.
Then an example of navigating to another ISD.
In this case we navigate to the MacW University server and in here we see that resources are loaded, all of them via Cyan and we have also some path information.
So here we see that we go from the Swiss ISD where my client is through this CERA education network that I presented before.
So here you find the exact AS numbers that the traffic traverses.
So here I type yet another example.
And basically also we have more path information.
This resource also happens to be located in the same ISD.
If you really do find different ISS but this is not important information.
So basically that will be it.
Now this is just again for just showing that we fall back to the GPIP but this I already explained.
The second demo I wanted to show is this Quake 3 demo.
So here this demo is using the CYLAB testbed network so it's not using the production network.
And here our client is located in note at ETH in Zurich and we connect to the server which is located in Magdeburg, Germany.
We connect it to the server and okay.
So basically here what you will see commands being typed.
The piece of information I want to convey is that so different things that we have is this showpaths command that's CYM specific.
And this showpaths command show all available paths from the client to the server.
So you get a bunch of paths and well we see a little bit more of them.
And the other thing is that for demonstration purposes what we do is we bind to the key to command next path.
So then we can iterate basically and see how different paths provide different latencies.
So we have this key shortcut and while we are playing you will see on the top left of the screen not right now but while we are playing.
So this path for example, so if you saw before this path had 100 milliseconds latency, we start playing.
And then what I was saying before is that now for example you see in the top left corner we have switched the path.
So we just press this key shortcut and we iterate over the set of available paths.
So this is for demonstration purposes for show that we can find paths with different latencies.
We keep iterating, we see changes in latency, we see we keep iterating on the top left part of the screen and yes basically we see these different latencies.
So hopefully this will stop now in the last frame and here for this specific path we receive this latency.
So this interactive of course you can program this and adapt your application to have path selection algorithm that does it automatically and always takes the path with best latency.
And yes that was it. I will now let the floor to Till for explaining the rest of the presentation.
Okay thank you Jody. So now let's imagine you found all the science stuff very interesting and you tried to implement your own project.
How would you go about that? Yeah the first step would be to go through this awesome science list that Jody presented earlier where you can find existing projects but also libraries, language libraries to connect to the science network.
So these are probably most important ones for a new project. The first one here is the Go API that's like the reference implementation, the original implementation of science.
It's the most comprehensive implementation. It contains everything including border routers, control servers and everything you need to completely run science.
It also comes with language bindings for C, C++ and Python.
More recently we have a Rust API 100% written in Rust and just released a few days ago we have an alpha version of the Java API and that's actually what I'm going to talk about in the next few slides because that's kind of the project I'm involved in the Java API.
So yeah it's written in 100% pure Java. It is very similar to the Datagram channel that people may know from Java with a few exceptions.
Datagram socket is currently not implemented but that's very pretty much the next thing to do in our list especially since I realized that a lot of existing older projects rely on Datagram socket instead of Datagram channel.
The library also has an API for path inspection. This is pretty much all what science is about. You kind of get a lot of paths from your AS and you select the best path for your purpose.
So yeah path inspection and selection is very essential.
It also supports the SCMP protocol. SCMP is like ICMP for science. So again you have echo or ping and trace root commands available.
So let's look at a very basic Java client. So this is a Datagram channel example and basically there's nothing to see here because it looks exactly like you would use a normal Datagram channel.
The one thing to just bear in mind is for example the host name eth.ch that needs to be in sign and able to host otherwise you can't run that example and also your local machine needs to be somehow connected to the sign network.
Let's look at a bit more interesting example. So there's an additional method. There are several ones but this is one that may be interesting. It's called set path policy.
So what you can do of course is just go through all the paths that you get from your local ISP, your local AS and then pick the one that you want to use.
But it's much easier if you can just define a path policy. In that case maximum bandwidth. You set that path policy on your channel and the channel will always try to find a path that suits this path policy.
Now we're going to look at the server side. It's a little bit different from the native Java implementation in the sense that the receive doesn't return an Ionet socket address but a path object.
And the path object does contain the Ionet socket address from the client that connected to the server.
But it also contains the whole path that the packet actually took through the internet.
And you can just use this path and to send a response back to the client.
The idea here in sign is that usually if you send a packet to a server you would send it back the exactly same route.
Technically you don't have to do that but it makes it a lot easier for the server because the server doesn't have to look up paths how to connect to the client.
It's just much faster.
So I mentioned path policies before. The Java library comes with some predefined path policies.
Somewhat self explanatory probably but one path policy is called first. That just picks the first path that your AS gives you back when you ask it for a path to a certain destination.
That's kind of a cheap way for the AS to actually recommend you a path. They think this is a path you should use.
The next one is min hop that just tries to find the shortest path.
So with the least hops in the path on hop being like a border router or other ASs you have to go through.
Then there is min latency and max bandwidth which also pretty much do what you would expect them to do except that these implementations are non parameterized aesthetic.
So they just rely on metadata. So you ask your AS for a path to get metadata back that kind of estimates the latency and give you like the allocated bandwidth for the short for the links in the path.
If you want to have like really the best latency you would need to implement a new filter or I may also provide that in the future.
A new filter that looks at all the paths, pings all the paths and then just selects the one that has a lowest latency.
At the bottom of the list we have the ISD allow and ISD disallow filters.
ISD being the isolation domain numbers that we previously saw, although this whole set of ASs.
So basically isolation domains can map to countries for example or to something like the university network that we saw earlier.
So these ISD allow and disallow can be used to implement something like geo fencing.
And since the ISDs represent countries for example you can decide that you don't want your packets to go through a certain country.
So imagine you're on the bottom left ISD in one of those ASs in that ISD and you want in your ISD is 110 and you want to send to ISD 130 and there are a lot of paths, some direct path.
Some go out by 99 and one some path by 125 and 120 and for some reason you don't like ISD 99 which could be a country, could be just some other organization.
And then you can just define your path policy like that.
The exact syntax is a little bit different.
So I simplified it here but it's pretty much that.
So you can just exclude 99 so the filter will pick any path that is not and that doesn't go by a 99.
So once you wrote your application, your first step, well not the first step but yeah, the next step is testing.
And the common way to test sign is just to run a local network on your computer on your machine.
And you can do that using the reference implementation that was mentioned earlier, the sign proto reference implementation.
So what you do is first you define a topology in a file, topology file, then you run this command.
This will create a lot of configuration files for all the border routers and control servers, demons and whatever needs to be started in your machine.
Then you can view the topology if you like.
So we have a very simple topology here with three ASs like the three ellipses, one core AS that's a button on the top and they all reside in the same ISD.
That's just a simple example.
There are also a number of topologies that are already in the repository so you don't really need to write your own if you don't want to.
Then you just run the topology that will start up all the different processes for the different border routers, control services.
They're all connected by loopback devices and then you can just connect with your local application to the network.
In this case I just run a ping to the core ISD and that's the result.
So there are other methods for testing.
So there's for example the seed emulator that Jordy already mentioned that does support Sion.
Then there's the Sion lab.
This is a worldwide network of Sion nodes.
If you want to use it you can go to the website, register, you can allocate your own ASs if you want.
Then you can, as mentioned previously, download an image for a virtual machine and the virtual machine is like an AS that you run locally.
You can even create several of those and then create a network.
Then you can test in the production network but that requires you to actually have access to the production network.
So if you're lucky your ISP supports that but there are currently not that many.
AWS offers nodes that have Sion access so you can rent an AWS cloud center or something.
Or maybe your university has access to the Sierra network.
And finally for debugging there's a lot of command line tools.
I think I mentioned ping and trace route before, show path and several others.
And there's also a very neat wire shark plugin.
So you can just look at Sion packets, inspect the header, look at the path that is associated with the header.
So and if you want to contribute there are several tons of projects that could be done.
You could carry your own project so we are still missing native libraries for C and C++ for example.
There are no libraries at the moment for C sharp or swift.
You could think about embedded or mobile devices.
Also network protocols.
For example Java implementation currently only supports UDP.
We aim to use support quick and probably TCP very soon but there are many other protocols that would need support.
Or you can just use one of the big existing projects for web proxies,
HTTP servers or video conferencing clients like JITC or something.
Or gaming libraries and try to make them sign a way so you can select path or automatically select good path in these projects.
So yeah finally if you want help or support there's a Sion Slack channel, there's a Matrix channel.
And since last week we also have a Sion tag on Slack overflow so you can tag your question with Sion and we have some developers subscribe to the tag and they will try to answer your questions.
Yeah that's already from my side everything.
Thank you and looking forward to some questions.
Thank you for a great presentation.
I have my question is regards security and protection against the DOS attack.
So you allow everybody to select a path for packets and how do you protect against someone doing it maliciously.
For example sending packets back and forth between ASS to overload the network.
Yeah so the question was I think how do you prevent DOS attacks or how to prevent people abusing paths to send traffic for creating loops for example.
So these paths that you can see here they all signed.
So that makes it kind of impossible to create your own path.
The paths are all signed by all the ASS on the way.
And that also makes it a bit easier to prevent DOS attacks because you know where a packet came from.
And if you don't like that region you can quite simply block everything that comes from that region.
Thanks.
Yes.
I think a question is someone in the similar vein how do you deal with resiliency of the network which with.
How do you deal with.
Oh yeah the speakers.
How do you deal with the resilience.
Like the internet is very resilient because the routers can take independent decisions but if you select a path as a user and like a link goes down then like.
Like information that information has to disseminate all the way back to the user so they can select a new route and then.
Have their link up again instead of that just happening transparently to the user.
So.
Okay the point here is that normally you send the packet out to the network right and just pick routers to send it to the next hop just based on the destination information right.
So when you have for example some link failing in the middle you need to converge to a stable state in which okay what's now the after the failure what's the next router I have to send the package to.
So this is this takes some time and by that time your packet may be time out already so you need to still send the packet so with Sion you can already detect that when you see that the packet it's taking long or you don't get feedback and you can already take for example.
Completely disjoint path and in that sense this failover mechanism is quite effective.
So normally when link is busy you also get network feedback right so you see that packets are thinking longer latency is increasing so what you do is you as a user you are interested in taking a more.
Healthy path in that sense if I can say that so you will automatically switch to that path.
I have I have a question you showed in your API example that when you create a connection you specify the route.
But supposedly a country changes you don't want to go your want your packet to go through a certain country then you have to change your software.
Currently when I make a connection I only specify the destination and I don't care how it gets there.
Now the information of how it gets there is mixed with where it should go.
So when the route changes I need to change my client software.
If I understand correctly.
I hope I understood the question.
So the routers become very simple because I don't need to do any decisions anymore.
The only thing is they could verify whether the path is assigned past.
So yes you do have to update your clients.
The clients all need new libraries that could be.
I mean I have a quite high level library with a Java but it could be an operating system.
Just another driver that sits underneath UDP or TCP and adds like the sign path transparently.
But yeah that's kind of the big work we have to provide updates for the clients.
Let me add five cents.
So there are also transition mechanisms right.
So we have for example a thing so called Sion IP Gateway.
So there for example traditional IP applications so you have your applications in a certain subnet
and this traffic gets to this Sion IP Gateway.
And this Sion IP Gateway encapsulates traffic to the Sion network.
So in that sense you don't need to change for example with this transition mechanism.
You don't need to change your application.
Of course the application is not taking like the best properties in that sense.
For example then you would not be as application choosing your path and optimizing for all of those or for some of those metrics.
But you can still let this traffic go to this specific gateway and then this gateway will decide for you depending maybe on policies
and local policies where do I send this traffic to.
I don't mean the one time conversion of course if you switch to a new network protocol you have to change your software.
But it's more the dynamic stuff when now my provider decides if some AS is out of the loop.
But now I have to decide that as a client.
Yes but you can easily default to whatever paths your provider provides to you.
So you can always pick your default and just don't care about the rest.
But on top of that you have the choice as an host to decide where you want to send your traffic to.
If your for your use case is not important whether your traffic goes through I don't know any country you name it.
Then you can just fall back to the default paths and then you don't have to make this decision if so.
Is path selection always from the client side or can the server make a decision of what paths are acceptable.
So the password is usually the client would connect the path server in his AS in its AS to get a selection of paths and we would use those paths.
And those paths are sent to the server and the server could look up a different path to the client in theory but that feels a bit ineffective.
So they can just reverse the path what's automatically reversed in this API to you send the packet back.
Yes but just adding something else. There are some projects for example that try to make some negotiations so the server can signal or indicate the client.
What's the best path to choose in their opinion but this is also like separate from the vanilla side I don't think.
This is something you could put in place.
I have a few questions but they should be quick to answer.
So I've read about this thing called secure backbone autonomous system which is where you advertise better routes to existing BGP infrastructure.
Is this in wide deployment is this popular is it being used.
Also have there been any experiments with Wi-Fi does Zion work well in wireless context.
Also in the quake example I didn't see an IP address in the quake demo I saw some other sort of address.
What is that address. It's like the ISD or something.
So I got the first and the last questions I will try to answer those first.
So the first was talking about as much right.
So as much is also an incremental deployment model architecture which basically is a hybrid between BGP and and so in that sense.
The idea very basic idea and I'm not the one like involving the project but very basic ideas that you combine BGP so that BGP are announced closer to this backbone.
And then you use this backbone as secure backbone and then you go out to the Internet again hopefully close to the to the to the destination.
So the specific question was about the current deployment so it's under deployment.
So some members in our team are making efforts and this I would say should be soonish already to be used in production.
It's not yet there but it's there.
The last question was about the address format right.
So yes the address format that you saw is composed of the ISD so this color bubble and a yes the individual is of the of this ISD.
So these two numbers plus the end host the end host address.
This end host address has a scope within the autonomous system.
So you could use basically any address you want but the scope of this end host address is specific to this specific autonomous system which is indicated by the ISD plus AS numbers.
There was just one more question about wireless. Is there any experiments with wireless? Has anyone done anything?
So now we will be starting projects for supporting Sion in Android and there we are going to go deeper on that.
But of course I mean for example if you are interested in providing wireless support and optimize for wireless this Sion use case I mean you are more than welcome.
But yeah.
Thank you for the talk. My question is you mentioned earlier at the presentation that there is a way to update ASS which nodes which which nodes can be trusted with the further routing.
So my question is how does that work? Who decides which nodes can act as ASS which ones cannot and how those bigger bubbles ISP or something else whatever it's called.
How do you decide which nodes act as ASS and can you dynamically update it?
So if I understood the question correctly it's about who decides what ASS is trustable or not trustable right?
So what Sion brings is this possibility to the sender in this case the end host within the ASS as I said before.
So your ASS will provide you with a set of paths and then you will based on your local policies as end host you will apply these policies to these set of paths and then you will end up having a subset of path that you consider that good for your use cases.
So this of course brings so this delegates some responsibility but this is good. I mean at the end as I answered before you can fall back to any default path right?
And just be kind of agnostic to okay where my packet is going to but I mean the main benefit is just having a choice on that.
So ISDs basically represent jurisdictions right? So you can think about them for example we have the Swiss ISD.
We will have other countries ISDs or regions or in this case for example this group of university institutions.
So you may think so in there is pretty much for my use case for example I would want my traffic only go through research institutions because I'm deploying this thing from maybe my home country.
And then I could basically steer that policy or implement that policy in there and then of all the sets of available paths I will be doing that.
Of course this will depend maybe on your application for doing certain things you are good with other paths.
So I don't know if I...
The initial trans routes so they are agreed upon so basically...
Can we take this offline so we can get the next speaker please?
Yeah I mean I can answer you offline because they need to...
Hallway track it's a thing. Okay thank you for the talk thank you.
Thank you.