Subject: [lisp] Design discussion -06-(4) -> protecting against coarse Map-Replies

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Dec 2009 18:38:07 -0800

A description of the design issue:

(4) Add text in a new subsection of section 6.1.5 about dealing with
    Map-Replies with coarse EID-prefixes.

As mentioned in the Hiroshima IETF, an ETR could return a Map-Reply  
with a coarse EID-prefix. One that is shorter in mask-length than what  
was allocated to it. Even if it is registered properly with the  
mapping system, there can be a bug, a compromise, or an inadvertent  
configuration to cause the Map-Reply to have a shorter mask-length  
then what was registered.

To fix this, there can be two possible solutions, one is proxy Map- 
Replying by a Map-Server on behalf of the ETRs for the registering  
site and ITRs being configured to not accept EID-prefixes shorter than  
a configured mask-length.

Would anyone like to comment on this? We can propose text but there  
may be other lightweight solutions to this. We would like to figure a  
lightweight solution versus having a strong ITR-to-ETR authentication  
mechanism which most probably would require third-party systems.

Thanks,
Dino/Darrel

---

From: Damien Saucez <[email-masked]>
Date: Tue, 22 Dec 2009 09:31:48 +0100

On 22 Dec 2009, at 03:38, Dino Farinacci wrote:

> As mentioned in the Hiroshima IETF, an ETR could return a Map-Reply with a coarse EID-prefix. One that is shorter in mask-length than what was allocated to it. Even if it is registered properly with the mapping system, there can be a bug, a compromise, or an inadvertent configuration to cause the Map-Reply to have a shorter mask-length then what was registered.
> 
> To fix this, there can be two possible solutions, one is proxy Map-Replying by a Map-Server on behalf of the ETRs for the registering site and ITRs being configured to not accept EID-prefixes shorter than a configured mask-length.
> 
> Would anyone like to comment on this? We can propose text but there may be other lightweight solutions to this. We would like to figure a lightweight solution versus having a strong ITR-to-ETR authentication mechanism which most probably would require third-party systems.
> 

Using the proxy will not protect against configuration error. We should seriously consider authentication for mappings:
- authenticate the owner
- authenticate the EID prefix
- authenticate the RLOCs

Maybe we should have a look at X.509 and the proposals to put authentication in BGP. For the moment, it is not clear how to completely pre-calculate the Map-Reply to avoid overloading the MS while keeping protected against replay attacks.

The authentication is not only a protection against attackers, but also against miss-configurations that could generate partial black-hole for up to TTL instants (how to send SMR to the requesters if traffic never arrives the miss-configured site?) 

Damien Saucez

> Thanks,
> Dino/Darrel
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Dec 2009 16:48:28 -0800

>> with a coarse EID-prefix. One that is shorter in mask-length than  
>> what was allocated to it. Even if it is registered properly with  
>> the mapping system, there can be a bug, a compromise, or an  
>> inadvertent configuration to cause the Map-Reply to have a shorter  
>> mask-length then what was registered.
>>
>> site and ITRs being configured to not accept EID-prefixes shorter  
>> than a configured mask-length.
>>
>> may be other lightweight solutions to this. We would like to figure  
>> a lightweight solution versus having a strong ITR-to-ETR  
>> authentication mechanism which most probably would require third- 
>> party systems.
>>
>
> Using the proxy will not protect against configuration error. We  
> should seriously consider authentication for mappings:
> - authenticate the owner

Well it does. Unless the config error happens on both the ETR and the  
map-server, in which case, it will be the map-server's EID-prefix  
length which is advertised.

> Maybe we should have a look at X.509 and the proposals to put  
> authentication in BGP. For the moment, it is not clear how to  
> completely pre-calculate the Map-Reply to avoid overloading the MS  
> while keeping protected against replay attacks.
>
> The authentication is not only a protection against attackers, but  
> also against miss-configurations that could generate partial black- 
> hole for up to TTL instants (how to send SMR to the requesters if  
> traffic never arrives the miss-configured site?)

Well, that may not be true. If it's consistently misconfigured, you  
have the same problem you state above.

Dino