Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
Don't fight it. It's clear that implementation on a per-packet basis of RFC4824 (datagrams over Semaphore Flag Signaling System) would have prevented this entire situation. Refer to sections 3.3 and 3.4. -j On Mon, Feb 3, 2014 at 12:23 PM, Paul Ferguson fergdawgs...@mykolab.com wrote: On 2/2/2014 2:17 PM, Cb B wrote: And, i agree bcp38 would help but that was published 14 years ago. But what? Are you somehow implying that because BCP38 was ...published 14 years ago (RFC2267 was initially published in 1998, and it was subsequently replaced by RFC2827)?
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
Cool, thanks for the pointed. Now if we could get the data by ASN and publish it on a site like bcp38.info, that would be awesome. On 2/4/14, 11:03 PM, Frank Bulk frnk...@iname.com wrote: Here's such a report: http://spoofer.cmand.org/summary.php Frank -Original Message- From: Livingood, Jason [mailto:jason_living...@cable.comcast.com] Sent: Tuesday, February 04, 2014 6:53 PM To: Octavio Alvarez; North American Network Operators' Group Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] On 2/4/14, 7:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: What I'm failing to understand, and again, please excuse me if I'm oversimplifying, is what data do you need from researchers, specifically. What specific actionable data would be helpful? Why does the lack of the data prevent you from applying an ACL. What I am suggesting is that the community at large needs measurement data, rather than individual network operators (which already know if they do or do not implement BCP38). Only with a long list of operators that DO prevent spoofing and a list of those that DO NOT, backed up with a decent data set (enough measurement points, enough measurement tests, across enough time, with an openly shared methodology), can the community start to encourage non-adopters to change their position. Just my two cents though... Jason
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
I here tell the spoofer project people are looking to improve their data and stats... And reporting. On Feb 5, 2014 1:08 PM, Livingood, Jason jason_living...@cable.comcast.com wrote: Cool, thanks for the pointed. Now if we could get the data by ASN and publish it on a site like bcp38.info, that would be awesome. On 2/4/14, 11:03 PM, Frank Bulk frnk...@iname.com wrote: Here's such a report: http://spoofer.cmand.org/summary.php Frank -Original Message- From: Livingood, Jason [mailto:jason_living...@cable.comcast.com] Sent: Tuesday, February 04, 2014 6:53 PM To: Octavio Alvarez; North American Network Operators' Group Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] On 2/4/14, 7:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: What I'm failing to understand, and again, please excuse me if I'm oversimplifying, is what data do you need from researchers, specifically. What specific actionable data would be helpful? Why does the lack of the data prevent you from applying an ACL. What I am suggesting is that the community at large needs measurement data, rather than individual network operators (which already know if they do or do not implement BCP38). Only with a long list of operators that DO prevent spoofing and a list of those that DO NOT, backed up with a decent data set (enough measurement points, enough measurement tests, across enough time, with an openly shared methodology), can the community start to encourage non-adopters to change their position. Just my two cents though... Jason
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
- Original Message - From: Octavio Alvarez alvar...@alvarezp.ods.org Maybe I'm oversimplifying things but I'm really curious to know why can't the nearest-to-end-user ACL-enabled router simply have an ACL to only allows packets from end-users that has a valid source-address from the network segment they provide service to. The common answer, Octavio, at least *used to* be our line cards aren't smart enough to implement strict-unicast-RPF, and our boxes don't have enough horsepower to handle every packet through the CPU. As I've noted, I'm not sure I believe that's true of current generation gear, and if it *is*, then it should cost manufacturers business. 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
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 2/5/14, 1:24 PM, Jay Ashworth wrote: - Original Message - From: Octavio Alvarez alvar...@alvarezp.ods.org Maybe I'm oversimplifying things but I'm really curious to know why can't the nearest-to-end-user ACL-enabled router simply have an ACL to only allows packets from end-users that has a valid source-address from the network segment they provide service to. The common answer, Octavio, at least *used to* be our line cards aren't smart enough to implement strict-unicast-RPF, and our boxes don't have enough horsepower to handle every packet through the CPU. As I've noted, I'm not sure I believe that's true of current generation gear, and if it *is*, then it should cost manufacturers business. There are boxes that haven't aged out of the network yet where that's an issue, some are more datacenter-centric than others. force10 e1200 was one platform that had this limitation for example. Cheers, -- jra signature.asc Description: OpenPGP digital signature
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 2/5/14, 13:24, Jay Ashworth wrote: The common answer, Octavio, at least*used to* be our line cards aren't smart enough to implement strict-unicast-RPF, and our boxes don't have enough horsepower to handle every packet through the CPU. As I've noted, I'm not sure I believe that's true of current generation gear, and if it*is*, then it should cost manufacturers business. In Cisco 6500 land - which were very popular - Earl7 uRPF is limited to one of strict or loose (no mixing modes) for IPv4 only. Otherwise you have to rely on ACLs and the possibility of running out of TCAM space for them depending on density. The Sup2T (Earl8) does fix these limitations: uRPF is configurable per-interface basis and independent of IPv4/IPv6, and can be a mix of loose or strict mode. But Sup2T only came out in 2011. ~Seth
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth wrote: As I've noted, I'm not sure I believe that's true of current generation gear, and if it *is*, then it should cost manufacturers business. But only matters if you're refreshing or just starting out. A lot of operators have a large installed base of such kit, and given horsepower is still plenty, getting that swapped out is a tall ask. Mark. signature.asc Description: This is a digitally signed message part.
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
Sure. Part of the data collection task. Making sure all the current new gear knows how, still a good idea. On February 5, 2014 11:32:26 PM EST, Mark Tinka mark.ti...@seacom.mu wrote: On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth wrote: As I've noted, I'm not sure I believe that's true of current generation gear, and if it *is*, then it should cost manufacturers business. But only matters if you're refreshing or just starting out. A lot of operators have a large installed base of such kit, and given horsepower is still plenty, getting that swapped out is a tall ask. Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth wrote: Sure. Part of the data collection task. Making sure all the current new gear knows how, still a good idea. Yep - like Joel said; current kit supports it (well, the ones I buy, anyway), and certainly a good idea for operators to make sure their favorite vendor can support this when they run their next purchase cycle. Mark. signature.asc Description: This is a digitally signed message part.
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
I'm going to be somewhat of a pain in everybody's ass this year, pounding on the drum whenever the topic pops up. :-) On February 5, 2014 11:38:08 PM EST, Mark Tinka mark.ti...@seacom.mu wrote: On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth wrote: Sure. Part of the data collection task. Making sure all the current new gear knows how, still a good idea. Yep - like Joel said; current kit supports it (well, the ones I buy, anyway), and certainly a good idea for operators to make sure their favorite vendor can support this when they run their next purchase cycle. Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 2/5/2014 1:20 PM, Christopher Morrow wrote: I here tell the spoofer project people are looking to improve their data and stats... And reporting. I know it's not possible due to the limitations of javascript sandboxing, but this really needs to be browser based so it can be like DNSSEC or MX or IPV6 testing. Users (and reddit) can be coerced into clicking a link if it shows a happy green sign when they pass the test. Asking them to download an executable is too much for most of them. I'd also love a way as a network administrator that I could audit my own network. Even with all the correct knobs tweaked I occasionally find a site where someone turned up an interface and forgot some template commands, or in the case of gear that doesn't support it there might not be a filter on an upstream device even though there should be. It'd be nice to have a CM profile that would attempt to spoof something to a control server then alert if it works.
BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/4/2014 10:03 AM, Jared Mauch wrote: Ask your vendors for these features. Ask them to fix the bugs. The ball rolls uphill here and it's in their lap. Blaming the carriers is wrongheaded and putting it where it doesn't belong in many cases. Happy to discuss offline. I'd like to echo Jared's sentiment here -- collectively speaking, service providers need to figure out a way to deal with this issue, before some congresscritters start to try to introduce legislation that will force you to to do it in a way that no one will like. $.02, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLxLL4ACgkQKJasdVTchbJ95AEAm5GcMZUKvy5WDjycH8f4C4Dq 7t1inFCPmGhbmo/456kBAKpUxaf/y7eXVnsxo9/IvULsGEbrf8zdapuAOSUdJrem =v0jF -END PGP SIGNATURE-
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said: I'd like to echo Jared's sentiment here -- collectively speaking, service providers need to figure out a way to deal with this issue, before some congresscritters start to try to introduce legislation that will force you to to do it in a way that no one will like. Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? (And yes, I know that in the first case, it urges the customer to cough up the bucks, and in the second case, it's usually not a revenue generator) pgpJHtjhQejkY.pgp Description: PGP signature
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/4/2014 10:47 AM, valdis.kletni...@vt.edu wrote: On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said: I'd like to echo Jared's sentiment here -- collectively speaking, service providers need to figure out a way to deal with this issue, before some congresscritters start to try to introduce legislation that will force you to to do it in a way that no one will like. Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? (And yes, I know that in the first case, it urges the customer to cough up the bucks, and in the second case, it's usually not a revenue generator) It's a dichotomy that is... unexplainable for me personally. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLxNz8ACgkQKJasdVTchbJq6AEApzaaZ9PpPX30kUYAxsGZFzeV WR98y6VBxlocQE2oQFkBANSa4m0/JOGv+PDQovI4xSkjaE/Ru0V8woagAs1hS1C0 =KAL8 -END PGP SIGNATURE-
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
- Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? The purported argument is our edge concentrators don't have that knob/ enough horsepower to do it manually and stay on the line card. I'm not sure how accurate that argument is any more and (as I noted in another reply just now[1]), I'm officially not buying it anymore. Cheers, -- jra [1] http://www.bcp38.info/index.php/Information_for_equipment_manufacturers -- 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 [Was: Re: TWC (AS11351) blocking all NTP?]
On Tue, 4 Feb 2014, valdis.kletni...@vt.edu wrote: On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said: I'd like to echo Jared's sentiment here -- collectively speaking, service providers need to figure out a way to deal with this issue, before some congresscritters start to try to introduce legislation that will force you to to do it in a way that no one will like. Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? (And yes, I know that in the first case, it urges the customer to cough up the bucks, and in the second case, it's usually not a revenue generator) The only way this is going to get fixed is to make it more expensive to originate abuse than it is to block it. The only thing management is going to pay attention to is their pocketbooks. -Dan
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On Tue, Feb 4, 2014 at 1:47 PM, valdis.kletni...@vt.edu wrote: Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? The DOCSIS spec has source address verification (as I understand it, for about a decade.) It is deployed within at least one large cable access provider network I am familiar with (though I don't personally work on the DOCSIS side of things). Why don't enterprises, hosting and cloud providers do it? (I don't know that they don't, but I figured I'd just keep with the tone.) Enterprises know what prefixes they have so should drop outbound packets with source IPs other than those, right? Likewise hosting providers ought to put in some safeguards. What about cloud providers who also provide virtual OSes and other software? Are those VMs and their third-party software kept patched? All those folks also provide access at the network edge. Tony
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? i suspect the non-payment case is solved at a layer below three randy
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? i suspect the non-payment case is solved at a layer below three In a DOCSIS network the source address verification (as Tony said) is typically done on the CMTS IIRC. Turning a customer off for non-payment is done in an accounts management / billing system. While I am sure continuing to agree with each other that spoofing is bad, we lack actionable data. ;-) As I said in another thread, I think someone / some group needs to invest to collect actual data and share the results openly. So any volunteers out there? I¹m sure there are lots of ways to underwrite independent research on the subject (contact me off-list). Jason
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 04/02/14 16:31, Livingood, Jason wrote: Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? i suspect the non-payment case is solved at a layer below three In a DOCSIS network the source address verification (as Tony said) is typically done on the CMTS IIRC. Turning a customer off for non-payment is done in an accounts management / billing system. While I am sure continuing to agree with each other that spoofing is bad, we lack actionable data. ;-) As I said in another thread, I think someone / some group needs to invest to collect actual data and share the results openly. So any volunteers out there? I¹m sure there are lots of ways to underwrite independent research on the subject (contact me off-list). Maybe I'm oversimplifying things but I'm really curious to know why can't the nearest-to-end-user ACL-enabled router simply have an ACL to only allows packets from end-users that has a valid source-address from the network segment they provide service to. What I'm failing to understand, and again, please excuse me if I'm oversimplifying, is what data do you need from researchers, specifically. What specific actionable data would be helpful? Why does the lack of the data prevent you from applying an ACL.
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 2/4/14, 7:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: What I'm failing to understand, and again, please excuse me if I'm oversimplifying, is what data do you need from researchers, specifically. What specific actionable data would be helpful? Why does the lack of the data prevent you from applying an ACL. What I am suggesting is that the community at large needs measurement data, rather than individual network operators (which already know if they do or do not implement BCP38). Only with a long list of operators that DO prevent spoofing and a list of those that DO NOT, backed up with a decent data set (enough measurement points, enough measurement tests, across enough time, with an openly shared methodology), can the community start to encourage non-adopters to change their position. Just my two cents though... Jason
BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/2/2014 2:17 PM, Cb B wrote: And, i agree bcp38 would help but that was published 14 years ago. But what? Are you somehow implying that because BCP38 was ...published 14 years ago (RFC2267 was initially published in 1998, and it was subsequently replaced by RFC2827)? I hope not, because BCP38 filtering would still help stop spoofed traffic now perpetuating these attacks, 14 years after BCP38 was published, because spoofing is at the root of this problem (reflection/amplification attacks). This horse is not dead, and still deserves a lot of kicking. $.02, - - ferg (co-author of BCP38) - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLv3ocACgkQKJasdVTchbLhowEAuO9DSQiRswVeqpHSccHo060h cqmIB8XlaNkzEPQw1w0A/0G6cjvtWBiJfwWbWoTY7X3RRMHeN36RkYR+2TonyNBi =W2wU -END PGP SIGNATURE-
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On Feb 3, 2014 10:23 AM, Paul Ferguson fergdawgs...@mykolab.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/2/2014 2:17 PM, Cb B wrote: And, i agree bcp38 would help but that was published 14 years ago. But what? Are you somehow implying that because BCP38 was ...published 14 years ago (RFC2267 was initially published in 1998, and it was subsequently replaced by RFC2827)? I hope not, because BCP38 filtering would still help stop spoofed traffic now perpetuating these attacks, 14 years after BCP38 was published, because spoofing is at the root of this problem (reflection/amplification attacks). This horse is not dead, and still deserves a lot of kicking. $.02, - - ferg (co-author of BCP38) I completely agree. My sphere of influence is bcp38 compliant. And, networks that fail to support some form of bcp38 are nothing short of negligent. That said, i spend too much time taking defensive action against ipv4 amp udp attacks. And wishing others would deploy bcp38 does not solve today's ddos attacks. CB - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLv3ocACgkQKJasdVTchbLhowEAuO9DSQiRswVeqpHSccHo060h cqmIB8XlaNkzEPQw1w0A/0G6cjvtWBiJfwWbWoTY7X3RRMHeN36RkYR+2TonyNBi =W2wU -END PGP SIGNATURE-
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
- Original Message - From: Cb B cb.li...@gmail.com I completely agree. My sphere of influence is bcp38 compliant. And, networks that fail to support some form of bcp38 are nothing short of negligent. That said, i spend too much time taking defensive action against ipv4 amp udp attacks. And wishing others would deploy bcp38 does not solve today's ddos attacks. Nope. But providing a bigger, better tuned hammer to apply to people's heads may. So any contributions you can make to http://www.bcp38.info will be cheerfully accepted. :-) 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
