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

[Robin Whittle <[e-mail]>]

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.

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

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?

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.

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.

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?

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.

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.

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.

If an ITFH lets through a packet without tunneling it, then the
packet will be forwarded to some ITRC or ITRD (or maybe explicitly
tunneled by the ITFH to an ITRD).  Likewise, if things are
properly organised, an ITRC doesn't have to encapsulate and tunnel
every packet with an Ivip-mapped DA.  It can either tunnel these
packets to some other ITRC, or ideally to an ITRD, which will
handle them - or if the local routing system is suitably
organised, the packets will flow through one or more ITRCs or
ITRDs anyway.

I will add something like this to the I-D:

  The idea is that any ITFH or ITRC can let a packet addressed
  to an IMAB pass on to another ITRC or an ITRD which will handle
  it.

  This will happen naturally with an ITFH, since any still
  unencapsulated packets it emits will ultimately be forwarded
  to some router which advertises the Ivip-Mapped Address Blocks
  (IMABs) and so can presumably definitely encapsulate the packet.

  To achieve this, any ITRC which advertises the Ivip IMABs must
  have a way of tunneling the packets it can't handle to some
  other ITR which definitely can encapsulate them.  This could be
  another such ITRC, provided any chain or tree of these always
  forwards packets which still need to be encapsulated towards
  either an ITRD which will do it, or to the Internet, where
  the packets should find such an ITRD (which hopefully won't
  be overloaded.)

  ITRC functions could be installed on internal routers in
  a network, so they look out for all packets with DA matching
  any IMAB and either encapsulate them, or leave them
  unencapsulated.  However, forwarding some or all of these
  packets without encapsulation will only work if this ITRC
  does not actually advertise itself as the destination for
  packets addressed to these IMABs.  If it did, the packets
  it forwards which still need to be encapsulated will probably
  not progress to any other router.  So an ITRC which is simply
  in the path of packets in general, without advertising itself
  as the destination for the Ivip IMABs, doesn't need to
  explicitly tunnel packets it can't handle to some other ITR.


So the impact of the DoS attack on any one ITRC or ITFH in a
network which was correctly configured for Ivip (according to the
new text above) would be to cause some packets to go on longer
paths before an ITR encapsulated them.  This would cause extra
load on the network, and on these other ITRs, but unless the
packet wound up at a core ITR or some other ITR which advertised
the IMAB prefixes and was overloaded with traffic, then the packet
would always be encapsulated and find its way to the destination.


  - Robin     http://www.firstpr.com.au/ip/ivip/



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