[168748] in North American Network Operators' Group
Re: TWC (AS11351) blocking all NTP?
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Feb 4 11:24:05 2014
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAP-guGXbBfr3RqQC+KmQZydK042Aj6xANsMTM4rVx74yhbwj-w@mail.gmail.com>
Date: Tue, 4 Feb 2014 11:23:36 -0500
To: William Herrin <bill@herrin.us>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 4, 2014, at 11:04 AM, William Herrin <bill@herrin.us> wrote:
> On Sun, Feb 2, 2014 at 5:17 PM, Cb B <cb.list6@gmail.com> wrote:
>> And, i agree bcp38 would help but that was published 14 years ago.
>=20
> Howdy,
>=20
> If just three of the transit-free networks rewrote their peering
> contracts such that there was a $10k per day penalty for sending
> packets with source addresses the peer should reasonably have known
> were forged, this problem would go away in a matter of weeks. Granted
> it would also be helpful to have a BGP extension signifying
> allowed-source-but-don't-route so that RP filtering would work even
> when multihomed. Still, even without automatic RP filtering we're
> capable of preventing spoofed packets if financially incentivized.
>=20
> Thing is, they can't be the source of the solution until they stop
> being part of the problem.
I=92ve seen similar comments in other forums. We are all generally paid
for moving packets, not filtering them. The speed at which you can =
forward
packets can often cause increased $$. Using these features also impacts
performance, so the cost may actually be 2x in capex+opex to provision =
ports
due to reduced line-rate capability. =20
Even if you take a RPSL-IRR approach to building filters, and even if =
the router
can handle such long ACLs bug-free, you have some objects that expand to
cover 50-90% of the internet. They may be someones backup route at some
point because of =91something=92.
Clearly putting the filters as close to the source is helpful but =
detecting the
actual spoofed packet is hard. Take the thread from last-week about how =
I
can detect folks that are allowed to =93spoof=94, or =93forward=94/=93rewr=
ite=94 my packet
destination. Even if it goes over GRE to somewhere, that IP should only
be sourced from *my* host. At some point the rest of the trust comes =
into play
that the IP is correct. Too many devices are generous in what they =
accept
and allows these types of attack surfaces to be abused.
Until you find yourself on the receiving end of these types of things, =
you may not
ask for or pay for DDoS protection services, or advanced filtering, or =
even ask
your vendor to support these features. I have to wait months for fixes =
in the
features because no support from others in the industry on the platform, =
etc.
Those that are up in arms about this stuff seem to not be the ones =
asking
the vendors for features and fixes.
- Jared=
