Re: [44net] Odd Features/Bug? ampr-ripd

Marius, It's always assumed a.) the operator "wants" ALL packets and b.) that they always want them to be processed on the same device, at all times. Day by day, we increasingly see that because something isn't YET exploited...but could be, or even other GWs are misconfigured...In truth, I only need to: - See any packet bound for my WAN (broken) - INSPECT/DROP any packet on my WAN that doesn't match my network security policy (broken) - Accept IPENCAP only from assigned 44 IP endpoints (broken) - Accept other multipoint IPENCAP packets (broken) - Accept RIP44 from AMPRGW, Forward it, or to cut it off (broken) - Ability to Forward IPENCAP routing to a downstream device (broken) - get ping from your WAN interfaces - get ping from your tunl0's - Accept connections to services I offer: DNS, NTP, HTTP to 44.60.44.0/24 - The -r only model assumes that all packets on WAN are trusted, and hence accepts ANY IPENCAP packet on the WAN and drops them off on the secure side of my router, unchecked though iptables/etc. Only other iptables/ip rule/ip route statements I've added (prior) prevent this from being a security risk. - The -r uses creates a pseudo Layer 2 on my WAN, just to filter-out and process 1 particular of Layer 3 packet, from 1 particular endpoint - while forwarding the rest, unfiltered - To use the Encap File from the site and not rely on/process any packets from 44.0.0.1 (Stratum 1 redundancy/sanity checking of process AMPRGW uses to obtain the routes) - Temporally stop receipt, remove routes, etc. (more so important since ampr-ripd removes routes on exit, perhaps add an argument to make this an optional feature) - If we could see Rob's 'MAC,' we could possibly efficiently filter between the IPENCAP and inside header (i.e. detect spoofed 44.0.0.1 packet - and possibly, all other 44 addresses) - See firewall hits for this outer traffic - To firewall the other approximately 4 billion IP addresses that can send an kmod-ipip-compatible packet - that my Kernel/ampr-ripd now processes - Prevent unknown issues with interaction with kmod-ipip and ampr-ripd in raw-only mode (e.g. bypassing netfilter) - Prevent a GW/rogue machine from sending packets to - and my sending a response via AMPRGW (there's other ways to do this, but I still need to use other resources to process the outer header as an agent for netfilter, which I NO LONGER HAVE) - Block all other traffic from the Internet without use of additional CPU resources - Block traffic from individual GWs - Distribute packets to routers/sensors//LANs - based on outer header (at this point, I can't run point-to-multipoint IPENCAP tunnels for any reason - except AMPRNet). - Forward traffic to a backup router on-the-fly via change of iptables INPUT rule to a NAT FORWARD rule (possibly implement VRRP, especially for those who use BGPed tunnels) - When running point-to-multipoint kmod-ipip tunnels through your router, needing to end ampr-ripd for any reason would now also crash other non AMPR tunnels (unless the same, but now redundant iptables rule is added; but its effect on connection states are untested). - Lynwood KB3VWG