[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[trimming to just the topics still under discussion; no change to the
text of the remaining items even though some changes have been made
to the document]

I think there needs to be some justification of why rfc822Name is chosen
over a more conventional structure in the otherName portion of the
subjectAltName, which is explicitly designed to be extensible.

In a few places, the MTI cryptographic mechanisms are under-specified,
whether the cipher mode for IKE or the TLS ciphersuites.  I have attempted
to note these locations in my section-by-section comments.

Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL
root, but if I understand correctly the RPL root is automatically
determined within the ACP, and thus the operator does not a priori know
which node will become the RPL root.  Am I misunderstanding, or is this
effectively placing this requirement on all ACP nodes?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for adding the implementation experience note to the shepherd
writeup; it is helpful to understand the maturity level of the document.

The comments here are probably best understood in the context of my
previous ballot position, specifically with respect to certain topics
being "speculative" or a matter for "future work".

One somewhat general comment that occurred to me on the reread is that
by encoding the ACP address into a node's LDevID, we are on the face of
things locking it into a given addressing model, though in practice it
should be fairly straightforward to issue a new certificate through
regular update/renewal mechanisms.  I forget if we have discussion of
this non-issue already.

Section 1

   Combining ACP with Bootstrapping Remote Secure Key Infrastructures
   (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the
   "Autonomic Network Infrastructure" as defined in
   [I-D.ietf-anima-reference-model], which provides autonomic
   connectivity (from ACP) with fully secure zero-touch (automated)
   bootstrap from BRSKI.  The ANI itself does not constitute an

nit: It's unclear that there's universal agreement about what "fully
secure" might mean, so I'd suggest just using "secure".

Section 2

   ACP (ANI/AN) Domain Certificate:  A provisioned [RFC5280] certificate
      (LDevID) carrying the domain information field which is used by

nit: I think the reference is for "certificate", not "provisioned".

   ACP secure channel:  A cryptographically authenticated and encrypted
      data connection established between (normally) adjacent ACP nodes
      to carry traffic of the ACP VRF secure and isolated from Data-
      Plane traffic in-band over the same link/path as the Data-Plane.

nit: I'm not sure if "secure" or "securely" is better (but what does
"secure from" mean?)

   Enrollment:  The process where a node presents identification (for
      example through keying material such as the private key of an
      IDevID) to a network and acquires a network specific identity and
      trust anchor such as an LDevID.

nit: the LDevID is the identity; it's not a trust anchor.

Section 5

   3.  For each node in the candidate peer list, it authenticates that
       node (according to Section 6.1.2) and negotiates a mutually
       acceptable channel type.

   4.  For each node in the candidate peer list, it then establishes a
       secure tunnel of the negotiated type.  The resulting tunnels are
       then placed into the previously set up VRF.  This creates an
       overlay network with hop-by-hop tunnels.

nit: the "channel type" of (3) is the "negotiated type" of the "secure
tunnel" in (4), right?  It might be nice to use the same word in
both items, to help tie the language together.

Section 6

nit: "must have it's ACP domain certificate" gained an apostrophe in "it's"
but the original "its" was correct.

Section 6.1

   members.  The LDevID is used to cryptographically authenticate the
   membership of its owner node in the ACP domain to other ACP domain
   members, the TA is used to authenticate the ACP domain membership of
   other nodes (see Section 6.1.2).

nit: comma splice

   The ACP does not mandate specific mechanisms by which this keying
   material is provisioned into the ACP node, it only requires the
   Domain information field as specified in Section 6.1.1 in its domain
   certificate as well as those of candidate ACP peers.  See

nit: comma splice

   The ACP domain certificate SHOULD be used for any authentication
   between nodes with ACP domain certificates (ACP nodes and NOC nodes)
   where the required condition is ACP domain membership, such as ACP

nit(?) I'd suggest s/required condition/required authorization
condition/

Section 6.1.1

The ABNF in Figure 2 seems to have multiple what I'll call for lack of a
better term "terminal constructions" (i.e., routing-subdomain and
domain-information) that are not used in other rules.  Some text on
which one is used in the rfc822Name and which is just informational for
other purposes is probably in order.

   o  The maximum size of "domain-information" is 254 characters and the
      maximum size of node-info is 64 characters according to [RFC5280]
      that is referring to [RFC2821] (superseded by [RFC5321]).

nit: I don't think we refer to node-info anywhere.

On the topic of rfc822Name vs. otherName, I note that there's no
requirement to use ASN.1 for the internal structure of the value; it's
perfectly acceptable to make it an OCTET STRING and shove a
more-friendly data structure in there.  (It's a little bit weird in
terms of mental models, but funny looks aside, it's pretty common.)  If
the other structure is fixed-length, there is not any actual ASN.1
knowledge required by the recipient; they just check that the length is
right and the data starts with the correct fixed prefix (corresponding
to the OID and ASN.1 length encoding), before processing the encoded
data in whatever  manner is appropriate.  Since we want to put domain
names in, fixed-length is probably out of the figure, but even if we're
limited to what openssl provides, getting an ASN1_OCTET_STRING and
extracting its contents to a pointer+length is pretty well established;
we don't need to make people learn about ASN1_SEQUENCE() at all.  So you
could have the fundamental structure of the otherName be something like:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
|                        Flags                              |M|A|
+---------------------------------------------------------------+
|                                                               |
+                                                               +
|                                                               |
+                         [acp-address]                         +
|                                                               |
+                                                               +
|                                                               |
+---------------------------------------------------------------+
|     rsub-len                 |   rsub...                      |
+------------------------------+                                +
~                                                               ~
+---------------------------------------------------------------+
|     acp-domain-len           |   acp-domain...                |
+------------------------------+                                +
~                                                               ~
+---------------------------------------------------------------+
|                    [TLV extensions]                           |
+---------------------------------------------------------------+

where M means that the holder of the cert is allowed to establish an ACP
secure channel (what the '0' acp-address does in the present
formulation) and A means that the acp-address field is present

and just pack that into an OCTET STRING.

Is the [e-mail] email address for human use really
providing much value?  This is pretty clearly breaking an abstraction
barrier, from my point of view.

      It also makes acp-domain-name a valid e-mail target across all
      routing-subdomains.

nit: rfcSELF@acp-domain-name

   o  It should be possible to share the LDevID with other uses beside
      the ACP.  Therefore, the information element required for the ACP
      should be encoded so that it minimizes the possibility of creating
      incompatibilities with such other uses.

otherName with an ACP-specific OID has zero possibility of collisions
with other uses; reusing rfc822Name has nonzero possibility of
collision.  (Note that having multiple otherNames is allowed.)

   o  The information for the ACP should not cause incompatibilities
      with any pre-existing ASN.1 software.  This eliminates the
      introduction of a novel information element because that could
      require extensions to such pre-existing ASN.1 parsers.

Even getting to the rfc822Name requires some level of ASN.1 parsing, so
it's unclear how strong this argument really is.

   o  The element required for the ACP should not be misinterpreted by
      any other uses of the LDevID.  If the element used for the ACP is
      interpreted by other uses, the impact should be benign.

[OIDs are by construction unique]

   o  At minimum, both the AN domain name and the non-domain name
      derived part of the ACP address need to be encoded in one or more
      appropriate fields of the certificate, so there are not many
      alternatives with pre-existing fields where the only possible
      conflicts would likely be beneficial.

It's even possible to define multiple OIDs for otherName use, one for
acp-domain-name, one for rsub, etc.. But that feels kind of like
overkill to me.

Section 6.1.2

   3:   The peer's certificate passes certificate path validation as
      defined in [RFC5280] against one of the Trust Anchors associated
      with the ACP nodes ACP domain certificate (see Section 6.1.3
      below).

nit: "node's" possessive

   4:   If the node certificate indicates a Certificate Revocation List
      (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or
      Online Certificate Status Protocol (OCSP) responder ([RFC5280],
      section 4.2.2.1), then the peer's certificate must be valid
      according to those criteria: An OCSP check for the peer's
      certificate across the ACP must succeed or the peer certificate
      must not be listed in the CRL retrieved from the CDP.  [...]

side note: we could (but don't have to)  note that OCSP stapling is a
way to get an OCSP response to check.

   5:   The peer's certificate has a syntactically valid ACP domain
      information field (encoded as subjectAltName / rfc822Name) and the
      acp-domain-name in that peer's domain information field is the
      same as in this ACP node's certificate (lowercase normalized).

(Writing this as "has an otherName subjectAltName using the ACP OID"
seems more concise to me, but I'll try to stop beating that horse.)

   When an ACP node learns later via OCSP/CRL that an ACP peers
   certificate for which rule 4 had to be skipped during ACP secure
   channel establishment is invalid, then the ACP secure channel to that
   peer SHOULD be closed even if this peer is the only connectivity to
   access CRL/OCSP.  The ACP secure channel connection MUST be retried
   periodically to support the case that the neighbor aquires a new,
   valid certificate.

nit: we could probably tighten up the writing here about "MUST be
retried periodically" in terms of needing to reestablish the TLS
connection provisionally and repeat the initial connection steps, though
on second read the current text seems better than I thought on first read.

   Only when checking a candidate peer's certificate for the purpose of
   establishing an ACP secure channel, one additional check is
   performed:

nit: I'd suggest s/Only when/When/

   Formally, the ACP domain membership check includes both the
   authentication of the peers certificate (steps 1...4) and a check
   authorizing this node and the peer to establish an ACP connection
   and/or any other secure connection across ACP or data-plane end to
   end.  Step 5 authorizes to build any non-ACP secure connection
   between members of the same ACP domain, step 5 and 6 are required to
   build an ACP secure channel.  For brevity, the remainder of this
   document refers to this process only as authentication instead of as
   authentication and authorization.

I'd prefer to see a penultimate sentence along the lines of "Other
authorization models are possible by local policy, but for this
specification (and to some extent, autonomic systems in general), domain
membership is deemed sufficient authorization for all operations."

Section 6.1.3

   A certificate path is a chain of certificates starting at a self-
   signed certificate of a so called root-CA or Trust Anchor, followed

nit(?): I'm used to seeing chain construction start at the
leaf/end-entity and chain up to the root, but to some extent this is an
editorial question.

   A single owner can operate multiple independent ACP domains from the
   same set of private trust anchors (CAs) when the ACP Registrars are
   trusted not to permit certificates with incorrect ACP information
   fields to be signed.  Such as ACP information with a wrong acp-domain
   field.  [...]

nit: This last sentence is a sentence fragment (I suggest joining it to
the previous one with a comma).

Section 6.1.4

   with its ACP domain certificate.  When BRSKI (see
   [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of
   the BRSKI registrar from the BRSKI TLS connection SHOULD be
   remembered and used for the next renewal via EST if that registrar
   also announces itself as an EST server via GRASP (see next section)
   on its ACP address.

IIUC, the BRSKI spec currently advertises BRSKI registrars with the
EST-TLS objective, and I don't really understand how this interacts with
SRV.est or whether this text should change.

Section 6.1.4.1

   The objective name "SRV.est" indicates that the objective is an
   [RFC7030] compliant EST server because "est" is an [RFC6335]
   registered service name for [RFC7030].  Objective-value MUST be
   ignored if present.  Backward compatible extensions to [RFC7030] MAY
   be indicated through objective-value.  Non [RFC7030] compatible
   certificate renewal options MUST use a different objective-name.

I'd consider adding some text about ignoring unrecognized
objective-values, to attempt to preserve the usability of this extension
point.

Section 6.1.4.3

   The ACP node SHOULD support Certificate Revocation Lists (CRL) via
   HTTPs from one or more CRL Distribution Points (CDPs).  The CDP(s)

My understanding is that HTTP-not-s is commonly used for CRL
distribution since the CRL content itself is signed, and there would be
a risk of a circular dependency in validating the server's TLS
certificate to get to the CRL information.

   HTTPs connections.  The connecting ACP node SHOULD verify that the
   CDP certificate used during the HTTPs connection has the same ACP
   address as indicated in the CDP URL of the nodes ACP domain
   certificate if the CDP URL uses an IPv6 address.

nit: "node's" possessive.

Section 6.1.4.5

   enrollment.  Using the ACP node's domain certificate allows the BRSKI
   registrar to learn that nodes ACP domain information field, so that

nit: "node's" possessive.

   with its old ACP certificate.  The re-enrolling candidate ACP node
   SHOULD only request a voucher from the BRSKI registrar when this
   authentication fails during TLS connection setup.

I might suggest "SHOULD only fall back to requesting a voucher".

Section 6.1.4.6

   An ACP domain certificate is called failing in this document, if/when
   the ACP node can determine that it was revoked (or explicitly not
   renewed), or in the absence of such explicit local diagnostics, when
   the ACP node fails to connect to other ACP nodes in the same ACP
   domain using its ACP certificate.  For connection failures to

nit: maybe "the ACP node to which the certificate was issued", since
when I first read this I was expecting it to be about telling that some
other node's certificate is failing, not a node's own certificate.

Section 6.5

   At this time in the lifecycle of ACP nodes, it is unclear whether it
   is feasible to even decide on a single MTI (mandatory to implement)
   security association protocol across all ACP nodes.

(This is a future-looking statement that implies uncertainty in the
current spec.)

   [11:C2] Node 2 certificate has lower ACP Node-ID than  Node2,
           therefore Node 1 considers itself Bob and Node 2 Alice
           on connection C1, but they also identify that C2 is to the

I think this first "Node 2"  should be "Node 1"?

   interface" that they both connect to.  An autonomic node must not
   assume that neighbors with the same L2 or link-local IPv6 addresses
   on different L2 interfaces are the same node.  This can only be
   determined after examining the certificate after a successful
   security association attempt.

This could potentially be a "MUST NOT".

Section 6.7.1.1

   To run ACP via IPsec natively, no further IANA assignments/
   definitions are required.  An ACP node that is supporting native
   IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and
   peer link-local IPv6 addresses used for encapsulation.  It MUST then
   support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256
   hash and MUST NOT permit weaker crypto options.  Key establishment
   MUST support ECDHE with P-256.

I don't think "SHA256 hash" is quite specific enough (and we probably
want GMAC for integrity anyway).

Section 6.7.1.2

   To run ACP via GRE/IPsec, no further IANA assignments/definitions are
   required.  An ACP node that is supporting ACP via GRE/IPsec MUST then
   support IPsec security setup via IKEv2, IPsec transport mode, local
   and peer link-local IPv6 addresses used for encapsulation, ESP with
   AES256 encryption and SHA256 hash.

Why is IPsec/GRE using AES256/SHA256 when IPsec native is using
AES256-GCM?

Section 6.7.2

   We define the use of ACP via DTLS in the assumption that it is likely
   the first transport encryption code basis supported in some classes
   of constrained devices.

nit: I don't think "basis" is quite the right word, here; maybe "base"
(or collapsed back to "codebase" as one word) or omit it entirely.

Section 6.7.3

   support DTLS.  An ACP node connecting an area of constrained ACP
   nodes with an area of baseline ACP nodes MUST therefore support IPsec
   and DTLS and supports therefore the baseline and constrained profile.

nit: this could probably work just fine as a non-normative "must", since
it's just describing facts.

Section 6.8.2

nit: Figure 8 has a doubled word "ACP GRASP virtual virtual interfaces"
in the second box from the top.

       ...............................................................
       .      |          |          |   ^^^ Users of ACP (GRASP/ASA) .
       .      |          |          |   ACP interfaces/addressing    .
       .      |          |          |                                .
       .      |          |          |                                A
       .      | ACP-Loopback Interf.|      <- ACP Loopback interface C
       .      |      ACP-address    |       - address (global ULA)   P
       .    subnet1      |        subnet2  <- ACP virtual interfaces .
       .  link-local     |      link-local  - link-local addresses   .
       ...............................................................

I'm still a bit confused by this box in the figure -- is the "Users of
ACP" label supposed to apply to the previous box(es) or the current one?
If the former, it's confusing to see the "ACP security and transport
substrate for GRASP" being described as a "user of ACP".

   GRASP unicast messages inside the ACP always use the ACP address.
   Link-local addresses from the ACP VRF must not be used inside
   objectives.  GRASP unicast messages inside the ACP are transported
   via TLS 1.2 ([RFC5246]) connections with AES256 encryption and
   SHA256.  Mutual authentication uses the ACP domain membership check
   defined in (Section 6.1.2).

Just "AES256 encryption and SHA256" describes quite a few TLS
ciphersuites
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4);
I'd suggest limiting to a specific handful like
"TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" (the "Recommended" column in
the registry will be helpful at picking things).
It's probably also useful to specify a RSA/ECDSA key size (and elliptic
curve for ECDSA) and the nature of the ECDHE or DHE.

Section 6.8.2.1

   If GRASP peer connections would just use TCP, compromised ACP members
   could simply eavesdrop passively on GRASP peer connections for whom
   they are on-path ("Man In The Middle" - MITM).  Or intercept and

nit: I'd suggest "were to use just TCP".

   modify them.  With TLS, it is not possible to completely eliminate

nit: sentence fragment

Section 6.10

   Links inside the ACP only use link-local IPv6 addressing, such that
   each nodes ACP only requires one routable virtual address.

nit: "node's" possessive.

Section 6.10.2

   o  Establishing connectivity between different ACP (different acp-
      domain-name) is outside the scope of this specification.  If it is
      being done through future extensions, then the rsub of all
      routing-subdomains across those autonomic networks need to be
      selected so their hashes do not collide.  For example a large

nit: the grammar could be more clear that it's hash(routing-subdomain)
that must be collision-free, rather than hash(rsub)

Section 6.10.7.2

   information - ACP domain-name, ACP-address, and so on.  If the ACP
   registrar uses BRSKI, it signals the ACP domain information field to
   the Pledge via the EST /csraddrs command (see
   [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR
   Attributes").

I don't see a "csraddrs" EST well-known URL in either BRSKI or RFC 7030
(and the section number is probably stale as well, as the RFC Editor
note attests).  Oh, but /csrattrs is very close, so this is likely just
a typo.

Section 6.10.7.3

   scheme.  The first address of the prefix is the ACP address, all
   other addresses in the prefix are for other uses by the ACP node as
   described in the zone and Vlong addressing sub scheme sections.  The

nit: comma splice

   policy.  For example, in BRSKI, the ACP registrar is aware of the
   IDevID of the candidate ACP node, which contains a serialNnumber that
   is typically indicating the nodes vendor and device type and can be

nits: "serialNumber", "node's vendor" possessive

   ACP registrars SHOULD default to allocate ACP zone sub-address scheme
   addresses with Subnet-ID 0.  Allocation and use of zone sub-addresses
   with Subnet-ID != 0 is outside the scope of this specification

nit: it's only referred to as "Subnet-ID" in the manual addressing
sub-scheme; for the zone addressing sub-scheme it's "Zone-ID".

Section 6.11.1.1

   Additionally, failed ACP tunnels can be quickly discovered the secure
   channel protocol mechanisms such as IKEv2 Dead Peer Detection.  This

nit: missing word, maybe "through the secure channel protocol"

Section 6.11.1.9

   [RFC6550] security not used, substituted by ACP security.

   Because the ACP links already include provisions for confidentiality
   and integrity protection, their usage at the RPL layer would be
   redundant, and so RPL security is not used.

The ACP links provide only hop-by-hop security, but it looks like at
least some of the RFC6550 mechanisms provide more global source
authentication.  (I'm not suggesting we change the protocol to use RPL
security, just noting that this text is not quite right about being
entirely redundant.)

Section 6.11.1.14

I still think it's worth calling out that the RPL root is not
necessarily preconfigured and this "SHOULD" requirement could
potentially apply to any node, but this is only Comment-level and you
should feel free to ignore it.

Section 6.12.5

   Care must also be taken when creating multi-access ACP virtual
   interfaces across ACP secure channels between ACP nodes in different
   domains or routing subdomains.  The policies to be negotiated may be
   described as peer-to-peer policies in which case it is easier to
   create ACP point-to-point virtual interfaces for these secure
   channels.

nit: the text is unclear about what sort of policies are being
negotiated.

Section 8.1.1

   When an ACP Edge node receives a packet from an ACP connect
   interface, it MUST only forward it intot he ACP if it has an IPv6

nit: "into the"

Section 9.1

      when using OCSP/CRL.  The same benefit can be achieved when using
      CRL/OCSP, periodically refreshing the revocation information and
      also tearing down ACP secure channels when the peers (long-lived)
      certificate is revoked.  There is no requirement against ACP

nit: "peer's" possessive

   partition is left with one or more of such ACP registrars, it can
   continue to enroll new candidate ACP nodes as long as the ACP
   registrars sub-CA certificate does not expire.  Because the ACP

nit: "registrar's sub-CA" possessive

Section 9.2.2

   not the Data-Plane.  Especially for those management plane functions
   that have no good protection by themselves because they do not have
   secure end-to-end transport and to whom ACP does not only provides
   automatic reliable connectivity but also protection against attacks.

nit: s/does not only/not only/

Section 9.3

   An ACP is self-forming, self-managing and self-protecting, therefore
   has minimal dependencies on the administrator of the network.
   Specifically, since it is (intended to be) independent of
   configuration, there is no scope for configuration errors on the ACP
   itself.  The administrator may have the option to enable or disable

nit: Given that Section 8.2.1 talks about configuring ACP neighbors and
8.2.2 about configuring tunneled neighbors, I'd suggest to s/no
scope/only limited scope/, and perhaps similar tweaks in the following
paragraphs.

Section 10.1

   o  Check the validity of the domain certificate:

      *  Does the certificate authenticate against the trust anchor?

nit: s/authenticate/validate/

            -  The neighbors certificate does not have the required
               trust anchor.  Provide diagnostics which trust anchor it
               has (can identify whom the device belongs to).

            -  The neighbors certificate does not have the same domain
               (or no domain at all).  Diagnose domain-name and
               potentially other cert info.

            -  The neighbors certificate has been revoked or could not
               be authenticated by OCSP.

            -  The neighbors certificate has expired - or is not yet
               valid.

nit: s/neighbors/neighbor's/ (every time)

Section 10.2.2

      For BRSKI or other mechanisms using vouchers: Parameters to
      determine how to retrieve vouchers for specific type of secure
      bootstrap candidate ACP nodes (such as MASA URLs), unless this
      information is automatically learned such as from the LDevID of
      candidate ACP nodes (as defined in BRSKI).

I thought the LDevID was essentially synonymous with "ACP domain
certificate" in this document, so I can't understand what this means
(unless IDevID was intended).

Section 10.2.3

   Even when such a malicious ACP registrar is detected, resolving the
   problem may be difficult because it would require identifying all the
   wrong ACP domain certificates assigned via the ACP registrar after it
   was compromised.  And without additional centralized tracking of
   assigned certificates there is no way to do this.

side note: RFC 6962-style certificate transparency is a somewhat
decentralized way to do such tracking, though I do not think the
engineering tradeoffs favor trying to use it for this situation.

Section 10.2.5

      Which candidate ACP node is permitted or not permitted into an ACP
      domain.  This may not be a decision to be taken upfront, so that a
      per-serialNumber policy can be loaded into ever ACP registrar.

nit: "every"

Section 10.3.x

I still think the document quality here is not as mature as the majority
of the document, though concede there is value in covering these topics
to some extent in the initial work.

Section 10.3.5

   interface level "ACP/ANI enable" is ignored.  Once set, ACP/ANI will
   operate interface where "ACP/ANI enable" is set.  Setting of

nit: "operate on interfaces where"

Section 10.3.5.1

   Automatically setting "ANI enable" on brownfield nodes where the
   operator is unaware of it could also be a critical security issue
   depending on the vouchers used by BRKSI on these nodes.  An attacker
   could claim to be the owner of these devices and create an ACP that
   the attacker has access/control over.  In networks where the operator
   explicitly wants to enable the ANI this could not happen, because he
   would create a BRSKI registrar that would discover attack attempts.
   Nodes requiring "ownership vouchers" would not be subject to that
   attack.  See [I-D.ietf-anima-bootstrapping-keyinfra] for more
   details.  Note that a global "ACP enable" alone is not subject to
   these type of attacks, because it always depends on some other
   mechanism first to provision domain certificates into the device.

It's probably worth double-checking  that all of these details are still
synchronized with RFC 8366 and the current state of BRSKI.

Section 10.3.6

   Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the
   reliable operations of the ACP if it can be executed by mistake or
   unauthorized.  This behavior could be influenced through some
   additional property in the certificate (e.g., in the domain
   information extension field) subject to future work: In an ANI

[I don't know if it was intentional or an omission to leave this "future
work" note in place when most others were removed.]

Section 10.4

   There is no desirable configuration for the ACP.  Instead, all
   parameters that need to be configured in support of the ACP are
   limitations of the solution, but they are only needed in cases where
   not all components are made autonomic.  Whereever this is necessary,
   it will rely on pre-existing mechanisms for configuration such as CLI

"will rely on" can also be seen as an indicator for future work.

   o  When the ACP needs to be extended across interfacess other than
      L2, the ACP as defined in this document can not autodiscover
      candidate neighbors automatically.  Remove neighbors need to be
      configured, see Section 8.2.

nit: s/Remove/Remote/

   Once the ACP is operating, any further configuration for the data-
   lane can be configured more reliably across the ACP itself because

nit: data-plane

Section 11

   o  Every ACP registrar is criticial infrastructure that needs to be
      hardened against attacks similar to a CA.  A malicious registrar

nit: as written, this parses as saying that the attacks are similar to a
CA, not the amount of hardening needed on  the ACP registrar.  Adding a
comma would probably help.

   The ACP It is designed to enable automation of current network
   management and future autonomic peer-to-peer/distributed network

s/It //

   Attacks from impacted ACP nodes against the ACP are more difficult
   than against the data-plane because of the autoconfiguration of the
   ACP and the absence of configuration options that could be abused
   that allow to change/break ACP behavior.  This is excluding
   configuration for workaround in support of non-autonomic components.
  [...]
   The ACP acts as a security (and transport) substrate for GRASP inside
   the ACP such that GRASP is not only protected by attacks from the
   outside, but also by attacks from compromised inside attackers - by
   relying not only on hop-by-hop security of ACP secure channels, but
   adding end-to-end security for those GRASP messages.  See
   Section 6.8.2.

This is true, but the system as a whole still has the weakness that the
compromised node is able to announce GRASP objectives for arbitrary
services and potentially cause legitimate traffic to be directed towards
it.  The  connection  would still validate (until the certificate
expires or is revoked) and the attacker could return bad data that
causes honest nodes to misbehave.

   revocation and non-renewal of short-lived cdrtificates.  In this

nit: "certificates"

Section A.6

In my opinion, a lot of this could be split out into a separate draft
(that need not be published as an RFC) and just a couple paragraphs left
here with a pointer to that separate draft.  But this is only a
Comment-level point, and I do not insist on it.

Section A.7

   An ACP domain is the set of all ACP nodes using certificates from the
   same CA using the same domain field.  GRASP inside the ACP is run
   across all transitively connected ACP nodes in a domain.

It's not entirely clear to me that we need to insist on a single shared
CA; given our discussion of potentially joining two distinct ACT domains
into a combined network, it seems that we just need to have all nodes
using the same set of trust anchor(s), which could potentially include
multiple CAs.  (There would of course need to be some out-of-band
mechanism to avoid address-assignment collisions, which could be as
simple as rsub.)

Section A.8

   For example, Intent could indicate the desire to build an ACP across
   all domains that have a common parent domain (without relying on the
   rsub/routing-subdomain solution defined in this document).  For
   example ACP nodes with domain "example.com", "access.example.com",
   "core.example.com" and "city.core.example.com" should all establish
   one single ACP.

It is interesting to see this discussion in the context of the text in
the previous section about """If different ACP domains are to be created
[...] Domains "example.com" and "research.example.com" are separate
domains if both are domain elements in the domain information element of
certificates."""

Section A.8

There still feels like a lot of speculative things in here; I'd suggest
adding a disclaimer/introduction at the top that "Intent is the
architecture component [...].  Its applicability for use is quite
flexible and freeform, with potential applications including:"

Section A.9

   Some solutions may already have an auto-addressing scheme, for
   example derived from existing unique device identifiers (e.g., MAC
   addresses).  In those cases it may not be desirable to assign
   addresses to devices via the ACP address information field in the way
   described in this document.  The certificate may simply serve to
   identify the ACP domain, and the address field could be empty/unused.
   The only fix required in the remaining way the ACP operate is to
   define another element in the domain certificate for the two peers to
   decide who is Alice and who is Bob during secure channel building.

I think we need to mention this requirement for tiebreaking earlier in
the document, when we introduce the possibility of a certificate with
ACP address of '0'.

Section A.10

nit: the section title uses "futures" as a standalone term synonymous
with "future work"; unfortunately, "futures" is already an English word
with a quite distinct meaning.

Section A.10.7

   1.  Consider if LLDP should be a recommended functionality for ANI
       devices to improve diagnostics, and if so, which information
       elements it should signal (insecure).  Includes potentially new
       information elements.

I'd suggest changing the parenthetical to "noting that such information
is conveyed in an insecure manner)".

   3.  The IDevID of BRSKI pledges should be included in the selected
       insecure diagnostics option.

In some environments (not really the current target case of Enterprise
networks) the IDevID would be considered privacy-sensitive, which may be
worth mentioning again here.

Section A.10.8

   Ensuring that manaement sessions using invalidated credentials are

typo: "management"