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. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Miller" <dmiller@tiggee.com> Sent: Tuesday, January 28, 2014 2:47 PM To: "Jared Mauch" <jared@puck.nether.net>, Valdis.Kletnieks@vt.edu Cc: "NANOG" <nanog@nanog.org> Subject: Re: BCP38.info On 1/28/2014 2:16 PM, Jared Mauch wrote:
On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
52731 ASN7922
It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
The data only includes those where the "source-ASN" and "dest-asn" of these packets don't match.
Hang on Jared, I'm trying to wrap my head around this. You're saying that AS7922 has over 50K IP addresses which, if you send a DNS query to that IP, you get an answer back from *an entirely different ASN*? How the heck does *that* happen?
Yup.
Jared, What you detected is a misconfiguration of devices on those networks, but that misconfiguration (in and of itself) is not necessarily what is commonly referred to as "IP spoofing" in the context of BCP38. You have *not* "shown" that these ASNs "allow IP spoofing". You have collected one data point that indicates the mere possibility that these ASNs allow IP spoofing. In the example that you provided, you sent a DNS query to a Pacenet (India) IP and received a response from a Vodafone (India) IP address. The IP from which you received the invalid response is an open resolver (bad thing). It is completely plausible that whatever device is being queried has interfaces on both networks. To have "shown" that this ASN "allows IP spoofing" you must have demonstrated that this response packet, sourced from a Vodafone IP, entered the "Internet" from a Pacenet router interface. Unless I am missing something here, you haven't come close to showing that. -DMM
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
Hi, Jared Mauch wrote on 1/28/14 9:03 PM:
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.
At the Internet Society we are flashing out an idea of an anti-spoofing "movement", where ISPs can list themselves as not spoofing-capable on our website. The requirement is that they can demonstrate that they block spoofed packets, for instance by successfully running the Spoofer test. I think your, Jared, test can add to this picture. Sort of a positive spin on the name and shame technique. It is not ideal, as one test is not a real proof of such capability, but might help raising awareness, at least. Does this sound as something that can be useful and fly? Andrei
Not working in the Internet access business but as Internet citizen this sounds interesting. You would need some motivations to make ISPs register and perhaps some kind of validation in the future. But as initial step it sounds cool. .as On Wed, Jan 29, 2014 at 10:16 AM, Andrei Robachevsky <robachevsky@isoc.org> wrote:
Hi,
Jared Mauch wrote on 1/28/14 9:03 PM:
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.
At the Internet Society we are flashing out an idea of an anti-spoofing "movement", where ISPs can list themselves as not spoofing-capable on our website. The requirement is that they can demonstrate that they block spoofed packets, for instance by successfully running the Spoofer test. I think your, Jared, test can add to this picture.
Sort of a positive spin on the name and shame technique.
It is not ideal, as one test is not a real proof of such capability, but might help raising awareness, at least. Does this sound as something that can be useful and fly?
On Jan 29, 2014, at 3:03 AM, Jared Mauch <jared@puck.nether.net> wrote:
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.
This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Feb 3, 2014, at 2:22 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing.
It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . . ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Feb 3, 2014, at 2:55 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . .
Another question is whether or not it's possible that in at least some cases, MITMing boxes on intermediary networks are grabbing these queries and then spoofing the scanner source IP as they redirect the queries . . . . if this is taking place, then it would be the network(s) with the MITMing box(es) which allow spoofing, irrespective of whether or not the intended destination networks do, yes? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
Hi, I think I might have already deleted subject matter a few days ago in re: BCP38. What exactly are you trying to do? I agree my general comment about the recent NTP weaknesses should be addressed via IPv6 RFC may have been mis-understood. I meant mostly that with IPv6 NAT goes away, all devices are exposed, and we also have the 'internet of things' - much more subject to potential abuse. An NTPv5 solution that could be done with NTP services already, and would be more of a 'best practices of how this shit starts up and what it can do' and educating vendors to have reasonable behavior in the first place? And an NTPv6 solution/RFC/guideline that was similar, could help? Neither will 'solve the problem' - but I think the idea of managing what somebody can do and having the provider filter in/out on IPv4 and/or mobile ipV4, much less ipV6 is very unorthodox and much against the spirit of having global m:n communications be helpful for humanity. My apologies if I mis-understand your recent and last few e-mails. I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol to 'protect the end user' is the wrong way to go when compared to just having things work in a secure manner. - Mike On Feb 3, 2014, at 12:07 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Feb 3, 2014, at 2:55 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . .
Another question is whether or not it's possible that in at least some cases, MITMing boxes on intermediary networks are grabbing these queries and then spoofing the scanner source IP as they redirect the queries . . . . if this is taking place, then it would be the network(s) with the MITMing box(es) which allow spoofing, irrespective of whether or not the intended destination networks do, yes?
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
On Feb 3, 2014, at 3:24 PM, Michael DeMan <nanog@deman.com> wrote:
I meant mostly that with IPv6 NAT goes away,
I don't know if this is true or not - and even if it is true, it's going to be a long, long time before the IPv4 Internet goes away (like, maybe, pretty much forever, heh).
An NTPv5 solution that could be done with NTP services already, and would be more of a 'best practices of how this shit starts up and what it can do' and educating vendors to have reasonable behavior in the first place?
Yes, but that's many years away, and doesn't address legacy issues.
And an NTPv6 solution/RFC/guideline that was similar, could help?
Again, many years away, and doesn't address legacy issues.
I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol to 'protect the end user' is the wrong way to go when compared to just having things work in a secure manner.
Yes, but since the latter part of this statement is unattainable in the foreseeable future, the idea is actually to protect *the rest of the Internet* from misconfigured CPE. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, 03 Feb 2014 00:24:08 -0800, Michael DeMan said:
An NTPv5 solution that could be done with NTP services already
Doesn't matter - the same people that aren't upgrading to a correctly configured NTPv4 aren't going to upgrade to an NTPv5. No need at all for a protocol increment (and actually doing that has its own issues).
participants (7)
-
Andrei Robachevsky -
Arturo Servin -
Dobbins, Roland -
Jared Mauch -
Michael DeMan -
Nick Olsen -
Valdis.Kletnieks＠vt.edu