Request for comment -- BCP38
nanog at ics-il.net
Mon Sep 26 16:00:25 UTC 2016
The only asymmetric routing broken is when the source isn't in public Internet route-able space. That just leaves those multi-ISP WAN routers that NAT it.
Intelligent Computing Solutions
----- Original Message -----
From: "Laszlo Hanyecz" <laszlo at heliacal.net>
To: nanog at nanog.org
Sent: Monday, September 26, 2016 10:47:43 AM
Subject: Re: Request for comment -- BCP38
On 2016-09-26 15:12, Hugo Slabbert wrote:
> On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase <math at sizone.org> wrote:
>> This might break some of those badly-behaving "dual ISP" COTS routers
>> out there
>> that use different inbound from outbound paths since each is the
>> fastest of
>> either link.
> As it should.
> 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.
> If you want to play asymmetry tricks, get some PI space and make
> arrangements. If that's outside your wheelhouse, get an ISP that will
> sell this to you as a service either with dissimilar links they
> provide to you or over-the-top with tunnels etc.
> Playing NAT games with different classes of traffic to e.g. send
> traffic type 1 over ISP A and traffic type 2 over ISP B *BUT* using
> the corresponding source addresses in each case and having the traffic
> return back over the same links is fine and dandy. If you send
> traffic into an ISP-provided link using addresses from another
> provider, though, that ISP *should* be dropping that traffic. If they
> don't, send them here so we can yell at them.
So instead of being able to use simple destination based routes to
direct their traffic, like the service provider can, the CPE operator
has to learn and implement policy based routing and manage state to
juggle each of the IP addresses they are assigned. It's orders of
magnitude harder to do this with the current ecosystem of routers/CPEs,
than it is to add a destination route. I think stuff like this is one
of the reasons why many are hesitant to implement this type of
filtering. It makes a specific type of abuse easier to track down *for
someone else* but it doesn't help you much and it can cause debugging
nightmares when something doesn't work due to filtering.
>> I did this manually when I was messing around with multiple broadband
>> links on
>> a fbsd router years ago, was glad it worked at the time.
>> On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said:
>> >No -- BCP38 only prescribes filtering outbound to ensure that no
>> packets leave your network with IP source addresses which are not
>> from within your legitimate allocation.
>> > - ferg
>> >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell
>> <list at satchell.net> wrote:
>> >>Is this an accurate thumbnail summary of BCP38 (ignoring for the
>> >>the issues of multi-home), or is there something I missed?
>> >>> The basic philosophy of BCP38 boils down to two axioms:
>> >>> Don't let the "bad stuff" into your router
>> >>> Don't let the "bad stuff" leave your router
>> >>> The original definition of "bad stuff" is limited to source-
>> >>> address grooming both inbound and outbound. I've expanded on
>> >>> original definition by including rule generation to control
>> >>> broadcast address abuse.
>> >Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> Ken Chase - math at sizone.org Toronto Canada
More information about the NANOG