Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 23 September 2017 20:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 12FCA132198; Sat, 23 Sep 2017 13:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XT9he73hLSzm; Sat, 23 Sep 2017 13:52:55 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 7EE74129B7A; Sat, 23 Sep 2017 13:52:55 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id l188so2049318pfc.6; Sat, 23 Sep 2017 13:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vI9iXjioWKLHhp+TZNDDwWEhBBFhaEtwSnDgy6C3rMU=; b=mzdB+p4OYDjJUe8j4GiwEYdot8VtfUdojGxf9D9hBDRRSGUkTlSLmAi305AKybGZGX kkVoj8Tt+0eosipz46ea8/1RT47u3zNwIs9MaUKV91S3bi/UO/aLLpNJbfuWSiJy393G O3rTpCbVXDAxjjaEQsFjJbyi/WrCj1U1GwieG9yQeNOmsBgAhsg/cyOuaYNCXEnxrPbO 9tV8/ZJQ3BM5AJ5GNNIpWtf3RboHU76Su10b6IxniFK50ieWfyyPbNRslsQ3pBqD2XGN 0u7/ZEdw1ZSHfnDjrrifSQ81DXm3vzqZYuhzHZ55bJis16IMNSGlDpqUXhRSY/OC43h0 qjZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vI9iXjioWKLHhp+TZNDDwWEhBBFhaEtwSnDgy6C3rMU=; b=SUViiqBC1viMBsGH0upMjMngz006bPBeZL+6bk67V+xd1/dwbDe/HNUF05w2bNzCTO pT0TQtEkeQBNOi6DnvlxPr9+kMojh8GPE+ph7nIVFdYPe8mLCV7vbNGJivtug8aqNsRY wVoVsQ5DQSnI9hL7eIlRXXDIsvJWiWzPPGPnafX9/JT0LSoOZj1MmpZd4mvWw2tk56Ug SwSgaZxgYmyW37iKPIxQgCdOp+GjeYh9Mpa8IKyUlfCcf0EvxbImZI0aZE63J3kfDpaB 9NbfjhIFB08/u1cZhSOaeL5mel7ffGD0WRillViTGEoP7EJH0MDSnpyUsylfVciblYfZ IcuA==
X-Gm-Message-State: AHPjjUjGKVCB6DBaEikZ6jT3UJBFCVV7BU37ZWcHDySh4macQ4JlPBZj tj3EI+H+Ne19OQX1GjlT2Gx8LA==
X-Google-Smtp-Source: AOwi7QC2p9T7R04jhEEFc/5ebx1YvBWTgEVDu6FnJmTIsyrU2EEGakqyK8s59pfjgCL3EWyuhDOg9Q==
X-Received: by 10.84.234.196 with SMTP id i4mr3019414plt.432.1506199974355; Sat, 23 Sep 2017 13:52:54 -0700 (PDT)
Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s81sm5853132pfg.162.2017.09.23.13.52.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 13:52:53 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com>
Date: Sun, 24 Sep 2017 09:52:48 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <11713.1506195333@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Rp0d3-b6UmI0zGf0QhwsLFWA5Vw>
Subject: Re: [Anima] 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: Sat, 23 Sep 2017 20:52:58 -0000

Michael,

I get a bit confused by the way your mail agent doesn't distinguish
new and old text, but in line...

On 24/09/2017 08:35, Michael Richardson wrote:
> 
> Toerless, thank you for this version.  We are very very close!
> Brian, Max, I invoke your name in my comments... please read and +1,
> or disagree with me.
> 
> I noticed in this version has two places with no space after the .:
> 
>  	   across the network.[RFC7575] defines the fundamental ideas and design
>            and it should be re-usable by all autonomic functions.[RFC7575]
>            calls
> 
> 
> Can we avoid semantic/normative statments like "ACP routing table may include
> multiple" in a terminology section?
> 
> Change:
> ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
>  	      normal/simple case, the ACP has one ULA prefix, see Section 6.10.
>  	      The ACP routing table may include multiple ULA prefixes if the
>  	      "rsub" option is used to create addresses from more than one ULA
>  	      prefix.  See Section 6.1.1.  The ACP may also include non-ULA
>  	      prefixes if those are configured on ACP connect interfaces.  See
>  	      Section 8.1.1.
> 
> to:
>   ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
>  	      normative case, the ACP has one ULA prefix as specified in
>               Section 6.10.  The cases where multiple prefixes are present
>               are explained in Section 6.1.1, and use of non-ULA prefixes
>               are explained in Section 8.1.1.
> 
> There are some good updates to the ACP domain.  I want to bring up this issue
> From BRSKI here:
>            https://github.com/anima-wg/anima-bootstrap/issues/20
> 
> I was suggesting that the information for the Pledge's CSR should be broken
> up such that the pledge will create the right CN from the pieces, which it
> needs to know anyway. I had suggested:
> 
>    "ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001",
>                     "acp-prefix-length": 96,
>                     "acp-plus-part": "area51.research",
>                     "acp-domain": "acp.example.com"
>    }
> 
> I don't like your text:
>            If the operator does not own any FQDN, it should
>  	   choose am FQDN format string that intends to be equally unique.
> 
> I suggest that:
>   If they don't own any FQDN, then, aside from WTF?, that they form a
>   unique name as: $(uuidgen).example.com.
>   Or, perhaps that they use ${ULA}.example.com.
> 
> the only real-life situation where this is going to happen is in a test lab
> run by co-op students, and in that case, the software might as well have a
> pre-configured default.
> 
> ======
> 
> Brian, Max and I asked you to remove the EST requirements on announcements
> From the ACP document.

