Bug: bogon network vs. filter.inc (RFC6598)

paulroot

(translated by google)

To developers pfSense.

Please remove this line in /etc/inc/filter.inc:

block in $ privnetlog quick on \ $ {$ oc ['descr']} from 100.64.0.0/10 to any tracker {$ increment_tracker ($ tracker)} label "{$ fix_rule_label (" Block private networks from {$ oc ['descr ']} block 100.64 / 10 ")}"

Explanation:

1. 100.64.0.0/10 is not a "private network", and does not refer to RFC 1918.
2. Violates RFC 6598
3. Makes it impossible to unlock the network 100.64.0.0/10 through the web-interface "Interfaces - WAN / DMZ - Block bogon networks"

phil.davis

Yes, technically it is not Private Address Space - it is Shared Address Space. But it is address space that is not routable on the public internet, and carriers are required not to allow Shared Address Space to be leaked onto the public internet, e.g.

packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links.

As an end-user, Private Address Space and Shared Address Space packets appearing on WAN should both be equivalently not wanted. End-users on LAN side should never be accessing Shared Address Space on WAN side - it should be just hops on the way through the carrier network to the public internet.
So in these use cases, Private and Shared Address Space filtering are both required together. So it is convenient that both are switched on/off by a single checkbox.

There might be cases of using pfSense inside a carrier network where you might want to filter Private Address Space but not Shared Address Space. For that, you should be able to uncheck "Block Private Networks" and then put your own mix of pass and block rules to achieve what you want.

The webGUI description is out-of-date:

When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8). You should generally leave this option turned on, unless your WAN network lies in such a private address space, too.

It should mention that CGN Shared Address Space is also blocked.

doktornotor

@paulroot:

2. Violates RFC 6598

How? I can see the exact opposite there, namely:

6. Security Considerations

Similar to other [RFC5735] special-use IPv4 addresses, Shared Address
Space does not directly raise security issues. However, the Internet
does not inherently protect against abuse of these addresses.
Attacks have been mounted that depend on the unexpected use of
similar special-use addresses. Network operators are encouraged to
review this document and determine what security policies should be
associated with this address block within their specific operating
environments. They should consider including Shared Address Space in
Ingress Filter lists [RFC3704], unless their Internet service
incorporates a CGN.

Really, this CGN junk is no different from RFC1918 ranges.

@phil.davis:

The webGUI description is out-of-date:

When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8). You should generally leave this option turned on, unless your WAN network lies in such a private address space, too.

It should mention that CGN Shared Address Space is also blocked.

This is blocked by /etc/bogons as well.

$ grep 100.64 /etc/bogons
100.64.0.0/10

Should be removed from there - https://redmine.pfsense.org/issues/4379

paulroot

RFC 6598: "The Shared Address Space address range is 100.64.0.0/10. Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks."

This means: RFC 1918 - range of action is LAN (not routed to ISP WAN and Internet),
RFC 6598 - range of action is ISP WAN (routed in ISP WAN, not routed to Internet)

pfSense WAN interface connected to a ISP WAN - among incoming packets MAY BE packets from 100.64/10 and it's legal. Source of this packets - other clients of this ISP, wishing to connect to the services behind pfSense. Example: my pfSense WAN iface connected to ISP Rostelekom, i have some Internet servers behind pfSense in DMZ - clients of this ISP Rostelekom routed by ISP to my pfSense with packet's source address 100.64/10 (by the way, ISP Rostelekom network - all territory of Russian Federation).

But by this line in the filter.inc causes you excluded the possibility of the pfSense administrator to resolve packets from 100.64/10 by unchecking "Block bogon networks" (/etc/bogons).

Since the RCF 6598 applies only to the network 100.64/10 the right decision is:

1. Exclude this line from filter.inc (not private)
2. Exclude 100.64/10 from /etc/bogons table (not bogon, allowed to work in ISP WAN by RFC 6598).

If you want, you may add separate checkbox for RFC 6598 in web-interface near "private" and "bogon" checkboxes.

And just in case (if pfSense is not used by the ISP within the his network), may be add block firewall rule for outgoing from LAN to WAN packets with source 100.64/10. Although it is still a concern of the ISP. By default, it will block onto the nearest router from the client both RFC1918 packets and not belong to him RFC 6598 packets.

doktornotor

@paulroot:

RFC 6598: "The Shared Address Space address range is 100.64.0.0/10. Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks."

This means: RFC 1918 - range of action is LAN (not routed to ISP WAN and Internet),
RFC 6598 - range of action is ISP WAN (routed in ISP WAN, not routed to Internet)

This blurb is just bogus. There's absolutely no difference whether you are behind NAT (RFC1918) or behind Carrier-grade NAT (RFC 6598). It's still the damn same NAT, just different non-routable address space. You effectively are on ISPs LAN and do not have proper internet connection at all.

Normally, the bogons shipped by the gyus who maintain those include all of RFC 1918, RFC 5735/RFC 6598 – this RFC1918 checkbox is pfSense special. Cf. http://www.team-cymru.org/Services/Bogons/

Regardless, go argue this on the bug linked above, it's been already dropped from the RFC1918 checkbox and I got tired quickly arguing for the other solution I originally proposed. Yet another CGN checkbox is even worse, never figured someone might suggest it. :o ::)

