|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Jared Mauch <jared@puck.nether.net> In-Reply-To: <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> Date: Thu, 2 Oct 2014 14:18:03 -0400 To: Roland Dobbins <rdobbins@arbor.net> Cc: "nanog@nanog.org list" <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org > On Oct 2, 2014, at 8:37 AM, Roland Dobbins <rdobbins@arbor.net> wrote: >=20 > 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.=20 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=92s not even technically viable if you want line-rate from certain = hardware sets. (See RFI/RFP). I=92ve 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=92s like any other things (e.g.: BGP hygiene), many people don=92t = invest the time/though/resources to cause the necessary impact. - Jared=
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |