Agreed.
Our's listed for AS36295 are two customers, Which I know for a fact have
While I see what you're saying. It's still not "Spoofed". The device in question receives the request. And then generates a response with the src address of the egress interface of the device dst to the IP and port that requested it... In this case. The GRE tunnel. Unless I'm missing something here about replying to a request only on the interface which it ingressed the device. And the fact that it's UDP. not TCP. So it's fire-and-forget. Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From our point of view. We saw the packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRC>DNS-DST. Obviously, This only works because it's UDP. And TCP would be broken. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Jared Mauch" <jared@puck.nether.net> Sent: Tuesday, January 28, 2014 3:04 PM To: nick@flhsi.com Cc: "David Miller" <dmiller@tiggee.com>, Valdis.Kletnieks@vt.edu, "NANOG" <nanog@nanog.org> Subject: Re: BCP38.info On Jan 28, 2014, at 2:57 PM, Nick Olsen <nick@flhsi.com> wrote: their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. Sure, but this means that network is allowing the spoofing :) What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested. I'm seeing a lot of other email related to BCP-38 right now on another list, but I wanted to share some data (again) in public regarding the state of network spoofing out there. I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network. - jared
On Jan 28, 2014, at 4:07 PM, Nick Olsen <nick@flhsi.com> wrote:
While I see what you're saying. It's still not "Spoofed".
The device in question receives the request. And then generates a response with the src address of the egress interface of the device dst to the IP and port that requested it... In this case. The GRE tunnel. Unless I'm missing something here about replying to a request only on the interface which it ingressed the device. And the fact that it's UDP. not TCP. So it's fire-and-forget.
Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From our point of view. We saw the packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRC>DNS-DST.
Nope, what happens is I send from my IP address (lets say 10.0.0.1). I send a packet to 192.168.0.1. It has 172.16.0.1 as it's DNS server. 192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1. Since i'm "outside" it's "NAT", the rule ends up taking the source IP, which isn't part of it's "NAT" set, and ends up copying my "source" IP into the packet, then forwards it to the DNS server. 172.16.0.1 is responding to 10.0.0.1 DIRECTLY. It took me awhile in looking at this to figure out what was happening. Was interesting when you find out the 192.168.0.1 CPE was doing. You may not call it "spoofing" as it's doing what it was supposed to do/configured to do, but it shouldn't be sending the packet with *my* IP address. - Jared
Jarad is correct. There is lack of BCP38 filtering in the CPE ASN. Either the packet has gone "probe" -> CPE ->(*) recursive server -> "probe" or "probe" -> CPE -> recursive server -> CPE ->(*) "probe" (*) indicates the packet that should have been blocked depending apon how the NAT worked. In either case the CPE ASN had failed to check the source address of a packet. In the first case the source address of the query to the recursive server. In the second case the source address of the reply back to the probe after it had been through the NAT process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Jared Mauch wrote on 1/28/14 10:11 PM:
192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1. Since i'm "outside" it's "NAT", the rule ends up taking the source IP, which isn't part of it's "NAT" set, and ends up copying my "source" IP into the packet, then forwards it to the DNS server.
This is really broken. Do you have any idea as to why such rule is implemented? I also heard that some CPE implement exactly the same logic if one spoof src IP inside their NAT. I think that the Spoofer project discards tests from the inside NAT, but maybe they track such cases? Andrei
On 1/28/2014 1:07 PM, Nick Olsen wrote:
While I see what you're saying. It's still not "Spoofed".
The device in question receives the request. And then generates a response with the src address of the egress interface of the device dst to the IP and port that requested it... In this case. The GRE tunnel. Unless I'm missing something here about replying to a request only on the interface which it ingressed the device. And the fact that it's UDP. not TCP. So it's fire-and-forget.
No in this case the system is being hit with a MITM type attack
Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From our point of view. We saw the packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRC>DNS-DST.
Obviously, This only works because it's UDP. And TCP would be broken.
Nick Olsen Network Operations (855) FLSPEED x106
---------------------------------------- From: "Jared Mauch" <jared@puck.nether.net> Sent: Tuesday, January 28, 2014 3:04 PM To: nick@flhsi.com Cc: "David Miller" <dmiller@tiggee.com>, Valdis.Kletnieks@vt.edu, "NANOG" <nanog@nanog.org> Subject: Re: BCP38.info
On Jan 28, 2014, at 2:57 PM, Nick Olsen <nick@flhsi.com> wrote:
Agreed.
Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src.
Sure, but this means that network is allowing the spoofing :)
What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested.
I'm seeing a lot of other email related to BCP-38 right now on another list, but I wanted to share some data (again) in public regarding the state of network spoofing out there.
I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network.
- jared
-- ------------- Personal Email - Disclaimers Apply
participants (5)
-
Andrei Robachevsky -
Jared Mauch -
Mark Andrews -
Nick Olsen -
TGLASSEY