Request for comment -- BCP38
Is this an accurate thumbnail summary of BCP38 (ignoring for the moment 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 the original definition by including rule generation to control broadcast address abuse.
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@satchell.net> wrote:
Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
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 the original definition by including rule generation to control broadcast address abuse.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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 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@satchell.net> wrote:
Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
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 the 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@sizone.org Toronto Canada
On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase <math@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? 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.
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
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@satchell.net> wrote:
Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
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 the 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@sizone.org Toronto Canada
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On 2016-09-26 15:12, Hugo Slabbert wrote:
On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase <math@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. -Laszlo
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
No -- BCP38 only prescribes filtering outbound to ensure that no
On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said: 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
Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
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
<list@satchell.net> wrote: the
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@sizone.org Toronto Canada
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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Laszlo Hanyecz" <laszlo@heliacal.net> To: nanog@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@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. -Laszlo
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
No -- BCP38 only prescribes filtering outbound to ensure that no
On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said: 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
Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
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
<list@satchell.net> wrote: the
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@sizone.org Toronto Canada
Den 26. sep. 2016 18.02 skrev "Mike Hammett" <nanog@ics-il.net>:
The only asymmetric routing broken is when the source isn't in public
From this follows that BCP38 can break things like traceroute and path MTU discovery in what is a very common setup. The only reason we do not have a bigger problem is that few networks will have a downward MTU change at this
Internet route-able space. That just leaves those multi-ISP WAN routers that NAT it. Some of our IP transits implement filtering. All of our transits assigned /30 subnets on the transit ports from their own range (the alternate would have be to ask us to supply the /30 from our pool). Our provider edge router will send back ICMP packets using the interface address from the interface that received the original packet. It will then route the packet using our normal routing table. This means we can receive some packet on transit port A and then route out a ICMP response on port B using the interface address from port A. But transit B filters this ICMP packet because it has a source address belonging to transit A. point in the network. Regards Baldur
* Baldur Norddahl:
Den 26. sep. 2016 18.02 skrev "Mike Hammett" <nanog@ics-il.net>:
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.
Some of our IP transits implement filtering. All of our transits assigned /30 subnets on the transit ports from their own range (the alternate would have be to ask us to supply the /30 from our pool).
Our provider edge router will send back ICMP packets using the interface address from the interface that received the original packet. It will then route the packet using our normal routing table.
This means we can receive some packet on transit port A and then route out a ICMP response on port B using the interface address from port A. But transit B filters this ICMP packet because it has a source address belonging to transit A.
Interesting. But this looks like a feature request for the router vendor, and not like an issue with BCP 38 filtering as such.
From this follows that BCP38 can break things like traceroute and path MTU discovery in what is a very common setup.
That doesn't follow. In order to break PMTUD, you also need an MTU drop. Is that a common configuration for routers in points in the network where this would matter?
This means we can receive some packet on transit port A and then route out
a ICMP response on port B using the interface address from port A. But transit B filters this ICMP packet because it has a source address belonging to transit A. Interesting. But this looks like a feature request for the router vendor, and not like an issue with BCP 38 filtering as such.
Can you quote an RFC for anything that the router is doing wrong? Is there a requirement that a router must support source routing? In our case we actually did contact the vendor. Turns out that it will do source routing but not for packets from the control plane. There is no way to resolve the issue with the current software available to us. The vendor is not priotizing fixing this as I am also unable to point to any RFC that is being violated. Even if or when we get a fix, this will continue to be a problem because it is a very common setup. There are thousands of networks out there that have the issue and many of them are probably not even realising it.
From this follows that BCP38 can break things like traceroute and path MTU discovery in what is a very common setup. That doesn't follow. In order to break PMTUD, you also need an MTU drop. Is that a common configuration for routers in points in the network where this would matter?
It is not a common configuration which was what I said in the text you removed from that quote: "From this follows that BCP38 can break things like traceroute and path MTU discovery in what is a very common setup. The only reason we do not have a bigger problem is that few networks will have a downward MTU change at this point in the network". Besides it appears that path MTU is broken in general. We accept the problem because the only actual consequence is that traceroute is a little funky. Regards, Baldur
* Baldur Norddahl:
This means we can receive some packet on transit port A and then route out
a ICMP response on port B using the interface address from port A. But transit B filters this ICMP packet because it has a source address belonging to transit A. Interesting. But this looks like a feature request for the router vendor, and not like an issue with BCP 38 filtering as such.
Can you quote an RFC for anything that the router is doing wrong? Is there a requirement that a router must support source routing?
It's not an RFC conformance issue (several implementations of source address selection are possible). But it appears to make it rather difficult to configure it in such a way it does what you need, and it looks like a reasonable enhancement request.
In our case we actually did contact the vendor. Turns out that it will do source routing but not for packets from the control plane. There is no way to resolve the issue with the current software available to us. The vendor is not priotizing fixing this as I am also unable to point to any RFC that is being violated.
Source routing is not required to fix this. Other options are using a globally routed IP address for the source address (this can also be used to conserve address space because the interface addresses will not matter anymore), or chosing the interface address based on the outgoing interface.
I have a question regarding language. We've seen bcp38 described as a forwarding filter, preventing unallocated sources from leaving the AS. I understand that unicast reverse path forwarding checks support bcp38, but urpf is an input check with significant technical differences from output filters. Are urpf and bcp38 interchangeable terms in this discussion? It seems impractical and operationally risky to implement two unique ways to dos customers. What are the lessons learned by operators doing static output filters, strict urpf, or loose/feasible urpf? For a new implementation, I assume the safe bet is to start with loose urpf. Even if it stops only some traffic it at least gives the network to dip its toes and expose some customer brokenness. Bcp38
From my allocation accept, else deny
Urpf loose
From route table exist accept, else deny
Urpf strict
From next hop interface true accept, else deny
On Sep 27, 2016 4:52 AM, "Florian Weimer" <fw@deneb.enyo.de> wrote:
* Baldur Norddahl:
This means we can receive some packet on transit port A and then route out
a ICMP response on port B using the interface address from port A. But transit B filters this ICMP packet because it has a source address belonging to transit A. Interesting. But this looks like a feature request for the router vendor, and not like an issue with BCP 38 filtering as such.
Can you quote an RFC for anything that the router is doing wrong? Is there a requirement that a router must support source routing?
It's not an RFC conformance issue (several implementations of source address selection are possible). But it appears to make it rather difficult to configure it in such a way it does what you need, and it looks like a reasonable enhancement request.
In our case we actually did contact the vendor. Turns out that it will do source routing but not for packets from the control plane. There is no way to resolve the issue with the current software available to us. The vendor is not priotizing fixing this as I am also unable to point to any RFC that is being violated.
Source routing is not required to fix this. Other options are using a globally routed IP address for the source address (this can also be used to conserve address space because the interface addresses will not matter anymore), or chosing the interface address based on the outgoing interface.
* Jason Iannone:
I have a question regarding language. We've seen bcp38 described as a forwarding filter, preventing unallocated sources from leaving the AS. I understand that unicast reverse path forwarding checks support bcp38, but urpf is an input check with significant technical differences from output filters.
Are urpf and bcp38 interchangeable terms in this discussion? It seems impractical and operationally risky to implement two unique ways to dos customers. What are the lessons learned by operators doing static output filters, strict urpf, or loose/feasible urpf?
Historically (in 1998, when RFC 2267 was released), BCP 38 was an egress filter applied at the AS boundary. A complainant would be able to identify the AS by looking at the IP address and contact the relevant ISP. Within the AS, that ISP could identify the actual packet source by other means. Reverse-path forwarding checks were explicitly ruled out as likely infeasible even in RFC 2267, except for links which are essentially dialups. Current terminology is more complicated. Personally, I think that mandating specific approaches such as BCP 38 or uRPF does not work. The goal should be to cut down spoofed traffic. Whether this is done by contracts (which are adhered to, obviously), monitoring or immediate technical enforcement in the routers, does not matter at all.
For a new implementation, I assume the safe bet is to start with loose urpf. Even if it stops only some traffic it at least gives the network to dip its toes and expose some customer brokenness.
If loose uRPF is effective at all depends a lot on network architecture.
----- Original Message -----
From: "Florian Weimer" <fw@deneb.enyo.de>
* Jason Iannone:
Are urpf and bcp38 interchangeable terms in this discussion? It seems impractical and operationally risky to implement two unique ways to dos customers. What are the lessons learned by operators doing static output filters, strict urpf, or loose/feasible urpf?
Historically (in 1998, when RFC 2267 was released), BCP 38 was an egress filter applied at the AS boundary.
You meant ingress, no? The control of the address space allocation resides with the upstream, as must control of the filtering. You *can* do BCP38 egress filtering on your network, but that filter would *be in control of the Bad Guys* whom we're trying to kill off. The filtering needs to be on the other side of the administrative span of control fence. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
* Jay R. Ashworth:
----- Original Message -----
From: "Florian Weimer" <fw@deneb.enyo.de>
* Jason Iannone:
Are urpf and bcp38 interchangeable terms in this discussion? It seems impractical and operationally risky to implement two unique ways to dos customers. What are the lessons learned by operators doing static output filters, strict urpf, or loose/feasible urpf?
Historically (in 1998, when RFC 2267 was released), BCP 38 was an egress filter applied at the AS boundary.
You meant ingress, no?
It's a bit murky. Section 4 suggests that it's not possible to apply ingress filters on dialup access concnetrators.
The control of the address space allocation resides with the upstream, as must control of the filtering.
That's not really true for customers who maintain their own routes and IP assignments/allocations.
You *can* do BCP38 egress filtering on your network, but that filter would *be in control of the Bad Guys* whom we're trying to kill off.
If you can't do ingress filtering (e.g. you do not give customers dedicated physical ports, or the equipment does not allow tying ports to specific IP addresses), egress filtering is surely better than nothing at all. In theory, it would not matter because the other side should have a matching ingress filter. In practice, egress filtering would make a significant difference in traceability of attacks. Any additional filtering would do so. Again, the goal should not be to deploy specific techonology in a certain way, but to reduce spoofing and attacks which cannot be traced back to the packet sources.
On 10/01/2016 06:39 PM, Jay R. Ashworth wrote:
You *can* do BCP38 egress filtering on your network, but that filter would *be in control of the Bad Guys* whom we're trying to kill off.
I don't see how you arrive at this conclusion. For an aggregating router, the Bad Guys(tm) don't get anywhere near the control plane of the thing. Besides, my security training (such as it is) demands that one implement defence in depth. Specifically, if the Bad Guys(tm) find a way around my ingress filtering, the egress filtering will bump 'em off. Where egress filtering really makes sense is with tunnels over SSH. I haven't found where I can "hook into" a SSH tunnel with Linux. I can turn off shell (and do), but the inbound packets look like local origination to the NetFilter. And (at this early time) The Rules(sm) say that you always ACCEPT packets to and from "lo". I've learned from hard experience that violating that rule breaks a lot of stuff. Then there is the web server case. The Bad Guys(tm) have access to PHP, or Perl, or even a user-level shell, but again NO ACCESS TO THE CONTROL PLANE. Do we really want web-generated packets to get a bye? (I want to put BGP egress filters on my mail servers, my FTP servers, my time servers, my *anything* servers. It's easy, and it means the defence gets as close to the source as I can get it.)
The filtering needs to be on the other side of the administrative span of control fence.
No reason NOT to have filtering on BOTH sides of that fence...
I'm trying to come up with a simple picture that embraces all the comments I've seen thus far on the definition of BCP38. The example scenario I'm about to paint may be over-simplified -- but I like to start simple. Given a single local inside network with: * multiple uplink providers (typical multi-home situation) * multiple edge routers, each connected to an upstream via a public routeable /30, and each further connected to the downstream inside network * 50 subnets (to pick a number) of routeable IP address space downstream from the edge routers, with routing announcements to the world that direct packets back to the edge routers BCP38 demands that ANY packet leaving ANY edge router to the upstream MUST have a source address: * within the 50 inside public route-able subnets, or * within a list of "my" addresses in the public /30 subnets. True statement? What am I missing here? (In this simplified view, I'm divorcing the BCP38 aspects from the practical effects of any policy or input filtering done by the upstreams, as I think that's a separate discussion -- important but off-topic right now for my understanding of BCP38 at its core. Those practical aspects can be added later, AFTER describing the basics.)
* Stephen Satchell:
Given a single local inside network with: * multiple uplink providers (typical multi-home situation) * multiple edge routers, each connected to an upstream via a public routeable /30, and each further connected to the downstream inside network * 50 subnets (to pick a number) of routeable IP address space downstream from the edge routers, with routing announcements to the world that direct packets back to the edge routers
BCP38 demands that ANY packet leaving ANY edge router to the upstream MUST have a source address: * within the 50 inside public route-able subnets, or * within a list of "my" addresses in the public /30 subnets.
True statement?
This depends on the agreements with the upstream providers. They might reasonably exclude their own /30 they provided to you and the /30s from the other providers. In general, packets from the /30s would not travel far anyway because they would wail source address verification checks at the upstream provider. Some providers also use globally unique, but unrouted addresses for transfer networks, for infrastructure protection purposes.
On 26 September 2016 at 16:47, Laszlo Hanyecz <laszlo@heliacal.net> wrote:
On 2016-09-26 15:12, Hugo Slabbert 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.
This is a legitimate and interesting use case that is broken by BCP38.
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
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.
This is a legitimate and interesting use case that is broken by BCP38.
I don't agree that this is legitimate.
Also we're talking about typical mom & pop home users here.
There are SOHO modems that will fall back to a second connection if the primary one fails, but that's not what we're talking about here. The customers I'm talking about are businesses large enough to have two dedicated upstreams, and a chunk of address spaced SWIP'ed from each. Some run BGP but I get the impression as likely as not they have static routes to the two upstreams. For people who missed it the last time, I said $50K/mo, not $50/mo. Letters matter. R's, John
On 2016-09-26 18:03, John Levine 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. This is a legitimate and interesting use case that is broken by BCP38. I don't agree that this is legitimate.
Also we're talking about typical mom & pop home users here. There are SOHO modems that will fall back to a second connection if the primary one fails, but that's not what we're talking about here.
The customers I'm talking about are businesses large enough to have two dedicated upstreams, and a chunk of address spaced SWIP'ed from each. Some run BGP but I get the impression as likely as not they have static routes to the two upstreams.
For people who missed it the last time, I said $50K/mo, not $50/mo. Letters matter.
This doesn't have to be $50k/mo though. If the connections weren't source address filtered for BCP38 and you could send packets down either one, the CPE could simply start with 2 default routes and take one out when it sees a connection go down. This could work with a cable + DSL connection even. It would be easy to further refine which connection to use for a particular service by simply adding a specific route for that service's address. This would be a lot better than having to restart everything after one of the connections fails. This would provide functionality similar to the BGP setup without any additional work from the service provider. People can't build CPE software that does this type of connection balancing because they can't rely on this working due to BCP38 implementation. In my experience the only way you can get people to stop source address filtering is if you mention BGP, but BGP shouldn't be required to do this. -Laszlo
R's, John
Guys, You're getting wrapped around the axle. Start by solving the 90% problem, and worry about the 10% one later. BGP38 addresses the former very well, and the other 10% requires enough manual labor already that you can charge it back. Eliot On 9/26/16 8:44 PM, Laszlo Hanyecz wrote:
On 2016-09-26 18:03, John Levine 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. This is a legitimate and interesting use case that is broken by BCP38. I don't agree that this is legitimate.
Also we're talking about typical mom & pop home users here. There are SOHO modems that will fall back to a second connection if the primary one fails, but that's not what we're talking about here.
The customers I'm talking about are businesses large enough to have two dedicated upstreams, and a chunk of address spaced SWIP'ed from each. Some run BGP but I get the impression as likely as not they have static routes to the two upstreams.
For people who missed it the last time, I said $50K/mo, not $50/mo. Letters matter.
This doesn't have to be $50k/mo though. If the connections weren't source address filtered for BCP38 and you could send packets down either one, the CPE could simply start with 2 default routes and take one out when it sees a connection go down. This could work with a cable + DSL connection even. It would be easy to further refine which connection to use for a particular service by simply adding a specific route for that service's address. This would be a lot better than having to restart everything after one of the connections fails. This would provide functionality similar to the BGP setup without any additional work from the service provider. People can't build CPE software that does this type of connection balancing because they can't rely on this working due to BCP38 implementation. In my experience the only way you can get people to stop source address filtering is if you mention BGP, but BGP shouldn't be required to do this.
-Laszlo
R's, John
BCP 38 does NOT prevent multi-homed clients. Naive deployment of BCP 38 prevents multi-homed clients. There is NOTHING in BCP 38 that says you may not also accept other prefixes allocated to your clients. BCP 38 says accept allocated address, drop everything else. Now it should be possible with ROA's to completely automate support for multi-homed clients as you can cryptographically verify the addresses allocated to your clients from other ISPs / RIRs. The DHCP server could generate a CERT for every allocation it hands out if a client requested it. This really only needs a DHCP option to be defined to request this. Just as it is possible to secure BGP it is possible to secure BCP 38 additional prefixes. BCP 38 is INGRESS filtering from your customers. Treating your own offices as a "customer" is also recommended. In message <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864@cisco.com>, Eliot Lear writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN From: Eliot Lear <lear@cisco.com> To: Laszlo Hanyecz <laszlo@heliacal.net>, nanog@nanog.org Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864@cisco.com> Subject: Re: Request for comment -- BCP38 References: <20160926180355.1229.qmail@ary.lan> <dc13dbd3-051c-2239-1ecb-3f4ab43b049a@heliacal.net> In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b049a@heliacal.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Guys,
You're getting wrapped around the axle. Start by solving the 90% problem, and worry about the 10% one later. BGP38 addresses the former very well, and the other 10% requires enough manual labor already that you can charge it back.
Eliot
On 9/26/16 8:44 PM, Laszlo Hanyecz wrote:
On 2016-09-26 18:03, John Levine 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=
*should* drop that traffic on the floor. This is a legitimate and interesting use case that is broken by BCP3=
A 8.
I don't agree that this is legitimate.
Also we're talking about typical mom & pop home users here. There are SOHO modems that will fall back to a second connection if the primary one fails, but that's not what we're talking about here.
The customers I'm talking about are businesses large enough to have two dedicated upstreams, and a chunk of address spaced SWIP'ed from each. Some run BGP but I get the impression as likely as not they have static routes to the two upstreams.
For people who missed it the last time, I said $50K/mo, not $50/mo.=20 Letters matter.
This doesn't have to be $50k/mo though. If the connections weren't source address filtered for BCP38 and you could send packets down either one, the CPE could simply start with 2 default routes and take one out when it sees a connection go down. This could work with a cable + DSL connection even. It would be easy to further refine which connection to use for a particular service by simply adding a specific route for that service's address. This would be a lot better than having to restart everything after one of the connections fails. =20 This would provide functionality similar to the BGP setup without any additional work from the service provider. People can't build CPE software that does this type of connection balancing because they can't rely on this working due to BCP38 implementation. In my experience the only way you can get people to stop source address filtering is if you mention BGP, but BGP shouldn't be required to do this.
-Laszlo
R's, John
--dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJX6YIpAAoJEIe2a0bZ0nozGHAH/3EXMt2/t68dgB92RPYyVSHR 46WpPPOEhD1Qd1s6MW4mhzhWWmv99RGwPm1ZXVzE9iIpMkptXEuzbsHz1V7mjsao 5MkIyzvWgF6qpe1kI1xZp2xoDa++XjfJqwUMg0swxji7idjkMILw6buE70lubOCB Uu2Y6uGPCnsIEcD106AxJYkP91BlBkBRPAFoBjbdZKRTs3+TYQgxS815qviSiDux MXhdxgpo8yg/B8knmjQwwIcG3+Ug5FvkPJyz88GQKwwU6nEIKUn2Zf3U/vw2vQTN 3K+DlRIGy6ZXani4ab58pswrrhFl9P9bocRom+cJQAqb3JwR60NuUX1/YKeTv2o= =HdDL -----END PGP SIGNATURE-----
--dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
This seems to have split into a few different sub-threads and had some cross-talk on which network is being described where (thanks in no small part to my flub on John's figures and target), but this seems to be exactly the kind of info folks are looking for but missing at http://www.bcp38.info. In the interest of clarity, does this roughly cover the options/challenges people are seeing at various types of networks? Network #1 ---------- Customer has PI space. ISP A learns routes to the customer's PI space across the customer links via BGP or even static routes. ISP A's active forwarding path to the PI space is via the customer link. We're assuming an edge provider, i.e. the customer is not providing transit for further downstream networks. BCP 38 implementation: Strict uRPF on customer-facing interfaces should "Just Work". If egress source address filtering is implemented, this can/should be populated from IRR data. Network #2 ---------- Same as #1, except while ISP A does have a valid forwarding path to the customer's PI space via the customer link, that is *not* the active path. Examples could be that customer prefers ingress via another link (either with ISP A or another provider altogether) and so prepends, uses provider communities to depref the advertisement below another path, etc. BCP38 implementation: Feasible Path RPF[1] should work, but AFAIK is not supported on all platforms. Failure modes should be considered, though, and using feasible path RPF would result in dropped traffic if the customer dropped the announcement to ISP A in the future. If Feasible Path RPF not supported or viable, IRR data can/should be used to generate customer interface input filters. Same as #1, if egress source address filtering is implemented, this can/should be populated from IRR data. Network #3 ---------- Same as #1, except the transit provider has *no* valid forwarding path to the customer's PI space via the customer link. IOW the customer is using the transit provider for egress *only*, not ingress. Feasible Path RPF is not viable. Input filters are required on customer-facing interfaces, and can/should be generated from IRR data. Same as #1 and 2, if egress source address filtering is implemented, this can/should be populated from IRR data. PA space variants to Networks #1 - 3 ------------------------------------ Flipping all of the above scenarios to PA space rather than PI, the options for implementing uRPF are the same. Where I would consider things becoming more challenging is on generating input filters on customer-facing interfaces were strict or Feasible Path RPF are not viable, or egress source address filters if those are in use. Mark: You mentioned the option of leveraging ROAs for validating customer prefixes allocated by other ISPs. I must admit my RPKI knowledge needs some love, but my understanding is that ROAs link prefixes to a given ASN, with the ROA signed by the private key from the resource holder's certificate. Would this validation option for PA allocations be applicable only in cases where the customer holds an ASN to which the prefix could be linked? In other words the prefix on the ROA would be the PA prefix allocated by ISP B, the ASN on the ROA would be the customer's ASN, and the private key signing the ROA would belong to ISP B, as they are the resource holder? Hopefully not downgrading this conversation, but lacking RPKI validators at ISP A and a valid RPKI setup at ISP B, and assuming that the customer has an ASN, this info could also be generated from IRR data as well, no? I mean, dropping a /29 into a routing registry won't do much good in terms of getting announcements accepted, but it could still be leveraged for this use case to generate filter prefix lists, right? If this is not tied to a customer ASN (because they don't have one) but rather to ISP B's ASN, how does ISP A vet that a ROA-validated prefix tied to ISP B's ASN applies to this particular customer? Absent RPKI and falling back to IRR, same question? Network #4 ---------- Customer has broadband connections from ISP A and ISP B. If I'm not totally out to lunch above re: needing an ASN for the customer to leverage an ROA-based solution as Mark touched on, are we stuck in either manual ACLs or asking or writing new implementations as John described? On Mon 2016-Sep-26 16:04:33 -0000, John Levine <johnl@iecc.com> wrote: ...
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.
Transit touchdown interfaces ---------------------------- This is Baldur's scenario. Barring both upstreams maintaining manual filters that cover the touchdown networks handed to their mutual customers, it seems either Mark's or John's suggestions could be potential solutions here? -- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal [1] https://tools.ietf.org/html/rfc3704#section-2.3 On Tue 2016-Sep-27 07:08:27 +1000, Mark Andrews <marka@isc.org> wrote:
BCP 38 does NOT prevent multi-homed clients. Naive deployment of BCP 38 prevents multi-homed clients. There is NOTHING in BCP 38 that says you may not also accept other prefixes allocated to your clients.
BCP 38 says accept allocated address, drop everything else.
Now it should be possible with ROA's to completely automate support for multi-homed clients as you can cryptographically verify the addresses allocated to your clients from other ISPs / RIRs.
The DHCP server could generate a CERT for every allocation it hands out if a client requested it. This really only needs a DHCP option to be defined to request this.
Just as it is possible to secure BGP it is possible to secure BCP 38 additional prefixes.
BCP 38 is INGRESS filtering from your customers. Treating your own offices as a "customer" is also recommended.
In message <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864@cisco.com>, Eliot Lear writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN From: Eliot Lear <lear@cisco.com> To: Laszlo Hanyecz <laszlo@heliacal.net>, nanog@nanog.org Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864@cisco.com> Subject: Re: Request for comment -- BCP38 References: <20160926180355.1229.qmail@ary.lan> <dc13dbd3-051c-2239-1ecb-3f4ab43b049a@heliacal.net> In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b049a@heliacal.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Guys,
You're getting wrapped around the axle. Start by solving the 90% problem, and worry about the 10% one later. BGP38 addresses the former very well, and the other 10% requires enough manual labor already that you can charge it back.
Eliot
On 9/26/16 8:44 PM, Laszlo Hanyecz wrote:
On 2016-09-26 18:03, John Levine 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=
> *should* drop that traffic on the floor. This is a legitimate and interesting use case that is broken by BCP3=
A 8.
I don't agree that this is legitimate.
Also we're talking about typical mom & pop home users here. There are SOHO modems that will fall back to a second connection if the primary one fails, but that's not what we're talking about here.
The customers I'm talking about are businesses large enough to have two dedicated upstreams, and a chunk of address spaced SWIP'ed from each. Some run BGP but I get the impression as likely as not they have static routes to the two upstreams.
For people who missed it the last time, I said $50K/mo, not $50/mo.=20 Letters matter.
This doesn't have to be $50k/mo though. If the connections weren't source address filtered for BCP38 and you could send packets down either one, the CPE could simply start with 2 default routes and take one out when it sees a connection go down. This could work with a cable + DSL connection even. It would be easy to further refine which connection to use for a particular service by simply adding a specific route for that service's address. This would be a lot better than having to restart everything after one of the connections fails. =20 This would provide functionality similar to the BGP setup without any additional work from the service provider. People can't build CPE software that does this type of connection balancing because they can't rely on this working due to BCP38 implementation. In my experience the only way you can get people to stop source address filtering is if you mention BGP, but BGP shouldn't be required to do this.
-Laszlo
R's, John
--dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJX6YIpAAoJEIe2a0bZ0nozGHAH/3EXMt2/t68dgB92RPYyVSHR 46WpPPOEhD1Qd1s6MW4mhzhWWmv99RGwPm1ZXVzE9iIpMkptXEuzbsHz1V7mjsao 5MkIyzvWgF6qpe1kI1xZp2xoDa++XjfJqwUMg0swxji7idjkMILw6buE70lubOCB Uu2Y6uGPCnsIEcD106AxJYkP91BlBkBRPAFoBjbdZKRTs3+TYQgxS815qviSiDux MXhdxgpo8yg/B8knmjQwwIcG3+Ug5FvkPJyz88GQKwwU6nEIKUn2Zf3U/vw2vQTN 3K+DlRIGy6ZXani4ab58pswrrhFl9P9bocRom+cJQAqb3JwR60NuUX1/YKeTv2o= =HdDL -----END PGP SIGNATURE-----
--dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
----- Original Message -----
From: "Hugo Slabbert" <hugo@slabnet.com>
This seems to have split into a few different sub-threads and had some cross-talk on which network is being described where (thanks in no small part to my flub on John's figures and target), but this seems to be exactly the kind of info folks are looking for but missing at http://www.bcp38.info.
I heartily encourage people to add content to the wiki for network types that I'm insufficiently familiar with; cookbook entries are where I'd like to see it end up. If anyone wants to contribute please poke me or Alain for an account (keeping a MediaWiki despammed is a fulltime job these days, if you allow user created accounts, so we don't). The address to poke at is moderator (at) bcp38.info Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
----- Original Message -----
From: "Laszlo Hanyecz" <laszlo@heliacal.net>
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.
Let me see if I have your argument straight: In order to enable an "interesting" use case that is used by maybe well under 1% of end nodes not in PI address space, we should decide *not* to do something which makes it much easier to protect attack targets against well over 75% of incoming attacks of ridiculous (>OC-12) bandwidth? Is that what you're advocating? No. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
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.
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?
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
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." 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? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "John Levine" <johnl@iecc.com> To: nanog@nanog.org Sent: Monday, September 26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38
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?
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
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." 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.
On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <nanog@ics-il.net> wrote:
----- Original Message -----
From: "John Levine" <johnl@iecc.com> To: nanog@nanog.org Sent: Monday, September 26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38
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?
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Mon 2016-Sep-26 09:21:55 -0700, Hugo Slabbert <hugo@slabnet.com> wrote:
On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <nanog@ics-il.net> wrote:
----- Original Message -----
From: "John Levine" <johnl@iecc.com> To: nanog@nanog.org Sent: Monday, September 26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38
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?
I myself am talking about the latter...
...dammit...obviously "former" here, not "latter". Caffeine injection requisitioned.
...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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Hugo Slabbert" <hugo@slabnet.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "John Levine" <johnl@iecc.com>, nanog@nanog.org Sent: Monday, September 26, 2016 11:21:55 AM Subject: Re: Request for comment -- BCP38 On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <nanog@ics-il.net> wrote:
----- Original Message -----
From: "John Levine" <johnl@iecc.com> To: nanog@nanog.org Sent: Monday, September 26, 2016 11:04:33 AM Subject: Re: Request for comment -- BCP38
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?
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
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."
Come on, John. Anyone spending 50K a month belongs in PI space with BGP, and they're a big enough customer for the ISPs to both put exception rules in their ingress filters even if they're not. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 09/26/2016 07:11 AM, Paul Ferguson wrote:
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? 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.
On Sep 26, 2016, at 7:47 AM, Stephen Satchell <list@satchell.net> wrote:
On 09/26/2016 07:11 AM, Paul Ferguson wrote:
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? 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?
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 — Paul Ferguson ICEBRG.io Seattle, Washington, USA
On Mon 2016-Sep-26 07:47:50 -0700, Stephen Satchell <list@satchell.net> wrote:
On 09/26/2016 07:11 AM, Paul Ferguson wrote:
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. -- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On 9/26/16 07:47, Stephen Satchell wrote:
On 09/26/2016 07:11 AM, Paul Ferguson wrote:
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? 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 start with customer interfaces and configure them to only allow traffic with a source address in their assigned subnet. ~Seth
participants (17)
-
Aled Morris -
Baldur Norddahl -
Eliot Lear -
Elmar K. Bins -
Florian Weimer -
Hugo Slabbert -
Jason Iannone -
Jay R. Ashworth -
John Levine -
Ken Chase -
Laszlo Hanyecz -
Mark Andrews -
Mike Hammett -
Octavio Alvarez -
Paul Ferguson -
Seth Mattinen -
Stephen Satchell