Re: [Anima] Some questions to the WG: [I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 02 October 2017 00:24 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AA7132D22; Sun, 1 Oct 2017 17:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 a54Jf73qGpP6; Sun, 1 Oct 2017 17:24:45 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB115132C32; Sun, 1 Oct 2017 17:24:45 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E254E1D5; Sun, 1 Oct 2017 20:30:00 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E4A481637; Sun, 1 Oct 2017 20:24:44 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org
In-Reply-To: <d7495a4d-380b-7b9a-e2ba-561952f747d7@gmail.com>
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca> <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de> <19014.1506705896@obiwan.sandelman.ca> <d7495a4d-380b-7b9a-e2ba-561952f747d7@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sun, 01 Oct 2017 20:24:44 -0400
Message-ID: <23483.1506903884@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/c9O1m8jsdfWV8P0mp60R5M4LWbo>
Subject: Re: [Anima] Some questions to the WG: [I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2017 00:24:47 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > So there are several separate questions here.

    > 1. I understood Toerless to be arguing that the registrar may need to be
    > contacted again some considerable time after the bootstrap (i.e. join)
    > action, specifically for what he called EST-renew.

    > Is that agreed?

Yes, but once on the ACP, a node has many different ways to find a renewal
Registrar.  Where that system is could be found via a number of other ways.

    > 2. If yes, would that need a new discovery action?

    > I assume the answer is yes, since we want to be reasonably
    > stateless and not assume that we can cache the registrar's address
    > and port indefinitely.

Yes.

    > 3. If so, do we want to re-use the same objective (AN_join_registrar
    > for the sake of argument)?

No, because:
  a) The join registrar might not support renewal or other complex
     EST methods.  This might be to avoid providing unnecessary attack surfaces.

  b) The join registrar may be provisioned for the join process.
     It might be turned off (or scaled down) when there are no nodes expected
     to join.

    > 4. In any case, do we want to make this objective or objectives
    > highly extensible (which basically means using CBOR maps instead
    > of simple CBOR arrays)? This has the usual pros and cons:
    > highly extensible = more complex parsing.

I don't want to do that.

    > Although we currently require that GRASP
    > runs over an ACP, there is nothing magic about that. I don't see that
    > BRSKI actually depends on the ACP either; both would surely run over
    > bare metal if we told them to (and the Security ADs weren't watching).

Agreed.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-