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

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Sep 2009 10:43:49 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > a "gleaned" map-cache entry will not be created if a map entry already
    > exists for an EID prefix containing the EID in the received packet,
    > even if the map-cache entry indicates that packets to that EID should
    > be sent to a different ETR.

_Especially_ if the map-cache entry indicates that packets to that EID should
be sent to a different ETR! :-)

    > if an attacker can reliably cause an ITR to send a map request for a
    > particular EID, he can then send map replies for that EID, even though
    > he didn't see the request.

<Innocent_face> How do you know the attacker is male? Maybe they are female?
</Innocent_face> :-)

    > If he sends a bunch (potentially thousands) of map replies over the
    > next several seconds, perhaps one of them will match the nonce
    > ... This is a percentages game... While it might only work 1 in a
    > ~10,000 times, there isn't any reason why the attacker couldn't try it
    > 10,000 times .. until it works. The spoofed entries could contain a
    > long TTL and a short prefix

This is all perfectly true, but I don't think people are saying that the
existing nonce is the perfect security mechanism for all time. Remember, the
current effort is just an _experiment_, and it's not expected that it will be
perfect in every way. If nothing else, lifetime-grade security probably means
a lot more configuration, and as secure DNS is showing us, that can be a big
hump to get over.

I do think it would be good to have the right _basic mechanisms_ in place
(i.e. fields in packets) so that if LISP catches on, we can later deploy
better security in an interoperable way, but that's a separate matter.

In the meantime, 'reply without matching nonce' probably out to be logged, so
that we can at least detect DoS attacks (and it should be possible to disable
the message, lest it itself become a DoS vector). It might also be good to
temporarilly disable 'gleaning' of entries, to make this attack less viable.

    > There are a couple ways to deal with this attack that I can think of:
    > (1) Make the nonce in the map request/reply larger

That is certainly one way to go, if we want to 'harden' the existing
mechanism. We probably ought to look at securing the entire system, though,
to see if that's the direction we want to go, or if the overall security
architecture is going to go in a different direction (e.g. security entries,
not communication). Or maybe we do both - this is certainly an easy-enough
change.

    > Require that the reply be sent from the map resolver to whom the
    > request was sent

This has the downside that it probably introduces additional latency. Of
course, if you already have a valid entry, and are merely trying to confirm
that the entry is valid, that may not be a problem.

    > What happens if you get two different replies that both have the right
    > nonce? Will you accept the first and then accept the second,
    > overwriting the information received in the first? Or will you accept
    > the first .. and reject the second because it doesn't match any open
    > nonce? Either way, if an attacker can send a reply with a matching
    > nonce ... you will end-up using his mapping about 50% of the time

I think there are two cases to consider here. The first is a DoS attack, but
as I pointed out above, we should already have logging in place to detect
those. Either one of these two events occurring could usefully be a _second_
message, which could indicate possible map cache corruption.

There's also the possibility that for some reason, you could get this pattern
(two different replies) for legitimate reasons. So what would the appropriate
response be there?

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Sep 2009 10:50:55 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > Is it possible to get them to state their requirements to the WG, so
    > that we can discuss the best way to meet them, rather than stating
    > their requirements as a need for a specific solution?

The impression I get from Dino's original is that their requirement was
indeed put in high-level terms, not as a specific mechanism:

    >>> hosting providers that wanted to reduce the additional delay in
    >>> returning packets to client sites

which I gather means 'packet arrives at large content provider site from
previously unheard-from correspondent, i.e. no cached mapping in the ITRs at
the LCPS, and the LCPS wants to be able to return a reply ASAP, in particular
without waiting for a mapping resolution cycle'.

BTW, I see from looking in my records that this particular optimization _may_
have come out of a block of work I did on optimizing CONS, back in 2007 - at
least, this particular optimization is discussed in the notes I have there.
It may also have been thought about before that - IIRC, some of the other
deployment models of LISP (e.g. LISP 1) used a similar concept.

Anyway, here is the block of notes about that particular optimization, from
a table of potential optimizations from September, 2007):

  #2b - Piggybacking of client bindings on initial data packet
  o Not considered at length
  o Costs are modest
  -- The ITRs either have to have some way of deciding which packets are
	  initial packets (probably means extra state), or they'd have to
	  put the binding on all packets
  -- Extra fields in the data packet to contain the reverse bindinga
  -- Processing of normal data packets in ETR is more complex, as they have
	  to check for, and process, the binding
  o Benefits are significant
  -- Removes all the overhead of the reverse request, in almost all cases
  o Vulnerable to hijacking unless the binding is secured in some way
  o Vulnerable to DoS unless the binding is secured in some way
  o This one also has the issue if the return ITR isn't the same as the
	  incoming ETR - the binding would have to be forwarded

Obviously, many (most?) of the optimizations in that table are CONS-speciic,
but several of them are directed at this very point: reducing the delay for
LCPS's to respond to clients which are contacting them for the first time.

I also have an extensive series of essays covering this very point:

  Caching bindings in the CDR hierarchy is half of what we need to make CONS
  work quite well for large content providers.

  ...

  It's the other direction that I think we need to think about now; i.e. the
  second binding needed for any two-way communication. I've been called these
  'reverse' bindings, but that is probably not the best term for that binding,
  because a 'reverse binding' is usually the binding between two names, but in
  the other direction to normal, e.g. in our case an RLOC->EID binding. So I'm
  going to start calling these 'client bindings'.

  To be exact, I use this term for the second of a pair of binding requests,
  one from each end - on the assumption that although not all pairwise
  connections are client/server, many are, and for all client/server
  interactions, the client does the lookup of the 'server binding' first.

  (One can be fairly certain that the other end will in fact need this binding,
  because if the client's ITR needs the server binding, the two probably have
  not communicated previously, and so the server's ITR won't have the client
  binding either; i.e. sending the client binding to the server end is not
  useless overhead.)

  We've discussed this a bit, alluding briefly to piggybacking them on server
  binding requests, and adding them to initial data packets. We've also
  mentioned some of the difficulties caused by non-symmetric operation, both
  for the [x]TRs and the CARs. What I want to do here is a more complete
  analysis of the whole problem, along with a detailed recommendation.

but alas most of it is CONS-specific, so I don't think there's too much use
in forwarding it.

	Noel