[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