NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
Scion EPIC: a path-aware clean-slate internet architecture (blog.apnic.net)
mlegner 1197 days ago [-]
He everyone! I'm Markus, the author of this blog post and the related USENIX paper. It's great to see the interest in this line of research. I would like to address some of the points brought up in the comments and provide additional information:

- 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

alexmingoia 1198 days ago [-]
This is known as source routing: https://en.m.wikipedia.org/wiki/Source_routing

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/

DyslexicAtheist 1197 days ago [-]
> Network operators have a better view of the network than sources, and will know how to route packets more efficiently.

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".

samoa42 1197 days ago [-]
well said, especially

> This technology is extremely political

toast0 1198 days ago [-]
Network operators have a different view of the network than sources, and of course, they have real time information about the next hop, but that doesn't mean all of their information is better.

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.

pdkl95 1198 days ago [-]
Source routing also gives malicious hosts the ability to influence packet routing. IPv4 already tried this with the LSRR/SSRR[1] options. The LSRR option was useful to malicious hosts for many purposes, such as[2]:

   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.
Due to these "well-known security implications"[2], RFC 7126 recommends[3]:

    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.
[1] "{Loose/Strict} Source and Record Route" http://www.networksorcery.com/enp/protocol/ip/option003.htm

[2] https://tools.ietf.org/html/rfc7126#section-4.3.3

[3] https://tools.ietf.org/html/rfc7126#section-4.3.5

donavanm 1198 days ago [-]
I can’t qualify “most”, but it’s certainly not as-path only. I’d be shocked if any significant network wasn’t using MED and local-preference. Your large networks (and NSPs and carriers) are also going to support various communities for all sorts of reasons, like redistribution of routes. The days of path pretending, deaggregation, and crossing fingers are quite a ways behind us.
comex 1198 days ago [-]
So the end host calculates the entire path in advance, and embeds it in the packet…

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?

parksy 1197 days ago [-]
I took a shotgun approach to it with clacks-p2p. I thought, any directed attempt to send data from A to B is going to leave traces of a path. With enough command of the network you'll be able to figure out from various side-channels who is communicating with whom.

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.

labawi 1197 days ago [-]
It seems to me, you still have to compromise between having a relatively small number of participants, very high and expensive overhead/throughput and sharing your network with potential attackers, which could observe the network by observing how their own data travels.

I think it could work, but only for niche uses or low threat models.

red0point 1197 days ago [-]
Their research group actually went down a similar road, and explored a possible design of an anoymous communication network on top of SCION, called HORNET - check this out:

https://netsec.ethz.ch/research/anonymity.php

hollerith 1197 days ago [-]
>What if there was a way to hide the IP address itself?

That was the main motivation for TOR (the onion router) but I guess you are asking for a solution at a lower network layer.

api 1198 days ago [-]
So they are reinventing source routing? There’s a reason we don’t use source routing.
aftbit 1198 days ago [-]
Could you elaborate please?
alexmingoia 1198 days ago [-]
Each node on the network does not have a complete map of the network, so cannot determine the shortest path. And if the shortest path is chosen by everyone it will become congested. This is essentially the main problem with all Internet routing. Because of this, network operators share information about the path taken by packets they route, and which packets they want to receive to control congestion. When they receive a packet they use this information to determine a best next destination. Since all sources on the Internet cannot practically share this information, source routing is at a disadvantage. And attempts to discover short or fast paths result in added network traffic contributing to congestion.

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.

red0point 1197 days ago [-]
As addressed by the author, Dr. Markus Legner, these points are not true for SCION, as it is a path-aware routing system. Especially the paths cannot be spoofed, as their MAC is checked at each router hop (an extremely efficient operation, much faster and energy efficient than big router table lookups).

And exactly this tradeoff is examined in the blog post (and their EPIC paper).

ilaksh 1198 days ago [-]
To me the interesting internet architecture research is content-centric.
sebmellen 1198 days ago [-]
DHT routing as seen with IPFS and DAT is certainly the future of content distribution, imo. It remains to be seen if this content based model can also work for websites, though.

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.

ilaksh 1198 days ago [-]
Those are a lot of the major ones, but really its been a popular field of research in academia for at least a decade. So there are quite a lot of papers and even careers and even some standards groups that have been working on different types of content-oriented networking for quite some time. So its not just the most popular ones.
sebmellen 1198 days ago [-]
Are you talking about efforts like PARC's CCNx?
ilaksh 1197 days ago [-]
Right. Or now NDN. Plus some other similar ideas.
sebmellen 1197 days ago [-]
Fascinating. I just started a project called the Interplanetary Publication Protocol (very incomplete site at https://interplanetary.pub) and am looking at all possibilities for content-based networking/data retrieval.

If you're knowledgeable on this, I would love to pick your brain a little - my email is s@slm.space.

ajb 1197 days ago [-]
Interesting, but the secure lifespan of crypto primitives seems too short to build into packet routing.
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 20:39:10 GMT+0000 (Coordinated Universal Time) with Vercel.