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

Luigi Iannone <ggx@gigix.net> Mon, 15 October 2018 15:18 UTC

Return-Path: <ggx@gigix.net>
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 310DA1294D0 for <lisp@ietfa.amsl.com>; Mon, 15 Oct 2018 08:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.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 2V1e0j9JSHcE for <lisp@ietfa.amsl.com>; Mon, 15 Oct 2018 08:18:24 -0700 (PDT)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 DD460130E84 for <lisp@ietf.org>; Mon, 15 Oct 2018 08:18:23 -0700 (PDT)
Received: by mail-wr1-x443.google.com with SMTP id a13-v6so21814183wrt.5 for <lisp@ietf.org>; Mon, 15 Oct 2018 08:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mgOBXghonsZnVw9H1979shRg+fZwD6Jior46usGdex8=; b=M+xDY+n1INn/TCYmzfjOWjbTmdpZED3TOwKSFxO4Ph1+fcnJPAwuzpjNMF8IjOvqwc wLGoxoM3dUyUxFtrQ6G8Q3lrbd3hqLrM+okv6zw46RKoYqmh7qc73GGU1pg49jcja9/N l1msdQSQSrDu1AIv3PgNbNk/Lu2gUH6d9Xm0h5xhsDnoY5QHDlj/mnNqgyF0i/lUiNRZ kQEXhwgVZ98iMpZ/n3uHAzV8K/zdilM+p/Bhd5CF0BRe2cXs+VuHAwqIK1o2F2eMUSid kK5I7xkdyehxYgGQGrw0UBjEGswPjZRNbNapI5raDXGy477oZOhBbq+2rH0hDrUDNCG9 u8OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mgOBXghonsZnVw9H1979shRg+fZwD6Jior46usGdex8=; b=cS7Tm1KSNOOFn8jcVU9f9QTV5Ogg7wdJFBUk/290AU4zT+6ouFcdPgwdTNMjFieESk DMuNfNE+UD+9fSnE8zc77dh0l4Ta2pFZ+pok9CKz5g9gPOS1jaFJatSqd3NgKiSwVLec IrsR9/7QHckk6Virc3P0e0ZEhPP7WJF7c4lbHlQO0/ZS+ONrypLIu/w2wxKqW/NQyZRb SlZaWXai/VKJF/ln49ntccsXqNn5W1VjQ+oapkvV+sFKmI6/t42U71f7adjGBJIy+LIJ dAr/NWgXaALpOQNNmOt8cYGzUj8T2ykTQhLQgUMud3IIRLcV/h8tFJoLGHYlynFX8s8U L5yQ==
X-Gm-Message-State: ABuFfoiZcJYhspzEQ7kEiZxr5jSrrpUW/lwNu9Oa2/BKO/FHLLiM3stt 0mLzv/L8/wzYVhzMhwh1qt0mOg==
X-Google-Smtp-Source: ACcGV62VRWGlO7hjQCNsQTV1+8ZzIbi1b7o9YC9odL44w8gjoLI0w6Fx9e4mTqTMXaO2X4SM7TPd4A==
X-Received: by 2002:a5d:620b:: with SMTP id y11-v6mr14806785wru.105.1539616702192; Mon, 15 Oct 2018 08:18:22 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:fda3:d27a:939b:2383? ([2001:660:330f:a4:fda3:d27a:939b:2383]) by smtp.gmail.com with ESMTPSA id t3-v6sm9091689wru.47.2018.10.15.08.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 08:18:20 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <A0A7D67B-2C02-429F-895B-EB8F810676AB@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AAE46E1B-BF17-4BD5-8338-71553C0E946A"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Mon, 15 Oct 2018 17:18:18 +0200
In-Reply-To: <CABcZeBN=LCa2q2SiJ0o56iyso+wOXZL9RsJoJ9E9thc-tHL51Q@mail.gmail.com>
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>
To: Eric Rescorla <ekr@rtfm.com>
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> <CABcZeBN=LCa2q2SiJ0o56iyso+wOXZL9RsJoJ9E9thc-tHL51Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/YJql1pCtgRGlWqKCQPsfoJx1eDQ>
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 15:18:27 -0000


> On 15 Oct 2018, at 15:13, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Mon, Oct 15, 2018 at 3:49 AM Luigi Iannone <ggx@gigix.net <mailto:ggx@gigix.net>> wrote:
> Hi,
> 
> > On 15 Oct 2018, at 04:20, Dino Farinacci <farinacci@gmail.com <mailto: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.
> 

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