On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote:
On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote:
On Tue, 19 Aug 2008, Kevin Loch wrote:
While you're at it, you also placed the reachable-via rx on
all your customer interfaces. If you're paranoid, start with the
'any'
rpf and then move to the strict rpf. The strict rpf also helps
with
routing loops.
Be careful not to enable strict rpf on multihomed customers. This
includes
any bgp customer unless you know for sure they are single homed to
you
and that will not
change.
Isn't it time to change the assumption that sending arbitrary
source IP
addresses without checking is Ok?
Unless the customer has specifically told their ISP about all the IP
addresses they intend to use as source IP addresses, shouldn't the
default be to drop those packets.
If those multi-homed customers have not told their upstream ISPs
about
additional source IP addresses (hopefully also registered/
authorized for
use by the same customer) why can they still send packets with those
source addresses? Instead shouldn't you say "Be careful if you are a
using source IP addresses without informing your upstream."
In practice, how many multi-homed customers send packets with
unannounced
source IP addresses? And for those customers which do, why is the
ISP
unable to implement any of the alternative source IP checking
options,
such as using a ACL with uRPF or on the interface?
I certainly believe that this is the trap people fall into.
I can't manage it, nor do I want to spend the effort telling
my provider, peer, etc.. that I stole their customer from them, so
I'm better off making the global network less secure.
With all the concern about DNS cache integrity, network abuse, etc..
networks that are not taking afirmative action to implement better
policies,
systems are going to continue to lower their overall value.
If you think I'm wrong, I do suggest you sit back and ignore your
network and customers further. When they are unable to trust your
network
to deliver the correct response to a dns query, they will ask for
credits
and will leave. If I were any sort of a bank, I would insist that
my provider
take actions to prevent my customers from being redirected to a
phishing
site. The interesting thing is the effort put into dns patching,
dnssec, etc..
could all be helped by the networks doing u-rpf. Not 100% mitigated
against, but
the difference would be huge.
this is no longer a ddos issue of people spoofing packets. That's
gone, it's easier to take over a million desktops with malware than
one
on a fe/ge. But the ability to use those machines to brute-force or
reconfigure
the resolver settings to someplace bad, that risk is truly tangible
and
possibly severely disruptive to the industry. If I can't trust that
I am
reaching my bank, email, etc.. what impact will that have?
My Bank (Bank of America) put in something to mitigate against this
about 2 years ago (IIRC), so they
were clearly anticipating something like this. Not only do you have to
verify that you are you, you
also have to verify that the bank is the bank.
Regards
Marshall
If you've not factored these things into your business process,
hardware acquisition, I think you will end up with a bad situation.
- Jared
--
Jared Mauch | pgp key available via finger from [EMAIL PROTECTED]
clue++; | http://puck.nether.net/~jared/ My statements are
only mine.
