Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
- Original Message - From: Roland Dobbins rdobb...@arbor.net On Feb 8, 2014, at 4:25 AM, Chris Grundemann cgrundem...@gmail.com wrote: Documenting those various mechanisms which are actually utilized is the key here. =) Yes, as well as the various limitations and caveats, like the wholesale/retail issue (i.e., customers of my customer). And anyone who has factual data on that topic is invited to contribute it to (stop me if you've heard this one)... http://www.bcp38.info 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: Why won't providers source-filter attacks? Simple.
On 2/5/14, 7:11 PM, Mark Andrews ma...@isc.org wrote: Well when industries don't self regulate governments step in. This industry is demonstratably incapble of regulating itself in this area despite lots of evidence of the problems being caused for lots of years. Which industry is that? App providers that have not implemented? Hosting providers that have not? Transit providers that have not? Access network ISPs that have not? Large enterprises and education networks that have not? ;-) I still prefer a list of specific networks that need to pay attention to improving anti-spoofing since otherwise I think most of us are in violent agreement on the need. This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 years. Everybody else is having to deal the problems caused by these bad actors. Hell, I suspect you could send the directors to gaol or make them pay a heavy fine today by properly examining the existing laws. A new law would just make the problem more explicit. In the U.S. one of the FCC Communications Security, Reliability, and Interoperability Council (CSRIC) working groups is focused on this issue. I do not know what is happening in other jurisdictions. Jason
Re: Why won't providers source-filter attacks? Simple.
On 2/7/2014 1:26 PM, Livingood, Jason wrote: I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Why won't providers source-filter attacks? Simple.
On 2/7/14, 2:30 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/7/2014 1:26 PM, Livingood, Jason wrote: I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. Sorry - too many country-by-country regulators to keep track ofŠ
Re: Why won't providers source-filter attacks? Simple.
On 2/7/2014 1:44 PM, Livingood, Jason wrote: On 2/7/14, 2:30 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/7/2014 1:26 PM, Livingood, Jason wrote: I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. Sorry - too many country-by-country regulators to keep track ofŠ Each and every and any one of which can put you and me out of business. Or worse. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Feb 5, 2014, at 2:12 AM, Jimmy Hess mysi...@gmail.com wrote: On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. ... A good start would be to get BCP38 revised to router the Host requirements RFCs, to indicate that ingress filtering should be considered mandatory on site-facing interfaces. ... It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. If the standards documents still just call it a best practice what hope is there of having governments require it of the service providers that their networks are connected to, anyways? There is a significant difference between a best current practice (BCP) document from the IETF (a technical standards body) versus one which actually reflects the well-considered best practices of a large network operator forum. The latter would be of some interest to governments (and groups of governments) when they ask for any options that might help with their growing spam and DDoS concerns... FYI, /John
Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Feb 8, 2014, at 3:37 AM, John Curran jcur...@arin.net wrote: It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. Many already do - including operators of very large networks. There are operational, vendor, and topological considerations which mean that it's achieved utilizing various mechanisms in different scenarios. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Fri, Feb 7, 2014 at 2:07 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Feb 8, 2014, at 3:37 AM, John Curran jcur...@arin.net wrote: It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. Many already do - including operators of very large networks. There are operational, vendor, and topological considerations which mean that it's achieved utilizing various mechanisms in different scenarios. Documenting those various mechanisms which are actually utilized is the key here. =) $0.02 ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Feb 8, 2014, at 4:25 AM, Chris Grundemann cgrundem...@gmail.com wrote: Documenting those various mechanisms which are actually utilized is the key here. =) Yes, as well as the various limitations and caveats, like the wholesale/retail issue (i.e., customers of my customer). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Why won't providers source-filter attacks? Simple.
On Feb 5, 2014, at 2:46 AM, Saku Ytti s...@ytti.fi wrote: If we keep thinking this problem as last-mile port problem, it won't be solved in next 20 years. Because lot of those ports really can't do RPF and even if they can do it, they are on autopilot and next change is market forced fork-lift change. Company may not even employ technical personnel, only buy consulting when making changes. It can be solved, but not by NANOG. Imagine if Cable labs required all DOCSIS compliant cable modems to default to doing source address verification in the next version of DOCSIS? It would (eventually) get rolled out, and it would solve the problem. Even if it doesn't default to on, requiring the hardware to be capable would be a nice step. The consumer last mile is actually simpler in that there are a few organizations who control the standards. Efforts need to focus on getting the BCP38 stuff into those standards, ideally as mandatory defaults. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Why won't providers source-filter attacks? Simple.
On (2014-02-04 23:01 -0500), valdis.kletni...@vt.edu wrote: Regulation and audits works well enough for butchers, resturants etc. Remember once BCP 38 is implemented it is relatively easy to continue. The big step is getting it turned on in the first place which requires having the right equipment. Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. Time to name-and-shame. It's 2014. Who's still shipping gear that can't manage eyeball-facing BCP38? If we keep thinking this problem as last-mile port problem, it won't be solved in next 20 years. Because lot of those ports really can't do RPF and even if they can do it, they are on autopilot and next change is market forced fork-lift change. Company may not even employ technical personnel, only buy consulting when making changes. If we focus on transit borders, we can make spoofed DoS completely impractical very rapidly, as spoofing is then restricted inside domain, and if target isn't in same domain, you can't benefit from it. And as attacks are from distributed botnets, you'll simply generate more attack traffic by not spooffing, as you're not restricted inside spooffing domain. However transit border doing ACL is something that seems to very controversial, there is no universal consensus that it even should be done and quite few seem to do it. I feel we need to change this, and make community at large agree it is the BCP and solve the challenges presented. -- ++ytti
Re: Why won't providers source-filter attacks? Simple.
In message CABgOHgs0nEiTCQfOHM21cYwB5Z0PUpAnsWBqV=ppy4k24zw...@mail.gmail.com , Landon Stewart writes: --f46d042c63a5ad12dd04f1abc724 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4 February 2014 17:18, Mark Andrews ma...@isc.org wrote: That would never fly, because it would put the politicians at odds with the telecom buddies that make huge political donations. Hard to throw someone in jail then hit them up for campaign money. What will probably happen is the same thing we do with everything else that might be used for evil purposes but where we don't want to tackle the real underlying problem -- just write a law banning something and hope the problem goes away. No, you write a law requiring something, e.g. BCP 38 filtering by ISPs, and you audit it. You also make the ISPs directors liable for the impact that results from spoofed traffic from them. Making it law puts all the ISP's in the country on a equal footing with respect to implementation costs. This is a slippery slope if I've ever seen one. If we start having legislators making laws for how packets are served we are just begging for them to put their feet into all kinds of doors that we don't want them in. Well when industries don't self regulate governments step in. This industry is demonstratably incapble of regulating itself in this area despite lots of evidence of the problems being caused for lots of years. This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 years. Everybody else is having to deal the problems caused by these bad actors. Hell, I suspect you could send the directors to gaol or make them pay a heavy fine today by properly examining the existing laws. A new law would just make the problem more explicit. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Why won't providers source-filter attacks? Simple.
Well when industries don't self regulate governments step in. This industry is demonstratably incapble of regulating itself in this area despite lots of evidence of the problems being caused for lots of years. This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 years. Everybody else is having to deal the problems caused by these bad actors. Hell, I suspect you could send the directors to gaol or make them pay a heavy fine today by properly examining the existing laws. A new law would just make the problem more explicit. and the reason for the extreme hyperbole is that this problem is seriously affecting the service provider where you work?
Re: Why won't providers source-filter attacks? Simple.
On Wed, Feb 5, 2014 at 2:46 AM, Saku Ytti s...@ytti.fi wrote: If we keep thinking this problem as last-mile port problem, it won't be solved in next 20 years. Because lot of those ports really can't do RPF and even if [snip] The last-mile ports don't necessarily need RPF; a simple inbound access list on the ISP side... Or even outbound on CPE side, with all valid source addresses allowed, and nothing else: is just perfect. In essence; it is a last-mile problem, and that is part of the challenge. The last-mile is the best possible place to filter, without breaking things. As for the idea, that the world can take a shortcut, and filter in some manner at transit services is tantalizing, but also: is not quite adequate, and that's probably not going to happen either. [snip] However transit border doing ACL is something that seems to very controversial, there is no universal consensus that it even should be Anything that is likely to blackhole legitimate traffic is going to be controversial. IP source based filtering on transit links may very well fall into that category of greatly increasing that risk in many cases. Restricting the source IP address range in from transit links is a bad idea, unless you can be certain that no other source IPs will show up legitimately, which you cannot necessarily be. If i am a transit provider, and I connect with a peer network buying transit from me, then they get to route traffic over that link: according to the routes my network announced to their router. If my router discards any of that traffic based on source, then the route I propagated to my peer was dishonest --- that is, it would mean my route announcement was a lie: the filtering would in essence make some routes blackhole routes, and I am disrupting the connectivity for the unexpected source addresses, just by turning up that link. Or I am at risk of disrupting connectivity in the future, to any network that my downstream peer later interconnects with, if they will also provide transit in that relationship, and also... it would be a common practice on many networks to turn up such interconnections at a date before I or any other transit upstreams are informed. It is likely from time to time, that many transit downstreams will obtain additional address allocations, or that they will make additional network connections: especially, if in fact, my downstream peer is multihomed, possibly with numerous providers, and they may themselves be a transit provider. At a certain level; RPF does not work, because: by design, routing IN and OUT can very well be asymmetric traffic flows for networks that are multihomed. Not announcing the source to a specific network, doesn't make it OKAY for the adjacent transit network to drop traffic from that source. done and quite few seem to do it. I feel we need to change this, and make community at large agree it is the BCP and solve the challenges presented. -- -JH
Re: Why won't providers source-filter attacks? Simple.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/5/2014 7:06 PM, Jimmy Hess wrote: The last-mile is the best possible place to filter, without breaking things. I could not agree more. :-) - - 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/ iF4EAREIAAYFAlLy/5gACgkQKJasdVTchbKXbAEAqFswL2qtqIgRcALVMLdQA0H/ dRLvmDhCoXEmRtOB2B8BAMbH489q8lB/qdiEofYviAAnNA6aqpT38ASXDzBUKO/K =xjIk -END PGP SIGNATURE-
Re: Why won't providers source-filter attacks? Simple.
In message 52f2ff98.2030...@mykolab.com, Paul Ferguson writes: On 2/5/2014 7:06 PM, Jimmy Hess wrote: The last-mile is the best possible place to filter, without breaking things. I could not agree more. :-) - - ferg Remember last mile includes datacenter and noc. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Why won't providers source-filter attacks? Simple.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/5/2014 7:35 PM, Mark Andrews wrote: In message 52f2ff98.2030...@mykolab.com, Paul Ferguson writes: On 2/5/2014 7:06 PM, Jimmy Hess wrote: The last-mile is the best possible place to filter, without breaking things. I could not agree more. :-) - - ferg Remember last mile includes datacenter and noc. Whatever gets it done. I'm just sick of hearing why people can't do it, instead of reasons why they can. - - 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/ iF4EAREIAAYFAlLzBE8ACgkQKJasdVTchbL6mQEAo6p/QQxyEdiQkf1/91nteK1u z3zyR9QbO7dtDuEBftkBANAlfy+zqbMuOp03rIiPu/pk3Ixt+mo58Yjs3fOHfqUG =9wRN -END PGP SIGNATURE-
Re: Why won't providers source-filter attacks? Simple.
The last-mile is the best possible place to filter, without breaking things. I could not agree more. :-) very large consumer populations are on metro-ether-like things. and it gets kinkier from there, don't eat before looking at what ntt-east has done with ngn. i fear we really have most of the easy big deployments and all of the cool kids. we're down to statistically small stubborn do-nothings and some folk with equipment that will take years to be pushed off net. randy
Re: Why won't providers source-filter attacks? Simple.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/5/2014 7:43 PM, Randy Bush wrote: The last-mile is the best possible place to filter, without breaking things. I could not agree more. :-) very large consumer populations are on metro-ether-like things. and it gets kinkier from there, don't eat before looking at what ntt-east has done with ngn. i fear we really have most of the easy big deployments and all of the cool kids. we're down to statistically small stubborn do-nothings and some folk with equipment that will take years to be pushed off net. Maybe. Maybe not. I think it really depends how we approach the problem -- apparently our approaches up until now have been failures to a certain degree. At least 20-30% failure, if you believe the Spoofer Project numbers. I'd like to think (and I am not happy smiley person as you well know) that perhaps we can motivate some younger, brighter, ingenious people who have not been tilting at this for 15 years to consider new ways to approach this problem. :-) -- Smiley! - - 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/ iF4EAREIAAYFAlLzBggACgkQKJasdVTchbL8hwEAwXbejfCFaOQnqYz6v8xcXfb7 uTmSIWZj+kuiGh976lUA/A5gGGrrAzaVyp3SqX57p5AR8w9kfMQEEbVMLCn7il4R =FE9f -END PGP SIGNATURE-
Re: Why won't providers source-filter attacks? Simple.
I'd like to think (and I am not happy smiley person as you well know) that perhaps we can motivate some younger, brighter, ingenious people who have not been tilting at this for 15 years to consider new ways to approach this problem. :-) -- Smiley! we should definitely scream at them and threaten legal action and lightning strikes from the gods. randy
Re: Why won't providers source-filter attacks? Simple.
On 04/02/14 11:35, Jay Ashworth wrote: It *is in their commercial best interest (read: maximizing shareholder value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is forced -- it's actually their fiduciary duty not to. That's short-sighted, but I agree in that that's what happens. Not filtering doesn't prevent them to operate. *THIS* is the problem we have to fix. Source-based routing when going back to the backbone, at least on IPv6. It allows end-user multihoming with no BGP, and routers could be programmed to, by default, drop packages that don't know how to source-route, hence, automatically source filtering for those that don't care enough. Difficult to do. Will take years to develop and adopt... if at all.
Re: Why won't providers source-filter attacks? Simple.
In message 977303.7242.1391542533531.javamail.r...@benjamin.baylink.com, Jay Ashworth writes: - Original Message - From: Paul Ferguson fergdawgs...@mykolab.com (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. Nope: it's easy to explain; you merely have to be a cynical bastard: Attack traffic takes up bandwidth. Providers sell bandwidth. It *is in their commercial best interest (read: maximizing shareholder value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is forced -- it's actually their fiduciary duty not to. Then the need to be made criminally liable for the damage that it causes. Yes, the directors of these companies need to serve gaol time. *THIS* is the problem we have to fix. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.co m Designer The Things I Think RFC 210 0 Ashworth Associates http://www.bcp38.info 2000 Land Rover DI I St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 127 4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Why won't providers source-filter attacks? Simple.
Then the need to be made criminally liable for the damage that it causes. Yes, the directors of these companies need to serve gaol time. why not just have god send down lightning bolts? quicker and cheaper. or maybe they will just drown as the level of hyperbole keeps rising. randy
Re: Why won't providers source-filter attacks? Simple.
On 2/4/2014 5:00 PM, Mark Andrews wrote: Nope: it's easy to explain; you merely have to be a cynical bastard: Attack traffic takes up bandwidth. Providers sell bandwidth. It *is in their commercial best interest (read: maximizing shareholder value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is forced -- it's actually their fiduciary duty not to. Then the need to be made criminally liable for the damage that it causes. Yes, the directors of these companies need to serve gaol time. That would never fly, because it would put the politicians at odds with the telecom buddies that make huge political donations. Hard to throw someone in jail then hit them up for campaign money. What will probably happen is the same thing we do with everything else that might be used for evil purposes but where we don't want to tackle the real underlying problem -- just write a law banning something and hope the problem goes away. Make it illegal to posses a device capable of bandwith greater than 33.6Kbps without a special license, and BAM -- no more problems, overnight. For added political-style points, tack on a catchy moniker, like Immoral Bandwidth Prohibition, The War on DDOS, or High-Capacity Digital Assault Bandwidth to help sell it to the public. The public will be OK with their funny cat videos taking 19 hours to load if they know they're preventing bad guys from doing something evil. After all, it's worked flawlessly for alcohol, drugs and guns, so it MUST work for networks... and it's much easier than those silly, so-called solutions y'all are talking about! :p - Pete (P.S. Dear politicians: in case you're reading this, the above was satire and should not be construed as anything resembling a good idea.)
Re: Why won't providers source-filter attacks? Simple.
In message 52f17931.40...@alter3d.ca, Peter Kristolaitis writes: On 2/4/2014 5:00 PM, Mark Andrews wrote: Nope: it's easy to explain; you merely have to be a cynical bastard: Attack traffic takes up bandwidth. Providers sell bandwidth. It *is in their commercial best interest (read: maximizing shareholder value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is forced -- it's actually their fiduciary duty not to. Then the need to be made criminally liable for the damage that it causes. Yes, the directors of these companies need to serve gaol time. That would never fly, because it would put the politicians at odds with the telecom buddies that make huge political donations. Hard to throw someone in jail then hit them up for campaign money. What will probably happen is the same thing we do with everything else that might be used for evil purposes but where we don't want to tackle the real underlying problem -- just write a law banning something and hope the problem goes away. No, you write a law requiring something, e.g. BCP 38 filtering by ISPs, and you audit it. You also make the ISPs directors liable for the impact that results from spoofed traffic from them. Making it law puts all the ISP's in the country on a equal footing with respect to implementation costs. Make it illegal to posses a device capable of bandwith greater than 33.6Kbps without a special license, and BAM -- no more problems, overnight. For added political-style points, tack on a catchy moniker, like Immoral Bandwidth Prohibition, The War on DDOS, or High-Capacity Digital Assault Bandwidth to help sell it to the public. The public will be OK with their funny cat videos taking 19 hours to load if they know they're preventing bad guys from doing something evil. If you have millions of compromised customers it doesn't matter what bandwidth limits they have. You can still launch a amplifying reflection DDoS from hosts behind 300 baud links. After all, it's worked flawlessly for alcohol, drugs and guns, so it MUST work for networks... and it's much easier than those silly, so-called solutions y'all are talking about! :p Regulation and audits works well enough for butchers, resturants etc. Remember once BCP 38 is implemented it is relatively easy to continue. The big step is getting it turned on in the first place which requires having the right equipment. Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. - Pete (P.S. Dear politicians: in case you're reading this, the above was satire and should not be construed as anything resembling a good idea.) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Why won't providers source-filter attacks? Simple.
No, you write a law requiring something, e.g. BCP 38 filtering by ISPs, and you audit it. You also make the ISPs directors liable for the impact that results from spoofed traffic from them. Making it law puts all the ISP's in the country on a equal footing with respect to implementation costs. you have done this in your network, the isp for which you are an engineer? randy
Re: Why won't providers source-filter attacks? Simple.
On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: Regulation and audits works well enough for butchers, resturants etc. Remember once BCP 38 is implemented it is relatively easy to continue. The big step is getting it turned on in the first place which requires having the right equipment. Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. Time to name-and-shame. It's 2014. Who's still shipping gear that can't manage eyeball-facing BCP38? pgpqQICGIPHkH.pgp Description: PGP signature
Re: Why won't providers source-filter attacks? Simple.
On Tue, Feb 4, 2014 at 10:01 PM, valdis.kletni...@vt.edu wrote: On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. A good start would be to get BCP38 revised to router the Host requirements RFCs, to indicate that ingress filtering should be considered mandatory on site-facing interfaces. If the standards documents still just call it a best practice what hope is there of having governments require it of the service providers that their networks are connected to, anyways? Time to name-and-shame. It's 2014. Who's still shipping gear that can't manage eyeball-facing BCP38? -- -JH
