[151734] in North American Network Operators' Group
Re: BCP38 Deployment
daemon@ATHENA.MIT.EDU (Joe Provo)
Thu Mar 29 18:51:33 2012
Date: Thu, 29 Mar 2012 18:50:52 -0400
From: Joe Provo <nanog-post@rsuc.gweep.net>
To: NANOG list <nanog@nanog.org>
In-Reply-To: <D57C460F-FEC9-4E63-91F0-171D6A9A3C2A@virtualized.org>
Reply-To: nanog-post@rsuc.gweep.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote:
> Leo,
>
> On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote:
> >> #1) Money.
> >> #2) Laziness.
>
> > While Patrick is spot on, there is a third issue which is related
> > to money and laziness, but also has some unique aspects.
> >
> > BCP38 makes the assumption that the ISP does some "configuration"
> > to insure only properly sourced packets enter the network. That
> > may have been true when BCP38 was written, but no longer accurately
> > reflects how networks are built and operated.
>
> An interesting assertion. I haven't looked at how end-user
> networks are built recently. I had assumed there continue to be
> customer aggregation points within ISP infrastructure in which
> BCP38-type filtering could occur. You're saying this is no longer
> the case? What has replaced it?
uRFP was a trivial, 0-impact feature on the cisco VXR-based CMTS
platform. Assert a simple statement in the default config (along
with 'ips classless' and all your other standard config elements)
and job done. It assisted in reducing our abuse desk workload by
eliminating a class of attacks from us, so the trivial "cost" was
worth it in opex. ISTR it being on the required feature list for
additional CMTS evaluations but it has been many years since I
touched that kit.
Cheers,
Joe
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
