RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

Mailman List Mirror (Read Only)
1

Hello,

so 100.64/10 is used in CGNAT deployments requiring service providers
(that is AS operators) to drop 100.64/10 on the border to other AS in
BGP and in the dataplane, as per RFC6598 section #6 Security
Considerations [1].

Within an AS though traffic from 100.64/10 can very well bypass CGNAT
for AS local traffic to reduce state/logging. This appears to be quite
common and it makes a lot of sense to me.

At the same time folks like team-cymru are picking up this prefix for
their bogon lists with the following description [2]:

A packet routed over the public Internet (not including
over VPNs or other tunnels) should never have an address
in a bogon range.

It would be quite a bad idea to drop 100.64/10 on a firewall or
servers, when legitimate traffic can very well hit your infrastructure
with those source IPs.

Thoughts?

Lukas

[1] RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space
[2] https://www.team-cymru.com/bogon-networks

2

It would be quite a bad idea to drop 100.64/10 on a firewall or
servers, when legitimate traffic can very well hit your infrastructure
with those source IPs.

Thoughts?

Don’t use bogon lists in places you shouldn’t use bogon lists.

3

Hi Lukas,

If you're using the team cymru bogon list at your customer border,
you're doing it wrong. You should be using BCP38 there, which calls
for filtering source addresses not assigned to your customer.

At the Internet and peering borders, there is no legitimate traffic
which still has 100.64/10 as a source IP address.

There may be accidental traffic which has 100.64/10 (or 10/8 or
192.168/16) as a source address but it's not "legitimate." Of
particular concern, there may be ICMP type 3 (destination unreachable)
packets with these source addresses. It continues to irritate me that
vendors haven't addressed this discrepancy with tech that statelessly
translates these escapees to a public address that's legitimate for
your organization.

Regards,
Bill Herrin

4

Hi Lukas,

If you're using the team cymru bogon list at your customer border,
you're doing it wrong.

I'm not.

I'm trying to educate people that bogon lists do not belong on hosts,
firewalls or intermediate routers, despite Team-cymru's aggressive
marketing of the opposite, quote:

THE BOGON REFERENCE

*A bogon prefix should never appear in the Internet routing table*.
Team Cymru’s Bogon Reference provides several resources for
the filtering of bogon prefixes from your routers *and hosts*.

A bogon prefix is a route that should never appear in the Internet
routing table. A packet routed over the public Internet (not including
over VPNs or other tunnels) *should never have an address in a
bogon range.* These are commonly found as the source addresses
of DDoS attacks.

They either have to make it clear what their bogon list can actually
be used for or they need to drop RFC6598 from the list.

They talk about bogon prefixes "for hosts", provide configuration
examples for Cisco ASA firewalls, at the same time they include
RFC6598 in the list and it's marketing material suggests it can be
used for everything.

You can't have it both ways. Either you provide a list of prefixes to
be dropped on autonomous system borders *and make that clear* or you
provide a list of prefixes that can be dropped in all systems.

Lukas

5

They talk about bogon prefixes “for hosts”, provide configuration
examples for Cisco ASA firewalls,

Which are perfectly valid use cases for some networks / situations.

6

You'll have to connect the dots for me here, I'm not seeing the
problem. The ISP's local network is not "the public Internet." They
can use RFC6598 and even RFC1918 at their leisure. If they choose to
place services on those addresses and you want to use them, you'll
have to exclude them from your local filtering and/or your own
internal use. For everybody else, they're bogons.

Is someone out there defaulting consumption of the bogon list who
shouldn't be? What leads you to the strong objection about 100.64/10's
inclusion?

Regards,
Bill Herrin

7

Dear team,

I’ve already reached out to Lukas directly, but I’ll kibitz a bit:

They talk about bogon prefixes "for hosts", provide configuration
examples for Cisco ASA firewalls,

Which are perfectly valid use cases for some networks / situations.

