RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)
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] https://www.rfc-editor.org/rfc/rfc6598#section-6 [2] https://www.team-cymru.com/bogon-networks
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. On Tue, Mar 7, 2023 at 5:10 PM Lukas Tribus <lukas@ltri.eu> wrote:
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] https://www.rfc-editor.org/rfc/rfc6598#section-6 [2] https://www.team-cymru.com/bogon-networks
On Tue, Mar 7, 2023 at 2:09 PM Lukas Tribus <lukas@ltri.eu> wrote:
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?
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 -- For hire. https://bill.herrin.us/resume/
On Wed, 8 Mar 2023 at 00:05, William Herrin <bill@herrin.us> wrote:
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
They talk about bogon prefixes "for hosts", provide configuration examples for Cisco ASA firewalls,
Which are perfectly valid use cases for some networks / situations. On Tue, Mar 7, 2023 at 6:35 PM Lukas Tribus <lukas@ltri.eu> wrote:
On Wed, 8 Mar 2023 at 00:05, William Herrin <bill@herrin.us> wrote:
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
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. :) Be well, Rabbi Rob.
On Tue, Mar 7, 2023 at 6:35 PM Lukas Tribus <lukas@ltri.eu> wrote: On Wed, 8 Mar 2023 at 00:05, William Herrin <bill@herrin.us> wrote:
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
— Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree.” - Leo McKern
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
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. On Wed, Mar 8, 2023 at 7:34 AM Lukas Tribus <lukas@ltri.eu> wrote:
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
On Tue, Mar 7, 2023 at 3:34 PM Lukas Tribus <lukas@ltri.eu> wrote:
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.
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 -- For hire. https://bill.herrin.us/resume/
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
On 3/8/23 5:35 AM, Lukas Tribus wrote:
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. -- Grant. . . . unix || die
On 3/8/23 5:35 AM, Lukas Tribus wrote:
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.
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
On Wed, Mar 8, 2023 at 4:35 AM Lukas Tribus <lukas@ltri.eu> wrote:
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.
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 -- For hire. https://bill.herrin.us/resume/
On 9 Mar 2023, at 08:41, William Herrin <bill@herrin.us> wrote:
On Wed, Mar 8, 2023 at 4:35 AM Lukas Tribus <lukas@ltri.eu> wrote:
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.
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 -- For hire. https://bill.herrin.us/resume/
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 3/7/23 4:34 PM, Lukas Tribus wrote:
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:
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. -- Grant. . . . unix || die
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
On Wed, Mar 8, 2023 at 7:43 AM Lukas Tribus <lukas@ltri.eu> wrote:
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
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
On 3/8/23 6:17 AM, Victor Kuarsingh wrote:
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.
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
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. 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. -- Grant. . . . unix || die
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. https://www.team-cymru.com/bogon-networks 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. — Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree.” - Leo McKern
participants (8)
-
Grant Taylor -
Lukas Tribus -
Mark Andrews -
Rabbi Rob Thomas -
Tom Beecher -
Travis Garrison -
Victor Kuarsingh -
William Herrin