BCP38 For BGP Customers

Matthew Petach mpetach at netflight.com
Tue Nov 8 21:01:32 UTC 2022


On Tue, Nov 8, 2022 at 8:44 AM Grant Taylor via NANOG <nanog at nanog.org>
wrote:

> [...]
>
> I don't understand why you would want to allow packets that couldn't
> return the same path.
>
> As for asymmetrically routed packets, I would still expect a return path
> to exist, even if it's not utilized.
>
>
Grant,

You're thinking about it from the upstream perspective, where a route
could be accepted but depreferenced and thus not actively used.
Think about it from the downstream network's perspective, though.
If you're my upstream, and I don't want to use your link for inbound
traffic, but I'd like to be able to send out some traffic over the link,
how can I advertise the prefix to you in a way that would both ensure
that you have it in your table locally, so that uRPF is happy, but also
to ensure no packets actually make *use* of that routing table entry?
Sure, you could tag the routes with 'no-export', but that only prevents
the prefix from propagating outward, it doesn't prevent traffic on that
router from using the routing table entry.  You can try adjusting your
MED, and hope the upstream doesn't squash the MED back to a default
value it applies to all its customers.  For the most part, you're up
against
a wall.  You don't know how your upstream's route selection process is
stacked with respect to routes you advertise, so you have no certainty that
if you announce a prefix to them, it won't potentially be used to carry all
your inbound traffic.
The only way to be sure that you won't take inbound traffic on a link is to
not advertise the prefix at all across that link.

Why might this be necessary, you ask?

Imagine you've got links of different sizes on your network.
You have a 1G link to provider A
You have a 1G link to provider B
You have a 10G link to cheap provider C
You have a 10G link into a peering exchange

Somewhere beyond provider A, someone decides they don't like one of your
customers, and sends a 5Gbps DDoS flow at you.

If you continue advertising that prefix to provider A, everyone going
through
provider A will suffer, including all their customers.  You have plenty of
capacity
to take the inbound flow through the exchange point and through cheap
provider C.

So, you stop advertising the prefix under attack to provider A and provider
B, to ensure
the traffic doesn't saturate your 1G links.

Inbound traffic happily shifts to the exchange point port and provider C's
port.
Life is good.

Oh no!  Provider A has implemented uRPF, and now all their customers are
unhappy
because they can't reach your websites on that prefix, because the *return*
traffic
is still flowing out the 1G link directly to provider A.
Trying to implement a source-based routing filter to redirect all traffic
*coming* from
the prefix under attack destined to ISP A to instead go through ISP C is a
pain in the
butt.  So, you grudgingly stop accepting routes from ISP A, as that's the
only way to
make the uRPF pain stop.

Now, none of your traffic is flowing out the 1G link to ISP A;  their
customers are happy
again, because they can reach websites on your prefix that is under attack
(via ISP C,
or the exchange point).

At the end of the month, you look at your contracts, and realize that you
had to spend
a chunk of your limited engineering resources working around the upstream
uRPF filter,
and ultimately ended up not sending traffic across a link you were paying
for.

When renewal time comes, you decide it's not worth the headache to pay for
a link to
ISP A that you can't reliably use, and that requires manual intervention to
work around
whenever creative routing solutions are necessary.  You don't renew your
contract with
ISP A.

As Mr. Bush might say,
"I recommend all my competitors implement this in their networks."

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221108/a72634a0/attachment.html>


More information about the NANOG mailing list