Indeed! There was a time early in the life of the bogon lists where folks requested host-based and firewall-based filter examples. This was because these were their AS-border devices, e.g. host-based routers and firewalls, and hardware firewalls. I don’t remember writing a Cisco ASA example, but that was a long time ago. :slight_smile:

Be well,
Rabbi Rob.

8

I don't have any problem with bogon lists being on hosts or intermediate routers.

The think that you have to remember to do is to exclude locally significant (100.64/10, RFC 1918, et al.) from those filters /or/ account for them in another way.

I have bogons on some hosts /and/ locally significant / more specific routes to 100.64/16 without any problem.

Bogons is just a list of IPs that shouldn't be on the open Internet. But that same list can be re-used ~> abused elsewhere without. How that list is used is installation specific. If you're running default free, make sure that you remove the bogon prefixes from your routing tables /and/ /then/ (re)add any locally significant prefixes.

The Team Cymru bogon's list is a tool and like all tools, it can be mis-used and become a foot gun.

9

Hello,

It is just that, marketing.

I disagree, authoritative and accurate product description and
documentation of the tools used by the public matter a lot. If a
ticket lands on my desk because a third party misuses a tool, I want
to point to a single authoritative source of information.

It doesn't mean you have to follow it to the letter.

I know that, you know that. That doesn't solve my problem. What solves
my problem is accurate documentation and education.

Why not take this up with them Team Cymru directly?

This is an operational networking issue that goes beyond the bogon
list of Team Cymru. I am now in contact with Team Cymru, to improve
the situation there, but that is just an example. My intention is to
explain the problem and educate.

Thanks,
Lukas

10

They talk about bogon prefixes "for hosts", provide configuration
examples for Cisco ASA firewalls,

Which are perfectly valid use cases for some networks / situations.

Absolutely, everybody's free to drop whatever they like on their gear,
I'm sure there are networks, gear, applied and documented
configurations out there that block 1.1.1.0/24.

That doesn't mean publically available blocklists need to misrepresent
their use-case.

The concern is not about networks that know what they are doing, the
concern is about the rest (and more specifically entities that don't
operate their own ASN).

Thanks,
Lukas

11

You'll have to connect the dots for me here, I'm not seeing the
problem. The ISP's local network is not "the public Internet."

It very much is.

An autonomous system can contain both "eyeballs" (possibly RFC6598
adressed) and services in datacenters/clouds, it's not *always* a
different ISP.

Perhaps I should have started this topic with a very specific example:

- ISP A has a residential customer "Bob" in RFC6598 space
- ISP A CGNATs Bob if the destination is beyond it's own IP space
- ISP A doesn't CGNAT if the destination is within its IP space (as
explained in the OP, this means reducing state and logging)
- ISP A has a cloud customer "Alice" running mail/webservers, which is
of course using public IP address space
- when Bob access Alice's mail/webserver, the source IP will show
RFC6598 addressing
- if Alice filters RFC6598, Bob can't connect
- Alice should not drop RFC6598, it should threat RFC6598 just like
every other public IP subnet
- only ISPs (which Alice is not) should drop RFC6598 on its network borders

RFC6598 filters belong on network borders to other autonomous systems,
not in a datacenter on a mail/webserver.

They can use RFC6598 and even RFC1918 at their leisure.

No, they really can't and shouldn't use RFC1918 in the public part of
their network, because that will conflict with RFC1918 used by
customers.

Which is the entire point of RFC6598: an address space that does NOT
conflict with private deployments, so that it can actually be used by
the ISP.

RFC1918 : the ISP customer gets to assign it
RFC6598 : the ISP get's to assign it

Of course a customer can configure 8.8.8.0/24 or 100.64.25.0/24 on
their LAN, and a ISP can assign 192.168.0.0/16 to an addressing pool.
That is technically possibly and I'm sure there are folks that are
doing it. But it is not a good idea, it's not RFC compliant and will
lead to issues down the road, which is why we have RFC's and BCP's.

