We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback
00:00

Formal Metadata

Title
SCION
Subtitle
Future internet that you can use today
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Do you know where your internet traffic flows? Does it go through China even if you don't want it to? SCION is a new internet architecture aimed at solving this problem. We will show how you can easily join the already existing worldwide network. The current Internet was not designed with control and security considerations in mind: incidents such as the hijacking of all traffic for YouTube by a Pakistani ISP in February 2008, the Cloudflare DNS service hijacked by AnchNet in May 2018, or a large chunk of European mobile traffic being rerouted through China in June 2019 show that we cannot quite trust the current Internet. SCION is a proposed future Internet architecture aiming to offer high availability and security, even in the presence of actively malicious network operators and devices. Designing a new Internet from scratch gives us the opportunity to make it work a lot better: we are aiming to notably improve security, availability, and performance. At the same time, just replacing the Internet would not be feasible, and thus we also emphasise practical concerns, such as incremental deployment and backwards compatibility. Thanks to that, SCION is currently the only clean-slate Internet architecture with a world-wide research network and production deployments in several large institutions in Switzerland; and you can start using it today. In the first part of this talk, we will drive you through the current state of SCION design and implementation, showing how it provides its important features: path awareness and path control by end hosts geofencing and isolation from untrusted actors scalability backward compatibility with existing infrastructure and protocols increased performance by active usage of multiple links fast rerouting in case of outages in any segment of the network The world-wide test deployment, SCIONLab, consists of around 50 different points-of-presence around the globe, many of them connected via direct, BGP-free, links. Having many independent organizations belonging to a continually evolving network introduces some non-trivial challenges of managing what you don’t own, which we will also talk about. We will show a live demo presenting how easy it is today for the end user to join the network and start using the available services. We will also present how taking down a part of the network can look and how SCION prevents a scenario of traffic passing by China or Pakistan. To close the talk, we will very briefly present the future plans and the direction in which we want the project to evolve.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
InternetworkingBitQuicksortInternetworkingVideo gameNeuroinformatikPhysical systemOpen sourceComputer-assisted translationPresentation of a groupPersonal digital assistantMultiplication signRule of inferenceComputer hardwareProjective plane
InternetworkingMereology2 (number)InternetworkingComputer animation
EmailInternetworkingFraction (mathematics)DampingMultiplication signComputer animation
PlastikkarteSoftwareRouter (computing)NeuroinformatikInternetworkingComputer configurationLine (geometry)Right angleComputer animation
Hill differential equationInformationComputer configurationProjective planeRoutingSoftwareGame controllerMereologyTelecommunicationGoodness of fitComputer animation
InformationControl flowRoutingScaling (geometry)Decision theoryCartesian coordinate systemSoftwareComputer configurationGame controllerMereologyTelecommunicationInternetworkingSuite (music)Flow separationInformationPhysical systemOrder of magnitudeIn-System-ProgrammierungLine (geometry)Metropolitan area networkAreaRight angleLaptopFigurate numberStaff (military)XML
Connected spaceBackupSoftwareRoutingLink (knot theory)Decision theoryGame controllerCASE <Informatik>Universe (mathematics)Multiplication signIn-System-ProgrammierungCartesian coordinate systemBand matrixBeat (acoustics)System callVideoconferencingAxiom of choiceMedical imagingArithmetic meanInternetworkingPhysical systemBitComputer architectureAlgebraMereologyVideo gamePoint (geometry)RoboticsComputer animation
Internet service providerScalabilityTable (information)In-System-ProgrammierungChemical equationRouter (computing)Symmetric matrixField (computer science)Public domainEmailFreewareDifferent (Kate Ryan album)Set (mathematics)Open sourceComputer configurationData structureRootGame controllerCurvatureRoutingRoundness (object)MereologyAxiom of choiceCategory of beingInternetworkingOrder (biology)Perspective (visual)Semiconductor memoryProgrammschleifeFault-tolerant systemRandomizationInformation securityPublic-key cryptographyCombinational logicWritingPhysical systemScaling (geometry)SpacetimeSoftwareNetwork topologyMultiplicationState of matterOnline helpCASE <Informatik>Key (cryptography)PlanningCryptographyPhysical lawInterior (topology)Computer animation
Coma BerenicesOcean currentLaptopState of matterCASE <Informatik>MereologyBitDifferent (Kate Ryan album)Perspective (visual)Fiber (mathematics)Term (mathematics)DistanceInternetworkingMoment (mathematics)Communications protocolMassDefault (computer science)Axiom of choiceMultiplication signQuicksortGroup actionControl flowLevel (video gaming)Similarity (geometry)Direction (geometry)MathematicsComputer animation
Self-organizationOvalImage resolutionMoment (mathematics)WebsitePoint (geometry)TouchscreenLevel (video gaming)Computer animation
Open sourceFiber bundleRoutingStatisticsRouter (computing)Configuration spaceMereologyState of matterWorkloadBand matrixAreaBitComputer animation
Drum memoryText editorElectronic mailing listBasis <Mathematik>Level (video gaming)Radical (chemistry)Default (computer science)Computer animation
Text editorElectronic mailing listWindowPerfect groupRouter (computing)Selectivity (electronic)Computer animation
Sample (statistics)SummierbarkeitMultiplication signDefault (computer science)Server (computing)Computer fileDifferenz <Mathematik>Physical lawProper mapConfiguration spaceMathematicsProgram flowchartComputer animation
Disk read-and-write headMereologyOrder (biology)RoutingNetwork topologyRouter (computing)Zoom lensVideo game consoleBitRadical (chemistry)Level (video gaming)Office suiteTerm (mathematics)System callComputer animation
View (database)Firefox <Programm>Online helpInternetworkingNumberPerfect groupDifferent (Kate Ryan album)Web serviceComputer animationSource code
BefehlsprozessorState of matterDataflowRouter (computing)Sign (mathematics)Software40 (number)2 (number)Computer animation
2 (number)Direction (geometry)Priority queueDefault (computer science)Social classComputer animation
Infinite conjugacy class propertySelf-organizationBefehlsprozessorProper mapPriority queueAxiom of choiceMultiplication signComputer animation
BefehlsprozessorConvex hullLemma (mathematics)MappingGraph coloringSharewareReading (process)Band matrixPower (physics)Computer animation
BefehlsprozessorComputer networkView (database)Electronic mailing listInternetworkingSoftwareRegulator genePresentation of a groupOrder (biology)Different (Kate Ryan album)Product (business)Universe (mathematics)Process (computing)Physical systemBand matrixRoboticsCommunications protocolPerspective (visual)Cycle (graph theory)CASE <Informatik>TrailDesign by contractScaling (geometry)High availabilityComputer animation
Computer networkSoftwareMoment (mathematics)TrailInternetworkingProduct (business)Computer programExtension (kinesiology)Multiplication signField programmable gate arrayDifferent (Kate Ryan album)Sign (mathematics)BitSolid geometryCore dumpPhysical systemResultantPoint (geometry)Computer animation
Chi-squared distributionGateway (telecommunications)ArmVideoconferencingSign (mathematics)Cartesian coordinate systemPoint (geometry)SoftwareMereologyAxiom of choiceCommutatorGame controllerRouter (computing)CASE <Informatik>ImplementationOpen sourceNeuroinformatikDifferent (Kate Ryan album)Computer animation
Letterpress printingRight angleSoftwareCASE <Informatik>Default (computer science)Connected spaceUniform boundedness principleMereologyMessage passingOnline gameGame controllerVideoconferencingComputer animation
Information securityControl flowMultiplicationInternet service providerSoftwareUtility softwareOnline gameVideoconferencingIn-System-ProgrammierungCASE <Informatik>Game controllerInformation securityMultiplicationCycle (graph theory)Order (biology)User interfaceMultiplication signMessage passingPoint (geometry)Computer animation
Mobile appComputer fileOrder (biology)RobotComputer configurationUser interfaceSharewareAddress spaceCodeLink (knot theory)Scripting languageComputer architectureLattice (order)WebsiteInheritance (object-oriented programming)Open sourceBuildingComputer animation
Product (business)Computer architectureSlide ruleImplementationSoftware repositoryCommunications protocolCartesian coordinate systemOpen sourceTotal S.A.WebsiteTouch typingUltraviolet photoelectron spectroscopySoftwareInternetworkingFreewareRouter (computing)MereologyInternet service providerAddress spaceConfiguration space2 (number)Moment (mathematics)Decision theoryRoutingMultiplication signAdditionAxiom of choiceIn-System-ProgrammierungLastteilungDefault (computer science)MathematicsScaling (geometry)Presentation of a groupSelectivity (electronic)Different (Kate Ryan album)Virtual machine1 (number)Perfect groupCone penetration testMusical ensembleAlgorithmRow (database)Data storage deviceGoodness of fitSign (mathematics)Computer programSystem callChemical equationVideo gameLevel (video gaming)Client (computing)Computer animation
SoftwareApplication service providerSet (mathematics)In-System-ProgrammierungSelf-organizationComputer hardwareReal numberPower (physics)EmailAxiom of choiceImplementationRight angleConnected spaceEncapsulation (object-oriented programming)Video gameBoolean algebraNumberRouter (computing)Parameter (computer programming)CASE <Informatik>Perspective (visual)Extension (kinesiology)Computer configurationAlgorithmRoutingProjective planeBranch (computer science)Line (geometry)File formatStandard deviationMathematicsGoodness of fitDecimalUniverse (mathematics)Moment (mathematics)Logic gateGroup actionScripting languagePresentation of a groupLink (knot theory)Arithmetic meanComputer animation
Open setPoint cloudOpen sourceComputer animation
Transcript: English(auto-generated)
Hello, everyone. Yeah, so here's the next presentation. And Matyr Shkowalski and Kamil Esochkova,
they will tell you about the future of our future internet. Please welcome, guys. Thank you. So we would like to introduce ourselves and our talk. But it seems the internet has already done it for us.
So we have learned things about our talk. Our attempt will be to do something slightly different. So yeah, we are people coming from a university, but we are not academics. And we are kind of concerned about whether things
can be at least somewhat useful in practice. And an important thing is we don't think we have fixed the internet. We think the internet has many layers. And we are trying to provide a tool that helps in the toolbox of the many things you need to fix the internet.
So yeah. And also, our thing can let you communicate with more than 12 computers. So let's move on to who we are. We are not academics. Yeah, so I'm Mateusz on the side. I deploy stuff that really works, which definitely
defines me as I'm not an academic. In my past, I spent a few years working in corporations, bigger or smaller. Then I decided this is not the way to go. I hate them from some time ago. I spent a few years of my life working at CERN on various open source projects, mainly OpenStack.
Then I moved to ETH. And then from ETH, I moved to Anapaya Systems. This is our spin-off. And yeah, you will see what it is about in the presentation. And I'm Kamilas Ochkova. And I think of myself as the sort of person who comes to your system and kicks it until it starts working, or at least
kicks it until the system tells us why it's not working. And yeah, I know a little bit about a lot of things. I get excited about the new open source thing every week. This week, I'm very excited about FreeBSD, but I'm excited about a bunch of other things as well. And I am weird. I like hardware, and I like monitoring.
So those are two things that define weird people, I think. And this is my cat. So let's talk about what we're going to talk about. So we are trying to design a new internet, if we say it in a very grandiose way. But actually, as mentioned, we are doing not quite redesigning
everything, but we are trying to redesign one tool in the many tools needed to fix the internet. So why do we think it might be useful to do that? And what we are trying to do is going to be the first part of the talk.
And then in the second part, that's going to be more interesting, perhaps. We will tell you about how you can use and try out our idea yourself. So let's start. So you've probably seen, on occasion, the internet
doing weird things. And there quite often happens that something looks fishy with the internet. So as an example, sometime at the beginning of last summer, a large fraction of the European traffic float.
You would send a packet from Zurich to Bern, and it would go through China. And there was nothing you, as a user, could do about that. You just don't send the packet if you don't want that. So yeah, the internet, as it is designed today, it does a lot of the heavy lifting of the routing
and all of the thinking about moving data through the network. It does it for you. And this was a really good design back in the day when the internet started, because computers were kind of stupid and slow. And so you wanted the network to do the heavy lifting.
So how it works is you throw the packet, and then you somehow hope that the routers in the network somehow deliver it to the right place. And don't go through China when you're sending a packet for 20 kilometers and something along those lines. However, nowadays, we have more options.
So the design where the network does all of the difficult things for you is one option. But it's not the only option now, because nowadays, end hosts are a lot faster, a lot smarter. And there might be different pathways that we could take and take a look at that might or might not
work better. But we won't know until we try, right? So essentially, what our project is doing is trying this other way, or trying one of the other ways that we can do networks. And only reality can tell us whether it's any good.
So that's why you come in, and that's why I'm telling you about it, so that you can try it out and see whether it works better or worse. So our specific idea is called Sion. And it is designed for route control, failure isolation, and explicit trust information for end-to-end communication. So what does that mean?
End-to-end is the first interesting part. That means your end host, so your laptop, can make the decisions relevant for how the network delivers your packets. It also has the option to make decisions about trust.
So nowadays, your ISP has the routes from somewhere, and they work somehow, and you have no idea about that. While in our system, your end host knows about where this information comes from and can decide to trust it or not. And there's also a lot more emphasis on failure isolation.
So back in the days when the internet was designed, it wasn't really meant as a highly reliable system, but not at this scale. Yeah, it's a lot more difficult to scale failure
resilience when things get several orders of magnitude larger than what you expected. So today, convergence in today's internet can take a while. And in our system, hopefully, this is better, we think.
It remains to be seen in reality whether it's actually true. And of course, the interesting part here is route control. And that's kind of the route control aspect is the one where I am going to remove my salesman hat, and I'm going to be like, yeah, now our system is nice and does things and blind stuff.
But the route control is a general concept that applies not only to our system, but to general thinking about how you design networks. And that's why it's interesting. And that's why we are bringing our thing not to sell you our thing and to tell you we have fixed the internet once and for all, but to tell you, hey, this concept exists.
Give it a try. Figure out whether it suits your application. So that's what we're doing. So let me give a quick overview of why these things are interesting. So what does it mean to have route control? It means that if you have two hosts somewhere in the internet, you can make some decisions
about how your packet gets from here to there. So for example, in today's internet, there is this issue with if you're sending a packet that's on the picture upright, if you're sending a packet from Europe to the, like to Southeast Asia or Middle East or one of those,
usually the route that your packet takes is the long way around. It goes through the US, which means you have pretty high latency, because you can't beat speed of light. And this is because it's cheaper for the ISP to put the packet, to let the packet go the long way rather than to go the shorter way
but pay more per packet because that route is more expensive. So today you don't have a choice and you just are stuck with the decision that your ISP made for you. But in our system, you can make the decision yourself. So for example, if you're having, I don't know, an important video call or something like that,
you can choose yourself to use the lower latency path. So that's interesting. Another use case is that, for example, if you're sharing a lot of data, I don't know, you're doing some research, you have medical images or you have particle physics in CERN, that's a lot of data.
And nowadays, you can only stuff as much data into the pipe as the pipe is wide. But this is kind of wasteful because many places have backup links or have multiple connections that they can use for failover but they cannot use it to transmit more data at a time.
So if your university has a 10 gigabit connection and a 10 gigabit backup connection with a normal internet, you only get to have 10 gigabit even though you're paying for 20. But with our system, you can send some data through the first, some data through the second
and that way you get a lot higher bandwidth and that way that enables you to, at the same cost, have more interesting or more bandwidth-intensive applications. And another interesting feature of this path control is that, for example, let's say you're doing something
very critical, like you need high reliability from the network. For example, you're operating a drone remotely or something like that. Then it's very interesting for you to have control over your network instead of having to wait for the network to make your decisions. So let's say you're operating your robot,
you're using this violet path to send the packets. And then at some point, something goes wrong, one of the nodes dies or something. In today's internet, you have to wait for the network to start rerouting your packets. In this network, you just immediately notice, okay, this stopped working. You switch to the yellow path and you're done.
You have switched within milliseconds and you have a working path despite failures in the network. So those are the interesting use cases. And now, how does this work? So that's in general. And how does it work specifically in Scion in our architecture?
So as mentioned, your end host has a choice about the path but it cannot make it up completely arbitrarily. So it is not source routing. Source routing has many issues. In this case, the host chooses from a given set of options. So it's kind of a middle ground
which tries to avoid the common pitfalls with source routing but also it gives you, the end user, more control, like a lot more control than in today's internet. And then the advantage of this, so what we do is your end host chooses the path and then it puts the path onto the packet.
So it has a stack of hops in the packet header. Now, this kind of sounds bad at first sight because that means your packet headers get large and it is kind of annoying, especially, yeah, if you're trying to do it high performance. That is annoying but the nice thing is
that the routers can then just follow the instructions that are written on the packet. So the routers don't have to have these huge routing tables. We already see it in today's world. The routing tables are like 10,000 entries or I don't know, you're running out of memory. You're paying a lot of money for routers with a lot of fast memory.
In our system, there are no routing tables. You just have it on the packet. This packet wants to go to the ad hoc next so you don't have to think about it. You don't have to store that in memory on the routers. But in order to make sure that the packets only contain the allowed paths, as mentioned before, this is not source routing. So we have to make sure that the path is allowed,
that it's from the set of allowed paths. So what we do is we have a very fast cryptographic MAC on every hop field which verifies that this path came
from the ISP who has the private key. You as the user, you don't have it. Not private keys, it's symmetric for performance reasons. But the ISP has the key, you don't have it. You cannot create arbitrary paths. You can only use the things given to you by the ISP. So that tries to find the balance
between giving you choice but also not letting you completely break your ISP by making up random paths or loops or I don't know, something like that. So yeah, that's for the paths. Now there's another interesting concept that's also interesting from the security perspective but it also helps with scaling
and that is the concept of isolation domains. So an isolation domain is kind of a sovereign part of the internet. So you would still be connected to the other isolation domains but the other isolation domains cannot affect you in malicious ways.
So an example could be that a country is an isolation domain. So now your country has control over the routing, control over the root of trust for HTTPS certificates, for DNS, all of that. And some, I don't know, China or the US or something
cannot affect these things from the outside. They would first kind of need to infiltrate your isolation domain and without that step, they are unable to influence your routing. They are unable to cause the issue I mentioned at the beginning where packets go through China when they shouldn't. So that's why the isolation domains are interesting.
And from this design, from the combination of isolation domains and path control, you get some pretty nice properties. So one thing is the scalability. As mentioned, the routers don't have to have these huge routing tables, they are stateless,
so they can be potentially more efficient. And you also get the hierarchical routing thanks to the isolation domains because you first do things inside the isolation domain, then you figure out the round between, then you do the routing with inside the destination isolation domain. So even if you're going through the whole world,
there isn't as much overhead as with one global, flat internet structure. And of course, you have native multipath because if you are writing the path of the packet on the header, then nothing stops you from writing different paths on different packets. So you just get multipath kind of for free.
And then you have the fault tolerance. So there's the usual things in the control plane, things notice when routers go down and so on. But the interesting part is the do-it-yourself aspect where if you notice this path isn't working, you can immediately, within a millisecond or whatever,
switch to a different path and you don't have to wait for the network at all. It's instant. Okay, so now there will be demo part. It sounded so academic, guys, you have to admit. Let's do something real now. So we've heard about few features, some of them nicer, some of them maybe less,
wherever you judge it. So what I'm going to show you in the demo, I tested it around 50 times before this talk, it will fail, I'm pretty sure. So I'm going to show you a few scenarios. Namely, one of them will be, I will have a traffic going from Bern in Switzerland to South Korea, you will see by default, we will have a traffic engineer to go through China.
However, we do not like our traffic going through China. So we'll create a policy which will be enforcing on the protocol level. So on the internet itself, what we designed, that the traffic cannot ever enter the China and we will see how it's enforced. I will not be going into details. We can talk about this later,
but you will see that it just works. The second scenario, we are talking about this very fast rerouting in case something breaks. I don't know how many people here in the room are familiar with BGP, BFD and these kind of concepts. Not much. Okay, so for people who know this, you probably know this stuff is bad.
For people who do not know this, do not go into this direction. You don't want to know this. And the first scenario, I will show you something very useful from the traffic engineering perspective and this, and here we go a bit into money and this kind of scenarios. So let's imagine we want to have a traffic coming from Europe to Australia.
So the very first question we have, do we want to go through Asia or through US? Wherever, from the distance perspective, it should be something similar. We shouldn't really care. But if we go into money perspective, into business, we will see that this is much, much cheaper for our traffic to go from Europe to US
and then to Australia instead of going through Asia and jumping to Australia. However, if someone is doing some maths at this moment that starts calculating distance, maybe speed of light even, you will see that this path which I'm telling you is cheaper, is twice as slow in terms of latency, in terms of how long does the light need to go
over the fiber from one place to another going through the globe on the other way. Which means depends whether we need something to go fast or we need something to go cheap. We want a different solution. And of course, you as an end user, currently with your laptop going to google.com
or wherever, you cannot make this choice. It's imposed by your ISP, by some bunch of people somewhere sitting and looking through dollars at the end of Friday every week. But it's not your choice. So yeah, let's see how we can do it. I hope it will work.
Okay, so the resolution of the screen is not super big. So let me tell you briefly what we have. So you can see we have some points on the map. So these are sites where we are present at the moment. So you can see we have something here in Asia.
We have something in Japan, something in China, Singapore, Europe. We will have one thing in Sydney. Sorry, I cannot show you the whole map at once, but yeah, technology in 21st century still amazes me. So the very first scenario, let me. So we are talking about the scenario
of something going from Korea. Yeah, I cannot zoom out anymore. Well, okay. So something going from Korea to Bern, and we see. We have some paths marked, and this path goes through China,
then Singapore, then Europe. And you can see some statistics. So we have path with the latency 150, bandwidth 3 megabits per second, whatever. This is some traffic, some workload. We do not really care what's there. The only thing we care about is that it goes through China, and we do not want it to do it. So let me just change the policy in...
So a bit going a bit more into details. We have deployed some routers, software-defined routers, because we are in the area of SDN. This is fancy nowadays. We want to do it. We will change configuration of this router in cell, because this is source of our traffic. And as Camila said before, it's the source, it's the end host sending the traffic,
deciding how to route it. So the source of our traffic will be explicitly stating, whatever happens, do not go through China. So through this UI, I will create a traffic policy. So what I'm doing now, everything can be done through command line,
just a bunch of JSON files, but, of course, for the purpose of demo, especially at this hour when we all just want to go home, beer, whatever. It's much nicer to do this through the UI, just click, click, click. Some fancy stuff appears on the map rather than just some bunch of guys writing JSONs in the terminal. So I will create a path policy,
and I will name it avoidChina, because this is what we want to do. And I will configure ACL with the default policy allow. However, I will select the... And now I'm missing the map. That's lovely.
Yes, I should be able to do control-minus on the whole window. Perfect. Yes, that's exactly... Can someone from the back of the room tell me whether it's okay or should I make it bigger? Like this better?
Yes, but now I don't see the map. So you have to trust me. I will click what I want to click, and you believe me, I'm doing what I'm saying. So I'm selecting this router in China, and now it appeared here, selected AS, Hong Kong Telecom. I do not like these guys. I will not give them my traffic. So now we can see on the left-hand side,
this traffic will be denied. Let me save my policy. Let me save it once again. And now on this router, so in the cell, I will modify the default policy to use the path which I just defined,
which means avoid China. I will save it, and if I click save enough times, here you can see just if someone is interested, this is a diff in JSON which happens in the background, because this is just a bunch of files somewhere on the server running. I will deploy the config. I will click show log, but I'm afraid I will see some bad stuff there,
so I won't show you this. I just hope it deployed properly. So I will go back to the map, and yes, we have the same traffic, and as you can see, it's not going through China. We are avoiding this one dude here who's stealing our traffic and selling it to someone. So, okay, so the first scenario is covered.
What I'm going to do now, I will revert this change because I will need this Chinese guy later on. In the next step, just to give you some heads up, I will take down this Chinese router in order to show the fast tree routing. So we go back again, we allow this traffic,
and we should see the path as previously. Let me zoom out. This is a cool feature. Yes, if some people do not see the colors, this yellowish goes back through China, so everything happened correctly. So Camilla was saying about this scenario of fast tree routing.
I bitched a bit about the BGP BFD, so let me show you now what happens. I will log in manually through the console to this router in China. I will take it down. We will see the traffic immediately goes around, avoids this node, and we will see also on the map some fancy stuff will appear. I hope my terminal remembers what I wanted to do,
and I hope Internet is fast enough. I don't remember the numbers, so I don't know if I'm taking the correct one down now, but well, let's see.
Live demos, that's the... So Docker Compose, because we are running all this stuff in containers, so we have containers for routers, for different services, for selecting paths, certificates, and so on. I don't want to go into detail, so I will just take down everything.
So Docker Compose is down. It's my perfect... Yeah, that's my favorite stuff. I just... Yeah, I like destroying stuff. Yes, and it's the correct guy. So we can see immediately stuff. Something started happening. We see some red signs. For people who are going to read us later,
it means that the beacons, so the small packets which routers send to each other to announce paths in the state of the network, they stopped flowing. So we have so-called revocations which tell us, no, this path is not available anymore. Please do not use it. Okay, let's keep this guy like this. I do not care about him anymore. I will show you the last scenario,
because we are... Yes, everyone wants to go from this room already, I think. So I will show you the scenario of traffic going from burn. Can I click burn? Yes, no, I cannot. Now I can. Okay, so we have the traffic going to Australia. We have five megabits per second of traffic,
and it goes with latency around 140. So this is the best we can get going this direction. It goes to Singapore, Australia. But this is too expensive. If you've seen the bill for this traffic, it's enormous. So I will change the policy in burn. Here I pre-created some stuff, because it would be boring to show you all of this.
So I created traffic class high prio and default. And the high prio means this is the traffic which I want to go fast, doesn't matter the price. And default, it can be slower. People do not pay. It's, you know, best effort, no SLA, let them do it. I will create a path policy then.
Low latency, go through Asia. And I think I'm selecting everything properly. Okay, I have this policy already created,
so I was trying to do something stupid, of course, because it's late. So I will create a traffic policy, ABCD, whatever, let's name it like this, for the high priority traffic. And the high priority traffic will be going east through Singapore. This will be my policy. And the second policy will be wherever for any traffic.
You see, it was like logical true, so this is always, always true. It will be going west. And if I clicked save enough times and everything deployed correctly, which I hope, because I sacrificed a lot for this demo to work, we should see exactly what we want to see.
Oh, yes, okay, colors are playing tricks with us now. But you have to believe me that we have now four... It's a darker orange and a lighter orange. Yes, so we have this traffic with four megabits going with the high latency path and the very low bandwidth traffic with the low latency going by the other.
So if I zoom out, you can see that the path which was the fastest before, it stays. And we have some traffic going around, so it goes to Spain, US, then probably Japan. If I can read maps correctly, geography is not my best side, and then Australia. So this is what we have,
and now the bill will be much, much cheaper. Customer will be happy. So, yes, so this was for this demo. Okay, so now let's go into something more practical because we just show you some stuff on CI, some are some UI, but maybe, yeah, what happens next? Do we really use it?
Like this dude from the Internet, he wrote, we have like 12 users. No, this is not true. So, in fact, we have two separate deployments. One is driven by the Anapaya, so I told you, spinoff of ETH in Zurich. This is a production network, and this production network is already used by few entities. One of them is Swiss National Bank. They have deployed Sion already two years ago,
and they use it for hike. From their perspective, this is a mission-critical traffic. What they are now deploying is a product in Switzerland for people who may be... Okay, so I will say something as interbank clearance. This means different banks in the same country,
in order to send money from one to the other, need to use a very specific protocol, and for this protocol, as we are talking Switzerland finance, the regulations are really fucking crazy. This is so difficult. I was working in the past in one company which had to go through the audit of this, whether the systems are really compliant. This is crazy.
You do not want to do this ever. So, yes, they decided to use Sion for this deployment because they feel like this serves the purpose. Another use case, this is, once again, Switzerland and the government. We have some of Swiss embassies around the world. I can recall now from my mind Berlin and South Korea.
They are also using Sion in order to connect their premises offshore with the headquarters in Bern, Switzerland. Also, what we are doing in a smaller scale, so national, we are now in a process of deploying Sion to connect all the universities in Switzerland so the high availability, high bandwidth,
and all these nice features will be available for different people working in different scientific entities in Switzerland. And as you can see, this is a BGP-free. So, yes, we have this nice sticker. Kamliad wrote it like a few hours ago. This network is not using BGP,
which means you are covered by definition from all these problems which were described at the beginning of the presentation. So, we are not running on top of the current Internet. Yes, it's not running on the current Internet. This is going back to this dude from N-something, yes. He does it every year. He's just trashing all the talks on the main track.
And then for people who want to try, who want to do some experiments, perform some research, maybe you want to discover some new features, we have SionLab Research Network. This is network consisting of around 60 scientific institutes in four continents at the moment.
We have widely deployed SionLab backbone, which is managed by people at ETH, and then in different countries, continents, we have created for them their own isolation domain. They can join at any point in time. They can try. They can do research. I think the biggest con... Not really customer, but the biggest user right now
are some people in Korea. They are using Sion as SionLab extensively. They are doing pretty nice research. They are writing papers like crazy. They are delivering results, and they say SionLab really helps them. I think some guys in Netherlands... I don't remember the name. S-I-D-N? Maybe that means something to people?
Yeah, whatever. Some guys in Netherlands, they are using this for more production research. I think they are trying to do something with P4 and programming FPGAs if this says something to someone. So this network is big, and this is something you can join wherever you want and, you know, just play around, just discover some stuff.
And, yeah, Camila is going to tell you some fun facts about how to run this. Yeah, so that's all very nice what we've told you, but how do you yourself, like, sit down tonight at 1 a.m. after you've done your drinking and deploy this on your home router? So that's my home router. The most important feature, of course,
on any home router is ICE. And this is a small passively-cooled computer that can run Sion on, like... to test it out. So it runs on any PC. The sources for our reference implementation are on GitHub, and you can deploy it on a PC
or in a VM to try it out quite easily. What's interesting is that it is possible to use Sion also for, like, IP traffic by letting it go through a gateway. So, of course, if you want your application
to take full use, to make full use of the offensive features, your application needs to be able to select the path itself, so it has to be Sion-aware. But if you don't have a Sion-aware application, but I don't know, you have your video calls or you have your... not torrent streaming nowadays, you can use the Sion IP gateway
to make different choices about IP traffic and define policies for your IP traffic to go through different paths in the Sion network. So kind of use it as an overlay. And it is also possible to deploy Sion and IP on the same networks.
Then you would kind of have Sion on top of IP, and then if you use the Sion IP gateway, then you have IP on top of Sion on top of IP, but it kind of makes sense because you still have the path control policies. So that means you don't have to have a dedicated network and you don't have to write all shiny new applications,
but you can literally start using it without all that extra work. But in case you do want to write an application, in case you do want to make use of the offensive features, this is what it looks like in a hello world fashion. So it's pretty similar to normal networking,
to IP-based networking. The interesting thing is you have to get the paths to your destination. You get, I don't know, three paths, and then you can choose it somehow, depending on what your needs are. You may try all the paths, find out which one is fastest or find out which one is cheapest or I don't know. And then you do a connect,
but you just give it the selected path as well. Right now, you have to give it one path, and if you want to use multipath, you open different connections. But we are working on a native, like, default multipath thing, but that's in the works. Yeah. And we are very curious about people coming up with ideas
of what you can do with a path-aware network like this. You could have some interesting use cases for path control. I don't know. The video calls is an obvious example. Maybe online games might be interesting, some streaming, I don't know, things. There's lots of things about efficiently using multipath because there are issues with
how do you actually make use of the fact that you have multiple paths, improve the network utilization. There are a bunch of security implications that might be interesting to explore. And from the ISP viewpoint, there's the question of, okay, your users are choosing paths now. How do we do traffic engineering? How do we define path policies that make sense
both for our users and for us? So we are curious to see what people do. Sorry, we are running out of time, so I won't be showing you any more demos. I will just tell you what I wanted to show you. So in order to join the scionlab research network, what we provide you, we have a very simple web interface in which you can register.
So you just create an account. We provide you vagrant files, so you can just run scion inside a VM. It will connect to scionlab transparently from you. So effectively what you need to do, you go to the website, you register. We do not need any data from you, just email address so we know the person, so we know that there is someone behind.
It's not just a bunch of bots from Pakistan, China, India, wherever you name it. You register that, yes, I want to download the vagrant file to join scionlab. You get it, vagrant app. That's probably something very simple for people, and you run it. It runs on top of ubuntu. We do not do any fancy stuff inside.
So, yeah, just a bunch of scripts which we provide to you in order to make it very simple. Of course, if you want some more advanced scenario, you can even build it from code because this is on GitHub. The links are later. So, yeah, do as you want. We provide Debian packages. I don't know. I think RPMs are not available. I built them a few times, but I never published,
so this is something yet to go, but Debian packages ready to go, vagrant file built from source. These are the options you can do. So, yes, so we have some links. Go through them later. We will upload the slides. I think they should be up. So, scion-architecture,
if you want to know something more about the architecture itself, scion-app as I described, anapionet if you are ever interested in the production network, scion-proto-scion is the protocol itself, the reference implementation for all the stuff you've seen there, and netsec-eth-scion-apps, you have some examples. You've seen on the slide Hello World because, of course, we won't be pasting the source code, but if you want to see some applications already in place,
this is in the repo scion-apps. And, yes, if you want to keep in touch with us, please feel free. There is a lot of ways to contact us. Also, feel free to catch up with us later, and I think we have ten minutes for questions, so let's go.
Thank you, Mateusz, Camilla, for an interesting talk. So, I guess you can share my microphone, yeah? Okay. So, if this allows users to determine which route
they go through the internet with, does that involve a completely different thing at internet backbone level, and does it change the way that ISP Berlin would work? Yeah, so this is kind of interesting on the larger scale of things, so not your home network, but a bunch of ISPs.
And, yeah, it's kind of an interesting question of why the ISPs should care, and I think it's like if you, as the end users, want it, the ISPs will then have an incentive to start providing it.
Just to add some of this, we already have ISPs in Switzerland, and I think we are working with one in Korea to start providing this for end users, so you don't need to build anything on top. If you are based in Switzerland, you can just, in some time from now, call Swisscom, tell them, I want, on top of the internet, which I have at home from the network outlet,
I want to have Scion Natlivi there, and I think they are already working on a commercial offer for this. I don't know for residential customers if it's going to be available anytime soon, but for businesses, this is something you can already talk with ISPs, and they will be very happy to quote you on this, and, you know, you pay the money,
they will provide you whatever you need. Hi, thank you for your presentation. I'm just wondering if my ISP changes the available routes to something that is not compatible with the policies that I have set up, then I'm just out of luck, or what happens then? Yeah, so it can happen that there are no paths
that are compatible with your policy because the ISP makes the decision of what is available, and you locally make the decision of what you want, so, yeah, if it's incompatible, you are sad, you get no paths, and you have to talk to your ISP to make them change their policy, or you change your policy,
but it's still, we think, an improvement over the current Internet because at least you know if they're doing something you don't like, and you can make yourself the decision of, okay, will I not be so picky, or will I try to make them do what I want, right?
Hello, thank you for the presentation. I have a question about the protocol itself. So you defined it as a priori definition of a path, so what I understand, you design your path in the same way as Tor does it,
and what you do is you always have one path, so you are exposed to a problem, the same problem which cities have with roads because people tend to choose the same roads over and over again, so this way, you lure people into thinking
that they are designing something better by themselves, which actually is, they actually perform what is performed currently by routers of ISP, so first of all, people are becoming routers themselves, well, business people, and second of all, fixed paths force you
to send your configuration with the packet, so for example, if I would have five blacklisted routers, yes, I can use a bloom filter, and I could zip my MAC addresses into the packet, it would not be very big,
but if I would have something more fancy like ignore these routers, prefer these ones, and not go to here, and so on, then you suddenly can send megabytes of additional data just because you forgot, yeah,
so it's an interesting concept. The second part, this is not really true, maybe we did not explain it fully, but this whole configuration, you do not attach it to the packet because this is not really source routing what you are doing, just as a client, you select the path,
so you do not send a packet saying to the next router on the way, I want to avoid China, that's not what happens, the decision you want to avoid China happens at the moment when you send a packet from your machine, which means no router on the way knows that you have a policy, avoid China, the only thing they see is that you've made a choice of arbitrary routers
on the way, they do not know what incentive do you have behind this, so this is a very, let me say, stupid way of routing because you just tell router what should be the next hop, you are not telling router to make any kind of decision, router is not that as if in this path
because you've made a selection when you constructed your packet, of course, if something happens and the path is not available, your packet will not make it because router will not be allowed to make the change. As for the first part of the question, which was like, yeah, okay, but people will kind of do the default routes that they are doing anyway
and just think they have the choice, we think that it is an interesting question to design the paths in a way that makes better use of the internet than it is today, so for example, if you give the users three paths and all of them go to the first path, then that path will suddenly be congested
and will have a higher latency, so it is actually in the user's own self-interest to try to kind of load balance things, right? But then it is up to, as the programmers, to design good algorithms that are able to do this without introducing oscillations and stuff, but there can be options which are where it is useful for the user
from the selfish perspective to do the right thing for the network. Yeah, and the problem with this design is that I don't know which routers will be down in the future, so that is what I cared. Thanks.
Hi, I was just wondering, let's say I am a business and I want to start using Scion and I have an ISP and they are prepared to start offering Scion. In practice, at the moment, could an ISP just start offering it to their customers
or would they be waiting on a number of other organizations to all start offering it to communicate with the other side of the world? So this really depends on the case, so I'm not sure how much I can tell you without paying debt till the end of my life and getting fired as soon as I leave the building,
but I believe we already have at least one ISP who prepared a commercial offer to a customer to run native Scion. So this answers partially the question. However, I believe if I, as a private customer, Mateusz Kowalski leaving XYZ, if I went to another ISP and I told them,
hey guys, can you give me native Scion connection to my home, they would tell me, yeah, you know, sure, but 100 million Swiss Francs and maybe in 10 years. So this is a very tricky question, but of course, as with any business, it depends on your size,
it depends who you are in the country, what power do you have. We are somehow in Switzerland in this comfortable situation that we are doing a lot of government projects, so if government decides that we are running this project for banks now, banks have to comply. So some businesses, they do not have a choice, they will just join the party because they are told to do so,
but I agree this is a very comfortable situation. As a private customer, probably it will take you much more effort. I think maybe the question was also about, okay, I want to send Scion traffic from here to there, but it doesn't work if only my ISP says, okay, we'll do Scion for you, but it has to be every,
like the whole path must be Scion network, right? So it's difficult to do it globally right now because there aren't ASPs in many countries in the world that offer this, but that's, again, something that we are hoping to fix, and also Scion Lab Research Network is on four continents. So if the research network is enough for you, then that's kind of an entity that already does this globally.
Yeah, so this is also kind of, yeah, let me get 30 seconds of this. This is what makes it different from standard SD1 and list lines and MPLS because you do not need to have a dedicated line between every branch of your business. We are building a fabric so we can just join the network fabric
and we are building backbone for you, which means it's cheaper because we'll provide you backbone, you just need to provide the end hop, the last hop to both your premises, but you will be consuming the backbone which is provided. A question about how it looks on the wire. So does it mean that every package,
every packet has embedded preferred route? Where is this route placed? Is it like IP extension header or like some kind of encapsulation on top of IP, or is it UDP, or what is it? Yeah, so we have had, like, people thought about this
and figured out that the best way to actually have all of these features and not end up with something completely horrible is actually to design a completely new header. So we have a custom header. We kind of need this because of also the cryptographic checks that we do. So we have our own header
and we have a reference implementation and we have given some thought to whether this header is doable in hardware and we have made some changes to the format of the header so that it is possible to do it at high performance in hardware. But yeah, it's a custom header.
Okay, last question now, okay. Do you handle multicast routing? Sorry? Multicast? Do you handle only unicast or also multicast routing? Oh, multicast. There has been some thought given to multicast
but I think it's probably too early because we are still fleshing out the details of that. So we don't have anything publishable right now but there is some research ongoing at our university. Yeah, if I remember correctly, there was one project working on multicast.
It never made it to the reference implementation but it wasn't only technical choice. As far as I remember, there was a lot of discussions whether we really want to provide multicast. Like what is the real use case of multicast, why people want to do it and if they really want, maybe they are doing something wrong because this is kind of a way of thinking.
We do not want to take the existing protocols and implement exactly the same features because then it just bunch of guys redoing work, reinventing the wheel. We want to go back to the beginning and ask what is really the feature you want and why do you want it. Only after this, we will provide you a set of stuff
that will fulfill your purpose. But saying kind of things like, I want multicast because I have multicast in IPv4 right now is, yeah. I do not think people really want to go like this and fight with this kind of arguments. Okay, thank you, Mateusz. Thank you, Camila,
for your enthusiastic and interesting presentation. Thank you audience for the interest.