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

Eric Rescorla <ekr@rtfm.com> Mon, 15 October 2018 13:14 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8BB130DFB for <lisp@ietfa.amsl.com>; Mon, 15 Oct 2018 06:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNzVOFpnzvTu for <lisp@ietfa.amsl.com>; Mon, 15 Oct 2018 06:13:59 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF70D130E62 for <lisp@ietf.org>; Mon, 15 Oct 2018 06:13:56 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id n14-v6so2180283lfe.6 for <lisp@ietf.org>; Mon, 15 Oct 2018 06:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hu9WqeAccOSnP2LFt/TKBp97WrXjMlm1EPAG/A5B6Gs=; b=gvf0GQmq6zd9xwOL5jPwSCQ3jRL9l96qUsbXvGrVIgEf42obioQW4btFqGrtNXJ+GK Xcg99y1hpxUhLCBi4I5uyTuCTwLsQM6faBaG1R2yoqxTPA8Kg/gDo53YDI8ifU3/Zmri z8UyDE0tg7Cm6MG+A9xiRUlLZqv2CwkU5pJv5EAWRCbqsSmuecWaSnguNYnkNbCbJDCc Dn4Mk/gXUjvF/tsoYdyZXUYdX/tQCH+6g6sR1Mb82FltS1X+7GIwwMrPbV9KY/g88l/y OjOrQOACg4vkJfnECWbJ9BsPm4xp7NI7HMiIjFwcxVM3mY4yN1mzI7LxWU9Y1X3DA9IT W1jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hu9WqeAccOSnP2LFt/TKBp97WrXjMlm1EPAG/A5B6Gs=; b=VRx/2uA/pueEPKzA65J0D8nluroj++YjPkKJprc+2pa3a7d0jYlN2qfsCgOOzJjmt6 K7tuX6dOlLvvLrEf1Yjnn1XwCaJCVlzyEoTZkWddzR7NJ8phcZgGlzvCOxZkVw+XaOg6 Hpk9PBFg/zsRm07RvRJkj4iMi566pa5OUVbgCLVnQ5pxQHHWfo9zuXnNT4ZB0kxA+EB3 pEn2d1CFVNh8zmhq/PVQ8aOMmuHZuNdB7RcVZ74sWXdqPbMxN+Y6h4MvEsBvQETsp0l6 kknLPNpwwVQ7jjaWMbGe50/5exC392s+/4fny6w+dL3lLjLZiRa1Z/qs/AHcGrdHWtzy xcBg==
X-Gm-Message-State: ABuFfoi7aP+nzbUsX2x0HzN12xY0CLyZ4LP0m0+yKINpN2VeBBk4gzYK rrklogZF2W0xnm7pZHHkrWAbPjyaLYJauCKU0bx1vQ==
X-Google-Smtp-Source: ACcGV625DdZD3PKiAKDqU1Osg/RMCRS5wyBNfr0OH6Ofxn+nblyVNaKJX6eACfvnB9tntK/YE7iIZWAPlOOil4pWJxo=
X-Received: by 2002:a19:3bcf:: with SMTP id d76-v6mr9482577lfl.126.1539609234978; Mon, 15 Oct 2018 06:13:54 -0700 (PDT)
MIME-Version: 1.0
References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> <ACFD874F-113E-4AD4-9056-CD3CFA9BA477@gmail.com> <CABcZeBM4XotbW6BYbCzHq7SJW7NdVK+fJZom8J=AHwi+dkL5Wg@mail.gmail.com> <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> <DDB8DF69-02B3-4168-A3B2-250421ED2584@gigix.net>
In-Reply-To: <DDB8DF69-02B3-4168-A3B2-250421ED2584@gigix.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 15 Oct 2018 06:13:17 -0700
Message-ID: <CABcZeBN=LCa2q2SiJ0o56iyso+wOXZL9RsJoJ9E9thc-tHL51Q@mail.gmail.com>
To: Luigi Iannone <ggx@gigix.net>
Cc: Dino Farinacci <farinacci@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" <db3546@att.com>, fmaino@cisco.com, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008b4c130578443512"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/E5T3zwCzSoKkUMnsiCgJ-cKJ_Ic>
Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 13:14:01 -0000

On Mon, Oct 15, 2018 at 3:49 AM Luigi Iannone <ggx@gigix.net> wrote:

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