If they choose to place services on those addresses and you
want to use them, you'll have to exclude them from your
local filtering and/or your own internal use. For everybody
else, they're bogons.

I think my example above may clarify this. It's not about services in
RFC6598. It's about services in public IP space, where clients connect
to *from* RFC6598 IPs, which can and does happen when eyeball and
service are in the same ASN/ISP.

Thanks,
Lukas

12

The think that you have to remember to do is to exclude locally
significant (100.64/10, RFC 1918, et al.) from those filters /or/
account for them in another way.

You know all this if you are the network operator.

If you are the customer of the ISP, let's say a datacenter/cloud
customer and you are deploying Web or Mailservices, you have no idea
whether this ISP will route RFC6598 traffic to you or not and you
certainly will not get informed by the ISP if that ever changes. You
only know about this once you are dropping production traffic from
clients in 100.64/10 and a trouble ticket has found it's way to you
("residential customers of the same ISP can't reach your cloud
services").

That is why RFC6598 is suggesting to drop this traffic on autonomous
system borders. The RFC is not suggesting to drop this traffic
elsewhere.

Bogons is just a list of IPs that shouldn't be on the open Internet.

Which, for RFC6598 is misleading because RFC6598 space is used within
(but not beyond) ISP networks. "The internet" includes ISP networks.

The Team Cymru bogon's list is a tool and like all tools, it can be
mis-used and become a foot gun.

Which is why proper description, documentation and education is important.

Thanks,
Lukas

13

The think that you have to remember to do is to exclude locally
significant (100.64/10, RFC 1918, et al.) from those filters /or/
account for them in another way.

You know all this if you are the network operator.

If you are the customer of the ISP, let’s say a datacenter/cloud
customer and you are deploying Web or Mailservices, you have no idea
whether this ISP will route RFC6598 traffic to you or not and you
certainly will not get informed by the ISP if that ever changes. You
only know about this once you are dropping production traffic from
clients in 100.64/10 and a trouble ticket has found it’s way to you
(“residential customers of the same ISP can’t reach your cloud
services”).

That is why RFC6598 is suggesting to drop this traffic on autonomous
system borders. The RFC is not suggesting to drop this traffic
elsewhere.

This was the intention of the RFC. As this space was intended to be used with an AS’s network to service CGN needs. That CGN boundary likely ends before a given customer and/or neighboring network, so it would make sense that downstream and neighboring networks would filter at their borders. All that said, if for some reason, a downstream network has 100.64/10 assigned to direct links on an interconnection, that may be a problem. That type of deployment model was not within the intention of RFC6598 (using the block for non-CGN use cases).

Trying to block RFC6598 at the host level can potentially be problematic as the network that host is connected to may be using RFC6598 space.

Bogons is just a list of IPs that shouldn’t be on the open Internet.

Which, for RFC6598 is misleading because RFC6598 space is used within
(but not beyond) ISP networks. “The internet” includes ISP networks.

It is true an ISP’s network would be part of the Internet, but the part which is servicing CGN zones would not part of the generally reachable part of the Internet (inbound, all ports, all protocols). The CGN zone within the ISP network is as much part of the Internet as a home network would be (non-routable addresses used to service an upstream NAT).

Victor Kuarsingh

14

That doesn’t mean publically available blocklists need to misrepresent
their use-case.

Respectfully, this is exceptionally ignorant.

Team Cymru is not misrepresenting anything. They are very specific and detailed about which addresses the bogons and fullbogons lists contain. They also clearly state that individual networks MAY need to make adjustments based on their circumstances.

Team Cymru CEO, Rob Thomas, studied a frequently attacked website to discover that 60% of the bad packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). Your mileage may vary, and you may opt to filter more conservatively or more liberally. As always, you must KNOW YOUR NETWORK to understand the effects of such filtering.

Bogon filtering is a component of anti-spoofing filtering

The concern is not about networks that know what they are doing, the
concern is about the rest (and more specifically entities that don’t
operate their own ASN).

