[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] cache issues in LISP and CONS
On 24-okt-2007, at 12:36, Darrel Lewis (darlewis) wrote:
I just realized that such an architecture could have some
nice security benefits. The access to the overlay network
could be rate limited, and direct communication using the
ITR/ETR system could be subject to negotiation of
credentials. This could potentially help against denial of
service attacks.
I think we need to do some more thinking about whether with the
overlay
network it is better to send the data packets themselves, or just Map
Request packets.
Agree.
The rate limiting of data to the overlay network could itself become a
vector for DoS attacks. If I flood a site with random sourced
syns, the
site will start accessing the overlay network to discover mapping
information for all the various syn-ack packets. If this resultant
flood of requests is rate limited, then I could starve legitimate
requests for mapping from that site.
That would depend on the design. First of all, I think I'd defer the
mapping request until the third packet in the three-way handshake to
avoid mapping floods caused by SYN floods.
And if there are enough rendezvous points it becomes hard to make the
path from each towards the target destination choke. Then again, only
doing that for a few may be enough of a nuisance. However, each ITR
should rate limit packets it injects into the overlay network and
mapping requests that it generates. That means that DoS attacks are
felt close to the source rather than at the target, which is good
because close to the target it's easier to deal with them.
If the overlay network doesn't let a useful amount of traffic
through, it should still be possible to obtain mappings and the
traffic will start to flow after an initial delay. If the ETR detects
too much or abusive traffic from a particular ITR, it can then tell
that ITR to stop sending traffic. We may want to have the option to
require a certain nonce in each packet to make sure that ITRs only
get to send traffic after being authorized to do so by the ETR.
There are no magic bullets in (D)DoS mitigation, but I think useful
results can be gained here.
The whole overlay system, especially if it shares fate with other
network elements, could have some interesting vulnerabilities.
It's important to consider all eventualities, because that's exactly
what the attackers are going to do.
LISP itself has a light form of authentication in the form of return
routability checks with a nonce.
The big problem today is that people can inject large amounts of
abusive traffic and can hide in large numbers or by spoofing their
source addresses. Obtaining mappings means revealing a working source
address, and after that, any non-conformant behavior, such as failing
to rate limit properly, can easily be spotted and dealt with though
offline methods.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg