Scion EPIC: a path-aware clean-slate internet architecture
blog.apnic.net
blog.apnic.net
- Path-aware Internet architectures and SCION in particular are not source-routing architectures. End hosts neither have/need a full view of the network topology, nor can they unilaterally choose paths. Instead, network operators explore and distribute candidate paths. End hosts get a set of such pre-selected paths from which they can then choose the one they want to use. This is one of the main points of the paper: How can autonomous systems in the Internet efficiently restrict the choices of end hosts. - SCION does not help with censorship. On the contrary: compared to the BGP/IP Internet, some power is shifted from network operators to end hosts. It is these end hosts, who can implement "geo-fencing" not the network operators. While these still retain a significant amount of control over paths (see above) it is easier for end hosts to circumvent networks that employ censorship. - One important point about SCION and other path-aware architectures is that the path control of end hosts is at an autonomous-system level. Thus, most problems with LSRR/SSRR are not present in SCION. For example: - End hosts cannot choose paths at a router level and thus not evade firewalls (unless they are very poorly deployed). - End hosts do not learn any information about the intra-domain topology, only about the inter-domain topology. This information can already be inferred today and is available in public datasets such as the CAIDA AS-relationship dataset [1] - There is a Tor-like anonymous-communication network designed to use with SCION: HORNET [2].
Of course, path control by itself cannot solve all problems. This is why SCION includes several additional innovations such as a public-key infrastructure (PKI) that does not depend on global trust anchors and single points of failure, a secure routing mechanism, highly efficient mechanisms for packet authentication, etc.
[1] https://www.caida.org/data/as-relationships/index.xml [2] https://netsec.ethz.ch/research/anonymity.php
The disadvantage to source routing is efficiency. Network operators have a better view of the network than sources, and will know how to route packets more efficiently. At the end of the day they’ll still have route tables and send the packets on the path they want, defeating the purpose of having the source specify a path.
A kind of source routing has interesting applications in P2P routing. Yggdrasil uses a spanning tree to assign every node a location, so that peers can determine efficient paths upfront. https://yggdrasil-network.github.io/
If a source had information on available paths, and was able to select the path taken, it could measure and estimate congestion and latency and pick the best paths.
As far as I know, most BGP routers are using least AS hops as the primary metric. Latency, link capacity, and utilization aren't generally considered.
o Bypass firewall rules.
o Reach otherwise unreachable internet systems.
o Establish TCP connections in a stealthy way.
o Learn about the topology of a network.
o Perform bandwidth-exhaustion attacks.
Routers, security gateways, and firewalls SHOULD implement an option-
specific configuration knob to select whether packets with this
option are dropped, packets with this IP option are forwarded as if
they did not contain this IP option, or packets with this option are
processed and forwarded as per [RFC0791]. The default setting for
this knob SHOULD be "drop", and the default setting MUST be
documented.
the value proposition here targets operators not end-users. if you look at it from an operator pov there are many advantages:
1) geo-fencing service for enterprise customers (think public sector, or ICS, which may have a strong need to guarantee a packet never leaves a jurisdiction)
2) "transparency" in the data plane while isolating the control plane.
I'm not convinced about this being better for security. let me rephrase, I doubt that it will eliminate/mitigate more security issues than it will create on its own. apart from the superior-security sales angle it will further lead to a "balkanization of the Internet".
This technology is extremely political and so there is little surprise it has momentum now when the focus is on isolating ourselves. See 1 Above - this value proposition isn't just great for off-shore banks, but also for countries who want less exposure to traffic from other countries (for whatever reason! think copyright laws, political sanctions, incompatible "human rights", or content-control e.g. social / free-speech / whatever values our own overlords might disagree with). SCION allows fine grained control over what to impose on who and helps with censorship since not everyone will be affected, it allows micro sanctions on anyone they disagree with and it will be harder for them to say it's happening because only they experience it. Think of it as a great-firewall-lite without all the political stigma and dressed up in the language of "security".
> This technology is extremely political
Imagine if this were augmented with onion routing capabilities, like Tor. Each address in the path would be encrypted such that only the immediately preceding router can read it. That way, if an attacker intercepts a packet in transit, they can only determine the next hop address, not the final destination.
Yes, yes, this would add a massive amount of overhead and complexity, and it would probably take decades to get implemented.
But I've been wondering what the next step is after encrypted DNS. Encrypted DNS prevents an attacker from knowing which domain name you're connecting to, but they can still see the IP address, and if there's only one site hosted at a given address, that's all they need. So to achieve privacy you need many unrelated sites to be hosted at the same IP, i.e. you need a big CDN. But that risks overcentralization, and it means you have to trust the CDN. What if there was a way to hide the IP address itself?
Clacks just randomly sends stuff between peers, it's up to the peers to decide if it's relevant or not. With encryption and payload size obfuscation there would be no way to know which node is directing communications with another node.
Anyway, obviously the drawback is performance. It might take a while for all your packets to reconvene on the intended target.
I think it could work, but only for niche uses or low threat models.
That was the main motivation for TOR (the onion router) but I guess you are asking for a solution at a lower network layer.
In addition to the basic routing issues, source routing presents DDoS and 2-way spoofing attack vectors. You can spoof a 2-way conversation because destinations will take the reverse of the packet’s route. Eddie pretends to be Bob talking to Alice and crafts a path so that Alice returns communication to Eddie, thinking she’s talking to Bob. This is a major security vulnerability with source routing, which requires the use of encryption to prevent.
And exactly this tradeoff is examined in the blog post (and their EPIC paper).
IPNS offers something useful, but the kinds of routing we need for the "web" as we know it vs content/file sharing are different. Browsing the web through IPFS or something similar is a bit nightmarish.
If you're knowledgeable on this, I would love to pick your brain a little - my email is s@slm.space.