<p dir="ltr"><br>
On 29 Feb 2016 6:28 PM, "Jeff Young" <<a href="mailto:young@jsyoung.net">young@jsyoung.net</a>> wrote:<br>
>><br>
>> From: "Roland Dobbins" <<a href="mailto:rdobbins@arbor.net">rdobbins@arbor.net</a>><br>
>> Subject: Re: [AusNOG] MANRS Project - Fixing the Internet's routing security is urgent and requires collaboration<br>
>> Date: 29 February 2016 4:40:20 pm AEDT<br>
>> To: "<a href="mailto:ausnog@ausnog.net">ausnog@ausnog.net</a>" <<a href="mailto:ausnog@lists.ausnog.net">ausnog@lists.ausnog.net</a>><br>
>><br>
>><br>
>> On 29 Feb 2016, at 12:33, Mark Andrews wrote:<br>
>><br>
>>> So 16 years is not enough time for them to do the right thing?<br>
>><br>
>><br>
>> Ignorance and apathy are the key reasons we don't have near-universal source-address validation.  I'm not apologizing for anyone - you know very well that I advocate for implementing source-address validation, as you've seen/heard me talk about it many times before.<br>
>><br>
>> My point is that we're in the situation we're in, and not in some idealized situation, and it's important to understand that we can't wave a magic wand and make this happen overnight.  Access networks are the logical places to implement source-address validation by default, as they're the points in the network where it's least likely to cause operational problems and where the requisite features are available on most major hardware platforms.<br>
>><br>
>> -----------------------------------<br>
>> Roland Dobbins <<a href="mailto:rdobbins@arbor.net">rdobbins@arbor.net</a>><br>
>><br>
><br>
> While it may have taken some time for the equipment to support source-address-validation, at least from the statistics quoted, the situation is getting better<br>
> (more providers implementing checks).  <br>
></p>
<p dir="ltr">RPF is basically an automated form of ingress source address ACLs, so anything that can do those can enforce source address validation - which would include going back at least as far back as AGS+.</p>
<p dir="ltr">I was working on an enterprise network that had edge source address ACLs in 1998. There really aren't many excuses for not implementing them - even your switches might be able to do it if your routers can't.</p>
<p dir="ltr">> I wonder what could be said of the number of ISP’s using a registry to validate their customer’s (not peers) routing announcements?  Ignorance and apathy<br>
> have played an even larger role in route-hijacks (intentional or otherwise).  We’ve had the solution forever (validate your customer’s announcements) but <br>
> it would seem that few ISP’s implement it anymore.<br>
><br>
> I haven’t yet read the MANRS docs (I will) but it would seem that a system that ranks the accuracy of routing announcements per ISP based on their method<br>
> of accepting and propagating updates would be really useful.  If you run a completely clean system, keep your customers from announcing garbage, you get<br>
> a good rating and everyone trusts your updates.  If your customers are prone to announcing portions of the YouTube address space and you blithely pass it to<br>
> the world, not so much.<br>
><br>
> All we’d need is a knob to turn based on that measure of accuracy… Dampening is too big a stick, and to implement it in this way might be catastrophic, number <br>
> of prefixes to accept over time, smaller stick, maybe less consequences…  correlation? <br>
><br>
> If I think your routes are suspect perhaps I don’t accept an announcement from you until I hear it from someplace else?  or from some ISP I trust?  <br>
><br>
> just a thought (after hearing people complain about route hijacks during Apricot — took me way back)<br>
><br>
> _______________________________________________<br>
> AusNOG mailing list<br>
> <a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
> <a href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
><br>
</p>