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

[Robin Whittle <[e-mail]>]

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.

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.


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


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


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

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.

 - Robin


_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram