RE: [RRG] cache issues in LISP and CONS

["Darrel Lewis (darlewis)" <darlewis@cisco.com>]

> -----Original Message-----
> From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
<snip>
> > What I'd like to see here is a two-pronged system: a standard issue 
> > ITR/ETR system that handles most of the traffic, and an increased 
> > stretch overlay network that can handle the packets that run into 
> > cache misses.
> 
> Replying to myself - always cool.
> 
> 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. 

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.  

The whole overlay system, especially if it shares fate with other
network elements, could have some interesting vulnerabilities.

LISP itself has a light form of authentication in the form of return
routability checks with a nonce.

I think you do describe one of the key benefits of a map/encap scheme
like LISP however:  Having persistent EIDs that are visible in the
inner-header that a network element can classify and apply policy on.

-Darrel

--
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