If someone is blindly filtering a list of prefixes from a 3rd party without understanding what that list is, and why they are filtering with it, then they are likely to transition from ‘don’t know what they are doing’ to ‘educated on the subject’ soon enough.

15

This was the intention of the RFC. As this space was intended to be used with an AS's network to service CGN needs. That CGN boundary likely ends before a given customer and/or neighboring network, so it would make sense that downstream and neighboring networks would filter at their borders.

I would assume ~> expect that any operator of a system being deployed with a globally routed IP to be well aware if there system was expected to handle non-globally routed IPs or not. E.g. at $DAY_JOB we /explicitly/ configured systems to allow ~> support non-globally routed IPs from RFC 6598 Shared Address Space et al. clients.

Either you're outside of the CGN context or you are explicitly aware that you are inside of the CGN context.

Or said another way - either you're only communicating with the globally routed Internet -- thus no non-globally routed IPs -- or your are explicitly aware that you may be communicating with non-globally routed IPs.

Trying to block RFC6598 at the host level can potentially be problematic as the network that host is connected to may be using RFC6598 space.

If a provider did not seek my consent before sending me non-globally routed traffic I would consider such traffic to be invalid ~> bogon and assume that replies thereto wouldn't make it back to the client and treat it like the errant configuration that -- I believe -- it is.

It is true an ISP's network would be part of the Internet, but the part which is servicing CGN zones would not part of the generally reachable part of the Internet (inbound, all ports, all protocols). The CGN zone within the ISP network is as much part of the Internet as a home network would be (non-routable addresses used to service an upstream NAT).

I think that anything that has a non-globally routed IP has "access to the Internet". Conversely to be "on the Internet" requires a globally routed IP address. I believe "the CGN zone ... home network" qualify as "access to the Internet" and very.

16

Perhaps I should have started this topic with a very specific example:

- ISP A has a residential customer "Bob" in RFC6598 space
- ISP A CGNATs Bob if the destination is beyond it's own IP space
- ISP A doesn't CGNAT if the destination is within its IP space (as
explained in the OP, this means reducing state and logging)
- ISP A has a cloud customer "Alice" running mail/webservers, which is
of course using public IP address space
- when Bob access Alice's mail/webserver, the source IP will show
RFC6598 addressing
- if Alice filters RFC6598, Bob can't connect
- Alice should not drop RFC6598, it should threat RFC6598 just like
every other public IP subnet

I argue that Alice should expect to not receive any traffic from non-globally routed IPs UNLESS her cloud provider has informed her that she should expect them.

I'd say that they shouldn't send them to her without her acknowledgement ~> consent to receive them.

- only ISPs (which Alice is not) should drop RFC6598 on its network borders

I disagree.

RFC6598 filters belong on network borders to other autonomous systems,
not in a datacenter on a mail/webserver.

Nothing prevents someone from filtering bogons without using RFC 6598 as justification to do so.

I suspect that there are many people using DFZ feeds that are in effect filtering bogons and they likely aren't using RFC 6598 as justification.

No, they really can't and shouldn't use RFC1918 in the public part of
their network, because that will conflict with RFC1918 used by
customers.

I disagree.

As long as the ISP is not duplicating* subnets in their network, then traffic will pass through links to / from the end user without any problem. This is predicated on traffic being from the end user's IP and a globally routed IP. Traffic from 100.64.64.100/24 to 8.8.8.8/24 will pass through a link using 100.64.100.100/24 without any problem.

The ISP could even duplicate subnets in their network segments that don't need to communicate with each other, like point to point links. E.g. R1 & R2 can use 10.10.10.10/31 .11 and R3 & R4 can use the same IPs without effecting transit traffic as long as said traffic /is/ transit and not to / from said prefix. The fact that R1 & R2 can't communicate with R3 nor R4 using said prefix is not an operational problem for transiting traffic. It is probably quite annoying for the ISP and as such discouraged.

