Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

> Cloudflare.NetworkEngineer

Ah, that explains a lot. Not that anyone else couldn't do such a thing, but I feel like even amongst more "hacker" types it takes a relatively specialized background to pull a trick like this (at least statistically; I'm sure there are outliers).

View on HN

It’s because practical experience with technologies like BGP is difficult to acquire without sufficient capital to run a network. You can of course purchase a /24 and dabble (search HN for blog posts describing exactly that). And you can experiment with large deployments in simulators. But network optimization is inherently more of a practical pursuit than a theoretical one, so most broad and consistent learning opportunities are siloed to large organizations where you can accrue daily experience with the stack.

This is really unfortunate, and I mostly blame Cisco and Juniper. They suffocated an entire academic discipline with obfuscated terminology driven more by their business models than anything resembling the OSI model or open standards. That’s why WireGuard feels like such a breath of fresh air after 20 years of L2TP/IPSec.

I applaud companies like Cloudflare and Fly.io for their openness in sharing techniques and open sourcing so much of their code. It goes a long way toward lowering the barriers to self-teaching and experimenting with the latest networking software. And I’m sure HR is happy about the increasingly large applicant pool of qualified networking engineers – even if some hires do eventually leave by advertising their resume to anyone who sends them an IPv6 trace-route :)

44Net and hamnet are also interesting to those with radio amateur licenses. Many folks run their own AS an BGP in that range.

You can contribute to the Solana core tech team, with the incentive alignment of underlying token value as a partial backer!

I think they're doing some really cool stuff on the network optimization level. As an example, Solana recently implemented QUIC in its latest release: https://github.com/solana-labs/solana/projects/74

Are they still using that hand-wavy "cryptographic proof that a duration of time has passed"?

Do you mean Proof of History? The concept is made concrete in Solana, but actually any blockchain that hashes a set of transactions in each of its successive slots/blocks can be used to prove that time has passed.

You can verifiably be assured of a temporal ordering between transactions that were hashed in different slots because the output of a slot/block is hashed and used as an input for the next block/slot.

Solana claims to prove that a certain duration of time has passed, which is a different and much stronger claim than just temporal ordering. The details of their claims, last I heard (which was some talks in Berlin years ago) were extremely hand-wavy and apparently not well understood even by some people working on the project.

What we care about is getting all the nodes to agree on what order the transactions occurred (aka "Proof of History"). And Solana's goal is to reach that agreement quickly, that's why they call themselves the most performant blockchain.

So how does Solana introduce a concept of "time" without relying on a central authority?

Solana uses a "hash that runs over itself continuously with the previous output used as the next input". Performing a hash over and over again takes some time. Then, someone can quickly verify that this "time" has occurred. The verification of the hashes can be parallelized on a GPU, which makes the verification extremely quick.

https://medium.com/solana-labs/proof-of-history-a-clock-for-...

> search HN for blog posts describing exactly that

Know any offhand? Search is a bit tough for a common number like 24. The concept sounds interesting

Oh wow you’re right - and neither “autonomous system” nor “AS” are much better keywords! I think this post from 2017 [0] is the one I’m remembering, but I’m pretty sure I saw another one more recently and now I can’t find it (edit: skitter found it! see sibling comment)

“BGP” is a signal-yielding search [1]. And any post from benjojo’s blog [2] is always a must-read.

[0] https://news.ycombinator.com/item?id=15727115

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[2] https://news.ycombinator.com/from?site=benjojo.co.uk

Thanks!

A quick search turned up https://news.ycombinator.com/item?id=30178655

it's ipv6 so a /120 would do!

You can easily obtain a /44 and your own ASN as an individual, through various RIPE LIRs, no questions asked. If you're in the US, you'll have to procure an overseas VPS so you have a European presence.

Yesterday i was watching LSD documentary (https://www.netflix.com/title/80229847). They briefly stated that LSD usage in California was very likely to have accelerated invention of computers. It helped people with problem solving.

How is that relevant?

Fun Fact ; I'm not sure if it was RIP or BGP, but a certain Cisco Founder stated that they wouldnt have come up with the routing protocol if it weren't for Hoffman and LSD.

Would love to read more about this.

I really have no idea what any of those acronyms mean.

The drug

RIP = Routing Information Protocol BGP = Border Gateway Protocol LSD = Lysergic Acid Diethylamide

I think consolidation has also lead to this knowledge/experience, at least among younger engineers, being siloed in larger companies rather than spread out among many smaller companies. I started in the industry when the Internet was still relatively new, and at that time most companies I worked with had their own ASN & address space and were running BGP, whereas nowadays most companies just use the cloud.

This is a very old and oft-repeated trick though.

https://github.com/blechschmidt/fakeroute

https://github.com/antifork/hopfake

https://github.com/jprenken/rickroute

https://github.com/sams-gleb/ipv4-traceroute-fake

https://github.com/job/ipv6-traceroute-faker

And so on…

I remember being a 13yo kid sitting on IRC doing exactly this for fun years ago back when IP addresses were cheap and easy to come by. But spoofing military IPs in the traceroute was more fun.

Believe it or not, you might have very specific interests :)

