Re: Request for comment -- BCP38

[Octavio Alvarez <octalnanog () alvarezp org>]

On 09/26/2016 08:47 AM, Laszlo Hanyecz wrote:
> > If you have links from both ISP A and ISP B and decide to send traffic
> > out ISP A's link sourced from addresses ISP B allocated to you, ISP A
> > *should* drop that traffic on the floor.  There is no automated or
> > scalable way for ISP A to distinguish this "legitimate" use from
> > spoofing; unless you consider it scalable for ISP A to maintain
> > thousands if not more "exception" ACLs to uRPF and BCP38 egress
> > filters to cover all of the cases of customers X, Y, and Z sourcing
> > traffic into ISP A's network using IPs allocated to them by other ISPs?
>
> This is a legitimate and interesting use case that is broken by BCP38. 
> The effectiveness of BCP38 at reducing abuse is dubious, but the
> benefits of asymmetric routing are well understood.  Why should everyone
> have to go out of their way to break this.. it works fine if you just
> don't mess with it.

This is really wrong.

Any ISP reserves the right to drop irrelevant traffic, traffic that does
not belong to its network (read: dropping traffic that is not required
to fulfill or is preventing the fulfillment of its contractual and
technical requirements).

BCP38 does not get in the way of the above and provides some potential
benefits like avoiding blacklists in some cases, detecting attacks and
hacked computers and contributing to the greater good of the community
(yes, some ISPs choose to be good netizens as much as possible, and this
is good).

This means that applying BCP38 is just natural for those that wish to
adopt it. Furthermore, being against it means being against the right to
drop irrelevant traffic.

In turn, this means that whenever a technical problem comes in conflict
with BCP38, it is just a sign that there is some underlying technical
flaw in the global Internet structure that should be addressed. I see
this as a feature of BCP38.

BCP38 does not break anything that it is not already broken, like the
PD-addressing multihoming problem. The problem is not BCP38.

Octavio.