21 Aug
2016
21 Aug
'16
6:39 a.m.
I wanted to ask the maintainers of the "Requesting a Block" page
regarding the paragraph about being prudent in requesting IP space; and
to comment about the safety of a firewall in-general:
There's a section that currently reads: "Don't be *greedy* request what
you actually need for service nodes...ISPs don't configure their routers
with publicly routable IP space for end users, why would you?"
I agree about the security concerns, etc. But in some uses of IP, it
would be very difficult to provide services to multiple devices over NAT
technology (e.g. allowing multiple servers needing the same TCP or UDP
port or IP protocol number, providing an adjacent private network the
option to route to the host via direct connection or over the Global
Internet). Also, the reason supporting the statement is quite
inaccurate. A large majority of ISPs not yet implementing Carrier Grade
NAT, do in fact, assign the end user pubically routable IPv4 space.
Granted, it's commonly a single /32 IP address. The page actually goes
on to describe the need of IPs according to the same principal - which
is basically today's standard practice.
The comment regarding 802.11 devices (or any IP routing device for that
case) is somewhat dubious security-wise ("this would not include any
802.11 routers for use on /HamWan/HamNet/ as doing so would make you
quite insecure."). Archives of security comments in this forum from
others suggest proper firewalling is necessary in environments running
IPENCAP-enabled routers, ESPECIALLY BECAUSE of the presence of
NAT/masquerade co-existing in some AMPRNet nodes. It can only be assumed
from the Wiki that the Ham allocated the IP space ensures or guarantees
firewalling by using NAT. While NAT has security benefits, it was
invented with an affect of slowing IPv4 exhaustion. In our IPENCAP
environment, it is a vector to send IP datagrams to "this network" (i.e.
how your router perceives 0.0.0.0/0), AMPRGW, other gateways, or an
adjacent private network (e.g. your home/corporate/government LAN). For
this reason, the OpenWRT router setup page includes information
regarding configuration of a basic Virtual Routing and Forwarding
environment on your Linux-based router. This configuration places any
AMPR interface on a separate, routing table not possessing locations of
non-AMPR subnets (i.e. routing table "44"). While I'm not certain if any
node in the /HamWan/HamNet/ networks run IPENCAP, others in AMPRNet do.
These statistics are from my router's firewall, current uptime, 78 hours:
2 84.00 B DROP all -- tunl0 * 192.168.0.0/16
0.0.0.0/0 -
1 40.00 B DROP all -- tunl0 * 172.16.0.0/12
0.0.0.0/0 -
1 28.00 B DROP all -- tunl0 * 10.0.0.0/8
0.0.0.0/0 -
It's important to note, without a firewall, and even with a Virtual
Routing and forwarding Instance, these inbound packets would have
forwarded to AMPRGW. Unless an operator arranges to use private
addresses directly with me, these packets were invalid because my tunl0
interface faces the Global Internet - where use of these IPs are not
allowed by RFC 1918. Accordingly, I possess no specific route on my
"table 44" that AMPRNet nodes should use to reach these destinations.
Other tools to improve security are programs to automate adding and
flushing entries on a firewall permitting AMPRNet endpoints to send
IPENCAP. Even then, a mis configured client or infected machine within
AMPRNet could send a crafted packet to traverse our network, or networks
physically or logically adjacent to our nodes.
Just a thought...
73,
KB3VWG