Is this an accurate thumbnail summary of BCP38 (ignoring for the moment the issues of multi-home), or is there something I missed?
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
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.
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.
/kc
So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on every interface sending packets out to the internet, to block any source address matching a subnet in the BOGON list OR not matching any of my routeable network subnets? Plus add null-route entries for all the BOGONs in my routing table so I don't send a bad destination packet to my upstream?
Re Stephen,
So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on
every interface sending packets out to the internet, to block any source
address matching a subnet in the BOGON list OR not matching any of my
routeable network subnets? Plus add null-route entries for all the BOGONs
in my routing table so I don't send a bad destination packet to my upstream?
The correct way to implement this is
- outgoing permit my allocated address blocks as source addresses
- outgoing deny EVERYTHING (else)
Elmar.
BCP38 only provides for disallowing spoofed packets into the Internet. Any additional filtering against bosons, etc., are probably a good idea, just not including specifically in BCP38.
- ferg
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.So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on every interface sending packets out to the internet, to block any source address matching a subnet in the BOGON list OR not matching any of my routeable network subnets?
TBF, I would assume that you don't have routable/allocated networks within BOGON ranges, so just "if src in mynets permit else discard" covers both sets.
Plus add null-route entries for all the BOGONs in my routing table so I don't send a bad destination packet to my upstream?
I don't think that falls within the purview of BCP38 as BCP38 has to do with source address filtering/verification rather than destination. If you're running full tables and filtering BOGONs on BGP import, though, you shouldn't have routes for BOGONs in your tables and with a 0/0 discard should be dropping them anyway, but if you're not running full tables and so need to "punch holes" in a static default, then explicit null-routes for BOGON destinations would do it. Honestly, though: your upstream probably drops BOGON destinations anyway, so dropping BOGON destinations within your own network is just (a) good hygiene and (b) saves from your transit bill however may bps of BOGON-destined traffic you have.
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?
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.
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.
-Laszlo
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.
I start with customer interfaces and configure them to only allow traffic with a source address in their assigned subnet.
~Seth
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?
I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."
From the conversations I've had with ISPs, the inability to manage
legitimate traffic from dual homed customer networks is the most
significant bar to widespread BCP38. I realize there's no way to do
it automatically now, but it doesn't seem like total rocket science to
come up with some way for providers to pass down a signed object to
the customer routers that the routers can then pass back up to the
customer's other providers.
R's,
John
PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.
Are you talking BGP level customers or individual small businesses' broadband service?
From: "John Levine" <johnl@iecc.com>
To: nanog@nanog.org
Sent: Monday, September 26, 2016 11:04:33 AM
Subject: Re: Request for comment -- BCP38If 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?I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."From the conversations I've had with ISPs, the inability to manage
legitimate traffic from dual homed customer networks is the most
significant bar to widespread BCP38. I realize there's no way to do
it automatically now, but it doesn't seem like total rocket science to
come up with some way for providers to pass down a signed object to
the customer routers that the routers can then pass back up to the
customer's other providers.R's,
JohnPS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.
Are you talking BGP level customers or individual small businesses' broadband service?
I myself am talking about the latter and included the option of PI space to cover that (although I guess at some point this can be made fly with PA space from another provider if both providers are willing enough to play ball), though from the $50/mo figure John listed, I'm assuming he's talking about the latter.
Do people really expect to be able to do this on residential or small business broadband networks? I can't remember any time in recent memory where I assumed I could set a source address to any IP I fancy and have that packet successfully make its way through the SP's network.
From: "John Levine" <johnl@iecc.com>
To: nanog@nanog.org
Sent: Monday, September 26, 2016 11:04:33 AM
Subject: Re: Request for comment -- BCP38If 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?I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."From the conversations I've had with ISPs, the inability to manage
legitimate traffic from dual homed customer networks is the most
significant bar to widespread BCP38. I realize there's no way to do
it automatically now, but it doesn't seem like total rocket science to
come up with some way for providers to pass down a signed object to
the customer routers that the routers can then pass back up to the
customer's other providers.R's,
JohnPS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.
Are you talking BGP level customers or individual small businesses' broadband service?
I myself am talking about the latter...
...dammit...obviously "former" here, not "latter". Caffeine injection requisitioned.
I don't agree that this is legitimate.
Also we're talking about typical mom & pop home users here.
I'll sell you a multihoming capable service at a price that includes my
time in maintaining your bespoke configuration, but my off-the-shelf
home-user service is going to be BCP38.
Aled
I would assume that on a broadband grade connection it shouldn't work unless you have a niche player and proper LOA.
I would assume that on a BGP level circuit that it would work, again, given proper documentation (LOAs, IRRDB entry, etc.). IRRDBs make this wonderfully easier. By default, deny. Allow whatever is in the IRRDB entry. $250 for manual changes.
I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."I myself am talking about the latter and included the option of PI space to cover that (although I guess at some point this can be made fly with PA space from another provider if both providers are willing enough to play ball), though from the $50/mo figure John listed, I'm assuming he's talking about the latter.
Who said $50/mo?
Apparently I need even more caffeine that I first imagined...
If we're talking about networks with that kind of MRC, is it really that far of a stretch to require PI space for this? Then again: If we're talking about that kind of MRC, then I'm assuming ISP A can be coaxed to allow explicit and well-defined exceptions on the customer's links.
This discussion started wrt to COTS dual-ISP routers though, as mentioned in Ken Chase's message, no? Where I'm assuming we're talking about mom-and-pop operations rather than a $50K/mo business account.
If we're talking about networks with that kind of MRC, is it really that far of a stretch to require PI space for this? Then again: If we're talking about that kind of MRC, then I'm assuming ISP A can be coaxed to allow explicit and well-defined exceptions on the customer's links.
Yes.
A) Check the prices for PI space, if you can even get any.
B) Our network works fine with PA space. If you claim otherwise, we know plenty of other operators who aren't as wedged as you are.
Trying to solve technical problems with social solutions rarely works. See for example, the sad history of passwords.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
If we're talking about networks with that kind of MRC, is it really that far of a stretch to require PI space for this? Then again: If we're talking about that kind of MRC, then I'm assuming ISP A can be coaxed to allow explicit and well-defined exceptions on the customer's links.
Yes.
A) Check the prices for PI space, if you can even get any.
B) Our network works fine with PA space. If you claim otherwise, we know plenty of other operators who aren't as wedged as you are.
Trying to solve technical problems with social solutions rarely works. See for example, the sad history of passwords.
Mike and Aled covering this better than I am.