How can the IP spoofing problem be solved within a country?
Hello I am Taygun, I am a 23 year old who has been working in cyber security and information technologies as a hobby for about 13 years. There are countless people and institutions that have been victims of IP spoofing attacks that have increased recently in my country (Turkey). I started researching to find a solution to this problem and offer a solution to the ISPs and the IT institutions in my country. After brainstorming in the TRNOG group in Türkiye and on LinkedIn, such as NANOG, I thought that bcp38 could be a solution, but some people said that this solution would create a problem in multihome networks. What is the exact optimum solution? Where should I look? How can I create a plan that can be presented to the necessary places? Currently, all existing or old ISPs and datacenters in Türkiye have completely lost hope in resolving the problem. References: https://www.linkedin.com/posts/taygun-firinci_son-zamanlarda-servis-sa%C4%9F... https://spoofer.caida.org/recent_tests.php?as_include=&country_include=tur&no_block=1 Best Practices for Deploying SAV: https://manrs.org/2023/04/why-is-source-address-validation-still-a-problem/
BCP38 is the solution, but getting networks to actually implement it is a challenge. It can be achieved in a few different ways. When you say it is a problem for multi-homed networks, I think you may be conflating BCP38 with uRPF specifically. BCP38 can be done without using uRPF, and I think it usually is. uRPF may cause issues with multi-homed networks from what I understand. --TimH On Sat, 5 Apr 2025 18:07:57 +0300 T. Fırıncı via NANOG <nanog@lists.nanog.org> wrote:
I thought that bcp38 could be a solution, but some people said that this solution would create a problem in multihome networks.
Source Address Validation is one of the key components to preventing spoofing. No network operator should be allowing packets to egress their network with source addresses that are external to their network, nor should they allow packets to ingress their network that have a source IP address internal to their network. The problem isn't in the implementation of BCP38, its network operators failing to do so. BCP38 technically could cause issues for multihoming networks, however if you are using your own IP space delegated by an RIR then it wouldn't be an issue. Where it could cause issues, is when you are using a source address from ISP A to send traffic via ISP B and they have strict filtering policies in place. There is no one single plan as every network is unique. One way to do this would be to filter packets at your border. Regards, Christopher Hawker On Sun, 06/04/2025 02:09 AM, "T. Fırıncı via NANOG" <nanog@lists.nanog.org> wrote:
Hello I am Taygun, I am a 23 year old who has been working in cyber security and information technologies as a hobby for about 13 years. There are countless people and institutions that have been victims of IP spoofing attacks that have increased recently in my country (Turkey). I started researching to find a solution to this problem and offer a solution to the ISPs and the IT institutions in my country. After brainstorming in the TRNOG group in Türkiye and on LinkedIn, such as NANOG, I thought that bcp38 could be a solution, but some people said that this solution would create a problem in multihome networks. What is the exact optimum solution? Where should I look? How can I create a plan that can be presented to the necessary places? Currently, all existing or old ISPs and datacenters in Türkiye have completely lost hope in resolving the problem.
References: https://www.linkedin.com/posts/taygun-firinci_son-zamanlarda-servis-sa%C4%9F... https://spoofer.caida.org/recent_tests.php?as_include=&country_include=tur&no_block=1 Best Practices for Deploying SAV: https://manrs.org/2023/04/why-is-source-address-validation-still-a-problem/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KXTZVI2F...
On Sat, Apr 5, 2025 at 8:07 AM T. Fırıncı via NANOG <nanog@lists.nanog.org> wrote:
I thought that bcp38 could be a solution, but some people said that this solution would create a problem in multihome networks.
Hi Taygun, BCP 38 works great on multihomed networks. Where it doesn't work is: 1) Large core peering scenarios where an ISP trades routes with another ISP and has to take that ISP's word for it that the offered routes are valid. 2) The customer side of Internet Transit service where the customer has to take the ISP's word for it that the presented routes are legitimate. What _does not_ work in multihomed networks is Reverse Path Filtering. You have to explicitly filter the routes and source IP addresses your customer has authenticated to you. You can't rely on their route advertisement to tell you what packets are legitimate because BGP routing tends to be asymmetric: packets in one direction often follow a different path than packets in the other. Strict RPF breaks multihoming and loose RPF falls far far short of meeting BCP 38's filtering requirement.
What is the exact optimum solution?
Depends on your source of authority. If you're constructing a government mandate then you require anyone selling Internet service in Turkey to implement BCP 38 on every paid Internet connection. That means egress filtering everywhere they buy transit or peering service inside or outside of Turkey and ingress filtering everywhere they sell Internet service inside and outside of Turkey. And you set large and escalating fines for every incident where the ISP is found to be in non-compliance. Then you sit back and let capitalism do what it does best: optimize for cost. If you're talking about voluntary industry action... give up. The BGPSEC effort fell apart and the people who care about BCP 38 already implement it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 06/04/2025 1:40, William Herrin via NANOG wrote: Based on the Spoofer project: https://spoofer.caida.org/country_stats.php https://spoofer.caida.org/recent_tests.php?country_include=tur the problem is diminishing constantly. Regards, Hank
On Sat, Apr 5, 2025 at 8:07 AM T. Fırıncı via NANOG <nanog@lists.nanog.org> wrote:
I thought that bcp38 could be a solution, but some people said that this solution would create a problem in multihome networks. Hi Taygun,
BCP 38 works great on multihomed networks. Where it doesn't work is:
1) Large core peering scenarios where an ISP trades routes with another ISP and has to take that ISP's word for it that the offered routes are valid. 2) The customer side of Internet Transit service where the customer has to take the ISP's word for it that the presented routes are legitimate.
What _does not_ work in multihomed networks is Reverse Path Filtering. You have to explicitly filter the routes and source IP addresses your customer has authenticated to you. You can't rely on their route advertisement to tell you what packets are legitimate because BGP routing tends to be asymmetric: packets in one direction often follow a different path than packets in the other. Strict RPF breaks multihoming and loose RPF falls far far short of meeting BCP 38's filtering requirement.
What is the exact optimum solution? Depends on your source of authority. If you're constructing a government mandate then you require anyone selling Internet service in Turkey to implement BCP 38 on every paid Internet connection. That means egress filtering everywhere they buy transit or peering service inside or outside of Turkey and ingress filtering everywhere they sell Internet service inside and outside of Turkey. And you set large and escalating fines for every incident where the ISP is found to be in non-compliance. Then you sit back and let capitalism do what it does best: optimize for cost.
If you're talking about voluntary industry action... give up. The BGPSEC effort fell apart and the people who care about BCP 38 already implement it.
Regards, Bill Herrin
In Türkiye, operators provide internet service to every customer with cgnat. Naturally, spoofing is not possible on these IPs. This may be the explanation for the IP blocks you see on the page you sent. According to my guess, most of the people who download and run spoofer want to do IP spoofing and have unintentionally contributed to the project (yes, I have seen examples recently). If a customer buys a static IP, they are taken to the public zone. Data centers and other customers who buy a public IP or uplink can generally do IP spoofing. Just a rumor, but I heard that an ISP in our country recently (still) dared to attack data centers with IP spoofing over its own infrastructure (still just a rumor).
Depends on your source of authority. If you're constructing a government mandate then you require anyone selling Internet service in Turkey to implement BCP 38 on every paid Internet connection. That means egress filtering everywhere they buy transit or peering service inside or outside of Turkey and ingress filtering everywhere they sell Internet service inside and outside of Turkey. And you set large and escalating fines for every incident where the ISP is found to be in non-compliance. Then you sit back and let capitalism do what it does best: optimize for cost.
I definitely agree. I am not very active in the sector but I am generally luckier than most people in reaching the authorities. The best plan I have in mind right now is to find the network topologies that TTNET, which is the central ISP in Türkiye, provides service to data centers, homes, and other ISPs, and to prepare a report that includes, in its simplest form, what can be done and how, what kind of a threat this poses to the country and the internet environment in general. Then all I have to do is print this report, give it to all the authorities I cross paths with, and run away :D Sorry for the late reply, I spend a lot of time on research, everything you write is very valuable to me. Regards, Taygun
The problem with the spoofer project is that the spoofer test client is most often not testing networks where attackers are sourcing their spoofed traffic from. The client is often run on volunteer’s laptops behind NATs on business or residential networks. I can assure you that spoofing is very much a problem, and the open tunnel vulnerability is going to make it much worse! https://github.com/vanhoefm/tunneltester On top of implementing SAV wherever possible, you need to be actively looking for spoofed traffic traversing your network and blocking it when you find it. Finding spoofed traffic can be done with netflow and/or ACLs (see Damian Menscher’s NANOG presentation https://youtu.be/q3TpdMZNeHg?t=969) . An easy way to look for this is to find traffic that matches this PCAP filter: ‘ip and udp and (src port 0 or src port 22 or src port 80 or src port 443) and (dst port 17 or dst port 19 or dst port 53 or dst port 69 or dst port 111 or dst port 123 or dst port 137 or dst port 161 or dst port 177 or dst port 389 or dst port 427 or dst port 520 or dst port 523 or dst port 631)’ This looks for invalid traffic with a forged source port of 0,22,80,443 to common ports used for DDoS amplification (port 53 is used the most by attackers). I have an open-source tool called Tattle Tale that will ingest netflow and help identify spoofed DDoS amplification traffic in real-time on your network. https://github.com/racompton/tattle-tale -Rich From: Hank Nussbacher via NANOG <nanog@lists.nanog.org> Date: Saturday, April 5, 2025 at 11:05 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Hank Nussbacher <hank@efes.iucc.ac.il> Subject: [NANOG] Re: How can the IP spoofing problem be solved within a country? On 06/04/2025 1:40, William Herrin via NANOG wrote: Based on the Spoofer project: https://urldefense.com/v3/__https://spoofer.caida.org/country_stats.php__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9DM7O6BQ$<https://urldefense.com/v3/__https:/spoofer.caida.org/country_stats.php__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9DM7O6BQ$> https://urldefense.com/v3/__https://spoofer.caida.org/recent_tests.php?country_include=tur__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk-_Q7mn4A$<https://urldefense.com/v3/__https:/spoofer.caida.org/recent_tests.php?country_include=tur__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk-_Q7mn4A$> the problem is diminishing constantly. Regards, Hank
On Sat, Apr 5, 2025 at 8:07 AM T. Fırıncı via NANOG <nanog@lists.nanog.org> wrote:
I thought that bcp38 could be a solution, but some people said that this solution would create a problem in multihome networks. Hi Taygun,
BCP 38 works great on multihomed networks. Where it doesn't work is:
1) Large core peering scenarios where an ISP trades routes with another ISP and has to take that ISP's word for it that the offered routes are valid. 2) The customer side of Internet Transit service where the customer has to take the ISP's word for it that the presented routes are legitimate.
What _does not_ work in multihomed networks is Reverse Path Filtering. You have to explicitly filter the routes and source IP addresses your customer has authenticated to you. You can't rely on their route advertisement to tell you what packets are legitimate because BGP routing tends to be asymmetric: packets in one direction often follow a different path than packets in the other. Strict RPF breaks multihoming and loose RPF falls far far short of meeting BCP 38's filtering requirement.
What is the exact optimum solution? Depends on your source of authority. If you're constructing a government mandate then you require anyone selling Internet service in Turkey to implement BCP 38 on every paid Internet connection. That means egress filtering everywhere they buy transit or peering service inside or outside of Turkey and ingress filtering everywhere they sell Internet service inside and outside of Turkey. And you set large and escalating fines for every incident where the ISP is found to be in non-compliance. Then you sit back and let capitalism do what it does best: optimize for cost.
If you're talking about voluntary industry action... give up. The BGPSEC effort fell apart and the people who care about BCP 38 already implement it.
Regards, Bill Herrin
_______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TW3OVQKQOBT774TFRVFV27FDGELLJDJM/__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9jdhy8Gw$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TW3OVQKQOBT774TFRVFV27FDGELLJDJM/__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9jdhy8Gw$>
"What is the exact optimum solution?” You build SAV into your architect. It is that simple. Start with the end in mind - ensure no packet leaves your part of the network if the IP source does NOT equal the IPs allocated to that network. It it does, you have FAILED as a network architect. People get caught up with the widgets you might use to achieve your archectural goals. How you do SAV depends on what you are building. What I would do on a 4G/5G architecture is different from an edge rack on a cloud/edge network which is then different from an office enterprise, which is different from a broadband provider which is different from my home network which is different from …… Taygun, people get all tided in knots debating on which is best - the nail, the wood screw, the bolt, the clamp, wood glue, duct tape …. All to connect to piece of wood together. Do not get lost in ’SAV widget debate.’ Focus on the regulatory requirement for networks to have SAV be integral to the network architecture. Yes, “regulator requirement” .. just like civil engineering architecture requirement to ensure a building is safe. It is the only way you are going to break the 80/20 problem. We reached 80% SAV deployment back in 2012 (see https://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/). People didn’t like my post, but it was reality. CAIDA got some funding to move the Spoofer project and do another year, but then that money disappeared. If you want Türkiye to deploy SAV effectively, then you go to the Telecom Regulator and ask for them to make it a licensed requirement. They do not need the knowledge of the “technical SAV widgets,” they just say - no spoofed packets.
What “Telecom Regulator” are you talking about?
On Apr 5, 2025, at 8:40 PM, Barry Greene via NANOG <nanog@lists.nanog.org> wrote:
"What is the exact optimum solution?”
You build SAV into your architect. It is that simple. Start with the end in mind - ensure no packet leaves your part of the network if the IP source does NOT equal the IPs allocated to that network.
It it does, you have FAILED as a network architect.
People get caught up with the widgets you might use to achieve your archectural goals. How you do SAV depends on what you are building. What I would do on a 4G/5G architecture is different from an edge rack on a cloud/edge network which is then different from an office enterprise, which is different from a broadband provider which is different from my home network which is different from ……
Taygun, people get all tided in knots debating on which is best - the nail, the wood screw, the bolt, the clamp, wood glue, duct tape …. All to connect to piece of wood together. Do not get lost in ’SAV widget debate.’
Focus on the regulatory requirement for networks to have SAV be integral to the network architecture. Yes, “regulator requirement” .. just like civil engineering architecture requirement to ensure a building is safe. It is the only way you are going to break the 80/20 problem. We reached 80% SAV deployment back in 2012 (see https://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/). People didn’t like my post, but it was reality. CAIDA got some funding to move the Spoofer project and do another year, but then that money disappeared.
If you want Türkiye to deploy SAV effectively, then you go to the Telecom Regulator and ask for them to make it a licensed requirement. They do not need the knowledge of the “technical SAV widgets,” they just say - no spoofed packets.
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AOI6DXPG...
On Apr 5, 2025, at 6:02 PM, sronan@ronan-online.com wrote:
What “Telecom Regulator” are you talking about?
A quick AI query …. The Information and Communication Technologies Authority (ICTA), known in Turkish as Bilgi Teknolojileri ve İletişim Kurumu (BTK), serves as Turkey's national regulatory and inspection authority for telecommunications and internet services. Established on January 29, 2000, it was initially named the Telecommunications Authority (Telekomünikasyon Kurumu) before adopting its current title. The ICTA is tasked with overseeing electronic communications, including the regulation of internet services. It operates under the broader policy framework set by the Ministry of Transport and Infrastructure, which is responsible for policy-making in the electronic communications sector. While the BTK has broad authority to implement regulations ensuring the security and proper functioning of communication networks, there is no publicly available information indicating that it has explicitly mandated Source Address Validation (SAV) across all internet and telecom providers. However, given the BTK's extensive regulatory powers, it is within their jurisdiction to introduce such requirements if deemed necessary for network security or public interest.
Greetings, When I was teaching CIS classes at a local Community College, when we would cover Firewalls I always taught them to NOT be the reason someone else is suffering Distributed Denial Of Service (DDOS) attacks. And the way to do this was to follow the "Best Common Practibe 38" (BCP-38) found in the RFC's, to NEVER send out any packets that don't have a SOURCE ADRRESS that is one within your own network. NEVER spoof a source address that is not your own. http://www.bcp38.info/index.php/Main_Page --- Jay Nugent WB8TKL o Retired o Had a nice career at Washtenaw Community College, Nugent Telecommunications, ANS/NSFnet, AOL, GTE Telenet, Bell Northern Research, Northern Telecom, and others... On Sat, 5 Apr 2025, Barry Greene via NANOG wrote:
"What is the exact optimum solution?”
You build SAV into your architect. It is that simple. Start with the end in mind - ensure no packet leaves your part of the network if the IP source does NOT equal the IPs allocated to that network.
It it does, you have FAILED as a network architect.
People get caught up with the widgets you might use to achieve your archectural goals. How you do SAV depends on what you are building. What I would do on a 4G/5G architecture is different from an edge rack on a cloud/edge network which is then different from an office enterprise, which is different from a broadband provider which is different from my home network which is different from ……
Taygun, people get all tided in knots debating on which is best - the nail, the wood screw, the bolt, the clamp, wood glue, duct tape …. All to connect to piece of wood together. Do not get lost in ’SAV widget debate.’
Focus on the regulatory requirement for networks to have SAV be integral to the network architecture. Yes, “regulator requirement” .. just like civil engineering architecture requirement to ensure a building is safe. It is the only way you are going to break the 80/20 problem. We reached 80% SAV deployment back in 2012 (see https://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/). People didn’t like my post, but it was reality. CAIDA got some funding to move the Spoofer project and do another year, but then that money disappeared.
If you want Türkiye to deploy SAV effectively, then you go to the Telecom Regulator and ask for them to make it a licensed requirement. They do not need the knowledge of the “technical SAV widgets,” they just say - no spoofed packets.
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AOI6DXPG...
participants (10)
-
Barry Greene -
Christopher Hawker -
Compton, Rich -
firincitaygun＠gmail.com -
Hank Nussbacher -
Jay -
sronan＠ronan-online.com -
T. Fırıncı
-
Tim Howe -
William Herrin