phil.davis

Yet another CGN checkbox is even worse, never figured someone might suggest it.

I was thinking of suggesting it, then didn't. Now glad it wasn't me that suggested it ;)

I was thinking to:
a) Remove the 100.64 from Bogons (I think bogons is just meant to be for "bad" public IP addresses that are known to be not issued yet (none of those left now in IPv4?) or to be old address allocations that (might) have been squatted by other nefarious users). So bogons should be addresses that nobody would ever want to see and should never see or allow in to anywhere.

b) Change the description of "Block Private Networks" to "Block Private and CGN Networks" with appropriate enahncement of the GUI page text. Just make it say what it already does - blocks all public-internet-non-routable IPv4 addresses.
But I see that cmb has already removed 100.64 from the private list.

doktornotor

What's bogons used for in pfS is basically "unallocated". Sticking anything else there has proven to break things, requiring nonsensical special-case dances around. I don't understand really why the files cannot get cleaned of all RFC 1918, RFC 5735 and RFC 6598 stuff, instead of doing the hack-arounds in other code.

So, what really would sound sensible is:

changing the special RFC1918 checkbox into "Martians", which includes RFC 1918, RFC 5735 and RFC 6598 debated here and fixing the description.
the rest left as "Bogons".

There's definitely not a good reason to single out CGN.

Then there's this IPv6 thing and the infamous 8000::/1 (which was breaking DHCPv6 and apparently is still breaking IPv6 in other ways for people) – but that's a different can of worms...

paulroot

@doktornotor:

There's absolutely no difference whether you are behind NAT (RFC1918) or behind Carrier-grade NAT (RFC 6598).

From the point of view of the pfSense gateway is a difference - by the side of LAN interface is strictly RFC1918 networks, and it making NAT for this network to outside, by the side of WAN interface is real Internet IP's and RFC6598. And it must somehow cope with it. And the words "absolutely no difference" will not help him in this (see diagram below). If you have at least a little bit of compassion help him, allowed to pass 100.64/10 from WAN, fix the filter.inc in the distribution.

@doktornotor:

It's still the damn same NAT, just different non-routable address space. You effectively are on ISPs LAN and do not have proper internet connection at all.

I want to clarify that in my case I have real Internet address (four), unlimited by ISP incoming and outgoing connections with real Internet addresses, but like the other customers of this ISP I'm still in of ISP's routed network (some tracert's hops). See your's tracert log to long distance Internet address - some first is routers in your ISP network too. Is thus ISP can (and do) send me packets from his clients with source addresses 100.64/10 according RFC 6598, he has the technical ability to.

By the way, we checked if same client (ISP Client 2 on diagram) sends a packet not to the my real Internet IP (ISP Client 1 on diagram) but to the Internet networks beyond ISP network - source IP of this packet not 100.64/10, it's real Internet IP address (Internet IP2). Yes, I also expected that the packet will come to me from this client will from this real Internet IP2, but it is not. So my ISP doing route - apparently reduces the route within his network and saves his Internet addresses space available. I do not know whether this routing is correct or wrong, but in fact the large scale ISP with dozens of engineers with Cisco certifications uses a RFC 6598 in this manner (see diagram below):

In another words, we are all connected to the Internet through ISP. And all the packets from you and for you pass through its network, its routers. And it can use in its network 100.64/10. And this packets legally (RFC 6598) can knock knock to firewall of pfSense gate. But your pfSense still is not ready for this and the packets will block. In real life I commented out this line in filter.inc and customers of the my ISP went on the my organization's website, ftp, audio-video-broadcast, vpn and so on.

robi

Really, why is such a big deal adding a third separate checkbox for this, which would actually improve usability?

doktornotor

Third checkbox for what? CGN? And fourth for RFC 5735? Of maybe there should be multiple checkboxes for various stuff under RFC 5735? Or, maybe there should be a separate checkbox for each of 10/8, 172.16/12 and 192.168/16? How would that improve usability?

Really, there are:

these ranges reserved for "private internets" use (RFC1918) + carrier-grade NAT (RFC 6598) which falls exactly there (called "Shared Address Space" by RFC 6890 now probably because it better fits the marketing of ISPs that put their customers on their LAN instead of providing IPv4 internet connectivity)
the special use reserved stuff (RFC 5735)
the currently unassigned ranges (bogons)

I'm sorry but single-out CGN makes no sense. Just stop using the "private networks" checkbox, create your custom alias for RFC1918 and move on. Hmmm, oh wait. That'd require fixing the proper thing, instead of leaving CGN in bogons. You'll need to argue that on the bug linked above. The bogons would actually be usable if it did not include unrelated junk such as various broadcast (240/4 - wonderful source of log noise) or CGN - i.e., if it included only unallocated stuff and not random reserved/special use ranges as well.

phil.davis

IMHO bogons should be just for variable address ranges that would be routable on the public internet as "normal" IP addresses, but that are not expected to actually appear because of things like:

as yet unallocated
allocated to a now defunct organisation and not yet reclaimed for re-allocation
known to be squatted
…

The pieces of fixed address space reserved for particular purposes in RFCs should not be in bogons and are better handled by using aliases or predefined lists for the purpose, so the user can control those as they need to.