On Mon, Oct 15, 2018 at 3:49 AM Luigi Iannone <[email protected]> wrote:

> Hi,
>
> > On 15 Oct 2018, at 04:20, Dino Farinacci <[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.

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.

-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

Reply via email to