[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (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-28: 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:
----------------------------------------------------------------------

Hopefully just a couple easy ones...

I made a pass over Ekr's ballot comments (nominally on the -16, though
some of the quoted text doesn't seem to match up with that version).
We're generally in good shape there, but I wanted to check on the point
regarding a "downgrade defense on the meta-negotiation between the
protocols", which in theory would allow an attacker to force the use of
IPsec or DTLS or whatever other protocol has a weakness.  It seems like
there may have been some confusion about DULL vs ACP GRASP in play here,
especially with respect to when there might be the possibility of
multiple secure channels.  My current understanding is that there is not
a major issue here, but let's confirm that: DULL GRASP runs only over a
local link (using link-local addresses), and as currently defined has
the option of flooding advertisements that use either DTLS or IKEv2 to
establish the ACP secure channel.  DULL GRASP has no cryptographic
protections at all, so if there is somehow (e.g., on a multi-access
link) an attacker on the link, they could drop or rewrite some
announcements to force either DTLS or IKEv2 to be used for secure
channel establishment even if the other would normally have been
preferred.  On directly-connected wired links, such tampering may be
unlikely (but not beyond the capabilities of, e.g., a nation-state or
well-funded attacker, especially for, e.g., long fiber runs.)  By
itself, this is not useful, since both DTLS and IKEv2+ESP are believed
to be secure, but if some future vulnerability is discovered the
downgrade might allow for the vulnerability to be exploited in cases it
would not otherwise have been usable.  Countermeasures to allow
detection of this kind of tampering are possible -- include as part of
the DTLS or IKEv2 exchange (or the first operation after it) a
preference-ordered list of supported secure channel mechanisms, and bail
out if the mechanism being used is not the most-preferred shared
mechanism -- but will still fail if the vulnerability in question is
sufficiently severe to allow handshake forgery.
ACP GRASP is different, in that it (1) runs over the ACP, so any on-path
attack to drop/rewrite GRASP would have as a prerequisite an attacker in
the ACP, and (2) unicast GRASP is protected end-to-end by TLS.  However,
it seems like broadcast/flooded ACP GRASP objectives will only have the
hop-by-hop ACP protection and so would in theory also be subject to a
downgrade attack if there was an in-ACP on-path attacker.  It also seems
like there's a general expectation that ACP services will run over TLS,
and the option of "TLS *or* DTLS (or something else)" is not expected to
be common, so the existence of a downgrade to a different protocol is
rare as well.
While I would like to be able to defend against downgrade attacks by an
in-ACP on-path attacker, I recognize that it's a defensible position to
take that we assume all entities in the ACP to remain secure and just
accept the corresponding risks in the case of compromise.  Similarly,
for "big iron" router deployments, physical links are the norm and the
DULL GRASP downgrade attack may not be a practical concern; I would
again like to have the mechanisms in place to be able to detect
downgrade if, for example, deployments broaden to the use of radio
technologies, but the absence of such a mechanism does not seem like a
critical flaw at this time.  So, to be clear, the DISCUSS here is just
to be sure that we're all on the same page as to what point Ekr was
making and the current state of affairs; given my current understanding,
I'm not holding a DISCUSS point for "add the downgrade-detection
mechanism" (though I do encourage it).

It looks like Section 6.1.3 is missing a "rule 6: verify that the
acp-address/prefix in the certificate matches the address being used to
talk to the peer", if I'm reading between the lines properly.  (If not,
and this is just skew introduced by editing, my comments about
references to a non-existent rule 6 apply, see COMMENT.)


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

Thank you for the extensive efforts you put in to respond to the
previous rounds of feedback; I'm happy to say that my discuss points on
the -19 have all been resolved.  I especially appreciate that you were
able to continue discussions with Russ and Barry (and others) even when
I myself was not being particularly responsive due to other pressing
issues.

I'd also like to express appreciation for the care that went into the
various "sweeping changes" (renames/etc.); there was very little fallout
that needed further fixup.

I note that I started off reviewing the diff from -19 to -27 and then
made a follow-up pass looking at the diff from -27 to -28, so there's
some risk I comment on something that I saw in the -27 but is already
fixed.

Section 1

   This document describes a modular design for a self-forming, self-
   managing and self-protecting ACP, which is a virtual out-of-band
   network designed to be as independent as possible of configuration,
   addressing and routing and similar self-dependency problems in
   current IP networks, but which is still operating in-band on the same
   physical network that it is controlling and managing.  The ACP design

nit: the antecedent for "similar self-dependency problems" seems to be
intended to be the issues with in-band OAM/control-plane that were
discussed a couple paragraphs prior, but grammatically we have to look
for a local binding within the same list.  So probably we want something
more like "avoiding the self-dependency problems of current IP
networks".

   In a fully autonomic network node without legacy control or
   management functions/protocols, the Data-Plane would be for example
   just a forwarding plane for "Data" IPv6 packets, aka: packets that
   are not forwarded by the ACP itself such as control or management
   plane packets.  In such networks/nodes, there would be no non-

nit: I suggest rewording to "packets other than the control and
management plane packets that are forwarded by the ACP itself" to avoid
ambiguity about whether the "such as" matches "forwarded by the ACP
itself" or "data packets".

Section 1.1

   The implementation footprint of the ACP consists of Public Key
   Infrastructure (PKI) code for the ACP certificate, the GRASP
   protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and

I agree with Barry that it's best to just say "TLS".  Referencing both
8446 and 5246 is okay, but 8446 needs to be there.

Section 5

   4.  For each entry in the candidate adjacency list, the node
       negotiates a secure tunnel using the candidate channel types.
       See Section 6.5.

Somewhere in this procedure (not necessarily exactly here), we might
want to say something about how failed
authentication/negotiation/authorization/etc. means that the candidate
peer adjacency is not accepted into the ACP, rejected, discarded, or
something of that nature.  Having the main focus be on the success case
rather than the detailed error handling makes sense for an overview, but
if we are listing only "candidate" adjacencies we probably ought to
acknowledge that not all candidates succeed.

Section 6.1.1

   ACP nodes MUST NOT support certificates with RSA public keys of less
   than 2048 bit modulus or curves with group order of less than 256
   bit.  They MUST support certificates with RSA public keys with 2048
   bit modulus and MAY support longer RSA keys.  They MUST support
   certificates with ECC public keys using NIST P-256 curves and SHOULD
   support P-384 and P-521 curves.

We probably can nail this down a bit more, particularly on the ECC side
as being ECDSA signatures (but RSA as well to be signatures vs.
encryption).  Maybe something like:

% ACP nodes MUST NOT support certificates with RSA public keys whose
% modulus is less than 2048 bits, or certificates whose ECC public keys
% are in groups whose order is less than 256 bits.  RSA signing
% certificates with 2048-bit public keys MUST be supported, and such
% certificates with longer public keys MAY be supported.  ECDSA
% certificates using the NIST P-256 curve MUST be supported, and such
% certificates using the P-384 and P-521 curves SHOULD be supported.

Also, 2048-bit RSA is starting to look shaky; note that
draft-cooley-cnsa-dtls-tls-profile insists on 3072-bit or larger at this
point, which would be my own personal recommendation as well.

   ACP nodes MUST support SHA-256 and SHOULD support SHA-384, SHA-512
   signatures for certificates with RSA key and the same RSA signatures
   plus ECDSA signatures for certificates with ECC key.

We should probably reword this to be clearer that we're talking about
the signature on the certificate, not the signatures made by the
certificate.  Perhaps:

% ACP nodes MUST support RSA certificates that are signed by RSA
% signatures over the SHA-256 digest of the contents, and SHOULD
% additionally support SHA-384 and SHA-512 digests in such signatures.
% The same requirements for certificate signatures apply to ECDSA
% certificates, and additionally, ACP nodes MUST support ECDSA
% signatures on ECDSA certificates.

   The ACP certificate SHOULD use an RSA key and an RSA signature when
   the ACP certificate is intended to be used not only for ACP
   authentication but also for other purposes.  The ACP certificate MAY
   use an ECC key and an ECDSA signature if the ACP certificate is only
   used for ACP and ANI authentication and authorization.

There may be a mismatch in the normative guidance here: we have MUST
baseline guidance earlier for 2048-bit RSA and P-256, but SHOULD
(stronger than MAY) for P-384/P-521 and only MAY for >2048-bit-RSA.  But
here, it's SHOULD use RSA and only MAY ECC, which is reversed.  I know
that the flexibility-of-strength question is not exactly the same as
what-to-use-externally, so maybe it's fine, but I wanted to check.

   Any secure channel protocols used for the ACP as specified in this
   document or extensions of this document MUST therefore support
   authentication (e.g.:signing) starting with these type of
   certificates.  See [RFC4492] for more information.

Do they all have to support both RSA and ECDSA certs, or is it okay to
only support one?

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

I suggest s/the required authorization condition/a required
authorization condition/, since even if there is more fine-grained
authorization needed, you still need an ACP certificate to prove you're
part of the domain.

   In support of ECDH key establishment, ACP certificates with ECC keys
   MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if
   X.509 v3 keyUsage and extendedKeyUsage are included in the
   certificate.

nit: "if X.509 v3 keyUsage and extendedKeyUsage are included" sounds
like both need to be present, but I don't think that's really what's
needed.  AFAICT only the non-extended keyUsage is relevant, so we would
just say "if the X.509v3 keyUsage extension is present, the keyAgreement
bit MUST be set".

   Any other field of the ACP domain certificate is to be populated as
   required by [RFC5280] or desired by the operator of the ACP domain
   ACP registrars/CA and required by other purposes that the ACP domain
   certificate is intended to be used for.

This sentence is a bit hard to parse; it has three clauses and it's not
entirely clear how they're intended to relate to each other ("populated
as required by RFC5280", "desired by the operator of the ACP domain",
"required by other purposes that the ACP domain certificate is intended
to be used for").

   certificate information can be retrieved bei neighboring nodes

s/bei/by/

   For diagnostic and other operational purposes, it is beneficial to
   copy the device identifying fields of the node's IDevID certificate
   into the ACP domain certificate, such as the "serialNumber" (see
   [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1).  This can be

I suggest noting that this "serialNumber" is the X520SerialNumber name
attribute, not the CertificateSerialNumber (IIUC this is the first usage
of "serialNumber" in this document).  IMO the quotes, while helpful to
set it apart, are not enough to indicate that this is not the normal
certificate serial number (of "issuer and serial number" that is
supposed to uniquely identify a certificate).

   Note that there is no intention to constrain authorization within the
   ACP or autonomic networks using the ACP to just the ACP domain
   membership check as defined in this document.  It can be extended or
   modified with future requirements.  Such future authorizations can
   use and require additional elements in certificates or policies or
   even additional certificates.  For an example, see Appendix A.10.5.

It might be worth noting that we already have the id-kp-cmcRA check for
EST servers, in addition to the "domain membership" check.

Section 6.1.2

     HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
             ; DIGIT as of RFC5234 section B.1

Note that (if I remember my ABNF right), this is not restricted to just
"lower case" hex digits, since matching is case-insensitive.  (Of
course, "LC" could stand for something else...)  In order to get the
case sensitivity, the %s"a" construction from RFC 7405 (or bare %x61)
would be needed.

     extension = ; future standard definition.
                 ; Must fit RFC5322 simple dot-atom format.

I think there's a different convention than "empty definition" for
extensibility points and am hoping that my colleagues will chime in
about it.

     acp-node-name      = fd89b714F3db00000200000064000000
                          [e-mail]

[has upper-case hex digit, if that ends up mattering]

   Nodes complying with this specification MUST also be able to
   authenticate nodes as ACP domain members or ACP secure channel peers
   when they have a 0-value acp-address field and as ACP domain members
   (but not as ACP secure channel peers) when they have an empty acp-
   address field.  See Section 6.1.3.

An "empty acp-address field" would seem to mean "", the empty string,
which is not allowed by the ABNF.  It is, however, allowed to omit the
acp-address, so I think that it's better to talk about the acp-address
field being "absent" rather than "empty" (and there are many subsequent
mentions of an "empty acp-address" in the document; I tried to point out
most of them as they occur.

   To keep the encoding simple, there is no consideration for
   internationalized acp-domain-names.  The acp-node-name is not
   intended for end user consumption, and there is no protection against
   someone not owning a domain name to simpy choose it.  Instead, it

We should presumably say somewhere (not necessarily here) that if
someone does maliciously try to choose a domain name they don't own as
the acp-domain-name, they won't be able to pass a domain-membership test
unless it's signed by the real domain's CA, and the CA should know
enough to not issue such certs to unauthorized entities.
In other words, the combination of acp-domain-name and root CA identify
the domain, so collisions of acp-domain-name are not fatal (which is
good, since they're trivial to produce).

       1.2  If "acp-address" is empty, and "rsub" is empty too, the
            "local-part" will have the format ":++extension(s)".  The
            two plus characters are necessary so the node can

nit: there's no ":" in the ABNF.

       2.4  Addresses of the form <local><@domain> have become the

nit(?): is the '@' intended to be outside the angle brackets?

       3.1  It should be possible to use the ACP certificate as an
            LDevID certificate on the system for 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.  The
            subjectName is for example often used as an entity
            identifier in non-ACP uses of a the ACP certificate.

There's not a "subjectName" field in a PKIX certificate, and I'm not
sure if this is intended to refer to subjectAltName (so as to say that
the ACP name can be used for non-ACP uses) or to some other field
(commonName?) (so as to say that we are leaving that field unoccupied
for other uses).  In light of the surrounding context, I'd guess the
former, but please clarify.

Section 6.1.3

   3:   If the node certificate indicates a Certificate Revocation List
      (CRL) Distribution Point (CRLDP) ([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 mechanisms when they are available: 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 CRLDP.  These mechanisms are not available when the node has

IIUC, the "node certificate" in the first line is the same as the
"peer's certificate" thereafter; we should probably use "peer node's
certificate" the first time as well, for consistency.

      peer if there are multiple.  The ACP secure channel connection
      MUST be retried periodically to support the case that the neighbor
      acquires a new, valid certificate.

(I forget if we already give guidance somewhere about the order of
magnitude for "periodically"; if not, we might want some here.)

   5:   The candidate peer certificate's acp-node-name has a non-empty
      acp-address field (either 32HEXLC or 0, according to Figure 2).

nit: per the ABNF, we should probably refer to the acp-address field
being absent rather than being empty.

      Steps 1...4 do not include verification of any pre-existing form
      of non-public-key-only based identity elements of a certificate
      such as a web servers domain name prefix often encoded in
      certificate common name.  Steps 5 and 6 are the equivalent steps.

I think we only have a step 5 (no 6) now?

      Steps 1...5 authorize to build any secure connection between
      members of the same ACP domain except for ACP secure channels.

      Step 6 is the additional verification of the presence of an ACP
      address.

      Steps 1...6 authorize to build an ACP secure channel.

(ditto)

Section 6.1.3.1

   node SHOULD obtain the current time in a secured fashion

I note with excitement that draft-ietf-ntp-using-nts-for-ntp is in the
RFC Editor's queue!

Section 6.1.5.3

   A CRLDP can be reachable across the ACP either by running it on a
   node with ACP or by connecting its node via an ACP connect interface
   (see Section 8.1).  The CRLDP SHOULD use an ACP certificate for its
   HTTPs connections.  The connecting ACP node SHOULD verify that the
   CRLDP certificate used during the HTTPs connection has the same ACP
   address as indicated in the CRLDP URL of the node's ACP certificate
   if the CRLDP URL uses an IPv6 address.

CRLDPs typically run over HTTP, not HTTPS, so this SHOULD is surprising.
That said, if there is to be a certificate check, why SHOULD vs MUST
verify that the IPv6 address matches?

Section 6.1.5.5

   Maintaining existing TA information is especially important when
   enrollment mechanisms are used that unlike BRSKI do not leverage a
   voucher mechanism to authenticate the ACP registrar and where
   therefore the injection of certificate failures could otherwise make
   the ACP node easily attackable remotely.

We should probably not say that you SHOULD immediatelly fall back to
forgetting the remembered TAs on the first TLS failure.  Some kind of
retry mechanism would give a bit more resilience against this attack.

Section 6.3

   Note that the use of the IPv6 link-local multicast address
   (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener
   Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to
   receive packets for that address.  Otherwise DULL GRASP could fail to
   operate correctly in the presence of MLD snooping, non-ACP enabled L2
   switches ([RFC4541]) - because those would stop forwarding DULL GRASP
   packets.  Switches not supporting MLD snooping simply need to operate

nit: I suggest putting the 4541 reference right after "MLD snooping"
(i.e., before "non-ACP-enabled L2 switches").

Section 6.7.3.1.1

It's a bit surprising to see ENCR_AES_CCM_8 as a "MAY", since the 8-byte
authentication tag may be significantly weaker than the strength of the
other primitives being used for ACP secure channels.

If ENCR_AES_CBC is listed, we probably want to say something about the
ESP Authentication Algorithm used with it (the AUTH_HMAC_SHA2_256_128
that's a MUST in 8221 would be fine).

   o  There is no MTI requirement against support of ENCR_AES_CBC
      because ENCR_AES_GCM_16 is assumed to be feasible with less cost/
      higher performance in modern devices hardware accelerated
      implementations compared to ENCR-AES_CBC.

I'm not sure what "against support of ENCR_AES_CBC" is intended to mean.
It sounds like it's saying "we don't forbid AES-CBC" but the rest of the
sentence doesn't really support that.

Section 6.7.3.1.2

   ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA
   when acting as an IKEv2 responder on the IPv6 link local address and
   port number indicated in the AN_ACP DULL GRASP announcements (see
   Section 6.3).

There's a subtlety of English here -- "to only use <X> when <Y>" means
that the only time X is used is when Y, whereas "to use only <X> when
<Y>" means that X is the only thing that is used when Y, which I think
is the intent of this statement.  (But I could be wrong!)

   In IKEv2, ACP nodes are identified by their ACP address.  The
   ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST
   convey the ACP address.  If the peer's ACP certificate includes a
   32HEXLC ACP address in the acp-node-name (not "0" or empty), the

[another case of "empty" vs "absent" for acp-address]

Section 6.7.4

nit: s/negoting/negotiating/

   An ACP node announces its ability to support DTLS v1.2 compliant with
   the requirements defined in this document as an ACP secure channel
   protocol in GRASP through the "DTLS" objective-value in the "AN_ACP"
   objective.

   To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP
   [...]

As previously, we probably want the "DTLS" objective value to be
version-agnostic; the 1.2 minimum/MTI can be specified in the following
paragraphs.

   Unlike for IPsec, no attempts are made to simplify the requirements
   of the BCP 195 recommendations because the expectation is that DTLS
   would be using software-only implementations where the ability to
   reuse of widely adopted implementations is more important than
   minizing the complexity of a hardware accelerated implementation
   which is known to be important for IPsec.

(side note: hardware TLS support is becoming more common these days,
though only for the record encryption and not the handshake protocol, as
I understand it.  Analogous to supporting ESP but not IKEv2 in hardware,
basically.)

Section 6.8.2

   TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
   with less than 256 bit symmetric key strength or hash strength of
   less han SHA384.  [...]

Those are TLS 1.2 ciphers; do you want to also say "when TLS 1.3 is
supported, TLS_AES_256_GCM_SHA384 MUST be offered and
TLS_CHACHA20_POLY1305_SHA256 MAY be offered"?

   less han SHA384.  TLS for GRASP MUST also include the "Supported
   Elliptic Curves" extension, it MUST support support the NIST P-256
   (secp256r1) and P-384 (secp384r1(24)) curves [RFC4492].  In addition,
   GRASP TLS clients SHOULD send an ec_point_formats extension with a
   single element, "uncompressed".  For further interoperability
   recommendations, GRASP TLS implementations SHOULD follow [RFC7525].

Note that RFC 8446 retconned "Supported Elliptic Curves" to being
"Supported Groups".  (It also obviated the need for "ec_point_formats",
but since ACP mandates ability to use TLS 1.2, you still have to send
that one.)

Section 6.10.2

   o  When creating a new routing-subdomain for an existing autonomic
      network, it MUST be ensured, that rsub is selected so the
      resulting hash of the routing-subdomain does not collide with the
      hash of any pre-existing routing-subdomains of the autonomic
      network.  This ensures that ACP addresses created by registrars
      for different routing subdomains do not collide with each others.

Ensured by whom?  What if the domain uses a "public CA" as a trust
anchor that might also be used by some other autonomic domain -- does
the CA also need to be checking?

Section 6.10.3

   o  Node-Number: Number to make the Node-ID unique.  This can be
      sequentially assigned by the ACP Registrar owning the Registrar-
      ID.

I see "can be sequentially assigned" and immediately think of
draft-gont-numeric-identifiers-sec-considerations, which I'm
AD-sponsoring for publication.  I don't have an obvious attack handy
against sequential assignment, but it may be worth a closer look.

Section 6.10.7.1

   Any protocols or mechanisms may be used as ACP registrars, as long as
   the resulting ACP certificate and TA certificate(s) allow to perform

nit(?): the ACP registrar is a PKI registration authority, i.e., a
specific entity that plays a role in certificate issuance.  I don't see
how a "protocol or mechanism" can fulfil that role.  Is s/as/by/ (or
similar) intended?

Section 6.10.7.3

   The choice of addressing sub-scheme and prefix-length in the Vlong
   address sub-scheme is subject to ACP registrar policy.  It could be
   an ACP domain wide policy, or a per ACP node or per ACP node type
   policy.  For example, in BRSKI, the ACP registrar is aware of the
   IDevID certificate of the candidate ACP node, which contains a
   "serialNnumber" that is typically indicating the node's vendor and
   [...]
   address scheme for ACP nodes based on the "serialNumber" of the
   IDevID certificate, for example by the PID (Product Identifier) part
   which identifies the product type, or the complete "serialNumber".
   The PID for example could identify nodes that allow for specialized
   ASA requiring multiple addresses or non-autonomic VMs for services
   and those nodes could receive Vlong sub-address scheme ACP addresses.

[same "serialNumber" comment as in Section 6.1.1, also s/Nn/N/]

Section 6.11.1.7

   When using ACP multi-access virtual interfaces, local repair can be
   directly by peer breakage, see Section 6.12.5.2.2.

nit: is there a missing word like "triggered" in here (e.g., "can be
triggered directly by peer breakage")?

Section 6.11.1.14

   As this requirement raises additional Data-Plane, it does not apply
   to nodes where the administrative parameter to become root
   (Section 6.11.1.12) can always only be 0b001, e.g.: the node does not
   support explicit configuration to be root, or to be ACP registrar or
   to have ACP-connect functionality.  If an ACP network is degraded to
   the point where there are no nodes that could be configured roots,
   ACP registrars or ACP-connect nodes, traffic to unknown destinations
   could not be diagnosed, but in the absence of any intelligent nodes
   supporting other than 0b001 administrative preference, there is
   likely also no diagnostic function possible.

Some nits here.  Maybe:

% As this requirement places additional constraints on the Data-Plane
% functionality of the RPL root, it does not apply to "normal" nodes
% that are not configured to have special functionality (i.e., the
% adminstrative parameter from Section 6.11.1.12 has value 0b001).  If
% the ACP network is degraded to the point where there are no nodes that
% could be configured as root, registrar, or ACP-connect nodes, it is
% possible that the RPL root ( and thus the ACP as a whole) would be
% unable to detect traffic to unknown destinations.  However, in the
% absence of nodes with administrative preference other than 0b001,
% there is also unlikely to be a way to get diagnostic information out
% of the ACP, so detection of traffic to unknown destinations would not
% be actionable anyway.

Section 6.12.5.1

   8.  Using global scope addresses for subnets between nodes is
       unnecessary if those subnets only connect routers, such as ACP
       secure channels because they can communicate to remote nodes via

nit: comma after "such as ACP secure channels".

Section 6.12.5.2

   Note that all the considerations described here are assuming point-
   to-point secure channel associations.  Mapping multi-party secure
   channel associations such as [RFC6407] is out of scope (but would be
   easy to add).

Let's drop the "but would be easy to add" parenthetical, please.

Section 7.2

   This is sufficient when p2p ACP virtual interfaces are established to
   every ACP peer.  When it is desired to create multi-access ACP
   virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to
   coalesce all the ACP secure channels on the same L3 VLAN interface,
   but only all those on the same L2 port.

This requirement that ACP devices know whether multi-access virtual
interfaces are expected or not is a bit hidden here, and might benefit
from being more prominent in an overall requirements list.

Section 8.1.1

   "ACP connect" is an interface level configured workaround for
   connection of trusted non-ACP nodes to the ACP.  The ACP node on
   which ACP connect is configured is called an "ACP edge node".  With
   ACP connect, the ACP is accessible from those non-ACP nodes (such as
   NOC systems) on such an interface without those non-ACP nodes having
   to support any ACP discovery or ACP channel setup.  This is also
   called "native" access to the ACP because to those NOC systems the
   interface looks like a normal network interface (without any
   encryption/novel-signaling).

It's "native access" (and I see later that there's discussion of how the
NMS routes into the ACP and of RPF filtering, and much later about the
ability of ACP connect channels to participate in ACP GRASP), but what
kind of services are accessible and how?  Do we need to make TLS
connections to ACP addresses, or is it at some other layer?  (If TLS,
are those services going to let us do anything with no client
authentication?)

   ACP Edge nodes SHOULD have a configurable option to filter packets
   with RPI headers (xsee Section 6.11.1.13 across an ACP connect
   interface.  These headers are outside the scope of the RPL profile in
   this specification but may be used in future extensions of this
   specification.

Does "filter" just mean "drop anything with an RPI" or something more
fine-grained?  (Also, s/xsee/see/.)

Section 8.2.2

I think we want to require (or at least strongly suggest) that the
tunnel used to produce a "L2 adjacent" interface provide some sort of
cryptographic protection, as otherwise the security properties that we
expect from the L2-adjacent nature can be violated by an attacker on the
path of the tunnel.

Section 9.1.1

   Another example case is the intended or accidental re-activation of
   equipment whose TA certificate has long expired, such as redundant
   gear taken from storage after years.  Potentially without following
   the correct process set up for such cases.

nit: sentence fragment.

Section 9.2.2

      Policies if candidate ACP nodes should receive a domain
      certificate or not, for example based on the devices IDevID
      certificate as in BRSKI.  The ACP registrar may have a whitelist
      or blacklist of devices "serialNumbers" from their IDevID
      certificate.

[Same comment about serialNumber as Section 6.1.1]

Section 9.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 every ACP registrar.
      Instead, it may better be decided in real-time including
      potentially a human decision in a NOC.

(ditto)

Section 9.3.5.1

   Automatically setting "ANI enable" on brownfield nodes where the
   operator is unaware of BRSKI and MASA operations could also be an
   unlikely but then critical security issue.  If an attacker could
   impersonate the operator and register as the operator at the MASA or
   otherwise get hold of vouchers and can get enough physical access to
   the network so pledges would register to an attacking registrar, then
   the attacker could gain access to the network through the ACP that
   the attacker then has access to.

nit(?): this last bit ("gain access ... then has access to") is easy to
read as being a tautology.  Maybe "attacker could gain access to the
ACP, and through the ACP gain access to the data plane"?

Section 9.3.5.2

   Attempts for BRSKI pledge operations in greenfield state should
   terminate automatically when another method of configuring the node
   is used.  Methods that indicate some form of physical possession of
   the device such as configuration via the serial console port could
   lead to immediate termination of BRSKI, while other parallel auto
   configuration methods subject to remote attacks might lead to BRSKI
   termination only after they were successful.  Details of this may
   vary widely over different type of nodes.  [...]

Most of this seems appropriate for, and (IIRC) already in, BRSKI itself
and may not need repetition here.

Section 9.4

   Note that the non-autonomous ACP-Core VPN would require additional
   extensions to propagate GRASP messages when GRASP discovery is
   desired across the zones.  For example, one could set up on each Zone
   edge router remote ACP tunnel to an appplication level implemented
   GRASP hub running in the networks NOC that is generating GRASP
   announcements for NOC services into the ACP Zones or propagating them
   between ACP Zones.

There's enough nits here that I've lost the intended meaning.  Is it:

% For example, one could set up on each Zone edge router a remote ACP
% tunnel to a GRASP hub, implemented at the application level, that runs
% in the NOC for the network and serves to propagage GRASP announcements
% between ACP Zones and/or generate GRASP announcements for NOC services

Section 10.1

   Merging two networks with different TA requires the ACP nodes to
   trust the union of TA.  As long as the routing-subdomain hashes are
   different, the addressing will not overlap, which only happens in the
   unlikely event of a 40-bit hash collision in SHA256 (see
   Section 6.10).  Note that the complete mechanisms to merge networks
   is out of scope of this specification.

Maybe "only happens accidentally"?  40 bits of work is not terribly hard
if you're trying to make a collision...

Section 10.2.1

nit: s/ectracting/extracting/

Using RFC 3596 ("DNS Extensions to Support IP Version 6") as the sole
reference for "DNS" seems surprising.

Section 15.2

Usually we put RFC 2119 as normative as well as 8174; the two together
comprise BCP 14, after all.

We seem to say that you MUST offer the TLS elliptic curve ciphers from
RFC 4492, which would make it a normative reference.  (It's also been
obsoleted by RFC 8422 at this point...)

Appendix A.7

   Note that RPL scales very well.  It is not necessary to use multiple
   routing subdomains to scale ACP domains in a way it would be possible
   if other routing protocols where used.  They exist only as options
   for the above mentioned reasons.

nit(?) s/it would be possible/that would be required/?