[RRG] LISP gleaning looks insecure and therefore unusable

[Robin Whittle <rw@firstpr.com.au>]

Short version:    Gleaning seems to be completely insecure,
                  so I can't imagine how it could be useful.


Hi Dino and Team,

Here are some questions about "gleaning".  I am basing these on:

  http://tools.ietf.org/html/draft-farinacci-lisp-06
  http://tools.ietf.org/html/draft-lewis-lisp-interworking-00

The other two:

  http://tools.ietf.org/html/draft-lear-lisp-nerd-03
  http://tools.ietf.org/html/draft-fuller-lisp-alt-01

do not contain the word "glean".

Here is my understanding of gleaning, by way of an example:

   HostA-->--R1==>==R2==>==R3-->--HostB

HostA sends a packet to HostB.  HostB's address is within a
LISP-mapped EID prefix.  R1 functions as an ITR and (after gaining
the mapping information for HostB's address) encapsulates the packet
and tunnels it "==" to R3 which acts as an ETR.  The decapsulated
packet is sent to HostB.  (Also, perhaps R1 had no mapping, but the
packet gets to R3 via the ALT network.)

As I understand it, "gleaning" involves R3, as an ETR, taking the
outer source address of the packet it received (R1's address) as an
RLOC location, presuming it to be the address of an ETR, and the
inner packet's source address (HostA's address) and presuming this
to be an EID.

The purpose is to have at least this gleaned mapping information:

  EID (HostA's address) mapped to RLOC (R1's address)

ready, without any delay due to mapping lookups, for the likely
event that HostB will soon send a packet right to left to HostA.

This is not the full mapping information for HostA's address - which
can only be obtained by a mapping request.  However, I understand
this mapping is to be used to send HostB -> HostA packets until
mapping has been retrieved.  This is an expedient to get packets
through without delays caused by mapping lookups - but this system
cannot implement the full LISP functionality of load sharing etc.
That has to wait for the arrival of the full mapping information.

Here are some observations, questions or critiques.

Is it true that gleaning has no role in LISP-NERD, where every ITR
has the full database?  If so, it would be good to point this out.

The basic draft-farinacci-lisp-06 document can be hard to
understand, because it primarily (or solely?) applies to LISP
variants 1.0 and 1.5.  Where do LISP-NERD and LISP-ALT fit into
this?  The reader is trying to construct a concrete understanding of
how NERD and ALT would work while reading multiple documents which
reference each other in general, but perhaps not in sufficient detail.

The rest of this discussion assumes LISP-ALT.

If R3, now acting as an ITR, used this gleaned mapping information
to enable it to tunnel a HostB -> HostA packet to R1, this would
work only if R1 was an ETR and if it was the ETR (or one of several
ETRs) which was configured to accept packets for HostA.

So I think that for gleaning to be a part of LISP, you are therefore
constraining every ITR to be an ETR, and furthermore, constraining
the network structures so that the first ITR a packet sent by HostA
reaches must also be the ETR for HostA.

I would have thought it would be better to allow ETRs and ITRs to be
physically separate things.  This way, operators can place them
wherever they like, or at least have more freedom about placement.

Also, this would enable the workload of ITR and ETR functions to be
split across two separate devices.

My main concern with gleaning is that it seems to be completely
insecure.

An attacker could send a packet to R3 which is identical to the
packet R3 gets from R1 in the above example, except that instead of
the outer header's source address being that of R1, it is of the
attacker's machine Bad1.

This would do two things.  Firstly the packet would be decapsulated
by R3, forwarded to HostB and so prompt HostB to send a packet to
HostA.  This is identical to the initial example.

Secondly, it would cause R3 to glean the ETR address of Bad1 as the
address to tunnel packets to (until mapping data arrives) when it
receives a packet addressed to HostA.

Consequently, Bad1 gets the encapsulated response packet sent by
HostB to HostA.  For a while - until mapping data arrives - Bad1 can
masquerade as HostA.

There's no way R3 can possibly ensure that this gleaned information
is valid - other than do a mapping lookup, which takes time, and
renders the gleaned information irrelevant.


The above example assumes that HostA's address is within an EID
prefix mapped by LISP.  That would mean that there was a purpose in
gleaning the HostA -> R1 mapping information.

But suppose HostA's address was an ordinary RLOC address.  It still
needs to use an ITR to get its packet to HostB, so with gleaning, as
I understand it, R3 will do as noted above: cache the HostA -> R1
association and whenever it gets a packet addressed to HostA, will
encapsulate it and tunnel it to R1.

Ignoring the security problems, you could fix this in at least two ways.

Firstly, you could have R3 look-up some kind of master list which
defines which parts of the address space are LISP EIDs and which are
not.  The purpose of gleaning is to get preliminary mapping
information without any mapping delays.  If the master list was not
in the ITR, but only stored at some remote server, then you could do
the look-up via ALT.  This means you would need to wait a while
while the query traverses the ALT network and the reply comes back
via an ordinary Internet packet.  There would be no point in doing
this, since it would be better for R3 to simply use the ALT
networked to ask for the mapping of HostA's address.  So the only
way of preserving the goal of gleaning is for every device which is
both an ITR and an ETR to have a previously created master list of
LISP EIDs.  This would need to be pushed out to all these devices,
securely, on a reasonably frequent basis.

Secondly, you could have the ITR (R1 in the above example) somehow
decide whether it was the ETR for this particular address (HostA)
and include a flag in the LISP header, telling the ETR (R3) whether
or not to glean this inner source address -> outer source address
combination as preliminary mapping information.  To do this, the ITR
R1 would need to have a complete list of LISP EID prefixes, or at
least by the time it sends this initial packet, to have found out
whether HostA's address was within a LISP EID or not.  The former
would require push to every ITR and the latter would require a
mapping lookup for HostA's address, in addition to the mapping
lookup of HostB's address.


Assuming you could somehow make gleaning secure, I think you would
need a flag in the LISP header to turn it on and off.  Without this,
you have to ensure that the ITR which encapsulates the packet is in
fact the ETR (or one of the ETRs) for the sending host (HostA above).

Proxy Tunnel Routers (the same as Ivip's "anycast ITRs in the
core/DFZ") are required to make LISP incrementally deployable.
Obviously, the PTR, which is an ITR in the DFZ  - not necessarily
anywhere near or associated with the sending host's network - is not
the ETR for the sending host.

It is not clear from my reading of the current LISP drafts how
gleaning could be successful when the packet was encapsulated by a PTR.


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



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