Re: [44net] Security - Nested IPIP

Rob, I now understand what you meant by this. I'm not seeing [lots of] improper Header 1 traffic with a known gateway IP as a SRC IP (and if I do, I want to block as it's asymmetric, as I tax AMPRGW on the reply trip). I receive the packet from AMPRGW (i.e. they're using the Public Internet instead of AMPRNet to reach the NTP server). * AMPR <> AMPR (OK, This allowed - as I list this service to my subnet in the Wiki) * Registered_Public <> Registered_Public (OK; but closed for MOST services) * Registered_Public <> AMPR (OK, not announced, taxes AMPRGW - may close soon; closed for some services) * Tunnel (Header 0) <> Public IP (Header 1) (NO - I consider this a crafted packet or improperly configured gateway, creates asymmetry; and taxes AMPRGW on the reply) - but cannot be mitigate except by blocking registered gateways on the de-encapsulated side of tunl0 I would advise you block that traffic with an improper Header 1 from registered gateways of you flag it via Header 0. But this discussion now causes me to recall discussions we've had before on: 1.) the security of seeing the Registered Public IP on both sides of the tunnel 2.) policy-based routing and the need to separate routing tables comes to mind....this comes from operators' failure to set that up. I'm now wondering how such a config is [incorrectly] made (i.e. the inside Header has the incorrect SRC)....likely because of no route policy...another discussion... Just note that bad IPENCAP is not the majority of bad traffic we're seeing on some nodes...in fact, bad IPENCAP is the least of this traffic (at least now). - KB3VWG Unfortunately this breaks legitimate traffic because some gateways are incorrectly configured (as I mentioned before) and send tunneled traffic with their own external address as source address, instead of the AMPRnet address assigned to the gateway. So such traffic is accepted as well here (i.e. traffic with a source address of one of the gateways)