Although the FAQ claims "Guaranteed communication despite DDoS attacks", it offers no further details on how this is supposedly achieved. After some looking, I found [0], which appears to be what they're doing. It has some good points, though I think there are some significant implementation challenges to be addressed before it would actually work for much of the real world internet. Unfortunately - and as is sadly all too common these days - the website is utterly devoid of any useful information and I don't have the time to read 50k lines of code to try to understand how it works in practice.
I note that a bunch of their running instances appear to just be AWS instances presumably set up for testing/marketing purposes - has anyone here actually tried to use this? Thoughts?
The next section "2.4.1 High-Availability Communication": In addition, the SIBRA extension, as described in Chapter 11, offers an extended level of availability through a concept we call DILL, which stands for dynamic inter-domain leased line. DILLs provide a lower bound on the guaranteed bandwidth at inter-domain scale, regardless of the bandwidth requirements of other ASes.
I wouldn't expect low-level info like this in an FAQ. Maybe the "SCION Book" listed at the top of "Publications" that goes into it on a higher level than what the paper does. If not there is a huge number of other links to papers and videos that I'd expect covers it in detail.
I probably missed something crucial here, but ... My worry about path selection despite all its theoretical potential is that it's still left to the ISP how they sell this feature to the user (and whether that promised potential materializes for the user as envisioned in the docs today). If an ISP decides which paths are allowed they might give only a subset of what they could offer to the customer, and that would not be in the spirit of "empowering the user". A "malicious" ISP could just box their users into a specific subset of the available routing paths. Or once SCION is adopted widely a country could outlaw certain paths being selected - e.g. routing could be enforced not just to protect but also to allow stricter enforcement of rules in all type of scenarios (e.g. ban communication both with or via specific paths in a trade/cyber/kinetic war, etc).
> I wouldn't expect low-level info like this in an FAQ. Maybe the "SCION Book" listed at the top of "Publications" that goes into it on a higher level than what the paper does. If not there is a huge number of other links to papers and videos that I'd expect covers it in detail.
I mean... maybe? But this is quite a big claim and just saying "yep, it does" with no further info is not a communications strategy that inspires confidence. I had to look about the site for a fair bit before I found the correct whitepaper, and I never managed to find the book until another poster linked it.
> Through authenticating sources and validating paths, the OPT can construct high-level security mechanisms such as DDoS mitigation, path compliance and packet attribution.This is because that the source authentication guarantees the identity of source and the path validation eliminates the illegal use of path by attackers.
I found mention of "Dynamically Recreatable Key (DRKey) protocol" interesting, which it I guess they designed for this (because it only gets mentioned in papers talking about SCION). I'm curious to know how well understood this protocol is within the wider crypto community. DRkey is also explained in this video (https://video.ethz.ch/events/2019/scion/2eff3fa5-6c42-4b28-8...) at the >2 min mark.
At page 14 of the pdf they go on to listing the benefits of each architecture (where SCION seems to be a clear winner):
> We have presented five famous future Internet architectures in details: NDN, COAST, MobilityFirst, XIA and SCION. In this section, we present the pros and cons of each and further compare them in terms of a number of security properties: anonymity, authenticity, integrity, privacy, DoS/DDoS resistance, error/fault resilience, and evolvability.
> Furthermore, the integration of the SCION with the XIA achieves a higher security than the above three architectures, including accountability, anonymity and availability. In order to maintain trust relationships, each entity should hold a secure identifier besides the changeable and various XIDs. Otherwise, an adversary can register into the network with a new identifier that may eliminate its ever-bad records, which results in inaccurate trust evaluation. With greater efforts on security research, the SCION presents more security properties than other four projects, e.g., resisting DDoS attacks, anonymity, authentication, etc. Trust management is mentioned in the NDN, the COAST, and the MobilityFirst as a key technical challenge. But none of them gives a concrete method to manage trust. The SCION presents a detailed discussion on trust management. It adopts the notions of ISDs and TRC to control trust efficiently, which can dominate its own trust and limit the influence of compromised trust root within its own ISD.
Basically all of what you are saying could happen, is already possible today. You have no control over the routing of a packet once it leaves your network.
I'm skeptical that would be adopted by the big organizations. Just this week, I sat on a call with Google's engineers to talk about how they plan to solve some of these issues. [1]
I note that a bunch of their running instances appear to just be AWS instances presumably set up for testing/marketing purposes - has anyone here actually tried to use this? Thoughts?
0: https://www.scion-architecture.net/pdf/2016-SIBRA.pdf