RIPE 82
.
SCION BoF
.
27 May 2021
.
17:30 (CEST)
DAVID HAUSEER: Hello, good afternoon, everyone. I hope you can all hear me. I would like to welcome you to this BoF session on a proposal a SCION Working Group. I hope you can see my slide as well, so we are all set to get started.
.
So, first before I start, let me express a few words of gratitude to all those who have made this BoF possible. First of all, a big thanks to the RIPE 82 organisers, and the Programme Committee for having us. Then I'd like to also thank to all the BoF speakers, supporters and participants who are here with us today, I see a big number which is great. Also I would like to thank Caspar for offering to serve again as a secretary today. He will become active later on taking all the questions and reading out them loudly.
.
Just one word about logistics. For those of you who have not used Meetecho before, if you would like to ask a question later on, this can be done either by asking the audio or video access with the icon shown on the top, or maybe since the group is quite large, preferable might be to write just the question in the chat by clicking on the question and answer icon, and then this will get queued up and Caspar will read the in the queue.
So what is this BoF about? This BoF is the second instance of BoF on SCION. SCION is a novel Internet architecture. For those of you who are not yet familiar with SCION, you will hear some words later on in the talk by Sam, also a more detailed introduction can be found on a RIPEstat article that has been published. You can see the URL here, so if you are interested to learn more details about it and the motivation behind this and how we believe RIPE could get involved here, I would like to point to this article.
.
So, as I said, this is the second instance of the SCION BoF. This follows the momentum that was created by the first BoF in RIPE 81. Back then, we asked the questions how RIRs could assist with registration of SCION resources, particularly SCION isolation domains and SCION AS numbers. Again, Sam will give a brief outlook on this later on. And also the question whether RIRs like RIPE should take a role in the issuing of SCION AS certificates similar to their role in RPKI.
.
Now, the goal for today's session is to discuss a proposal that we have come up with to build a SCION Working Group at RIPE. You can find the Charter, the proposed Charter for this under the URL indicated here, and so the plan is, later on in the discussion session, to discuss all the aspects of this proposal.
.
Now, a quick overview on the agenda after my brief introduction. I would like to hand over to Sam Hitz from Anapaya, he will talk about SCION isolation AS registration and certificates, so basically give a detailed insight about how they are doing this now, since Anapaya is currently the only entity who is dealing with this. And then, unfortunately, Fritz Steinmann cannot be here for personal reasons, so Sam offered to also deliver his talk on SCION challenges and risks for certificate‑issuing and AS number assignment on a specific example, the example of the Swiss secure finance network.
.
And then, later on, the majority of this session shall be dedicated, as I mentioned, to the discussion of the proposed Charter and the goals of this Charter, together with me, Adrian Perrig and Stavaros Konstantarar will help me with the motivation. Caspar will take the questions and we have also a number of SCION Working Group supporters on board today. These are all named here. So, those will be on board also to answer specific questions later on during the discussion as well.
.
Now, to start with, we would like to start again with a poll, by asking two questions, and for this I am briefly going to hand over to Caspar. Caspar, can you take the floor please?
.
CASPAR SCHUTIJSER: Yes, of course. Can you hear me? Okay, very good. I am going to start right away with one of the questions of our poll. So the question is, have you attended the previous SCION BoF? And I think the poll is now running.
.
So the majority of the participants that answered was not there, but a small part of the people that's here today was actually at the previous BoF, that's nice. Let me quickly prepare the second poll, which is about your familiarity with SCION.
.
So, we would like to know to what extent you have any experience with SCION. So in a second, that poll will pop up. And there we go. It's more interactive than a life session, you can see people raising their hands and that. In three seconds the poll closes. So over 50% have heard about SCION. 30% doesn't have any experience with SCION. Some people played with t some people considered themselves an expert and some people from practical experience. That's really good. Now, I am handing back to David.
DAVID HAUSEER: Okay. Thanks very much, Caspar, this is actually a great outcome. It means that the more people than half a year ago have heard about SCION, which is excellent. So, I guess we have so far done our job correctly.
.
All right. Now, to continue, let me introduce the presentation by Samuel Hitz. Samuel is the CTO of Anapaya Systems and he will talk about SCION isolation domain registration, AS number issuing and AS certificates. So, please, Sam, the floor is yours. I hope you can share your presentation now.
SAMUEL HITZ: Thanks a lot everyone for having me. I will give you a very brief introduction about what SCION actually is because some of you have never heard of it. So very briefly, that we have the foundations and then talk a little bit about current numbering practices, there are things that need to be numbered, closely related also the certificates that are involved in the SCION control plane and kind of raise a few questions or food for thought also for the upcoming discussions.
.
So, here is a SCION overview in basically one slide. Again, I won't have a lot of time of course to go into a lot of detail, but it should suffice.
.
What you see here is a SCION Internet, as we call it. It's just like the regular Internet, a network of networks. The basic building block are, as in today's Internet, autonomous systems, these are these hexagons that you see here on the map. And they are kind of three elements that I want to talk about here.
.
The first is so‑called isolation domain. So an isolation domain really groups together a set of autonomous systems into logical unit, and mainly through purposes for these isolation domains. The first purpose is that it introduces a routing hierarchy. I'll come to that shortly in the control plane, but basically during the path‑finding process, there are two levels of hierarchy: within an isolation domain and then across isolation domains.
.
The second one that is more important to what we discuss today is actually that isolation domain, they define a route of trust. In the SCION control plane, all path information that gets exchanged and registered and found is actually authenticated and verifiable by everybody on the network, and of course this involves public key topography and that always needs to be verified against a route of trust which is defined by an isolation domain.
.
So really, an isolation domain you can think about a logical grouping that, you know, you might think it's country‑specific, because it counter‑defines a jurisdiction, a common law, and so on and so forth, it usually has some regulators in there as well. But as we will see actually in the second talk, it can also make sense to have industry‑specific or industry‑vertical‑specific isolation domains, which the Secure Swiss Finance Network is one.
.
The second element is then the control plane, so that the routing and the purpose of the control plane is to find paths through the networks, between these SCION ASs. As I said, the SCION AS is the basic building block so we don't go deeper than the AS itself, but it's really about path‑finding between those ASs.
.
So the routing works in the following way: In a process we call beaconing. These are propagated through the network from AS to AS, right, as I mentioned before two levels of hiring; here, the yellow path, for example, is a path segment that gets found within an isolation domain, within the yellow isolation domain and this purple path segment would be an example of a path segment being found across isolation domains. So through this beckoning, basically you have these beacons that collect path information. Every AS on the path will kind of record the interface a beacon enters the AS and also then where it leaves the AS again, and it signs that information that it's verifiable.
.
This leads to these path segments being available. They get registered in the path directory service, if you so wish, it's very similar to a DNS actually. And then on the data plane, one of the fundamental pillars of SCION is that in the end the sender chooses the path that he wants to use to communicate with the destination. Now, it doesn't have the free choice over all possible paths, of course, but what happens is that these path segments that are being created through the routing process, a sender can request and look them up from the network, combine them in different ways to form end‑to‑end paths and then make a choice which one of them it wants to use to actually transmit the data.
.
The data ‑‑ the path itself as depicted here is written into the packet heard to each signed packet contains the AS level path of a packet already in its header and signed ‑‑ SCION routers. Basically, they don't do route table lookups any more, but they just verify the routing decision that that has already been made. This is cryptographically secured by using authentication codes and then forward the packet accordingly.
.
So this is all I want to say about SCION itself, how it works. Of course, you know if you are more interested about more technical details or the use cases of such an architecture, there are plenty of resources for you to consume.
.
To go a bit deeper into the isolation domains, as I said before, a SCION network, or a SCION Internet consists of a set of interconnected isolation domains. Each such isolation domain defines a root of trust and this is what we call this trust root configuration. It's basically a file, if you want to be more specific, a set of X 509 certificates together with a policy, how they can be updated. And then, crucially, each AS in such an isolation domain, they need to have an AS certificate issued by some ‑‑ a certificate authority within that isolation domain such that they can participate in the control plane in the route finding and then, more crucially, the path registration process. Without such an AS certificate, you cannot be part of a SCION network and of course that lends itself also to do some form of access control who can be part of such an ISDN, who cannot, which will be a very crucial point for the example we see in the second presentation.
.
As I said isolation domains by default are country‑specific. That's our current practice, but we also have examples of industry verticals like this banking isolation domain.
Good. So then to go a bit deeper. There are a few things to consider for knowledge. There are items that need to be numbered. First of all, every isolation domain needs a globally unique number. It's from a 16‑bit name space, and they cannot clash. So, every isolation needs to be uniquely identified and then every AS, in principle, needs to be uniquely identified within an isolation domain so the Tuple ISD number plus AS number that needs to be unique. The current practice is to assign globally unique AS numbers, mostly for identification. But technically, from the protocol specification, Only the ISD AS Tuple needs to be unique. And we have a 48‑bit name space to use as AS identifiers.
.
So that's pretty straightforward, right. Of course in the BGP Internet, as I call now today's Internet, we have also autonomous systems, we have numbering authorities, one of them is RIPE. Of course there is assigned AS numbers. Obvious question is who will take this role for numbering ASs in the SCION Internet and ISDs, because there needs to be some form of global coordination here.
A bit more food for thought is the fact that we might need to adapt for a future with many, many more ASs, so we expect that in a SCION Internet there will be many more ASs than in today's Internet. First reason would be that today's large BGP ASs, if they would transition into a SCION Internet, they would actually not be one global SCION AS, because at that point you lose, of course, some of the path control and path diversity that you want the users to have. So they would be splitting up multiple smaller signed ASs, maybe more regional ones.
On the other hand, SCION also makes it very, very easy and very useful to be dual or multihomed even for micro and nanosites. With that in mind, maybe there also needs to be another layer of delegation from the numbering authorities maybe down to providers, and have something like PA AS numbers, like a PA address space today. This is just food for thought.
.
So what is then the current numbering practice? Currently, on Anapaya we have this global numbering authority. We don't want to be the numbering authority. We are just fulfilling kind of the need because somebody needs to hang out numbers for entities that today want to use the SCION ‑‑ the current SCION network.
.
We have a very straightforward and small numbering policy. We have the 0, that's a wild card, 1 is basically any ISD. We have a small range for documentation, then sample code. Then private ISD numbers. If you want to run a private ISD, and then you have mostly limited to 4,000 public ISDs, that could be extended to the full 65 K if the need ever arises. We are just numbering in increments of one, we don't sign numbers. The first ISD was the Swiss ISD, which has number 64; the second one was a German ISD which has the number 65 and so on. So nothing special here.
.
For the ASs, very similar, again we are handing out AS numbers, again we don't want to be in that position. As I mentioned before, AS numbers they need to be ‑‑ there is technically scope to isolation domain, but we said we want to make them globally unique because also ASs can be part of multiple different isolation domains and if an entity or an organisation has an AS number and is part maybe of a banking ISD and the Swiss ISD, they should be identified by the same number. This is mostly that helps humans to identify that organisation.
Furthermore, what we did here is actually we said, okay, whoever has already a BGP AS number out of the 32‑bit, this range will be kind of reserved, so they will be able to grandfather their AS number into the SCION AS address space, again that's not something that is required by the protocol but it's a practice that we use. So, for example, Swisscom or Switch as a SCION provider, Switch has the number AS 559 in the BGP, world they also have 559 in the SCION world.
.
And then for all the new entities that do not yet have have their own AS numbers, we have reserved a relatively large range here, 4 billion, where we just allocated again in increasing numbers.
.
That's our current practice.
.
So then what about the certificates? As I said, every AS kind of needs, of course, a number, but they also need an AS certificate to participate in the SCION control plane, mostly to sign path information, and a SCION AS certificate, it binds really a public key to an AS identity. So that's how also you can see how AS identity, the AS number is related to that AS certificate, right, and SCION AS certificates are issued by CAs that are legitimised by the TRCs. So the a CA of an isolation domain would have the root certificate in the... trust configuration. These are basically for whoever is governing this isolation domain and then the ISD policy in there you will have things like okay, these are the voting members and let's say two out of three voting members need to agree, need to sign a new TRC for TRC update to be valid and so on. Then we have a classical certificate hierarchy, the root certs in the TRC from which the intermediate CA certs, issuing certs and those, in turn, issue a certificate.
.
That is all I want to say about the PKI, and, of course, there is similarly certificate issue considerations. Basically, in practice right now, also Anapaya, we play the role of a CA for every IC that is not strictly governed. We have an example of an ISD that has strict governance requirements, that is the Secure Swiss Finance Network, and, well Fritz will have been telling you more about this experience as a CA for the SFN, but I will do that just after this presentation.
.
And here, also, food for thought, right, numbering and certificate issues are related. So that means would a numbering authority kind of also deal with certificate issuance like, you know, similar to RPKI, or would actually CAs number things like how could that look like in a SCION Internet? Again, just something that you can think about and that should help you in the upcoming discussions.
.
That's for presentation 1. David, I think if you don't mind, I will transition directly to Fritz's presentation.
.
Okay. So very briefly, what is the SSFN? It is the banking, interbanking communication infrastructure. It's not just for banks but also for other financial institutions, for iPhone telecommunications, financial service companies that we are building here? Switzerland, together with six, our financial infrastructure service provider and the Swiss National Bank, to basically build the next generation for interbanking communication.
.
Implemented technically, it is moulded as a SCION isolation domain, it has number 70, to be precise here. And this one is actually very tightly governed. So there is a governance board consisting of members of the Swiss National Bank, of six, and of Switch as an independent provider. And they define the rules of who can be like an operator in that network operator in that federation, who is a CA, and what are the rules that CAs need to adhere to to allow new members to this network, right. So this is something that really we, at Anapaya, we have nothing to do with any more and it's completely delegated to six in this case and Switch and the Swiss National Bank.
.
Numbering. Again, they used ‑‑ for them it was easy, of course, to get numbers, seeings as Anapaya is the numbering authority. We just handed out AS numbers to them. Current thinking, and we use the same, of course, practice that, you know, whoever had origin AS number, BGPS number, they kept that, and another just got assigned a new one out of this range.
.
But, here, as I said for actually this range here, some numbering authority needs to be there. Our current thinking is actually to reserve a slice of this space here and assign it to the CAs in the SFN such that when they hand out the certificate to a new member that wants to join, they can also assign an AS identity for that. So, here the numbering is actually being coupled with the issuance of certificates.
.
Then, from a certificate authority point of view, since six is a certificate authority in the SFN, there are a few considerations and key questions that they had to look at. Especially related also to public versus private trusts, right so what I want to emphasise here is the AS certificates, these cannot be compared to a TLS certificates. Of course they have ‑‑ they also use the X.509 standard etc., but it's in the end not a public trust. It is trust ‑‑ it needs to be trusted within an isolation domain and for every other isolation domain that it's connected to that wants to communicate with the SFN. For now, the SFN is an isolated network so we're really in a private trust setting.
.
Furthermore, these AS certificates, they are really used for ‑‑ to protect routing and affording information. They are not used to encrypt application level payload, and thus also, you know, liability is not such a big issue for now. There have been pushes towards using these certificates of course to also use end‑to‑end encryption because they are already there. But six, so far, has pushed back on these things, because that would also increase liability potentially for them.
.
And then finally, there is an aspect of availability of the certificate authority. So, in SCION, we don't have explicit certificate revocation for the AS certificates. Instead, we work with very short‑lived certificates, they are typically three days and then they expire. That means that the ASs need to be really highly available, we implement it actually, that's why we also have the secondary CA that Switch runs as a backup in case SIX would experience some outage, and of course the whole certificate renewal and issuance needs to be fully automated because it will lead to this disconnection if you cannot renew your certificate in time.
.
Right. So these were some of the more practical aspects that Fritz would have been able to tell you about, and I hope this gave you a bit of a picture of what are the topics, or the questions that might arise, current practices and ‑‑ yeah, I hope this will lead to a healthy discussion.
.
Back to you, David.
DAVID HAUSEER: All right. Thank you very much, Sam. Looking at the time, we are already a little bit behind schedule, so, we are not going to take technical questions now. I would go directly into the BoF discussion and, for this, I have prepared a slide.
.
So, just briefly summarising what we'd like to discuss now for the remaining half an hour is the Working Group Charter that we have come up with as a proposal. So essentially our idea is that, with this Working Group, we can raise the awareness within RIPE about the role that the someone like RIPE could take in the architecture and facilitate the discussion around it, specifically, as Sam pointed out, the registration and the certification of SCION resources, SCION ISD establishment, SCION AS number assignment and provisioning of SCION AS certificates, and then to come up with a pilot for these aspects in which we would plan to specify how this pilot should look like in a first version in the first year, then to implement it and collect feedback and experience on it in the second year, then to specify a revised version based on the feedback, and then, in the year four, to consider potentially permanent implementation of the SCION registry and certification at RIPE NCC.
.
Of course, this will happen regularly in RIPE meetings, twice a year, as well as in remote sessions outside of the RIPE meetings as regular in Working Groups.
.
And, of course, we also commit to monitor and take part in related Working Groups like the Address Space Working Group|, the Routing Working Group, and potentially the RIPE NCC Services Working Group as well.
.
Now, we expect obviously some discussion on several items related to this proposal. The first question, of course, is why do we need it? So we do have some arguments that we would be happy to discuss with you. In relation to our Working Groups, as mentioned, is an important aspect here. Certainly the question about standardisation plans may also come up. And then specifically speaking about the pilot that we have in mind, we may discuss the planned deliverables and timeline, and also then the very concrete aspect of requesting the RIPE NCC to give out those signed resources as a registry. And then there may be more technical aspects like the Working Group organisation itself that are similar to our Working Groups as well.
.
So, with this, I would like to open the discussion and I have seen that there are already a number of questions that came in. So, Caspar, this is now your turn. Please, if you could, select the first questions and that we then will be able to answer in the forum.
CASPAR SCHUTIJSER: Yes, of course. So, one question about the forming of a working group from Raymond Jetten with his private hat on. He asks: "To the question should this be a separate Working Group, I hear so much that it's relating to routing and routing security that this would be a valuable part of the Routing Working Group."
.
So, what is your response to that?
DAVID HAUSEER: Yes. Thank you very much, Caspar. So I'm looking at the other supporters as well within the team. Who would like to take that one?
SIMON: I could say something about this. It is certainly a routing‑focused part of it, but at the same time it works very differently from the, from IP routing. I am not quite sure whether it has a place in the Routing Working Group yet. I'm a bit worried that it will be a bit alien to the typical discussions in the RIPE Working Group, Routing Working Group. So, personally, I think it's certainly an understandable reaction, but so far I think it's, it would still better live in its own Working Group. And then once it's a bit more socialised, the SCION way of doing routing then, yeah, why not? Maybe one day it will become just part of the normal routing discussions.
DAVID HAUSEER: Thanks, Simon. Do we have any other comments?
CASPAR SCHUTIJSER: We also have some people in the microphone queue. I don't know which order they came in but I will now give the floor to Jan.
JAN ZORZ: I would like to reiterate what Raymond said. So when I was thinking about this, and I understand your reasoning why you would like to have a working group and why would you need a working group, when we are at the in‑person meeting, we have big problem scheduling Working Groups one next to another, and people are complaining that they are missing one or another topic they would like to attend both, and I think that adding one more Working Group group to the existing setup would be an organisational nightmare for the RIPE NCC and for the meeting organisers. You need to understand that a RIPE meeting, it's not an IETF. IETF can add loads of Working Groups and nobody even knows how many Working Groups there are. But RIPE, as a meeting organisation, I don't think it can get more Working Groups. Me, personally, I would like to see this number being reduced, to be honest. But I understand your ‑‑ I understand your need why would you like to have it, but unfortunately I am ‑‑ I don't know...
DAVID HAUSEER: Thanks very much. Do we have maybe Stavaros, do you want to comment on that, if you could take the floor?
.
STAVAROS KONSTANTARAS: Yes. Okay. I understand the point of Jan and, yeah, definitely we have enough Working Groups in the RIPE meeting, and indeed also by myself when I go to the RIPE meetings I have to skip a couple of Working Groups and select which one I want to attend. But to come back to the point is that one of the main aspects of SCION, in order to make it work, is that we need to assign ‑‑ we have some administration al work to do and we need to assign ISD numbers and somebody has to do the job, and currently, Anapaya is doing that, which is a profitable organisation, and definitely we don't want to continue doing that. Somebody who is a third‑party organisation, respected from every source and who is already allocating resources, has to do this task, and this is the RIPE NCC.
.
In that aspect, we need to also work on the procedures and work on the whole administrational part and the roles that govern this procedure, and this has to be done inside the Working Group in the context of the RIPE Working Group and RIPE meeting with the community as well. So, I believe ‑‑ I strongly believe that we should have a working group. Okay, maybe not from the next RIPE meeting, but definitely put it in the agenda to have it just to clarify the government's policy, how we are going to proceed with assignment of ISDs and AS numbers, because we are going to have organisations that want to join the SCION architecture in the near future, so we have to define the policies and the rules, and also new organisations will pop up in the future and they are going to ask for an ISD and an AS number.
DAVID HAUSEER: Sorry, Stavaros, to continue the discussion, I see that there are already a number of people who have asked also for the microphone. I guess that's related to that question. So, Caspar, do you want to take maybe Daniel Karrenberg? He has been also discussing with us exactly about this question, so I would like to hear from him.
CASPAR SCHUTIJSER: I would also like to hear from him but also Jan Zorz is maybe back in the queue.
DAVID HAUSEER: Maybe give him a chance to reply to that.
JAN ZORZ: Yeah. Thank you. Well one thought is maybe you can start by asking for the community for a task force with a really defined output and what you will produce is something like one or two years, and with that you can ‑‑ you get a sort of official place to meet and it will not be a working group. That's just a suggestion.
DAVID HAUSEER: Thanks for the suggestion. Yeah. Caspar?
CASPAR SCHUTIJSER: I will now give the floor to Daniel Karrenberg.
DANIEL KARRENBERG: Hi there. I can totally see the reservations that Jan has, and I have one additional one, is that there is a big danger for having a very specialised Working Group is that it only talks about themselves and doesn't engage with the rest of the ‑‑ the rest of RIPE; we had that too. Yet, I think this is ‑‑ there is a ‑‑ we should actually have a SCION Working Group to start with, because we haven't had really some ‑‑ how do you say it? ‑‑ turnover ‑‑ something new. My feeling is a little bit that we keep sort of rehashing the same things very often in RIPE and I think if there is a really credible sort of new routing architecture, I think it deserves its own Working Group. But we should watch it very, very carefully and see whether there is actually substantial work being done and whether it actually serves to inform the RIPE community that's not part of this SCION effort, about it. So, my ‑‑ to keep it very short ‑‑ my opinion is, let's try it and see what comes out of it. We can close a working group as easily as we start one. Thank you.
DAVID HAUSEER: Thanks very much, Daniel, for your supporting statement. Caspar, do we have, in the chat or in the video queue, additional statements to that question?
CASPAR SCHUTIJSER: We still have Rudiger Volk in there and I will give him the floor now.
DAVID HAUSEER: Rudiger Volk, you should be able to speak now.
CASPAR SCHUTIJSER: He dropped his line.
DAVID HAUSEER: Maybe we can take the next one.
CASPAR SCHUTIJSER: We can't hear you, Hans. I think you are still muted.
HANS PETTER HOLEN: I am out of the audio queue. You can hear me now? So, yeah, Hans Petter Holen, Managing Director of the RIPE NCC. I see in the chat that there are several dimensions to what you are proposing here. I think that you want some work done, so whether that's a task force or a working group, I'll leave it for you to sort out with the RIPE Chair and for the RIPE community to decide on. Of course the RIPE NCC will support that work as we support any other community work with mailing lists and so on. That is not a huge undertaking and I think if the community wants to do this work, then we will support and sort it at the same level as we support other work by the community. The moment you are talking about establishing a new registry as a permanent service for the RIPE NCC, it becomes a bit more complicated, not necessarily much, but then that's a new service that will have to be proposed normally in the Services Working Group and be incorporated in the activity plan and budget in case it requires substantial funding in terms of FTEs and other systems to support this. And, of course, that's a matter for the Services Working Group and eventually the GM and the Board.
.
So, luckily, we are starting the next version of the activity plan work in a couple of months, and that will be presented in the autumn meeting, so, if there is a drive in the community to have substantial support for this in 2022, you really need to work fast. But if you are thinking of getting this standardised in the IETF and then have something happening in '23, '24, then you have plenty of time to do that. That was just to give you the two pots here, to start to work with the community, that should not be problematic, but to get the new service up and running from the RIPE NCC, that may take a bit longer.
DAVID HAUSEER: Okay. Thank you, Hans Petter, for this pragmatic viewpoint from the side of the NCC. That's very helpful. We seed Rudiger back in the queue.
RUDIGER VOLK: Okay. So, hopefully you can hear me? I have two types of comment.
.
One is regarding Working Group organisation. I agree with the statement that we cannot have a huge number. On the other hand, I certainly would like to comment on the inclusion in routing that the Routing Working Group is a working group of BGP practitioners, and the SCION stuff would be something entirely different, and I don't think that will be a good thing to merge, at least for the next five years.
.
The other thing is that ‑‑ and that's maybe a little bit closer to what Hans Petter is looking at ‑‑ is the wish for having the NCC running a registry opens a lot of questions, meaning what is going to be in the registry and what are the exact requirements there? And I am missing in the presentations that we had today so far, and I don't remember any others, answering to the question: Well, what are the various functions and the ways of supporting these functions of the SCION registries? That come to mind would be the question: Well, okay, having a registry where someone is sitting and knows what unique numbers are distributed, obviously is not sufficient for running a registry. A registry is about making the information about the registered resources available, and in the SCION environment it seems to me that a lot more of information than just the Swiss National Bank and Swiss ‑‑ what's the name? ‑‑ where Simon is working ‑‑ Switch ‑‑ are the owners of number 70, or whatever, and obviously for doing the SCION thing, one would need to register a lot more of information, hence the end users will be given the complex choice of selecting their paths through the networks, will not be able to make reasonable decisions.
DAVID HAUSEER: Absolutely. Thanks very much, Rudiger. I'd also like to give, because we are almost ten minutes before the end of the session, to others the chance to comment on this. Caspar, do we have any related question in the Q&A part or shall we move on to the next discussion items? I heard also, before, Hans Petter mentioning about standardisation, so maybe we could also comment on that briefly, but, before that, are there any further statements regarding the Working Group itself?
CASPAR SCHUTIJSER: I think most aspects are already discussed, Yeah.
DAVID HAUSEER: Okay. Good. So maybe for the standardisation, it might be helpful now at this point, Adrian, if you want to briefly give just a quick summary of what we are planning in that direction to also give a bit more meat to that.
.
ADRIAN PERRIG: Right. Just briefly, we have been working for several years also and going through the existing avenues for standardisation. However, SCION touches on many aspects, including, of course, routing and the data plane and other aspects, that it became clear traditional venues for standardisation will take quite a long time, and since we have today already eight ISPs that actually use SCION in production uses, we would like to move a bit quicker initially, and so we are establishing a foundation to publish a first standard, but, in the meantime, also work with existing standardisation organisations to then go also to the traditional avenues for creating a full SCION standard. And so there are several things happening simultaneously, and again, it's a completely open process which is important, and enabling the community to participate, but also interact with existing entities. We have, for instance, at the last IETF, also submitted a standard proposal as well, and we will continue to do more of that in the future as well.
DAVID HAUSEER: Thanks very much, Adrian. Now, Caspar, do we have further questions that may be related to that that we could take now at this point in the chat?
CASPAR SCHUTIJSER: Let me have a look.
DAVID HAUSEER: Also take the next question in line.
CASPAR SCHUTIJSER: There is no one in the microphone queue at this moment. So... for instance, Sander Steffann asked: "I think this needs to get consensus in the IETF before RIPE should start creating Working Groups. Why is this not a chosen approach?"
.
But I think Adrian already went into that.
DAVID HAUSEER: If not, please, Sander, speak up again so we can discuss that in more detail. Please go ahead with the next in line.
CASPAR SCHUTIJSER: Yeah. I don't know if I see any more questions related to this topic. There is a number of questions about, well, ISDs and ASN numbers, but do we want to get to them right now or later?
DAVID HAUSEER: Why not? Please go ahead with these kind of questions as well. I see Franziska Lichtblau had asked for the microphone. I think that will also be a chance to give her the floor.
FRANZISKA LICHTBLAU: Thank you. Just before you close the topic, we had that discussion in the chat right now. You already said there are a bunch of ISPs already involved with SCION actually using that. Especially, there is a little bit with my PC hat on but mostly from a personal perspective, if we decide to give SCION a proper Working Group slot, this will impose a time restriction on every meeting attendee. So can you give us an idea for how many of our community members SCION is actually going to be something they will encounter, need to touch, need to know about within the, let's say, next twelve months?
DAVID HAUSEER: Thanks very much, Franziska. I don't know if, Sam or Adrian, you want to comment on the ISP question? Maybe you can mention a little bit more on whether the concrete ISPs we currently have or related answer to that.
ADRIAN PERRIG: Right. Currently, it's mostly ISPs in Switzerland, but now there is also a large ISP in South Korea, LG U+, and also we're in discussion with many additional ISPs who are interested also to connect, and so it's definitely the network is expanding, there are a lot of interested parties, and so we believe that the interest in the next twelve months hopefully will be more and more increasing as the system is working well and is providing quite desirable properties, and so we expect the interest to keep growing way beyond Switzerland, of course, and Europe.
DAVID HAUSEER: Franziska, does that answer your question? If not, please speak up again.
FRANZISKA LICHTBLAU: I think, within the reasonable limit of this discussion, yes, thank you.
DAVID HAUSEER: Okay. Thank you very much. So we have some five minutes left for some additional questions. So, Caspar, I would like to leave it to you to decide on the next question in line.
CASPAR SCHUTIJSER: Okay. So, Leo Vegoda from And Polus LLC asks: "What are the qualifying criteria to get an ISD number?"
DAVID HAUSEER: Okay, that's maybe a question for Sam. Sam, do you want to comment on that?
.
SAMUEL HITZ: Sorry. So, right now, basically there is ‑‑ that is exactly the thing we are discussing here. But there is no really not a qualifying criteria, right. As I said our current practice is to hand out ISD numbers per country so ween ever we have a new network, be it an ISD or an end user that wants to use SCION in a different jurisdiction, then we usually create a new ISD, and then of course there was the very legitimate request from our national bank to create this industry vertical ISD. But exactly what should be the rule that governance? Yes, you can get an ISD number and no cannot. That, I think, is something that would be very fitting to such a working group here. So, to answer your question, currently it's solely at Anapaya's leisure.
CASPAR SCHUTIJSER: There are two questions.
DAVID HAUSEER: Maybe there is time for two, three more questions before we would ‑‑
CASPAR SCHUTIJSER: There are a couple of questions about, well, the size of address spaces. So, for instance, for the ISD series, I believe 16 bits, some people think that perhaps you should be using extendable format for those numbers. What's your response to such questions?
DAVID HAUSEER: Maybe that's another one for Sam.
.
SAMUEL HITZ: Yeah. Essentially, you know, we started out with a smaller address space, even than the 16‑bit. Initially only 12 bits going to 16 because we believed that this would be plenty, 65,000 ISDs. There is, you know, inter‑ISD routing and beaconing, there are some scaleability limitations there, so this would not scale to millions or even billions of isolation domains. That's why we think the 65K should be plenty, especially if you think ‑‑ and this should, of course, also influence who can get an ISD number and who can not. But if you think about country‑specific ones or maybe regional‑specific ones and then maybe some bigger industry or NGO types of use cases, then I think 65K would get a long way. Should the future prove us wrong, then we would need to kind of do a version 2 of the protocol that has an extendible format.
DAVID HAUSEER: Thanks, Sam. Caspar, do you want to maybe take Marco's question as well, that's also a very interesting related one.
CASPAR SCHUTIJSER: He asks: "Will a SCION Internet remain interoperable with the real Internet as we know it? And a lot of us are making a living from and what is the commercial proposition that drives this?" That's the question from Marco.
DAVID HAUSEER: Adrian, do you want to take that one?
ADRIAN PERRIG: Right. So there are parts we're working on that enables hosts to communicate ‑‑ hosts in today's Internet enables them to communicate with hosts on the SCION network, but for the most part, the idea would be to provide SCION as an upgrade to today's Internet, so the infrastructures are working side by side, and one can use an approach similar to happy eyeballs to see if SCION is available or if IPv6 is available or IPv4, then pick among them the appropriate way to connect. And so, although there are ways to interact, we do believe the main advantages come when SCION is used end‑to‑end, or used as a back plane in a way to take regular Internet traffic towards the destination, then place it back on the Internet and achieving stronger properties on this back plane essentially.
.
I hope that answers...
DAVID HAUSEER: Thanks, Adrian. So, actually time is up, even though there have been just, as you were speaking, coming additional questions, but I think it's time now to wrap up. I would like to thank everyone for participating in this very lively discussion. I hope it was what you expected. Martina Damas has offered to open a room in SpacialChat where we can actually continue the discussion and take all the additional questions that came in and the ones that we haven't been able to answer now in this one‑hour slot. So, please do make use of that, the SpacialChat room is called SCION BoF, so you can use that to ask additional questions, and I guess some of the speakers and supporters will remain around to help answering those questions.
.
All the slides that we presented today will also be made available on the RIPE 82 website. The URL is indicated here. So with that, I would like to conclude this BoF session. It was a pleasure to host and Chair it, I hope you liked it, and we'll certainly keep discussing about this topic. Thank you very much, and have a nice evening.
.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