Toerless explained elsewhere why he thinks the duplication is needed.
 
> ======
>    ACP secure channel MUST imediately be terminated when the lifetime of
>  	   any certificate in the chain used to authenticate the neighbor
>  	   expires or becomes revoked.  Note that is is not standard behavior in
>  	   secure channel protocols such as IPsec because the certificate
>  	   authentication only influences the setup of the secure channel in
>  	   these protocols.
> 
> This is rather impractical to implement in real life, that's why IPsec
> doesn't do that.  I strongly suggest you sit down with some Cisco, Juniper
> (Netscreen) and Checkpoint IPsec product managers, and ask them what they
> actually do, and why.
> 
> Assuming you really want to have this kind of behaviour, then the correct way
> to do this is to make statements about the rekey intervals on the channels.
> 
>    ACP secure channels created with the use of certificates will include some
>        lifetimes for the certificates. The set of lifetimes includes:
>                  1) the expiry date of the certificate
>                  2) the lifetime of the OCSP response
>                  3) the validity time of the CRL response
> 
>        The earliest date provided by these provides a time at which the
>        keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed.
> 
> 
> 6.10.4.  ACP Manual Addressing Sub-Scheme
> 
>    The sub-scheme defined here is defined by the Type value 1 (one) in
> 
> was changed to:
>    The sub-scheme defined here is defined by the Type value 00b (zero)
> 
> I think that this is a typo, and should be 01b ?
> Or does the Manual mechanism somehow fit into the
>    ACP Zone Addressing Sub-Scheme because the Z bit is different?
> 
> Do you explain this manual zone better somewhere?
> 
> 
> Can you show the two Types with their bits set at the end of the base scheme?
> 
>                 64                             64
>     +---------------------+---------+---++-----------------------------+
>     |    (base scheme)  01|Subnet-ID| Z ||     Interface Identifier    |
>     +---------------------+---------+---++-----------------------------+
>     <-------48--------->TT    13      1
> 
> 
> section 8.8.1, starting at:
>         The ACP connect interface must be (auto-)configured with an IPv6
> 
> seems to be missing articles and/or words, and needs an english editing pass.
> 
> ====== section 11
>            This document may be considered to be updating the IPv6 addressing
>  	   architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
>  	   addresses ([RFC4193]) depending on how strict specific statements in
> 
> I don't like this statement.  Either it violates the spec, and updates it, or
> it does not.  I do not think that it violates.  This is not a multi-link
> subnet, this is a prefix that is not on-link.

As readers of the 6man list know, this has been a very contentious topic.
I think it's safer to duck it in the ACP draft: say what we do, but say
nothing about RFC4291 etc.

>         It is possible, that this scheme constitutes an update to RFC4191
>  	because the same 64 bit subnet prefix is used across many ACP
>  	devices.  The ACP Zone addressing Sub-Scheme is very similar to the
>  	common operational practices of assigning /128 loopback addresses to
>  	network devices from the same /48 or /64 subnet prefix.
> 
> It does not. Brian? Do you concur?

Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign
them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that
sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links").
But we don't need to apologise. As you say, we're simply assigning /128
addresses to (virtual) interfaces using our own scheme. And we're relying
on BCP 198 (RFC 7608) which says that routing prefixes can be any length
up to /128. If you want to cite anything, cite RFC 7608.

>         The goal for the 8 or 16-bit addresses available to an ACP device in
>         this scheme is to assign them as required to software components,
>         which in autonomic networking are called ASA (Autonomic Service
> 
> We are not providing 8-bit or 16-bit IIDs.
> We are providing 256 or 65536 /128 addresses which are conveniently
> aggregated for routing purposes.
> 
>  	   In practical terms, the ACP should be enabled to create from its /8
>  	   or /16 prefix one or more device internal virtual subnets and to
>  	   start software components connected to those virtual subnets.
> 
> No, don't say this, and don't do this in practice.  Create /128 routes to LL
> address of the internal VM and configure the /128 as a loopback address
> inside the VM.

So yes, I concur with Michael.

    Brian