Subject: [lisp] Constructing Map-Replies with overlapping prefixes

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Feb 2019 18:11:19 -0800

I'm trying to piece together the algorithm in 6833-bis S 5.5
for Map-Replies. The text says:

   A Map-Reply returns an EID-Prefix with a mask-length that is less
   than or equal to the EID being requested.

So, consider the case where an MS has two mappings:

   10/8 -> ETR1
   11/8 -> ETR2

If the Map-Request is for 10.0.0.1, then I would return

   10/8 -> ETR1

Now consider what happens when I have three mappings:

   10/16   -> ETR1
   10.0.2/24 -> ETR3 // New
   11/16   -> ETR2

Now we turn to the remainder of this section:

   When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility],
   the database mapping system may have overlapping EID-prefixes.  Or
   when a LISP site is configured with multiple sets of ETRs that
   support different EID-prefix mask-lengths, the database mapping
   system may have overlapping EID-prefixes.  When overlapping EID-
   prefixes exist, a Map-Request with an EID that best matches any EID-
   Prefix MUST be returned in a single Map-Reply message.  For instance,
   if an ETR had database mapping entries for EID-Prefixes:

I'm having trouble parsing this, but what I get out of the example
is that the Map-Response is supposed to contain the EID-prefix that
best matches the request, plus whatever exceptions would be required
to create a correct routing table. So, that would mean in the case
where the Map-Request contains 10.0.0.1, the MS would have to reply
with:

   10/16   -> ETR1
   10.0.2/24 -> ETR3 // New

The first of these is necessary to provide correct routing information
for the requested prefix and the second to avoid providing incorrect
routing information for 10.0.2.1.

Do I have this correct? It seems like the alternative is that the MS
or ETR synthesize a new, more specific prefix. Is that what's intended
instead? The example in S 5.5 suggests otehrwise, but perhaps I am
misunderstanding.

Thanks,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Feb 2019 18:22:13 -0800

Another question: What does the Map Server do if it gets a request for a
shorter prefix than it has an EID for. E.g., I have a mapping for 10/8 (and
nothing else) but I get a request for 10/4. The text in S 5.5 suggests that
I return an empty locator set. Is that correct?

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Feb 2019 19:05:59 -0800

> So, that would mean in the case

10.0.0.1 is not more specific than 10.0.2.0/24 because 10.0.0.1 & 0xffffff00 = 10.0.0.0 which is not equal to 10.0.2.0 & 0xffffff00 = 10.0.2.0. 

So a lookup for 10.0.2.2 would return only the ETR3 entry. And if 10.0.0.1 was looked up later than the /16 would be returned. 

But when 10.0.0.1 is looked up first, than all more specifics of the matching entry, the /16, must be returned. Because you don’t want the cache to match a coarse entry in the cache when there is a more specific in the mapping system. 

> routing information for 10.0.2.1.

Right. 

> instead? The example in S 5.5 suggests otehrwise, but perhaps I am

Well it could return a prefix 10.0.0.1/32 with an RLOC of ETR1 so the entires stored in the cache are the ones actually used. But that would cause not Map-Request load and more entires in the cache. 

So one trades off up front all registered entries in the cache versus all possible destination EIDs that matches the coarsest prefix. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Feb 2019 19:08:17 -0800

> Another question: What does the Map Server do if it gets a request for a shorter prefix than it has an EID for. E.g., I have a

Returns an empty RLOC-set with action “native-forward” with an EID-prefix that is equal to the EID-prefix in the Map-Request. 

> mapping for 10/8 (and nothing else) but I get a request for 10/4. The text in S 5.5 suggests that I return an empty locator set. Is that correct?

Yep. 

Dino

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Feb 2019 20:29:05 -0800

On Wed, Feb 6, 2019 at 7:06 PM Dino Farinacci <[email-masked]> wrote:

> 10.0.0.1 is not more specific than 10.0.2.0/24 because 10.0.0.1 &
> 0xffffff00 = 10.0.0.0 which is not equal to 10.0.2.0 & 0xffffff00 =
> 10.0.2.0.
>
> So a lookup for 10.0.2.2 would return only the ETR3 entry. And if 10.0.0.1
> was looked up later than the /16 would be returned.
>

Sorry, I think you lost me here. How does the MS know that the ITR already
has the ETR3 entry? I would expect that if you had the sequence of queries:
10.0.2.2/32 and 10.0.0.1/32, you would get (10.0.2/24) and then (10/16 and
10.0.2/24). Am I confuges?

> > routing information for 10.0.2.1.

Thanks.

> Well it could return a prefix 10.0.0.1/32 with an RLOC of ETR1 so the
> entires stored in the cache are the ones actually used. But that would
> cause not Map-Request load and more entires in the cache.
>

Sorry, I think you lost me here. Are you saying that the MS can *either*
return both the 10/16 and 10.0.2/24 prefixes *or* 10.0.0.1/32 at its
discretion?

Thanks,
-Ekr

> So one trades off up front all registered entries in the cache versus all
> possible destination EIDs that matches the coarsest prefix.
>
> Dino

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Feb 2019 20:35:51 -0800

On Wed, Feb 6, 2019 at 7:08 PM Dino Farinacci <[email-masked]> wrote:

> shorter prefix than it has an EID for. E.g., I have a
>
> Returns an empty RLOC-set with action “native-forward” with an EID-prefix
> that is equal to the EID-prefix in the Map-Request.
>
> mapping for 10/8 (and nothing else) but I get a request for 10/4. The text
> in S 5.5 suggests that I return an empty locator set. Is that correct?
> Yep.
>

Thanks. This brings me to the security question I have.

As I understand it, Map-Requests are not integrity protected (except
for the protected OTK if LISP-SEC is used). So consider the following
situation.

Let's assume that the MS has a prefix table consisting of:

  10.1/16 -> ETR1
  10.2/16 -> ETR2

The ITR wants to send to 10.1.0.1, so it naturally send a Map-Request
for that address, but the attacker tampers with it.

ITR                           Attacker                  Map Server

Map-Request [10.1.0.1/32] ->
                                  Map-Request [10/8] ->
                                  <- Map-Reply [10/8, RLOC-Set=()]
   <- Map-Reply [10/8, RLOC-Set=()]

Assuming I have understood correctly, this will cause the ITR to think
that there is no available mapping for anything in 10/8.  Even if
there is LISP-SEC, because the Map-Request isn't integrity protected,
though the Map-Reply is, the integrity protection doesn't cover the
requested prefix, so that doesn't help.

Is there something in the protocol that I am missing that prevents this?

Thanks,
-Ekr

Dino