Well, coming up with a Mediawiki registration protocol that's hard to spam is apparently more difficult than I'd thought. For the moment, anyone who wants to contribute to the wiki, and to the expanded deployment of BCP38, is invited to toss a note to moderator [at] bcp38.info with a username, and we'll tell it to set you up an account and mail you a password manually. Sorry for the speedbump. I just want to tell you good luck. We're all counting on you. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Perhaps instead of trying to do this as a new independent activity (with all of the difficulties that entails), the community would be better served by documenting this information as a BCOP or two or three???
$0.02 ~Chris On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth <jra@baylink.com> wrote:
Well, coming up with a Mediawiki registration protocol that's hard to spam is apparently more difficult than I'd thought.
For the moment, anyone who wants to contribute to the wiki, and to the expanded deployment of BCP38, is invited to toss a note to moderator [at] bcp38.info with a username, and we'll tell it to set you up an account and mail you a password manually.
Sorry for the speedbump.
I just want to tell you good luck. We're all counting on you.
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- @ChrisGrundemann http://chrisgrundemann.com
Good stuff on this topic assembled by Barry Greene here: http://confluence.senki.org/pages/viewpage.action?pageId=1474569 Tony On Sat, Jan 25, 2014 at 7:57 PM, Chris Grundemann <cgrundemann@gmail.com>wrote:
Perhaps instead of trying to do this as a new independent activity (with all of the difficulties that entails), the community would be better served by documenting this information as a BCOP or two or three???
$0.02 ~Chris
On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth <jra@baylink.com> wrote:
Well, coming up with a Mediawiki registration protocol that's hard to spam is apparently more difficult than I'd thought.
For the moment, anyone who wants to contribute to the wiki, and to the expanded deployment of BCP38, is invited to toss a note to moderator [at] bcp38.info with a username, and we'll tell it to set you up an account and mail you a password manually.
Sorry for the speedbump.
I just want to tell you good luck. We're all counting on you.
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- @ChrisGrundemann http://chrisgrundemann.com
----- Original Message -----
From: "Chris Grundemann" <cgrundemann@gmail.com>
Perhaps instead of trying to do this as a new independent activity (with all of the difficulties that entails), the community would be better served by documenting this information as a BCOP or two or three???
Answering this on my phone last night, I didn't see Chris had carboned the group, so I will repeat on-list my observation that I stood up http://bestpractices.wikia.com something like 6 years ago, and couldn't get any traction on it then; I'm not sure I think much has changed -- apparently, extracting your BP thoughts from mailing list postings and putting them into a wiki is more effort than most NANOGers are up to. So no, perhaps attempting to load a rifle will be easier than a shotgun[1]. Cheers, -- jra [1] Firearms analogy not intended to encourage gun violence[2]. [2] Duh. -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Jan 26, 2014, at 12:47 PM, Jay Ashworth <jra@baylink.com> wrote:
something like 6 years ago, and couldn't get any traction on it then; I'm not sure I think much has changed -- apparently, extracting your BP thoughts from mailing list postings and putting them into a wiki is more effort than most NANOGers are up to.
I do have a list of the top ASNs that can be shown to allow IP spoofing by looking at the DNS scans part of the OpenResolverProject: 52731 ASN7922 31251 ASN9394 25241 ASN17964 15951 ASN4847 7576 ASN17430 5800 ASN17430 4110 ASN7497 3645 ASN9812 3492 ASN6854 http://openresolverproject.org/spoof-src-dst-asns-20140126.txt What the data is: It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.: [jared@hostname ~/spoof]$ dig @101.0.37.11 ;; reply from unexpected source: 182.19.83.65#53, expected 101.0.37.11#53 The data only includes those where the “source-ASN” and “dest-asn” of these packets don’t match. - Jared
We see this all the time with banking sites and some of the stock trading ones Todd On 1/28/2014 5:06 AM, Jared Mauch wrote:
On Jan 26, 2014, at 12:47 PM, Jay Ashworth <jra@baylink.com> wrote:
something like 6 years ago, and couldn't get any traction on it then; I'm not sure I think much has changed -- apparently, extracting your BP thoughts from mailing list postings and putting them into a wiki is more effort than most NANOGers are up to. I do have a list of the top ASNs that can be shown to allow IP spoofing by looking at the DNS scans part of the OpenResolverProject:
52731 ASN7922 31251 ASN9394 25241 ASN17964 15951 ASN4847 7576 ASN17430 5800 ASN17430 4110 ASN7497 3645 ASN9812 3492 ASN6854
http://openresolverproject.org/spoof-src-dst-asns-20140126.txt
What the data is:
It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
[jared@hostname ~/spoof]$ dig @101.0.37.11 ;; reply from unexpected source: 182.19.83.65#53, expected 101.0.37.11#53
The data only includes those where the “source-ASN” and “dest-asn” of these packets don’t match.
- Jared
-- ------------- Personal Email - Disclaimers Apply
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 dont 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? Hmm.. Comcast. Anybody over there have an explanation what's going on there?
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.
Hmm.. Comcast. Anybody over there have an explanation what's going on there?
Most of these devices are CPE that perform DNS redirection/proxy wrong because they didn't constrain their udp/53 rule in iptables to only work on the "inside" interface. They then send the packet to their configured DNS server (eg: 8.8.8.8) and rewrite the source address in the packet to be the IP address of the OpenResolverProject.org scanning server. They then spoof me to 8.8.8.8 and I get the response from there. I have a unique QNAME per-IP i send, so I can decrypt/decode this to get the original destination to detect this. I mentioned this in the past, so please don't act so surprised :) http://mailman.nanog.org/pipermail/nanog/2013-August/060246.html - Jared
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
David, * David Miller (dmiller@tiggee.com) wrote:
On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks@vt.edu wrote:
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.
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.
Sounds like he's got about 50k such data points, in some cases.
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.
If it was only one (and for those ASNs where it *is* only one, or even a few, IPs) then I'd tend to agree with you, however...
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.
We're talking about 50,000 distinct IPs which are doing this in some cases. It strikes me as at least pretty unlikely that all 50,000 devices (or 25,000 or 10,000 or what-have-you, if you want to consider that some devices might have multiple IPs) out there have multiple interfaces which cross ASN boundaries. Sure sounds to me like *someone* out there has some serious issues to deal with, and the rest of us are paying the price of their inaction. Thanks, Stephen
On Jan 28, 2014, at 2:46 PM, David Miller <dmiller@tiggee.com> wrote:
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.
No, i've shown that I send a packet to an IP address and It forwards a packet with *my* source address to a 3rd IP address (the configured DNS server). That DNS server is what responds to me. The 101.0.37.11 IP is allowed to spoof my IP address. Feel free to look at the other 261k lines in that file and let me know where I'm wrong. These are only the ones where the Cymru IP <-> ASN mapping service shows them in a *different* ASN, I have many others of these. Go ahead and search for 8.8.8.8 or 4.2.2.1 and similar at the website and look at these. You may find one in your network. If you compare this to the MIT spoofer project, they had ~18k samples from opt-in. This here could (in theory) be a larger dataset and generated by this indirect measurement. Since I have about a years of this data and have worked with others on researching some of these broken CPE behaviors with ISPs, the CPE vendors and others, I'm fairly confident in these results. Happy to continue the discussion here either on-list or off-list and in private with any networks trying to understand what is happening. I would love to hear from CPE vendors as well, but I've been doing a lot of other stuff so this isn't my primary focus. - Jared
On Jan 28, 2014, at 2:16 PM, Jared Mauch <jared@puck.nether.net> 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.
Hmm.. Comcast. Anybody over there have an explanation what's going on there?
So I owe an apology to Comcast for a few things here.. Thanks to a few people (Tony Tauber, Aaron Hopkins) I found an error in one of the scripts that decodes the “encoded” dns query name. It was misprocessing some data and it resulted in the 73.73.73.73 IP address occurring when it should not have. This IP maps to Comcast and resulted in wrong data here. This also means I need to go back and reprocess all the old data to correct for this constraint problem. (that should take awhile …) Once again, sorry to Comcast for this. Their numbers should be much lower. - Jared
participants (8)
-
Chris Grundemann -
David Miller -
Jared Mauch -
Jay Ashworth -
Stephen Frost -
TGLASSEY -
Tony Tauber -
Valdis.Kletnieks＠vt.edu