Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

[Luigi Iannone <[e-mail]>]

Hi,

> On 15 Oct 2018, at 04:20, Dino Farinacci <[e-mail]> wrote:
> 
>>> Well this is true, but 6833bis discusses RLOC-reachability and there
>>> is a RLOC-probe cache that will tell the ITR when it last heard from
>>> the RLOC.
>> 
>> Just to be clear, it's not "last heard from" that you need, but
>> rather "last verifiably responded".
> 
> Right agree. 
> 
>>>> S 16.
>>>>>   Map-Versioning is a Data-Plane mechanism used to signal a peering xTR
>>>>>   that a local EID-to-RLOC mapping has been updated, so that the
>>>>>   peering xTR uses LISP Control-Plane signaling message to retrieve a
>>>>>   fresh mapping.  This can be used by an attacker to forge the map-
>>>>>   versioning field of a LISP encapsulated header and force an excessive
>>>>>   amount of signaling between xTRs that may overload them.
>>>> 
>>>> Can't I also set a super-high version number, thus gagging updates?
>>> 
>>> It doesn’t matter the value. All that matters is that it changed and you should do to the mapping system to get an updated RLOC-set.
>> 
>> Hmm... S 5.1 of 6834-bis suggests that you can just discard it.

This is true if we talk about the destination version number (S5.1 6834bis).

If you receive a LISP packet carrying a map version number that is higher that what you registered in the map system then there is ana issue with the packet. Best option is to discard it.

Different think is about source version number. If I receive a packet with a source Map-Version number higher (does not matter how much higher, just higher) than the version I have stored in my cache, then I need to check with the mapping system whether something has really changed, hence I send a Map-Request. This last action can generate the attack described above.

Concerning the text it self, I think is OK. Or you guys see something missing or not clearly stated?

Ciao

L.

 

> 
> Luigi - what do you think. Do we need rewording?
> 
> Dino