I spent some time with this 44 spoofing issues and reached some
conclusions...
First of all, spoofing a 44 address while being outside the 44 tunnel
system and using one of its addresses is actually not possible. Beacuse
even if the 44 destination in a subnet can be reached via whatever means,
the replies will either go directly to the proper tunnel, which hosts will
ignore them since it did not originate that traffic, or will go through
the local gateway and through amprgw, which drops 44 to 44 traffic (which
is good). So a no go here.
Second, let's say the attacker implements a direct IPIP tunnel spoofing.
Since its routes are not in encap/rip, there will be no return route other
than the default route or the original proper tunnel. While the default
route will usually NAT to the public IP, the original src address is lost
and the communication will be probably compromised and the now orphan
replies sent to the non-spoofed originator by amprgw. Again no go here.
Going up one level, let't assume that the attacker could hijack a 44
subnet by injecting some fake BGP route into the global table. In this
case, it will affect only the bgp-announce subnets or undefined network
ranges, since the others are protected by the internal routings of the
full mesh.
So I don't think that spoofing is an efficient attack path in our case,
allthough, by tracking the gateway traffic, it seems that there are either
a lot of tentatives outside, or that some persons use our 44 address space
as private space, and there is some traffic leak in their configuration.
Marius, YO2LOJ