On Wed, Feb 6, 2019 at 7:08 PM Dino Farinacci <[email protected]> wrote:
> 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.
>
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
>
>
> On Wed, Feb 6, 2019 at 6:11 PM Eric Rescorla <[email protected]> wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
