Tier 2 ingress filtering
In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
is there a clear understanding of "the edge" in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. /bill On Thu, Mar 28, 2013 at 01:07:24PM -0400, Jay Ashworth wrote:
In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge.
My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week.
The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic...
which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface.
Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off.
Am I missing something?
Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater?
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Thu, Mar 28, 2013 at 1:07 PM, Jay Ashworth <jra@baylink.com> wrote:
My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week.
Hi Jay, There's a two part heirarchy of contracts involved in every legitimate end-to-end communication which occurs over the Internet, right? You buy service from someone who buys service on your behalf from someone who buys service on his behalf from someone. The other endpoint does the same, starting with his ISP. The contract hierarchies meet at the top, either with a single backbone ISP or with a pair of backbone ISPs who do settlement-free peering with each other. So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on. The reliability of these representations obviously falls at they grow distant from the source. So what? That's a problem for RPKI. The problem we need concern ourselves with is dropping packets whose source addresses are inconsistent with our customer's _representation_ of the addresses he's authorized to originate, however reliable or unreliable that representation may turn out to be. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on.
The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage. The latter, though, is arms-length, *and* has no reasonable way to be implemented that I can see without extending whatever OAM&P system that carrier has atop their gear.
The reliability of these representations obviously falls at they grow distant from the source. So what? That's a problem for RPKI. The problem we need concern ourselves with is dropping packets whose source addresses are inconsistent with our customer's _representation_ of the addresses he's authorized to originate, however reliable or unreliable that representation may turn out to be.
That's great, but that's a couple orders of magnitude of added complexity that, quite frankly Bill, I can't sell just now. :-) Worse (to bring this ontopic for NANOG): that complexity needs to live *inside routers*, unless I'm very much mistaken. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Thu, Mar 28, 2013 at 12:27 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on.
The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage.
Of course, he has to notice it first. :-) ObOpinion: It's best to *enforce* a policy which disallows a downstream network from sourcing spoofed packets -- and the closer to the "edge" you are, the better, Hierarchy is great for that. :-) I guess the next best thing is "Trust but verify"? - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
----- Original Message -----
From: "Paul Ferguson" <fergdawgster@gmail.com>
The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage.
Of course, he has to notice it first. :-)
Sure.
ObOpinion: It's best to *enforce* a policy which disallows a downstream network from sourcing spoofed packets -- and the closer to the "edge" you are, the better, Hierarchy is great for that. :-)
Sure; that's sort of my point: this is *much* more effectively done at the actual edge; I think the systemic complexity of pushing it further in goes up as a log function -- meaning that the fact that there are only maybe 6000 transit networks is a red herring.
I guess the next best thing is "Trust but verify"?
Always. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On (2013-03-28 13:07 -0400), Jay Ashworth wrote:
The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic...
Question is, is it reasonable to expect customer to know what networks they have. If yes, then you can ask them to create route objects and then you can BGP prefix-filter and ACL on them. I do both, and it has never been problem to my customers (enterprises, CDNs, eyeballs). But if your customer has many other transit customer it can quickly become less practical. I'm sure for many/most customers of tier1 it would not be reasonable expects to keep such list up-to-date. You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port. But there are only 6000 non-stubby networks, if you do it at network before stubby network, it's entirely practical and maintainable, provided we'd want to do it. -- ++ytti
----- Original Message -----
From: "Saku Ytti" <saku@ytti.fi>
On (2013-03-28 13:07 -0400), Jay Ashworth wrote:
The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic...
Question is, is it reasonable to expect customer to know what networks they have.
If by "customer" you mean the same thing I do: an end user who sources and sinks packets, which is fed by some Internet Access Provider... then my answer is the same thing it was before: "No, but it doesn't matter, because we're talking about ingress filters on the carrier which provides them with public address space, and *it* *does* know which network they've been given."
If yes, then you can ask them to create route objects and then you can BGP prefix-filter and ACL on them. I do both, and it has never been problem to my customers (enterprises, CDNs, eyeballs).
You are at least 30,000 feet higher than the conversation I'm having. BGP-speaking end sites are a whole different matter, and sufficiently smaller in number (2-5 orders of magnitude, depending on what you sell) that they're not really pertinent here.
But if your customer has many other transit customer it can quickly become less practical. I'm sure for many/most customers of tier1 it would not be reasonable expects to keep such list up-to-date.
Correct, and this was the substance of my question.
You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port.
I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware.
But there are only 6000 non-stubby networks, if you do it at network before stubby network, it's entirely practical and maintainable, provided we'd want to do it.
Your assertion is the thing for which I'm requesting support in this query. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On (2013-03-28 15:47 -0400), Jay Ashworth wrote:
You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port.
I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware.
Even if all of last mile devices support uRPF, which it does not, getting all these 100s of millions of ports configured correctly does not strike as practical goal. Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal. -- ++ytti
Saku,
all these 100s of millions of ports configured correctly does not strike as practical goal.
It is practical, IMO, similar to configuring IP address/prefix (or QoS policies) on every port. In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port.
Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal.
Agreed. Cheers, Rajiv Sent from my Phone On Mar 29, 2013, at 7:36 AM, "Saku Ytti" <saku@ytti.fi> wrote:
On (2013-03-28 15:47 -0400), Jay Ashworth wrote:
You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port.
I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware.
Even if all of last mile devices support uRPF, which it does not, getting all these 100s of millions of ports configured correctly does not strike as practical goal. Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal.
-- ++ytti
On (2013-03-28 23:45 +0000), Rajiv Asati (rajiva) wrote:
In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port.
There is incredible amount of L3 interfaces in the last mile, old ghetto stuff, latest gen Cisco, which does not do uRPF. -- ++ytti
On 3/28/2013 7:49 PM, Saku Ytti wrote:
On (2013-03-28 23:45 +0000), Rajiv Asati (rajiva) wrote: In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. There is incredible amount of L3 interfaces in the last mile, old ghetto stuff, latest gen Cisco, which does not do uRPF.
Very true. Some of it you can even configure as such, it just doesn't do anything... Jeff
* Saku Ytti
Question is, is it reasonable to expect customer to know what networks they have. If yes, then you can ask them to create route objects and then you can BGP prefix-filter and ACL on them. I do both, and it has never been problem to my customers (enterprises, CDNs, eyeballs).
I've had some problems with my upstream providers' ingress filtering, for example: - Traffic sourced from a prefix announced as a more-specific route at transit connection in location A got filtered on a transit connection in location B, where only a greater aggregate was announced. - A GRE tunnel anchored in my routers' addresses in the eBGP link network (part of my provider's address space) stopped working, as my outbound packets was dropped by the provider's ingress filtering. - Traceroutes that reaches my network through provider A show one missing hop if my best return path back to the traceroute source is through provider B, and provider B is doing ingress filtering. This is because the ICMP TTL/HL exceeded packet is sourced from provider A's address space (my router's interface address in the eBGP link net). AFAIK, you represent one of my upstream providers, so sorry, but saying your customers have never had problems with your ingress filtering isn't entirely accurate. Everything works fine now, though. Best regards, -- Tore Anderson
On Fri, Mar 29, 2013 at 8:31 AM, Tore Anderson <tore@fud.no> wrote:
I've had some problems with my upstream providers' ingress filtering, for example:
- Traffic sourced from a prefix announced as a more-specific route at transit connection in location A got filtered on a transit connection in location B, where only a greater aggregate was announced.
Yep, I've heard of that. This is very bad behavior on your ISP's part. Spank them and if need be, name and shame.
- A GRE tunnel anchored in my routers' addresses in the eBGP link network (part of my provider's address space) stopped working, as my outbound packets was dropped by the provider's ingress filtering.
Yep, I've encountered that. One of my providers decided that the IP on the exterior address of my router should not reach the Internet. Bad behavior. Spank, then name and shame.
- Traceroutes that reaches my network through provider A show one missing hop if my best return path back to the traceroute source is through provider B, and provider B is doing ingress filtering. This is because the ICMP TTL/HL exceeded packet is sourced from provider A's address space (my router's interface address in the eBGP link net).
This is a bug, if you will, in router design. It isn't just traceroute that's missing a hop; if that router needed to send an ICMP destination unreachable in support of path MTU detection for some pair of hosts' TCP, the impacted TCP session would collapse. It gets even worse if you want to configure a particular router link with RFC1918 addresses. I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2013-03-29 14:49, William Herrin wrote:
I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received.
Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip unnumbered loop0' everywhere. ;)
Hi, On 3/29/13, Patrick <nanog@haller.ws> wrote:
On 2013-03-29 14:49, William Herrin wrote:
I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received.
Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip unnumbered loop0' everywhere. ;)
Why do you think it will be better?, can you explain? So far I can only think in a more difficult troubleshooting if this idea/feature gets spread. I guess based in the scenario where the output interface can not reach Internet sounds as a practical solution however for sure the output interface is reachable inside the provider network. Thks, Alejandro,
On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta <alejandroacostaalamo@gmail.com> wrote:
On 3/29/13, Patrick <nanog@haller.ws> wrote:
On 2013-03-29 14:49, William Herrin wrote:
I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received.
Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip unnumbered loop0' everywhere. ;)
Why do you think it will be better?, can you explain?
Hi Alejandro, Consider the alternatives: 1. Provide a router configuration option (per router and/or per interface) to emit ICMP error messages from a specified IP address rather than the interface address. 2. At every border, kick packets without an Internet-legitimate source address up to the slow path for network address translation to a source address which is valid. 3. Design your network so that any router with at least one network interface whose IP address is not valid on the Internet has exactly the same MTU on every interface, and at least an MTU of 1500 on all of them, guaranteeing that the router will never emit a fragmentation-needed message. And do this consistently. Every time. 4. Redesign TCP so it doesn't rely on ICMP destination unreachable messages to determine path MTU and get your new design deployed into every piece of software on the Internet. 5. Accept that TCP will break unexpectedly due to lost fragmentation-needed messages, presenting as a particularly nasty and intermittent failure that's hard to track and harder to fix. Which do you find least offensive? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Hi William, Thanks for your response, my comments below: On 3/30/13, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta <alejandroacostaalamo@gmail.com> wrote:
On 3/29/13, Patrick <nanog@haller.ws> wrote:
On 2013-03-29 14:49, William Herrin wrote:
I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received.
Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip unnumbered loop0' everywhere. ;)
Why do you think it will be better?, can you explain?
Hi Alejandro,
Consider the alternatives:
1. Provide a router configuration option (per router and/or per interface) to emit ICMP error messages from a specified IP address rather than the interface address.
I imagine that and it sounds terrific. I guess at least this option should come disabled by default.
2. At every border, kick packets without an Internet-legitimate source address up to the slow path for network address translation to a source address which is valid.
IMHO this can be achieved with the current behaviour.
3. Design your network so that any router with at least one network interface whose IP address is not valid on the Internet has exactly the same MTU on every interface, and at least an MTU of 1500 on all of them, guaranteeing that the router will never emit a fragmentation-needed message. And do this consistently. Every time.
If you have pmtud enabled you won't need this every time
4. Redesign TCP so it doesn't rely on ICMP destination unreachable messages to determine path MTU and get your new design deployed into every piece of software on the Internet.
You will have the same problem using only one output interface for ICMP error/messages. Of course based in your comments you mean you will need to troubleshoot this interface only once.
5. Accept that TCP will break unexpectedly due to lost fragmentation-needed messages, presenting as a particularly nasty and intermittent failure that's hard to track and harder to fix.
Same answer as in 3.
Which do you find least offensive?
None of them if offensive, I think this could be a nice feature to have but I hope it's disable by default.
Regards, Bill Herrin
Thanks, Regards, Alejandro Acosta,
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Hi Alejandro, Also inline. On Sat, Mar 30, 2013 at 10:17 PM, Alejandro Acosta <alejandroacostaalamo@gmail.com> wrote:
Hi William, Thanks for your response, my comments below:
On 3/30/13, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta <alejandroacostaalamo@gmail.com> wrote:
On 3/29/13, Patrick <nanog@haller.ws> wrote:
On 2013-03-29 14:49, William Herrin wrote:
I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received.
Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip unnumbered loop0' everywhere. ;)
Why do you think it will be better?, can you explain?
Hi Alejandro,
Consider the alternatives:
1. Provide a router configuration option (per router and/or per interface) to emit ICMP error messages from a specified IP address rather than the interface address.
I imagine that and it sounds terrific. I guess at least this option should come disabled by default.
2. At every border, kick packets without an Internet-legitimate source address up to the slow path for network address translation to a source address which is valid.
IMHO this can be achieved with the current behaviour.
If you don't mind the router crashing. There's too much trash traffic with bad source addresses, even when no one is under attack. You kick it up to the main CPU, you overwhelm the router.
3. Design your network so that any router with at least one network interface whose IP address is not valid on the Internet has exactly the same MTU on every interface, and at least an MTU of 1500 on all of them, guaranteeing that the router will never emit a fragmentation-needed message. And do this consistently. Every time.
If you have pmtud enabled you won't need this every time
Clients effectively always enable path MTU discovery. If the ICMP error message your router generates when it discovers the MTU problem comes from an IP address that can't leave your system without being filtered then path MTU discovery fails absolutely. That path is a black hole that mysteriously swallows TCP connections. If you can't prevent mis-addressed ICMP error messages from leaving your system then you must prevent the conditions under which path MTU discovery would cause an ICMP error message to be generated. Practically speaking, that means you guarantee an MTU of at least 1500 bytes on every link and no endpoint MTU over 1500 bytes.
4. Redesign TCP so it doesn't rely on ICMP destination unreachable messages to determine path MTU and get your new design deployed into every piece of software on the Internet.
You will have the same problem using only one output interface for ICMP error/messages. Of course based in your comments you mean you will need to troubleshoot this interface only once.
With #4, path mtu discovery no longer relies on ICMP error messages. The endpoint client would have to reduce the MSS on retransmission and use the pattern of lost packets to acknowledgements to find path MTU on paths with an ICMP black hole. For the sake of robustness, this is something we probably should think seriously about adding to the TCP protocol. However, that's a long plan, two decades at least. It isn't something that could deliver a complete mitigation in the next release of the software, the way option 1 does.
5. Accept that TCP will break unexpectedly due to lost fragmentation-needed messages, presenting as a particularly nasty and intermittent failure that's hard to track and harder to fix.
Same answer as in 3.
See me response to #3. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On (2013-03-29 13:31 +0100), Tore Anderson wrote:
I've had some problems with my upstream providers' ingress filtering, for example:
That sounds like uRPF, which you should not run towards your transit customers. I'm talking only about using ACL. And I stand-by that I've never had to fix something that is broken. Now naturally it has happened that my customer has gotten new prefix, and things have been wonky, because they forgot to make route object, which meant we didn't allow prefix nor allow it in ACL. However, I think my customers prefer this. The alternative is that everything works fine for 6month, until the other transit who does not BGP filter goes down, after which the network stops propagating and everything is down. At least with ACL you notice the problem immediately. -- ++ytti
On 3/28/13, Jay Ashworth <jra@baylink.com> wrote:
My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to [snip]
Do you have a LOA on file for that peer/customer to route traffic to (or from) the prefix? If yes, then it's legitimate that they source traffic from it, or request that the prefix be included in their filters for BGP and ingress controls. If no, then consult the routing policy that applies to them. Ingress source addresses should optimally ideally be filtered at turnup to the list of authorized prefixes, if uRPF cannot be implemented (uRPF is convenient, but not necessarily necessary to implement ingress filtering), then access list based on source address, even the nearly oldest of the most ghetto equipment should be offering basic ACL functions. If the downstream need extra prefixes that you couldn't have known about, then it's the downstream network's job to contact you to have the prefix added to filters, before they start sourcing traffic from those addresses. By definition if they wouldn't be allowed to route traffic _to_ that address over your link, your network's routing policy documents could and probably ought to say, that it's not allowed to source traffic from such unauthorized addresses. If the peer is your transit provider that is authorized to give you default and route any prefix, then sure, allow any source, because they are authorized (except source addresses that belong to your network or your customers that have not secured your network's permission to be multihoming with their link and specified address space, of course)..
-- jra -- -JH
See below Jared Mauch On Mar 28, 2013, at 5:04 PM, Jimmy Hess <mysidia@gmail.com> wrote:
Ingress source addresses should optimally ideally be filtered at turnup to the list of authorized prefixes, if uRPF cannot be implemented (uRPF is convenient, but not necessarily necessary to implement ingress filtering), then access list based on source address, even the nearly oldest of the most ghetto equipment should be offering basic ACL functions.
Not everything can do acls at scale. Not all customers have anything reflecting symmetric routing creating a problem in the capabilities in the equipment working as desired. Many customers honestly don't know how their things work or think they work in ways that are not fully accurate. You get lots of default pointing even when they run BGP. Lots of people update prefix lists as a last resort vs proactively. Nobody removes things, making it hard. Automation of systems is also hard. Not impossible, but hard. I'm hoping some of the SDN marketing becomes reality when it comes to managing these configs. Maybe I will be able to have urpf work with my rpki and sdn.
Quite a number of people have responded to this post. But no one's actually addressed my key question: ----- Original Message -----
From: "Jay Ashworth" <jra@baylink.com>
In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge.
My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week.
Here's the important part:
The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic...
which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface.
An edge carrier, to whom an end-site connects, *can know* that that particular end-site will need an exemption, for reasons like non-BGP dual-homing or load- balancing. But there's no way for an upstream transit carrier to know that *at the present time*. So, short of building another big RPKI infrastructure to authenticate it (which isn't going to happen this decade) or getting lots of carriers to cooperate in some other information exchange so they know where to poke extra holes (which isn't going to happen this decade), is there any way at all to actually do ingress filtering at the transit level -- as many here advocate -- without throwing out the baby of *valid* unexpected source addressed packets with the bathwater of *actual* fraud? IP packets with source addresses that don't match the address space of the interface you got them on are *not* a 100.0% accurate proxy for fraud and attacks. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On (2013-03-30 11:39 -0400), Jay Ashworth wrote:
But there's no way for an upstream transit carrier to know that *at the present time*.
We expect our customers to mark any customers they have in their AS-SET. And we filter BGP announcements and we ACL traffic based on that. I know mandating strict IRR is not practical to everyone today. But for me, it's practical. Sometimes I need to educate customers how to create route object or AS-SET. At least every non-stubby ASN facing stubby ASN should be able to do strict IRR. This is about 6000 networks. Compared to other options: 1) close recursive name servers - even if all are closed, attack vector is virtually the same, as large RR can be found in arbitrary authorative due to DNSSEC - snmpbulkwalk - UDP du jour 2) implement uRPF at last mile - hundreds of millions of ports, many of them running on autopilot, good chunk of them will never ever support uRPF Obviously if we could choose 2) it would be best, but we can't choose it. -- ++ytti
participants (12)
-
Alejandro Acosta -
bmanning＠vacation.karoshi.com -
Jared Mauch -
Jay Ashworth -
Jeff Kell -
Jimmy Hess -
Patrick -
Paul Ferguson -
Rajiv Asati (rajiva) -
Saku Ytti -
Tore Anderson -
William Herrin