[RAM] Re: draft-bagnulo-lisp-threat-01

Hi Robin,

El 12/07/2007, a las 13:34, Robin Whittle escribió:

> Hi Marcelo,
>
> I was just stating how I believe Ivip differs from LISP and asking
> questions about LISP, for Dino and others to answer rather than you.
>

I am relieved then :-)

> When I wrote:
>
>>>   An attacker could massively generate either tunnelled data
>>>   packets so that the router cache is overflowed.
>>>
>>> looks incomplete.
>>
>> ?
>
> it was because I couldn't make full sense of this sentence in the
> context.  I thought maybe it should be "either tunneled data
> packets or ICMP packets" or similar - I think this is just a typo
> or expression glitch.

right, i think the either should be removed and it should then make  
more sense...

>
>
>>> Ivip ITRCs (caching ITRs) and ITFHs (caching ITR functions in
>>> sending hosts) are subject to some cache size limit and so would
>>> be subject to a DoS attack (or simply non-malicious traffic) which
>>> consisted of a sufficiently fast and diverse range of data packets
>>> to addressed to Ivip-mapped addresses.  However, the response of
>>> an ITFH or ITRC to this would probably be to not try to retain the
>>> mapping for every address of every packet - which is the same as
>>> their normal way of working, which is to only seek mapping
>>> information for addresses for which multiple packets are received.
>>
>> so, they would seeks for the maping information, forward the  
>> packet and
>> discard the mapping information? So, when the second packet  
>> arrives, do
>> they rememeber that they have queried for the same mapping before?  
>> (If
>> yes, then they store some state, hence a DoS vector is possible)
>
> OK - this is my bad expression.
>
> What I meant to write is that with Ivip, the ITRC's job is to find
> and tunnel as many packets as it can.  It doesn't necessarily have
> to tunnel each one, because (ideally, one way or another) the
> untunneled packets will get to to another ITRD - perhaps via one
> or more ITRCs.

so this basically means that the attack is propagated to other  
ITRC's, right? I mean, if oneITRC is receiving too many packets and  
it decides to forward them without tunnelling them to the next ITRC,  
then the the next ITRC will start receiving a huge amount of  
untunnelled packets, hence the attack is now not only affecting the  
initial router under attack but also to other routers that were used  
as fall back.

My point is that this is a two edged sword. On one hand, you have  
more processing power, becuase you can get the help of other routers,  
but otoh, a single attack can have a domino effect and affect  
multiple routers... makes sense?

>   Unless it is too busy, that ITRD which will tunnel
> it immediately, because its FIB is set up to do every mapping in
> the system.  I described what needs to happen in order that
> packets will be handled like this later in my message in the text
> following "I will add something like this to the I-D:".
>
> So an ITRC which is running out of cache memory could either dump
> some of its cached mapping and use the space for a recently
> received response, or it could keep the current cache contents.
> Either way, it is probably going to get packets it doesn't have
> mapping data for, so it doesn't tunnel them.

so other routers will need to tunnel them, hence the effect of the  
attack will affect the other routers as well, right?

>
>
>> In any case, i guess that:
>> - if you have a mapping database, the effect of the DoS attack is  
>> less
>> than when you don't since you can recover the mapping information,
>
> The idea with Ivip is that nearby, there will be a QSD which has a
> copy of the database and can answer queries quickly.  Maybe the
> ITRC doesn't send the query to that directly, but to a closer (and
> less expensive) QSC caching query server.  This way, one QSD with
> one feed of update data can handle a bunch of QSCs which can
> collectively handle more ITRCs than just the QSD alone.  Ideally,
> it would only take a fraction of a second for any of these ITRCs
> to get a response to its query, so it might be OK for the ITRC to
> hold a packet for a moment while it waits for the response - but
> then if the response doesn't come, it is left with a highly
> delayed packet.  My idea is that the ITRCs would not hold onto
> packets at all, but would let those it doesn't have mapping pass
> through untunneled.

so, bascally the effect of the dos based on overflowing the cache  
would be that the system is slower, because for every new address,   
query to the database is needed. (this seems better than not being  
able to communicate :-)

>
>
>> so
>> you don't have to discard the packets for which you have discarded  
>> the
>> cache information (which is the case of LISP 1, 1,5)
>
> LISP doesn't have any alternative as exists (or at least can and
> generally will exist) for Ivip, so any ITR which can't get mapping
> data will effectively drop the packet - and all LISP ITRs need to
> get the mapping information from somewhere else, since the whole
> database is too big to store.

yes, this is what i meant in the threat analysis and this seems an  
grave vulnerability imho

>
>
>> - the DoS attack will also affect the mapping database, which will
>> receive all the requests from all the routers it is serving,
>
> The QSD and any QSCs (which also have limited caches) would
> certainly get a hammering.  The result would be that other ITRCs
> nearby which are not subject to the attack would not be able to
> get so many responses to its requests.  So those ITRCs will be
> passing more untunneled packets.  Further along in the path taken
> by the packets, other ITRCs or an ITRD will get a lot more packets
> to handle than usual, which ultimately means that beyond some
> level, the DoS attack will succeed - including by stopping the
> tunneling of some packets from other parts of the network which
> rely on the one ITRD as the last way of tunneling packets.
>

yes, i think this is what i expressed above...

> I plan to finalise the ivip-arch-00 I-D on Sunday.  There isn't
> enough detail in it regarding how the database updates get to the
> ITRD and QSD for a security critique to be made.  There is a lot
> of stuff to think about regarding getting updates to hundreds of
> thousands of ITRDs and QSCs all over the world.
>
> I am thinking it that unless some really snappy techniques can be
> developed, it would be difficult to absolutely protect against
> spoofed packets being sent to the ITRDs and QSCs - but I think
> there will be ways of detecting any problems within a few seconds.
>
> These are really interesting problems.
>

i would expect that certificates similar to those being proposed in  
sidr for bgp could be used for protecting this database. It would be  
nice to have cheaper techniques though

Regards, marcelo

>  - Robin
>

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram