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

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 :)

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.

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

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.

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

Would love to read more about this.

> 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?

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

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

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.

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

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.

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

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.

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

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

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

Thanks for sharing these links.

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

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.

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

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.

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.

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

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.

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

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 :'(

I think that many HRs would be suspicious about somebody who worked at each job for 2.261 ms.

It is not length of experience that counts, but skill. Some people with 100ms experience have just done the same millisecond over and over.

It's contracting work, so the short duration makes sense!

2.261ms, aka a billable hour!

You've earned yourself a promotion.

He must have added Apple at some point. Here's what I got (using mtr):

    19. hello                                                   0.0%    14  141.6 140.5 139.1 141.6   0.7
    20. my.name.is.louis.poinsignon                             0.0%    14  141.9 142.1 141.2 143.3   0.5
    21. i.am.a.network.and.systems.engineer                     0.0%    14  140.5 140.4 139.7 141.6   0.5
    22. this.is.my.resume.over.traceroute                       0.0%    14  140.5 140.4 140.0 141.5   0.5
    23. o---experience---o                                      0.0%    14  139.9 140.4 139.4 141.4   0.5
    24. 2021.apple.engineer.sf.usa                              0.0%    14  140.7 140.5 139.8 141.2   0.4
    25. 2018.cloudflare.engineer.sf.usa                         0.0%    14  140.8 140.4 139.4 142.8   0.9
    26. 2017.cloudflare.engineer.london.uk                      0.0%    13  142.2 142.6 141.4 147.5   1.5
    27. 2016.cloudflare.engineer.intern.sf.usa                  0.0%    13  149.7 141.2 139.1 149.7   2.7
    28. o---education---o                                       0.0%    13  142.1 142.1 141.3 144.1   0.7
    29. 2015-2016.drexeluni.exchange.ce.philadelphia.usa        0.0%    13  140.9 140.3 139.5 141.3   0.5
    30. 2011-2016.utt.master.ce.france                          0.0%    13  143.1 142.3 140.8 143.3   0.7
    31. o---skills---o                                          0.0%    13  140.3 140.9 139.7 146.0   1.6
    32. golang.c.python                                         0.0%    13  142.2 142.4 141.1 146.0   1.2
    33. networks.linux.automation.kafka.clickhouse.kubernetes   0.0%    13  139.6 140.5 139.3 142.2   0.8
    34. statistics.maths                                        0.0%    13  141.6 142.1 141.2 142.8   0.5
    35. o---various---o                                         0.0%    13  141.8 142.4 141.8 144.8   0.8
    36. swimming.karate.piano                                   0.0%    13  139.8 141.4 138.7 155.2   4.2
    37. o---contact---o                                         0.0%    13  140.1 140.3 138.6 141.7   0.8
    38. mail.jobs.at.poinsignon.org                             0.0%    13  141.1 142.5 141.1 145.4   1.1
    39. cv6.poinsignon.org                                      0.0%    13  139.4 140.3 139.4 141.2   0.5

Remember when they said we'd never run out of IPV6 addresses?

Good times.

Will age just like the famous quotes about 640K of memory is enough.

they never anticipated the internet of internet of things. What a shame.

speaking as a software developer who has generally forgotten what little i know of routing, that is really cool

i love how the low bits of the addresses in hex are cognates for both the section and the actual content of the name/line.

also, looking glasses... jeez. i haven't heard or thought of those in _years_.

Why have you traceroute ip instead of domain?

> Host mail.jobs.at.poinsignon.org not found: 3(NXDOMAIN)

(A bit of a missed opportunity; the author should really set a AAAA record there IMHO)

There's no actual requirement that your PTR records resolve back to the same IP. Historically very little software bothered to check, and most of the Unix-y diagnostic software has never been updated to do so...

> Historically very little software bothered to check

For some reason, most IRC servers tend to do this.

Unless you send email.

you could have multiple IPs attached to a domain which could mess up this trick.

I also wonder why not use use the domain, much easier.

Bad copy/paste

So is that mail.jobs@ or mail+jobs@... or jobs@

A total flop on the last line

I bet if he can do this trace route thing, he can get all those emails going to his own domain regardless of who they are addressed to

I would presume a better way would be to not make people feel unsure of what it is, and just pick something thats super clear.

Or it's a filter. No need to send anything if you are unsure.

I didn't realize that arbitrary interpretation of vague text was a criteria for a great employer

Not really. From the lines above one can deduce that the dot represents space or colon, for obvious technical reasons. As such, I'd interpret

  mail.jobs.at.poinsignon.org

as

  mail: [email protected]

I still think it's mail.jobs@ - so I'd hope the engineer set up collection on both addresses.

It'd probably be a lot safer to just have the line be "jobs.at.[...]"

Edited to add: Oh also - from the same line you can infer that a dot means a dot - the ".org" at the end confuses the meaning. Perhaps it'd be clearer if they went 100% slashdot and had ".DOT.org"

Yes really, you can see even in the other replies the interpretations are not 100% clear.

It took me a minute to realize it wasnt some form of "mail+jobs" or "mail.jobs". It wasnt until I wrote the last line of my comment that it was "mail jobs@"

My interpretation was mail: [email protected]

My interpretation would be [email protected], given that it's become the de facto standard, and [email protected] looks like his main one.

I'm not sure it can be a de facto standard with the number of sites that flatly refuse to recognize + as a valid character in email addresses. There's so many that I gave up and started just using . instead.

Really, you're arguing about the email in a traceroute CV being somewhat ambiguous? Having to traceroute the thing is going to be a much bigger filter. And it's quite clear if you just read it out as spoken text and then try to get the address from that. Really, anyone actually interested in contacting the guy will manage just fine.

An extremely mediochre attitude. You must simply believe that things shouldn't be the best they can be, but rather things that are easily fixable for clarity should just be accepted. Typical garbage in garbage out.

You can see there is more than a few replies of people who are confused about the email.

"Ah yes, here is a thing thats a big filter, so let me make the email yet another filter but instead of just (EASILY) fixing it I will just use that as an excuse to leave it"

How about... (huge surprise here......... wait for it)....... one just makes it better, such as:

jobs.AT.domain.DOT.com

I quite honestly cannot even understand the mental processes some people here go through. It's so clear, yet you're also not the first arguing for a retarded justification instead of just "fix it by making it less ambiguous" which is the ONLY correct answer. That is... unless you don't care about getting emails to your resume.

Oh noes you just doxxed their email address on the https

It's probably more accurate to "Oh noes this HN post is going to get this guy a few dozen really lucrative job offers".

Doxxing usually implies ill intent but having your personal information broadcast to HN is likely only to result in a few of the hiring managers that haunt here sending a cold offer.

Yes I thought so, as in you're quoted thing was exactly what I meant, sarcasm doesn't serialise well

I don't think writing obfuscated email address as plaintext is doxxing, but it may be collected spam bot.