Le 02/10/2014 12:28, Nick Hilliard a écrit :

It would probably be more productive to pressurise transit providers to enforce bcp38 on their customer links.

This. But let me ask you, how many transit provider actually implement strict prefix-filtering ? I've seen many using a max-prefix as their sole defense. Now, let's consider what you want is to match an interface ACL to prefixes received on a BGP session runing through the same interface. Ain't that what uRPF-strict is all about ? What are the known downsides to uRPF-strict ? When buying from transits, you either update your IRR for automatic perfix-filter generation on your transit's side, or start by a "BGP over SMTP" session. While the former could generate ACLs from a template, the latter will be prone to human error. And still, how many of us _really_ ensure their IRRs are always up-to-date ? Next in line : IXPs. You never really know what routes will be available or has to be filtered when 800+ AS, most with customers also using BGP, starts talking to the same route-server. Or maybe, the route-server could provide a flowspec AFI to send filters AND routes simultaneously. Would you trust it ? Will your router have enough silicon-horse-power to match both IP _and_ L2 headers at line-rate ? BCP38 aims at spoof prevention by filtering as close to the source as possible. Implementation on network's edge looks to me like a tricky one. Sharing the load amongst CPE is the best practice, and could be considered a requirement enforced by transit providers. Or shouldn't it ? Best regards, -- Jérôme Nicolle

On 02/10/2014 12:23, Jérôme Nicolle wrote:

This. But let me ask you, how many transit provider actually implement strict prefix-filtering ? I've seen many using a max-prefix as their sole defense.

Plenty do and have no back-end capability to handle this, other than email updates.

Now, let's consider what you want is to match an interface ACL to prefixes received on a BGP session runing through the same interface. Ain't that what uRPF-strict is all about ? What are the known downsides to uRPF-strict ?

Your bgp announcement to your upstream is not guaranteed to be there all the time. E.g. if you're doing maintenance and stop announcing bgp to your upstream for inbound traffic, but still want to depend on it for outbound traffic, urpf will trash things. urpf is only feasible for statically configured hand-offs.

When buying from transits, you either update your IRR for automatic perfix-filter generation on your transit's side, or start by a "BGP over SMTP" session. While the former could generate ACLs from a template, the latter will be prone to human error. And still, how many of us _really_ ensure their IRRs are always up-to-date ?

This only happens when there is a reason to do so.

Next in line : IXPs. You never really know what routes will be available or has to be filtered when 800+ AS, most with customers also using BGP, starts talking to the same route-server. Or maybe, the route-server could provide a flowspec AFI to send filters AND routes simultaneously.

IXPs are more difficult, but if your IXP is running a route server, they should be implementing strict prefix filtering. At least, this puts pressure on IXP participants to register their prefix at their local irrdb.

Would you trust it ? Will your router have enough silicon-horse-power to match both IP _and_ L2 headers at line-rate ?

probably yes on most routers with dedicated hardware for this, but it will depend on the number of acl entries.

BCP38 aims at spoof prevention by filtering as close to the source as possible. Implementation on network's edge looks to me like a tricky one. Sharing the load amongst CPE is the best practice, and could be considered a requirement enforced by transit providers. Or shouldn't it ?

urpf is appropriate for the ISP last hop. Static filters are suitable for the transit provider connecting that ISP to the rest of the network. Nick

On 10/02/14 08:37, Roland Dobbins wrote:

On Oct 2, 2014, at 7:16 PM, Alain Hebert <ahebert@pubnix.net> wrote:

...

BCP38 compliance is the exception not the norm. I'm not sure that's actually the case, practically-speaking.

NAT is an awful thing for many reasons, and it's negative in terms of its overall impact on security, but there's one actual benefit from it; it is effectively a form of anti-spoofing.

The prevalence of NAT on consumer broadband access networks means that those networks do not generally emit spoofed packets. The same goes for many SME networks, even though they oughtn't to be running NAT in front of their servers. You are right on that point, I keep forgetting about the little man :(

My mindset was set on DDoS and not C&C/SPAM/etc.

My guess is that the majority, if not all, of the reflection/amplification attacks we see are actually initiated from servers under the control of attackers and residing on hosting/co-location IDC networks which don't enforce anti-spoofing at the access, distribution, or peering/transit portions of their topologies. Some of these servers are tied into so-called 'booter' systems, whereas others are linked into more conventional C&C under the direct control of attackers, while still others are utilized to launch attacks 'by hand', as it were.

We had the same experience where you get a 1Mbps steam of DDoS amplification start on the 15th and end abruptly on the 30th at 23h55m (CC report cycle/reject is often around 15 days). Then on the 5th and end 15 days later... for a few month in a row.

Those networks are unmanaged and are likely to remain so (or are so-called 'bulletproof' networks catering to criminals). Their peers/upstream transits likewise are not enforcing anti-spoofing on ingress, nor are they monitoring traffic originating from these networks as it ingresses their own networks (and in any event, the traffic volume of the spoofed packets on the attack source - reflector/amplifier leg is relatively small).

So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago.

---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Equo ne credite, Teucri.

-- Laocoön

