I still don't see how this is working, unless all routers on the way implement connection tracking (which is certainly not the case).

So, they send out a spoofed package using a 44 address as origin and then what? The reply will never get back to them. Instead it will be routed to the proper real 44 endpoint, either directly for BGP-ed subnets, or via 44.0.0.1, to no end result.

That is why I rather suspect some network using internal 44 addresses as "private" IPs, overlap our net and sometimes leak out via a non source-filtered ISP.

I think that is not a legitimate use but an attack group that spoofs sender addresses when sending their attacks and they use net-44 addresses as well. To have that go down, more ISPs should implement BCP38 (source address filtering).

...

I suspected at some point that there is a network using 44 addresses internally, had some leaks on them and that the garbage (DNS replies, ICM rejects, IP fragments and such stuff) were the replies from hosts on the internet receiving that traffic and sending replies back via the ampr-gw.

I think that is not a legitimate use but an attack group that spoofs sender addresses when sending their attacks and they use net-44 addresses as well. To have that go down, more ISPs should implement BCP38 (source address filtering).

Unfortunately, there is little incentive for ISPs to do that, because it benefits only others and not themselves.

Generaly speaking, yes, but not in this case.

If I understand correctly, the traffic drop was inbound from ipip-mesh, that means: some-ham-host -> ipip -> ucsd (-> inet or 44.0.0.1). ^ Measure in the Graph => Thus we're not talking about a faked IP address. It was either a case (or legitimite use) of - a ham-host sending traffic to ucsd (or via ucsd to the inet, or via ucsd to the inet to a bgp announced ham host (wich is even more legitimte)) - responses of inet attacks to a ham-host (good connected, the drop was abt. 3MBit) and this host has enabled his firewall for not sending RST, icmp unreachable, etc..

Without more detailed information, all we can do is to speculate.

If you ask me, it was - a ham who looked for weeks two or more HAM Webcam streams has closed his browser or - a ham has forgotton to switch off his file sharing tool before going online in the amprnet or - a ham has his default-route to the internet via ucsd and watched TV or - perhaps, somewhere in the world there was a huge ham event with many visitors? (then 3MBit is "nothing") or - a ham computer with a virus, attacking the world or - some services like DMR changed their infrastructure or - an ampr ipip host had a service which was used from an internet bgp-announced network and it delivered ham content (dmr, etc..) via ipip->ucsd->44-inet-host. or much more cases

If we'd have sflow/netflow data, we'd know what happened.

vy 73, - Thomas dl9sau

On Thu, May 18, 2017 at 10:06:46AM +0200, Rob Janssen wrote:

I think that is not a legitimate use but an attack group that spoofs sender addresses when sending their attacks and they use net-44 addresses as well. To have that go down, more ISPs should implement BCP38 (source address filtering).

Yes, that is what it is almost certainly. For more information, go to www.caida.org and search for 'telescope'. - Brian