Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Sep 2009 13:09:56 -0400 (EDT)

> From: "Darrel Lewis (darlewis)" <[email-masked]>

    > Dino's comments seem to be about data-gleaning. That is, placing map
    > entries in the cache by inspecting the data-plane traffic.
    > ...
    > Margaret and Noel (I think) seem to be talking about the map-data that
    > is piggybacked on a Map-Request packet.

Umm, no, but it's complicated.

Margaret is concerned (and I was discussing) a _two-step_ attack process, the
first step of which involves a temporary, gleaned, mapping ("map entr[y] in
the cache by inspecting the data-plane traffic"), and the second step of which
involves making that entry permanent by sneaking in a bogus Map-Reply, by
bombarding the ITR with bogus Map-Replies, hoping that one will have the
correct nonce.

AFAIK, we haven't discussed/considered here the "map-data ... piggybacked on a
Map-Request packet" stuff at all.

    > Data Plane gleaning doesn't seem useful in the capital I internet, but
    > Map-Request map-data gleaning is very useful, since it prevents packet
    > loss/delay on return traffic of session set up.

Now you have _me_ confused! :-)

I thought user-data gleaning was used/useful for precisely the same reason,
i.e. the it avoided having to do a binding cycle for the return packets. Now
you're saying that that functionality is provided by piggybacking the client
binding on the request for the server binding?

(I.e. the request for the server binding will be delivered to an ETR at the
server site, and that device can retain the client binding from that
Map-Request, so that when the return packet shows up, the client binding is
already there?)

If so, then yes, user-data gleaning seems to be superfluous.

But now we seem to have two separate, but intertwined, issues: i)
optimization of acquisition of client bindings (because I have some questions
about the piggybacked binding mechanism), and ii) the security of the
Map-Requst/Map-Reply cycle triggered by gleaning bindings from user-data
packets (the original issue).

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 14:18:51 -0400

> Map-Request packet" stuff at all.

As Noel said, this is not the attack I was discussing before.  This is  
a different potential avenue for attacking LISP.  I was thinking about  
this one last night, and I don't think that we can allow ETRs to cache  
map "replies" contained in the map requests they receive, unless they  
can verify somehow that the map reply information in the packet  
contains the valid ETR for the indicated EID prefix.

Margaret