> On 15 Oct 2018, at 15:13, Eric Rescorla <[email protected]> wrote: > > > > On Mon, Oct 15, 2018 at 3:49 AM Luigi Iannone <[email protected] > <mailto:[email protected]>> wrote: > Hi, > > > On 15 Oct 2018, at 04:20, Dino Farinacci <[email protected] > > <mailto:[email protected]>> 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. > > The issue is how you handle lower. >
Interesting. I didn’t think about this case…. > Because if you discard lower numbers, then an attacker who can get you to > accept a high-version can cause you to refuse future updates. True. This all depends on the mapping system actually. If somehow you can get into the control plane and make me think the version number is higher, than yes. At that point there is a bigger problem, if I could get an hold on the control plane I would do more than just tempering versions number… But this is a different story. What I suggest is that I add specific text about this in the 6834bis document. Do you agree? I’ll send you the text later on. Ciao L. > > -Ekr > > > 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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