On Oct 2, 2014, at 8:37 AM, Roland Dobbins <rdobbins@arbor.net> wrote:

So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago.

We have not seen support from other customers of our vendors for these features in RFI/RFP. It has taken us sometimes a year (or more) to get software fixes for uRPF related defects. The network performance can be impacted for all users due to the penalty by turning on uRPF as well, so it’s not even technically viable if you want line-rate from certain hardware sets. (See RFI/RFP). I’ve tried to collect a list of other interested parties to include this in their purchasing process with 0 takers so have put this on the back burner and just kept measuring networks that permit spoofed packets instead. It’s like any other things (e.g.: BGP hygiene), many people don’t invest the time/though/resources to cause the necessary impact. - Jared

On 10/03/14 19:36, Jay Ashworth wrote:

----- Original Message -----

...

From: "Alain Hebert" <ahebert@pubnix.net> PS: About that uRPF Convo, we could dump all that knowledges into lets say... some comprehensive wiki page maybe =D That way when the topic arise we could just link to it. Gee, Alain...

where would people find a wiki like that?

Cheers, -- jra

On google maybe... I see someone is already squatting http://www.bcp38.info :( ( /end_of_friday_silliness )

On Thu, Oct 2, 2014 at 10:54 AM, <Valdis.Kletnieks@vt.edu> wrote:

The *real* problem isn't the testing. It's the assumption that you can actually *do* anything useful with this data. Name-n-shame probably won't get us far - and the way the US works, if there's a

At least "name and shame" is something more useful than nothing done. Ideally you would have transit providers and peering exchanges placing "Must implement BCP38" into their peering policy, and then they could use the data to help enforce their peering policies. -- -JH

On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote:

What about providers who knowingly allow IP spoofing, because it's profitable?

What about providers who knowingly host massive spam operations, because it's profitable? As in: http://www.spamhaus.org/statistics/networks/ We've been down this road before. Unless there is prompt, concerted, collective action (as there was AGIS) then there is zero reason for those behind such operations to do anything but keep collecting dirty money. So it's all good and well to *know* where the problems are: that's useful. But if the goal is to actually make the problems go away, then that'll require fingers on keyboards implementing null routing, firewalling, blacklisting etc. ---rsk

On Fri, Oct 03, 2014 at 08:54:32AM +1000, Mark Andrews wrote:

Or it will require legislation and I will assure that whatever is written not be liked. On the other hand everyone one in the country will be in the same boat.

I concur with you -- strongly. Legislation is not the answer, because (a) it only applies in limited jurisdictions and this is a global problem and (b) it will inevitably be written by those with the deepest pockets, see for example CAN-SPAM, crafted by and for spammers and their supporters. But legislation isn't necessary. Within limits (prescribed by contractual obligations) none of us are required to offer services to arbitrary parties. We *choose* to do so, by default, all day every day because that's why we have an Internet. But we're not *obligated* to do so: those services may be withheld in full or part at any time for any reason (or even without a reason). And this is where I quote the best thing I've ever read on this mailing list: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie Having observed, for example, the spam problem since its genesis, I can unequivocally state that the *only* thing that has ever addressed the problem (rather than merely addressing its symptoms) is SMTP blacklisting. Everything else has been ineffective, misdirected, wishful thinking. The same thing applies here: persistent, systemic sources of large-scale abuse via BCP-38 noncompliance are either: 1. Being operated by clueless, negligent, incompetent people or 2. Being operated by deliberately abusive people There are no other possibilities. (Note: "persistent, systemic". Transient, isolated problems happen to everyone and are not what I'm talking about here.) It's difficult to know which of those two are true via external observation, but it's not *necessary* to know: the appropriate remedial action remains the same in either case: stop giving them the means. ---rsk

Well (beware it is friday), On the 1st of January 2015: . Refuse every routes; . Start accepting only those passing some sort of BCP38 specs performed by some QSA =D; . ??? . Profit; On 10/03/14 15:03, Mikael Abrahamsson wrote:

On Fri, 3 Oct 2014, Rich Kulawiec wrote:

...

The same thing applies here: persistent, systemic sources of large-scale abuse via BCP-38 noncompliance are either:

1. Being operated by clueless, negligent, incompetent people or 2. Being operated by deliberately abusive people

There are no other possibilities. (Note: "persistent, systemic". Transient, isolated problems happen to everyone and are not what I'm talking about here.)

It's difficult to know which of those two are true via external observation, but it's not *necessary* to know: the appropriate remedial action remains the same in either case: stop giving them the means.

So how do we detect these and make sure they feel pain for not doing the right thing. The CIDR report hasn't incurred pain as far as I know, so public shaming doesn't seem to work even in cases where we can detect people incurring hurt on others. So how do we work this? It obviously hasn't worked so far, what do we change to make this work?

Rich Kulawiec wrote on 03/10/14 00:47:

We've been down this road before. Unless there is prompt, concerted, collective action (as there was AGIS) then there is zero reason for those behind such operations to do anything but keep collecting dirty money.

There is, please join: http://www.routingmanifesto.org/manrs/ Andrei