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

Hi Robin,

El 12/07/2007, a las 6:39, Robin Whittle escribió:

> My understanding of:
>
>   http://tools.ietf.org/html/draft-bagnulo-lisp-threat-01
>
> is that 3.1 to 3.1.1.3 involves sending an encapsulated packet to
> a combined ETR-ITR which convinces that router that the RLOC to
> use when encapsulating packets with EID=V is the the attacker's
> address.  So subsequent packets with EID=V will wind up at the
> attacker's host.
>

right

> This is for "LISP 1" (1.5?) where there is no central database.
>

this applies to LISP as defined in draft-farinacci-lisp-01 which states:

    This document will focus on LISP 1 and LISP 1.5, both of which rely
    on a router-based distributed cache and database for EID-to-RLOC
    mappings.  The LISP 2 and LISP 3 mechanisms, which require separate
    EID-to-RLOC infrastructure, will be documented in additional drafts.

So, it is not clear to me whether this threats apply only to LISP1  
and 1,5, it depends on whether the other (yet to be documeted)  
versions of LISP will learn using data and MapReply packets or they  
will striclty learn mapping infromation from the database interface

which is clear that an additional threat analysis is needed to  
understand the threats to the database, how to introduce and  
propagate mapping information in it.

> In LISP 2.x, 3.x or 4.x:
>
> http://www1.ietf.org/mail-archive/web/ram/current/msg01289.html
>
> is it true to say that the ETR-ITR wouldn't learn any such false
> information simply by receiving a packet, because its mapping is
> controlled by a database instead?

i don't know, there is no ID describing LISP v2,3,4 afaik

>
> Ivip's ITRs are always controlled by one or more databases - there
> are no messages and ETRs don't "learn" anything from the
> encapsulated packet.  So this vulnerability doesn't apply to Ivip.
>

haven't read the ivip draft yet, sorry,

> Likewise, Ivip has no "Map-Reply" message and the ITRs don't learn
> their mapping from anything other than their own copy of the
> database(s) or from responses resulting from queries to a query
> server which has a copy.  So the rest of section 3.1, 3.2.1, 3.2.2
> and 3.2.3 doesn't apply to Ivip.
>

the tradeoff here, is that the receiving host needs to query the  
database to learn that information, introducing additional latency  
when the first packet is received i guess.

> In LISP 2 to 4 does the ITR learn mapping information from
> Map-Reply messages or from an associated ETR learning an RLOC from
> the outer header of an encapsulated packet it receives?
>

don't know, as i said i am not aware of any ID that documents lisp 2,3,4

> 3.2.4 concerns the cache of ETRs or ITRs overflowing - but the
> sentence:
>
>   An attacker could massively generate either tunnelled data
>   packets so that the router cache is overflowed.
>
> looks incomplete.
>

?

> I think that in all LISP variants the ITR is not intended to carry
> a copy of the entire database, so in principle its cache could be
> overflowed by either making it learn mapping information from the
> headers of encapsulated packets or perhaps by some use of the Map
> Reply message.
>

exactly

> I think the ITR's cache could also be made to overflow by simply
> sending packets to it which are addressed to a wide variety of
> LISP EIDs, each with different mappings.  This would force the ITR
> to query and cache the mapping for each EID, or for whatever
> prefix each EID is within which has the same mapping information.
>

right

> Ivip has ITRDs with a full copy of "the database" - actually
> multiple arrays of mapping information, one for each Ivip Mapped
> Address Block (IMAB, previously "master-subnet").  So an ITRD
> can't be overloaded by any pattern of destination addresses in the
> packets it encapsulates.  This is practical, at least for IPv4,
> using a server with a 64 bit CPU, rather than a conventional
> router (though in principle some routers could do it) because the
> Ivip mapping is simply a 4 byte IP address for every address in
> the IMABs.  (LISP's data per EID IP address or prefix is more
> extensive.)  2 billion Ivip-mapped addresses therefore require 8
> gigabytes of RAM, plus some extra RAM for indexing into this set
> of arrays for each IMAB and for decoding the incoming database
> dumps (boot time) and real-time updates.
>
> 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)

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, 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)
- the DoS attack will also affect the mapping database, which will  
receive all the requests from all the routers it is serving,

regards, marcelo

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