> 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.
No, I'm not recommending that.
In the example that you give, the prefix from which the packets in
question will be sourced *is* offered as a destination? Assuming yes,
then regardless of whether that offer is selected as the best to use
to reach the destination or not, the edge router that needs to make
the decision to accept or reject packets sourced in that prefix can
use its knowledge that the offer was made to accept packets.
The problem is differentiating these two cases:
1. the offer of a route to a prefix is not made but packets sourced in
that prefix are legitimate and are expected to be forwarded; the
reverse path is only available through a different AS
2. the source address is spoofed; packets are not legitimate and should
be dropped
Once upon a time, I tried to enable loose-mode uRPF on a peering
interface, effectively treating #1 as #2. The complaints were
relatively instantaneous (at 2am local for me, a traffic-low time),
and not localized to a specific source prefix (the majority were
residential broadband users); I wound up turning the loose-mode uRPF
check off in fairly short order.
Attempts to discover why #1 was happening ended with technical people
shrugging their shoulders and saying that the money people made them
do it.
Stephen
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.
No, I'm not recommending that.
so i suspected <g>
In the example that you give, the prefix from which the packets
in question will be sourced *is* offered as a destination?
not by me. but by one or more of the originator's other upstreams.
i suspect this is not uncommon.
The problem is differentiating these two cases:
1. the offer of a route to a prefix is not made but packets
sourced in that prefix are legitimate and are expected to be
forwarded; the reverse path is only available through a
different AS
2. the source address is spoofed; packets are not legitimate and
should be dropped
Once upon a time, I tried to enable loose-mode uRPF on a peering
interface, effectively treating #1 as #2. The complaints were
relatively instantaneous (at 2am local for me, a traffic-low time),
and not localized to a specific source prefix (the majority were
residential broadband users); I wound up turning the loose-mode uRPF
check off in fairly short order.
Attempts to discover why #1 was happening ended with technical
people shrugging their shoulders and saying that the money people
made them do it.
yep. some times it is even less intentional and less understood;
see tim's paper on bgp wedgies. and the "management made me do
it," is a bit disingenuous. it's part of what it means to have
customers.
randy
yep. some times it is even less intentional and less understood;
see tim's paper on bgp wedgies.
http://ispcolumn.isoc.org/2004-09/bgp-wedgies.html
Nice article. Too bad we don't see more stuff written up
like this in such a clear way.
http://www.potaroo.net/ietf/idref/draft-griffin-bgp-wedgies/
--Michael Dillon