[HN Gopher] Curious case of Martian traffic in Linux
___________________________________________________________________
Curious case of Martian traffic in Linux
Author : pavel_odintsov
Score : 42 points
Date : 2023-05-09 16:24 UTC (6 hours ago)
(HTM) web link (pavel.network)
(TXT) w3m dump (pavel.network)
| jimmaswell wrote:
| Why would the external device use this ip in the first place?
| schoen wrote:
| It's not correct that the modern Linux kernel refuses to forward
| packets with a source address in 0.0.0.0/8. The only address that
| it refuses to forward this way is 0.0.0.0/32.
|
| I just got a patch into the ip(7) man page that describes this
|
| https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/...
|
| although there hasn't been a man-pages release since then, so you
| probably can't see this on your own system yet.
|
| The original change (included in Linux 5.3) is
|
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
|
| (I'm working on a project that aims to make these addresses
| potentially useful for numbering Internet hosts in the future, as
| part of which Dave Taht's patch linked above was written, so I
| follow this very closely!)
|
| Separately, you need to be able to process a 0.0.0.0/32 source
| address on external interfaces (though not to forward it) in
| order to be able to implement a DHCP server, as that's the source
| address used by DHCP clients. (edit: another commenter pointed
| out that this commonly uses raw sockets so it doesn't necessarily
| require any explicit kernel support)
| bombcar wrote:
| Is there any similar work to change 127/8 to be something more
| reasonable like 127/16 or 24?
| schoen wrote:
| We have proposed it!
|
| https://www.ietf.org/archive/id/draft-schoen-intarea-
| unicast...
|
| The big prize is 240/4.
|
| https://www.ietf.org/archive/id/draft-schoen-intarea-
| unicast...
|
| Our proposals have not been warmly received in the intarea WG
| so far.
| jacquesm wrote:
| I think it is pretty reasonable to be reluctant to make
| such changes because it may well break stuff.
| schoen wrote:
| Well, for 240/4 in particular we (in a very expansive
| sense of "we"1) started making the change back in 2008 in
| response to
|
| https://datatracker.ietf.org/doc/pdf/draft-
| fuller-240space-0...
|
| If we (for an expansive sense of "we") had kept it up
| more actively, we would already have had 15 years of
| progress on updating implementations and evolving
| people's expectations. That wouldn't have been a super-
| fast change, necessarily.
|
| We (for a narrow sense of "we") think it's pretty likely
| that people will still be interested in having more IPv4
| space in 15 years from now, so it's too bad that progress
| is (somewhat) stalled on this (with most Unix-like
| systems allowing it, and Windows not allowing it, and
| dedicated routers from before about 2013-2016 often not
| allowing it).
|
| 1 the specific project I'm working on, started by John
| Gilmore, didn't exist yet at that time, but is trying to
| revive/continue this idea
| jacquesm wrote:
| Fair enough, but that more or less emphasizes my point:
| if it wasn't done by 2010 or so that means that a ton of
| IoT hardware has now shipped that may never see updates
| and that would possibly end up failing when presented
| with such a departure from what the expected behavior was
| at the time the hardware was shipped. You change old
| established standards at your peril, especially how IPV4
| is routed and which ranges are reserved. There are quite
| a few things that retrospectively could have been handled
| better and a large number of huge ranges got handed out
| like candy back in the day. Some of those have been
| reclaimed and some still remain. It may be easier and
| with less chance of breaking stuff if those ranges were
| reclaimed more aggressively.
| bombcar wrote:
| It would be amusing if a moderately breaking change to
| IPv4 is what finally causes all the old equipment to be
| finally dumpstered and IPv6 to reign supreme.
| usovalx wrote:
| May dhcp client/servers are using raw sockets and will thus
| bypass incorrect firewall config/martian packet filtering.
| schoen wrote:
| Yes, I forgot about that but you're right that that's the
| typical implementation method.
|
| So the DHCP case does not necessarily need any special kernel
| support (other than not prefiltering before the raw socket).
|
| Thanks for the correction.
| Robotbeat wrote:
| I thought this was about actual interplanetary networking. Can we
| change the title to be less clickbait and more informative?
| knome wrote:
| https://en.wikipedia.org/wiki/Martian_packet
|
| A quick usenet search shows references to the term back into
| the 90's.
| kamray23 wrote:
| The RFC which defines the term is from 1995, so it's been
| established enough to find its way into an RFC 28 years ago.
| 0xcde4c3db wrote:
| I don't think I've ever seen the specific form "Martian
| traffic", but "packet from Mars" or "Martian packet" is an
| established idiom for packets arriving on "impossible"
| interfaces (e.g. a packet from 192.168.x.x arriving on a
| publicly routed interface).
| LambdaComplex wrote:
| Martian traffic is a common term among network engineers (or at
| least among the ones who work at/with ISPs):
| https://en.wikipedia.org/wiki/Martian_packet
| denton-scratch wrote:
| Yeah, but I think that WP page is wrong.
|
| It relies on the page Reserved_IP_addresses, implying that a
| martian is a packet with a source address within certain
| ranges. In fact a martian is a packet with a source address
| for which the receiving interface isn't configured; any
| address could be a martian, depending on how the interface is
| set up.
|
| Hey, if I'm wrong, please set me straight.
| benou wrote:
| Looking at RFC1812, Martian packets [1] seems to be
| reserved addresses only.
|
| What you're talking about is referred to as source address
| validation [2] also known as strict reverse path forwarding
| (RPF) [3].
|
| [1]
| https://datatracker.ietf.org/doc/html/rfc1812#section-5.3.7
|
| [2]
| https://datatracker.ietf.org/doc/html/rfc1812#section-5.3.8
|
| [3]
| https://datatracker.ietf.org/doc/html/rfc3704#section-2.2
| gumby wrote:
| "martian" isn't an official term from the RFCs, and is terrible
| usage. If linux is not running on mars at the moment (perhaps in
| the Chinese rover?) it surely will be in the not too distant
| future. And a router in orbit may need to distinguish between
| martian and terrestrial traffic.
|
| Which the code can easily do of course, but a foolish name like
| this could confuse someone debugging code during development, or
| worse while debugging a communication problem in process far
| away.
|
| (BTW this is an earnest, not humorous comment).
| kamray23 wrote:
| Martian is an official term from the RFC's, though? It's
| mentioned in section 5.3.7 of RFC 1812 from 1995. That happens
| to be the exact section of the exact RFC with the
| recommendation whose kernel implementation is shown in the
| article. It seems to be fairly established terminology, having
| sat in that RFC for the last 28 years.
| gumby wrote:
| Thanks! It wasn't in the ones I looked at.
|
| Darn, it's still a short-sighted choice. Even "interstellar"
| would be good for another 75 years or so (
| https://i4is.org/what-we-do/technical/project-dragonfly/ ),
| though "intergalactic" would be better, even if ipv6 were
| used.
| denton-scratch wrote:
| A martian is a packet that has a source address in a network for
| which the interface it's arriving on isn't configured. They're
| not restricted to 0/8; they can have just about any source
| address.
|
| > The best way to fix this issue is to change Netflow / IPFIX /
| sFlow agent configuration on device to use another legitimate IP
| address instead of 0.0.0.0.
|
| Um, yes. 0.0.0.0 looks like a really bad choice of source
| address.
| renewiltord wrote:
| > _It 's relatively tricky to read as text and you may prefer to
| look on screenshot of my console_
|
| If you copy it from the console and then use a `<pre>` tag rather
| than a `<blockquote>` tag it'll work well.
|
| See here: https://i.imgur.com/gAsb9TR.png
| pronoiac wrote:
| It's Ghost, so Markdown's available, and you could use a
| triple-backtick block, ``` before and after.
| prewett wrote:
| I was hoping this was somebody with network equipment in NASA,
| seeing actual DSN traffic over their network...
___________________________________________________________________
(page generated 2023-05-09 23:01 UTC)