Re: BCP38.info
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 robachev...@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?
Re: BCP38.info
On Feb 3, 2014, at 2:55 PM, Dobbins, Roland rdobb...@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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info, RELATING: TWC (AS11351) blocking all NTP?
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 rdobb...@arbor.net wrote: On Feb 3, 2014, at 2:55 PM, Dobbins, Roland rdobb...@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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info, RELATING: TWC (AS11351) blocking all NTP?
On Feb 3, 2014, at 3:24 PM, Michael DeMan na...@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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info, RELATING: TWC (AS11351) blocking all NTP?
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). pgpReYols1Oli.pgp Description: PGP signature
Re: BCP38.info
On Jan 29, 2014, at 3:03 AM, Jared Mauch ja...@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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info
On Jan 29, 2014, at 4:47 AM, Nick Olsen n...@flhsi.com wrote: After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was Spoofed. Forgive me for being slow, but doesn't this seem to imply that there isn't any antispoofing taking place at the GRE tunnel ingress? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info
On Feb 3, 2014, at 2:22 PM, Dobbins, Roland rdobb...@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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info
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
Re: BCP38.info
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
Re: BCP38.info
On Jan 26, 2014, at 12:47 PM, Jay Ashworth j...@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
Re: BCP38.info
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 j...@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
Re: BCP38.info
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? pgpmH0k3shr2L.pgp Description: PGP signature
Re: BCP38.info
On Jan 28, 2014, at 1:50 PM, valdis.kletni...@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
Re: BCP38.info
On 1/28/2014 2:16 PM, Jared Mauch wrote: On Jan 28, 2014, at 1:50 PM, valdis.kletni...@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 signature.asc Description: OpenPGP digital signature
Re: BCP38.info
David, * David Miller (dmil...@tiggee.com) wrote: On Jan 28, 2014, at 1:50 PM, valdis.kletni...@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 signature.asc Description: Digital signature
Re: BCP38.info
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 dmil...@tiggee.com Sent: Tuesday, January 28, 2014 2:47 PM To: Jared Mauch ja...@puck.nether.net, valdis.kletni...@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.kletni...@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
Re: BCP38.info
On Jan 28, 2014, at 2:46 PM, David Miller dmil...@tiggee.com wrote: On 1/28/2014 2:16 PM, Jared Mauch wrote: On Jan 28, 2014, at 1:50 PM, valdis.kletni...@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
Re: BCP38.info
On Jan 28, 2014, at 2:57 PM, Nick Olsen n...@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
Re: BCP38.info
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-SRCOurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRCDNS-DST. Obviously, This only works because it's UDP. And TCP would be broken. Nick Olsen Network Operations (855) FLSPEED x106 From: Jared Mauch ja...@puck.nether.net Sent: Tuesday, January 28, 2014 3:04 PM To: n...@flhsi.com Cc: David Miller dmil...@tiggee.com, valdis.kletni...@vt.edu, NANOG nanog@nanog.org Subject: Re: BCP38.info On Jan 28, 2014, at 2:57 PM, Nick Olsen n...@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
Re: BCP38.info
On Jan 28, 2014, at 4:07 PM, Nick Olsen n...@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-SRCOurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRCDNS-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
Re: BCP38.info
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: ma...@isc.org
Re: BCP38.info
Correct, The assumption is that NAT was in use here. After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was Spoofed. However, Explained further in detail about what he sees from other IP's on that list. And it clicked when he pointed out how many times 8.8.8.8 and 4.2.2.1..etc. pop up as the src of the reply. Nick Olsen Network Operations (855) FLSPEED x106 From: Mark Andrews ma...@isc.org Sent: Tuesday, January 28, 2014 4:40 PM To: Jared Mauch ja...@puck.nether.net Cc: n...@flhsi.com, NANOG nanog@nanog.org Subject: Re: BCP38.info 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: ma...@isc.org
Re: BCP38.info
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-SRCOurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRCDNS-DST. Obviously, This only works because it's UDP. And TCP would be broken. Nick Olsen Network Operations (855) FLSPEED x106 From: Jared Mauch ja...@puck.nether.net Sent: Tuesday, January 28, 2014 3:04 PM To: n...@flhsi.com Cc: David Miller dmil...@tiggee.com, valdis.kletni...@vt.edu, NANOG nanog@nanog.org Subject: Re: BCP38.info On Jan 28, 2014, at 2:57 PM, Nick Olsen n...@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
Re: BCP38.info
On Jan 28, 2014, at 2:16 PM, Jared Mauch ja...@puck.nether.net wrote: On Jan 28, 2014, at 1:50 PM, valdis.kletni...@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
Re: BCP38.info
- Original Message - From: Chris Grundemann cgrundem...@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??? http://bcop.nanog.org/ 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 j...@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
Re: BCP38.info
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??? http://bcop.nanog.org/ $0.02 ~Chris On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth j...@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 j...@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
Re: BCP38.info
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 cgrundem...@gmail.comwrote: 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??? http://bcop.nanog.org/ $0.02 ~Chris On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth j...@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 j...@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
Re: bcp38.info wiki signup problem
Well, Out of 25 accounts, 22 where for spamming. Even with captcha, etc. Since then I put a mention to contact modera...@bcp38.info for account creation. You'll see it if you are going through the [Log in] link http://www.bcp38.info/index.php?title=Special:UserLoginreturnto=Main+Page You're right, directly to [Sign up] wont work. Sorry :( - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 01/23/14 23:03, Jay Ashworth wrote: A kind soul has just pointed out to me that the register link on the BCP38 wiki: http://www.bcp38.info/index.php?title=Special:UserLoginreturnto=Main+Pagetype=signup isn't, um, working right now. I guess that might explain the lack of contributions. Oops. We'll get right on that, folks. :-} Cheers, -- jra
Re: BCP38.info is now active
On Fri, Mar 29, 2013 at 3:14 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Alain Hebert aheb...@pubnix.net http://www.BCP38.info is up. I can't prove that from my neck of the woods... $ dig www.bcp38.info ; DiG 9.7.6-P1 www.bcp38.info ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 22339 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.bcp38.info. IN A phil
Re: BCP38.info is now active
I get amusing results as well: delong-dhcp227:owen (182) ~/idisk_backup/draft-delong-ula-example % host www.bcp38.info www.bcp38.info has address 192.172.250.28 www.bcp38.info has IPv6 address 2607:2a00:1:6::c0ac:fa1c Host www.bcp38.info not found: 3(NXDOMAIN) Owen On Mar 29, 2013, at 15:24 , Phil Dyer p...@cluestick.net wrote: On Fri, Mar 29, 2013 at 3:14 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Alain Hebert aheb...@pubnix.net http://www.BCP38.info is up. I can't prove that from my neck of the woods... $ dig www.bcp38.info ; DiG 9.7.6-P1 www.bcp38.info ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 22339 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.bcp38.info. IN A phil
Re: BCP38.info is now active
Well, Usual failure from my part =D. But I think I see what's happening... ns1.bcp38.org ns2.bcp38.org Are not yet registered. I've move them to production servers until it complete. Let me know. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 03/29/13 18:37, Owen DeLong wrote: I get amusing results as well: delong-dhcp227:owen (182) ~/idisk_backup/draft-delong-ula-example % host www.bcp38.info www.bcp38.info has address 192.172.250.28 www.bcp38.info has IPv6 address 2607:2a00:1:6::c0ac:fa1c Host www.bcp38.info not found: 3(NXDOMAIN) Owen On Mar 29, 2013, at 15:24 , Phil Dyer p...@cluestick.net wrote: On Fri, Mar 29, 2013 at 3:14 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Alain Hebert aheb...@pubnix.net http://www.BCP38.info is up. I can't prove that from my neck of the woods... $ dig www.bcp38.info ; DiG 9.7.6-P1 www.bcp38.info ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 22339 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.bcp38.info. IN A phil
