I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives. On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason@lixfeld.ca> wrote: On 2013-03-31, at 10:48 AM, Jay Ashworth <jra@baylink.com> wrote:
Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering?
I'm hoping for something that could be downloaded by users and run, and try to forge a few packets to somewhere useful, which could be logged somehow in conjunction with some unforged packets containing a traceroute, so we could build up a database of leaky networks.
On a related topic, while I know GRC Research's Steve Gibson is a bit of a polarizing personality, he does have a fairly sizable consumer audience, and might be a great distribution venue for such a thing.
Or, perhaps, is there someone on here from Ookla?
Patrick? Could Akamai be persuaded to take an interest in this as a research project?
From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period. Most network operators are probably either too inexperienced to understand or too lazy to care.
I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?
On 2013-03-31, at 9:43 PM, Peter Baldridge <petebaldridge@gmail.com> wrote:
I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives.
Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets.
On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason@lixfeld.ca> wrote:
On 2013-03-31, at 10:48 AM, Jay Ashworth <jra@baylink.com> wrote:
Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering?
I'm hoping for something that could be downloaded by users and run, and try to forge a few packets to somewhere useful, which could be logged somehow in conjunction with some unforged packets containing a traceroute, so we could build up a database of leaky networks.
On a related topic, while I know GRC Research's Steve Gibson is a bit of a polarizing personality, he does have a fairly sizable consumer audience, and might be a great distribution venue for such a thing.
Or, perhaps, is there someone on here from Ookla?
Patrick? Could Akamai be persuaded to take an interest in this as a research project?
From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period. Most network operators are probably either too inexperienced to understand or too lazy to care.
I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?
On 03/31/13 21:50, Jason Lixfeld wrote:
On 2013-03-31, at 9:43 PM, Peter Baldridge <petebaldridge@gmail.com> wrote:
I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives. Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets.
On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason@lixfeld.ca> wrote:
On 2013-03-31, at 10:48 AM, Jay Ashworth <jra@baylink.com> wrote:
Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering?
I'm hoping for something that could be downloaded by users and run, and try to forge a few packets to somewhere useful, which could be logged somehow in conjunction with some unforged packets containing a traceroute, so we could build up a database of leaky networks.
On a related topic, while I know GRC Research's Steve Gibson is a bit of a polarizing personality, he does have a fairly sizable consumer audience, and might be a great distribution venue for such a thing.
Or, perhaps, is there someone on here from Ookla?
Patrick? Could Akamai be persuaded to take an interest in this as a research project?
From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period. Most network operators are probably either too inexperienced to understand or too lazy to care.
I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?
An easy target would be anti-virus/trojan/security software providers that could add a BCP38 check to their software =D ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
----- Original Message -----
From: "Alain Hebert" <ahebert@pubnix.net>
An easy target would be anti-virus/trojan/security software providers that could add a BCP38 check to their software =D
Yes, but penetration is a problem, which is why I was thinking about people like YouTube, Ookla, and the like. Any Flash app that lots of people run frequently. Assuming those apps could generate the packets, which, on reflection, I would bet they can't. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
The good news is that source address spoofing does seem to fail with most CPE's NAT. At the end of the day, just turn on uRPF and/or use ACLs. It's amazing how much destination 192.168.0.0/24 and 192.168.1.0/24 our ACLs also block. Frank -----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Sunday, March 31, 2013 9:35 PM To: NANOG Subject: Re: BCP38 tester? ----- Original Message -----
From: "Alain Hebert" <ahebert@pubnix.net>
An easy target would be anti-virus/trojan/security software providers that could add a BCP38 check to their software =D
Yes, but penetration is a problem, which is why I was thinking about people like YouTube, Ookla, and the like. Any Flash app that lots of people run frequently. Assuming those apps could generate the packets, which, on reflection, I would bet they can't. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Sun, Mar 31, 2013 at 6:50 PM, Jason Lixfeld <jason@lixfeld.ca> wrote:
Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets.
I guess I can see that. You then have a question of implementation. Wouldn't a majority of those customers have a bridged connection with the providers CPE being a transparent bridged modem. So either a customer's cheap router (good luck getting those guys to add a feature) would have to do the check, or the modem would have to check with the router for ip and then do packet inspection. I'm not debating that this would be a good fix and eliminate the effect of botnets, but the home router market isn't going to be influenced by providers. If it sells at a big box electronics store, it will be in circulation. It seems that the only people who would care at the home networking level aren't likely to be contributing to the botnets. On the other hand, any ISP that would want this as a feature in their modems, would find it easier to implement on commercial hardware. It would work and it's a good idea, I just don't see it gaining traction in the right places to be effective. The answer still rests with providers.
participants (5)
-
Alain Hebert -
Frank Bulk (iname.com) -
Jason Lixfeld -
Jay Ashworth -
Peter Baldridge