Which is the entire point of RFC6598: an address space that does NOT
conflict with private deployments, so that it can actually be used by
the ISP.

RFC1918 : the ISP customer gets to assign it
RFC6598 : the ISP get's to assign it

Both parties can use addresses reserved for the other party. They just need to be aware of potential problems in doing so.

Of course a customer can configure 8.8.8.0/24 or 100.64.25.0/24 on
their LAN, and a ISP can assign 192.168.0.0/16 to an addressing pool.
That is technically possibly and I'm sure there are folks that are
doing it. But it is not a good idea, it's not RFC compliant and will
lead to issues down the road, which is why we have RFC's and BCP's.

Remember, IP addresses / subnets are *locally* *significant*. As long as you are aware of the scope of /locally/ and how it interacts with things, then do whatever you want. Just be aware of potential foot guns. There is such a thing as being overly clever when it comes to supporting things. But if it works, and you want to support it, then have a ball and route traffic however you want.

Aside: This is also predicated on interaction between the customer traffic and the ISP's management traffic. Overlays tend to really negate this issue and allow the ISP to (re)use any IPs they want as long as it's in a different routing domain.

I think my example above may clarify this. It's not about services in
RFC6598. It's about services in public IP space, where clients connect
to *from* RFC6598 IPs, which can and does happen when eyeball and
service are in the same ASN/ISP.

I would expect -- nay /demand/ -- that any ISP sending traffic to a co-lo customer from a non-globally routed IP to have said co-lo customer's consent before doing so.

17

Exactly

We use CGNAT in our network unfortunately. We skip CGNAT for internal resources only, to reduce logging, load, etc. but all outbound and/or customer to customer traffic goes through the CGNAT. Only public IP addresses are allowed to communicate between customers.

Travis

18

Hi Lukas,

Thanks for the clarification. As others have said: the error lies in
the base conditions of your reasoning, not team-cyrmu's bogon list.

The bogon list is designed to be used unmodified at one particular
kind of location only: the BGP-speaking link between two different
Autonomous Systems. Anywhere else you might choose to use it, you must
first exclude or override the filtering for locally used addresses.

Perhaps the folks maintaining the bogon list can document the need to
exclude locally used addresses when employing it elsewhere, and that
for the purposes of the bogons list, "local" includes your immediate
ISP. I can see how the latter part of that might not be completely
obvious.

Regarding the specific example, I'm dubious that ISP A should be
presenting Alice with Bob's un-natted 100.64/10 address. The RFC does
allow ISP A to use the address space that way, but there have been
several discussions here and in the groups where the RFC was first
envisioned and debated to the effect that the ISP sending traffic to a
customer with source addresses in 100.64/10 would be unwise due to the
possibility of overlap and/or filtering issues.

The more common example in these debates was ISP A using a 100.64/10
address for a DNS resolver or smtp relay intended to be used by only
the downstream customers. The issue with using the addresses that way
was that if the downstream customer had more than one ISP, it would be
unable to differentiate between ISPs for 100.64/10 destinations.

Regards,
Bill Herrin

19

Correct, you can’t use 100.64/10 for any service expected to be reached
by customers. CPE shouldn’t see traffic from 100.64/10 with the possible
exception of ICMP ERROR messages. Even advertising a 100.64/10 address as
next hop is problematic for dual homing CPE.

20

Happy Sunday, NANOG!

We’ve made several updates to our sundry Bogon pages and feeds, with some variation of the following caveat. We’re always keen to add clarity and updates, so please feel free to reach out.

Bogon filtering should be undertaken only if the impacts are well-understood. These are not simple filters, and can have adverse impacts if improperly applied. In particular, please consult RFC6598 regarding 100.64.0.0/10. It’s important that you know your network, and that any planned filters are rigorously tested before adoption. These filters may be more applicable to some devices, such as gear that functions as a border router, than other devices.

Be well,
Rabbi Rob.