Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15

Luigi Iannone <ggx@gigix.net> Thu, 30 August 2018 11:01 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48D130E48 for <ietf@ietfa.amsl.com>; Thu, 30 Aug 2018 04:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 DG7tc72Jjk_w for <ietf@ietfa.amsl.com>; Thu, 30 Aug 2018 04:01:27 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 D8D73130E4F for <ietf@ietf.org>; Thu, 30 Aug 2018 04:01:24 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id o18-v6so1574620wmc.0 for <ietf@ietf.org>; Thu, 30 Aug 2018 04:01:24 -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=gLVDjsZdaY2bbNjLHqG98l6mYBox4239AoGIdI7XN20=; b=VLT8eU+Cbub7agAZ0UPp9PvI4scSrUUakAgXIcnXRhQozfaqRSQj8wRgwa+HRQUCcO dipRJkikQsF9YwJY2ADOq3XcO+nWCO911DkBQAgWJ4SrzzltRiVc5HDUahrFSDmkcB69 RQ+mlOiRjONOkkOLFljQm6xC4b7vRdMfASWzFYGQ4saVraZoI1LgzjM7Fel4Lwp1cMk3 Q9zRFTepSTUKLLVsouzzxMKF4IghM3kZTecDb5E16dspoRFj3wXtbRO7Pl5I2d40I8Vh AzL3gWIILkYKA9+QT/5iJO0fGJGTnCI1U3C7BnhfsdAcBTrh/mBKarKZCJJcacm0mj6u 5kWw==
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=gLVDjsZdaY2bbNjLHqG98l6mYBox4239AoGIdI7XN20=; b=R1d77FW6w90aqVFzoy8Ba+Nk3G9qpGWxhYH7TDWp9eH6Ak9sa/nJ5Jhxeuh8rNlC27 TUZOkP8EwFLM/dcp3kMSgY/Aq6dA1WPzuN6hZg6ko2Sjv8Ck7lAt3BshogcBwyqkntbP NtpllK5RkxJbBmtEA9BSz8r1wrK05u10FwQvZHCo/FSG4m6yhLWpZPO80Jx/1kEmfYW2 hEKrzPdO1Od/1yBqVCfrWfwzpJxBOBuwCOCN2MYZSJtM6M9zSdMWVQe+Jd3RunRz/gqI is3TQ7Pzck49HoAYuq3c7ADvvgVCOwQdXjQs6b11fLzdx3THN3jQ6/V65+KQ2ijXJ/Rt aHDg==
X-Gm-Message-State: APzg51ArJEzRlZIG1KkXIHVWWGXZag/4zAjAYrM5T49ETzJNjqBqDiWy aKUkkZ2MDZqCUb7OTGFPQQLYYg==
X-Google-Smtp-Source: ANB0VdYO1JtdmIrXg1VxY9nyBizIZFmJeUw0U7NoIPhC6nBwBW6agKRnXFUvFA1kurUenJaC5M/EVQ==
X-Received: by 2002:a1c:93d2:: with SMTP id v201-v6mr1414066wmd.77.1535626883289; Thu, 30 Aug 2018 04:01:23 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:38:9171:c3a4:c6d3:6140? ([2001:660:330f:38:9171:c3a4:c6d3:6140]) by smtp.gmail.com with ESMTPSA id p89-v6sm11737564wrc.97.2018.08.30.04.01.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 04:01:22 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <0F515189-0329-49F6-9A86-41DD3557BA2E@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C2831D20-2417-4C0F-844E-DA78EBCC9CF8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15
Date: Thu, 30 Aug 2018 13:01:20 +0200
In-Reply-To: <CAJU8_nWwHAQYeo4oCVq=dVquRK1VhO-TdUKw5JmvbX1idWa=VA@mail.gmail.com>
Cc: Dino Farinacci <farinacci@gmail.com>, IETF SecDir <secdir@ietf.org>, draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
To: Kyle Rose <krose@krose.org>
References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <FDA69FDF-696B-4959-AADB-0999630C723D@gmail.com> <CAJU8_nWwHAQYeo4oCVq=dVquRK1VhO-TdUKw5JmvbX1idWa=VA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5C9K8Ql5VdeguqLhWpNp2Aox5wU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 11:01:30 -0000

Kyle, Dino,

I fill like this discussion is going sideways w.r.t. the original 6830bis document.

You started to discuss other documents and other solutions, which, while certainly interesting and important, belong to other threads and documents.

IMHO here are the few points that need to be clarified:

> On 28 Aug 2018, at 23:48, Kyle Rose <krose@krose.org> wrote:
> 
> Hi, Dino. I have additional responses inline.
> 
> > For the internet core (DFZ RIB) use-case, LISP proposes replacing BGP sessions
> > and global eventually-consistent state sharing with a global control plane and
> 
> LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC reachability across the network is available, or there would be no underlay for the LISP overlay.
> 
> The whole point of LISP is to create a routing overlay for the EID address space, the RIB of which is managed by a global mapping system, not BGP sessions. If control plane traffic managed by BGP (or static routes, or whatever networks use once the DFZ RIB is limited to entities in the core) continues to flow, that is of small comfort to end users trying to get data over the data plane. >From the perspective of end users, BGP is being replaced routing of the traffic that matters to them.
> 
> Maybe this is just splitting hairs: I certainly don't want to rathole on this point.

@Kyle: can we consider this point closed?

[trimmed]

> https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis <https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis>
> 
> > One area of concern, of which I have not been able to find discussion, is that
> > of the implications of shared capacity for the control and data planes, and how
> > this can allow a volumetric data plane attack to deny a router access to the
> > global mapping system, slowly choking off service to uncached portions of the
> 
> Well yes, this happens with all our IETF protocols. It is a valid concern and there are many operational techniques in network infrastructure that *help* solve (but not eliminate) these problems.
> 
> I would like to see a discussion of whether and how the nature and scale of this problem differs from that of the status quo. BGP sessions and RIB push have properties that are well-established from decades of experience: surely LISP does not have exactly the same properties. The security considerations should make clear, for instance, how a loss of control plane connectivity differs from the loss of a BGP session, and how this impacts visibility and behavior of the data plane.
 
I am not sure I understand the point. Isn’t this covered by RFC7835? Reference to that document isn’t sufficient?
If not, can you clarify further?

> 
> > I would also like clarification on what defines the separation between the
> > control plane and data plane, and whether authentication itself is used to
> 
> A control-plane obtains information to store in a table. The data-plane uses that table. That is the definition in the simpliest form.
> 
> I mean specific to LISP, not generically. For instance, does "LISP Control-Plane signaling" include only valid messages, or valid + inauthentic (and presumably dropped) messages? Traditional attack traffic (e.g., a DDoS attack against a website) is part of the same data plane as all legitimate end user traffic; is attack traffic directed at control plane endpoints considered part of the control plane, or is it a third category of traffic? If the latter, then what does an operator need to do to ensure that control plane is always available?

IMHO, these questions should be asked for in the 6833bis thread. Don’t you guys agree?

Ciao

L.





> 
> Kyle