If a 13 year old was using irc regularly in 2022 I would be concerned for them. Not thata 13 year old shouldn't use irc but I would wonder how they found that destination, especially given the countless other sinks for internet denizens

I'm curious why you would be concerned. I've seen a good number of teenagers hanging around and playing with computers.

Free software development and chat still largely happens over IRC: witness irc.gnome.org and libera chat.

As a 13 year old, if I had access to internet instead of buying Slackware floppies from local software "pirates" (they also had all the DOS stuff like Wordperfect and games), I'd probably be hanging around IRC.

I don't think there was much to be concerned about me back then.

Thanks for sharing these links.

Fakeroute was the funniest thing in the world back then. Thank you.

How would you spoof arbitrary IPs? IIUC it's poked at as the next hop...?

(Mhm, embarrassingly out of the loop)

I _think_ that if you know the real source and real destination of an ICMP message, you can just forge back a message with an arbitrary TTL exceeded message, from any "I'm IP address xxx" address. Those can come from a lot of rando IPs because the intent of them is just "at this hop, the TTL ran out", and the hops the original sender wouldn't know anyway. A lot of fake hops would be essentially impossible if you examined the real BGP routes and stuff, but verifying that in real time sounds hard enough that I bet nobody bothers.

I'd have to do a lot more research and testing to verify though, not something I've played with in practice, and obviously my terminology isn't even right above, so take it for what it's worth.

If you return fake IPs in a traceroute you won't be able to control the reverse DNS which is the point of this exercise.

I understood this current thread to be another, separate, stupid ICMP trick. I wouldn't think the two tricks can be combined.

You can however control the IPs, so you can pick IPs with funny nsa.gov/.mil/fbi rdns (and matching forward records).

Not sure how he did it, but my first guess would be just a bunch of virtual interfaces on a linux box with a->b->c->d->e->etc routing, and something like the tc command[1] to add enough latency to each one that traceroute sees them all.

If he's scripted it to do all the virtual nic creation and dns ptr entries, it would be interesting to see.

[1] https://bencane.com/2012/07/16/tc-adding-simulated-network-l...

traceroute(1) uses the IP Time-To-Live (TTL) field, not network latency. So just a bunch of virtual interfaces on a suitable *nix should be enough.

Ah, right, hop count ceiling and decrement from each hop.

Specifically timed latency might be fun to delineate sections for the viewer though.

Virtual interfaces aren't necessary, and would be overkill. All he needs on his server is to listen on a raw network socket, read the incoming packet's IP TTL value, then forge and send an ICMP "time exceeded" response with the source IP address set to a value that depends on the TTL. The entire thing could be done in 20-30 lines of Python.

Next to that he set up a DNS server configured with PTR records that map these forged IP addresses to arbitrary hostnames of his choices.

Sure, another way to do it, though the python would have to get the peer address, extract 64 bits of the incoming msg, table lookups of hop count -> forged address, decrement hop counts, etc. A shell script creating virtual interfaces and routing wouldn't likely be much longer than 20-30 lines either.

There is no need to do "table lookups of hop count" or to "decrement hop counts". The IP TTL value is just a field that can be read from the IP header, which is trivial since the Python would get the entire IP header from the raw socket. If you see a TTL=1 you send back the forged response as coming from $IP_1, if you see a TTL=2 you forge the response as coming from $IP_2, etc. The forged response can always contain the same default TTL.

> table lookups of hop count -> forged address

>> There is no need to do "table lookups of hop count"

>> If you see a TTL=1 you send back the forged response as coming from $IP_1, if you see a TTL=2 you forge the response as coming from $IP_2

You're describing a table lookup of the forged address using the hop count.

Right, I understand you now.

For maximum 'performance' you can do it in-kernel with eBPF :^) https://github.com/simmsb/traceroute-spoof

Feels like we’re a dying bread with everything cloud first and serverless.

Dying breed? Though dying bread sounds like an interesting metaphor.

Eh, smaller slice of a bigger pie. Somebody has to make "the cloud" work so that everybody else doesn't have to worry about the underlying bits as much.

There are always nerdy kids learning this stuff.

Especially when the breed has "died"

Ah so this is how "the next best thing since sliced bread"s die :'(

Reply on news.ycombinator.com