> i've never seen a dns attack that didn't have 50% or more packets coming
> from spoofed sources, though due to loose-mode uRPF, most spoofed sources
> in the last year or so have been from addresses for which a route exists.
> --
> Paul Vixie
reiterating a sometimes heretical idea...
are you refering to things like 172.17.0.0/16 where
only a couple hundred of those numbers have real services, e.g.
all the services are in 172.17.22.0/24 and the spoofed addresses
are in 172.17.128.0/17 space?
In that example, if the receiver uses loose-mode uRPF to filter
ingress and carries within their AS only the minimal set of RFC1918
routes corresponding to their actual use of it, then spoofed-source
packets "from" 172.17.22.0/24 would be allowed in by loose-mode uRPF
because a route table entry exists. Packets "from" the rest of
172.17.0.0/16 would be filtered.
Loose-mode uRPF does not protect you from spoofed-source packets where
the source address falls within a prefix that you use internally,
whether that space is RFC1918 space or not.
Likewise, loose-mode uRPF does not (completely) protect you from
spoofed-source packets where the source address falls within a prefix
that is valid externally, not necessarily via the reverse path on
which you're receiving the packet.
The first can be addressed with additional filtering, as has been
mentioned. The second is a harder problem, because of the business
decisions of some providers to source packets from prefixes that they
do not announce.
or... why do people insist on injecting routes to non-existent
things? a route table entry is a route table entry, regardless
of the scope.
Is this where you advocate that providers only announce the parts of
their assigned blocks that are in use?
> or... why do people insist on injecting routes to non-existent
> things? a route table entry is a route table entry, regardless
> of the scope.
Is this where you advocate that providers only announce the parts of
their assigned blocks that are in use?
seems like a good lead in, so yes - i advocate folks only
announce what they use. may play old-hob on the ISP that
likes to use some other metric for accepting announcements,
(e.g. RIR or other routing registry DB) and will no doubt
increase the tension on justification of proxy announcements,
but overall, this seems to be a good goal.
>
> Is this where you advocate that providers only announce the parts of
> their assigned blocks that are in use?
seems like a good lead in, so yes - i advocate folks only
announce what they use. may play old-hob on the ISP that
likes to use some other metric for accepting announcements,
(e.g. RIR or other routing registry DB) and will no doubt
increase the tension on justification of proxy announcements,
but overall, this seems to be a good goal.
i thought that a common goal was to announce only your aggregates
(which would inherently include unused space) rather than announce
all your deag'ed space (which should be more well used)
two of my acl's have dropped ~9million packets destined for bogon
networks in the past week (only about 20 Mbps on this router)...bogon
sources are probably equivalent (although i havent been logging it,
but in light of recent discussions, i probably will start again)
The second is a harder problem, because of the business decisions
of some providers to source packets from prefixes that they do
not announce.
i presume you are not intending to recommend that i drop packets
that multi-homed customers hand me when they have also asked me to
de-pref the prefix from which they come? i might be their backup
for inbound, but they need to balance their outbound.
FWIW, (you probably know this, but most on nanog maybe don't),
If you do 'feasible path strict uRPF' as described in BCP84 (I don't
know if others than Juniper are providing that), you can enable strict
uRPF toward those customers, still de-pref them, and accept the
packets with correct source addresses.
That's what we do with our customers whether multihomed or not.
One can also achieve the same without 'feasible path' by operationally
adjusting the weight or preference for the advertisement you receive
w/ eBGP and the advertisement you send in iBGP (so that only that one
router would send its traffic over that link), but that's likely a bit
more work and operational complexity.
And what do you do with a BGP customer which sends you traffic from
prefixes he doesn't want to announce to you? There are such customers.
Fail filter ACL?
Best regards,
Daniel (who wishes active/feasible would be switchable per interface,
not only per router)
It could be doable with fail-filter ACL, but we don't have any of
these, so it'd be just a silent discard.
Honestly, I fail to see this as a big problem. If they don't want to
announce the prefix to us, why would they want to source traffic from
that prefix to us? The inbound traffic engineering is the more tricky
business, not the outbound. If they want to keep the link usage low,
they could just send it with no-export or no-advertise, or suitably
prepended.
Except for really wacky asymmetric multihoming cases, I'd expect that
some customers might actually want 'restricted' or 'internal' traffic
to be discarded (compare to RFC1918 sourced traffic from enterprises,
because they use RFC1918 but don't set up the discarding ACLs on their
own).
Honestly, I fail to see this as a big problem. If they don't want to
announce the prefix to us, why would they want to source traffic from
that prefix to us?
I could delve in some exceptionally ugly examples of peering politics
but refrain to do that.
Let's just say that it's one way to make things "look wrong" to The
Uninitiated and easy to point complainers to the other party.
The inbound traffic engineering is the more tricky
business, not the outbound.
Well, but outbound TE based on _source_ needs policy routing. With
some vendor's gear this is not a too big problem, but with some other
vendor's gear this comes at a much higher price.
If they want to keep the link usage low, they could just send it
with no-export or no-advertise, or suitably prepended.
Prepend doesn't work as you as upstream normally localpref your
customers above all others (you have to by default, otherwise there
are setups in which $customer might be without _any_ upstream although
the link to you is still fine).
no-export doesn't work as $customer doesn't want ANY traffic from
your other customers to him directly for certain prefixes.
The whole point of BCP38 is that this isn't supposed to happen.
Yes, these restrictions are a huge pain in the rear end but a denial of service without even the possibility to tell where the packets come from is MUCH worse.
>And what do you do with a BGP customer which sends you traffic from
>prefixes he doesn't want to announce to you? There are such customers.
The whole point of BCP38 is that this isn't supposed to happen.
Unfortunately we are living in reality.
Yes, these restrictions are a huge pain in the rear end but a denial of
service without even the possibility to tell where the packets come
from is MUCH worse.
What you actually want to know is what the ingress interfaces for the
flows are. And if the ingress interface is not a p2p interface, from
which peer. For both problems quite effective solutions do exist
(ok, not really for the latter, but this is highly vendor specific).
Given that most DDoSses are mounted via huge zombie collections, there
is not much point in knowing the real source IPs.
Yes, these restrictions are a huge pain in the rear end but a denial of
service without even the possibility to tell where the packets come
from is MUCH worse.
What you actually want to know is what the ingress interfaces for the
flows are. And if the ingress interface is not a p2p interface, from
which peer. For both problems quite effective solutions do exist
(ok, not really for the latter, but this is highly vendor specific).
No, what I really want to know is the source IP.
Given that most DDoSses are mounted via huge zombie collections, there
is not much point in knowing the real source IPs.
Didn't we cover this?
Yes, there are zombie armies launching DDoS from "real" IP addresses. But that does not mean there are no spoofed-source attacks any more.
And what do you do with a BGP customer which sends you traffic from
prefixes he doesn't want to announce to you? There are such customers.
The whole point of BCP38 is that this isn't supposed to happen.
Unfortunately we are living in reality.
Tell that to the customers with the unrealistic wishes.
Yes, these restrictions are a huge pain in the rear end but a denial of
service without even the possibility to tell where the packets come
from is MUCH worse.
What you actually want to know is what the ingress interfaces for the
flows are.
For me, this has never been a big problem. (Not saying it isn't for anyone else.)
And if the ingress interface is not a p2p interface, from
which peer.
Sure, that helps, but it doesn't shut up the packets. With real addresses you can build filters and/or contact the source. Yes, both are hard to do. But with spoofed sources there is pretty much nothing you can do except hope that your transit choices were good ones and they'll investigate.
Given that most DDoSses are mounted via huge zombie collections, there
is not much point in knowing the real source IPs.
If the bottleneck isn't your ingress it is possible to filter tens of thousands of real sources. If the sources are fake you need to do much more destructive filtering.
> And what do you do with a BGP customer which sends you traffic from
> prefixes he doesn't want to announce to you? There are such customers.
The whole point of BCP38 is that this isn't supposed to happen.
no. the whole point of BCP38 is that if this is supposed to happen, you
(the upstream) should have to take explicit, non-default action which would
probably include a source-address ACL, or static routes, or something.
This has been my question with uRPF from the beginning. You can solve this
on for some networks, but it doesn't scale very well. Especially where you
really don't know that your customer's customer is doing this.
> And what do you do with a BGP customer which sends you traffic from
> prefixes he doesn't want to announce to you? There are such customers.
> Fail filter ACL?
This has been my question with uRPF from the beginning. You can solve this
on for some networks, but it doesn't scale very well. Especially where you
really don't know that your customer's customer is doing this.
It's 2004, and so, your customers who want to do this have to explain why,
and you have to maintain extra-ordinary filters for such customers, at either
your cost or the customer's cost.
