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

Brian E Carpenter <> Sat, 23 September 2017 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12FCA132198; Sat, 23 Sep 2017 13:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XT9he73hLSzm; Sat, 23 Sep 2017 13:52:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EE74129B7A; Sat, 23 Sep 2017 13:52:55 -0700 (PDT)
Received: by with SMTP id l188so2049318pfc.6; Sat, 23 Sep 2017 13:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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 with ESMTPSA id s81sm5853132pfg.162.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 13:52:53 -0700 (PDT)
To: Michael Richardson <>,,
References: <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
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: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Sep 2017 20:52:58 -0000


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:
> 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": ""
>    }
> 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)
>   Or, perhaps that they use ${ULA}
> 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.