An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-20

Ballot deferred by Alissa Cooper on 2018-05-22.

Summary: Needs a YES. Has a DISCUSS. Needs 3 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2019-07-16 for -19)
[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 (2019-07-16 for -19)
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 rfcSELF@acp.example.com 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"

(Eric Rescorla) Discuss

Discuss (2018-08-01 for -16)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D9959


I found this document extremely hard to follow due to a large number
of grammar errors. It really needs a very thorough copy-edit pass,
which I believe is beyond the RFC-editor's usual process. Ideally, the
WG would do this.


DETAIL
S 6.1.1.
>      each other.  See Section 6.1.2.  Acp-domain-name SHOULD be the FQDN
>      of a DNS domain owned by the operator assigning the certificate.
>      This is a simple method to ensure that the domain is globally unique
>      and collision of ACP addresses would therefore only happen due to ULA
>      hash collisions.  If the operator does not own any FQDN, it should
>      choose a string (in FQDN format) that intends to be equally unique.

These rules do not seem to be strong enough. Unless you have disjoint
trust anchors, there is a potential for cross-domain attac.


S 6.1.2.
>      See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
>      field.
>   
>   6.1.2.  ACP domain membership check
>   
>      The following points constitute the ACP domain membership check of a

What is the relationship of these rules to the existing 5280 rules?


S 6.1.2.
>   
>      o  The peer has proved ownership of the private key associated with
>         the certifictes public key.
>   
>      o  The peer's certificate is signed by one of the trust anchors
>         associated with the ACP domain certificate.

So you don't allow chaining? It seems later that you say you do, but
this language prohibits it.


S 6.1.3.1.
>      The objective value "SRV.est" indicates that the objective is an
>      [RFC7030] compliant EST server because "est" is an [RFC6335]
>      registered service name for [RFC7030].  Future backward compatible
>      extensions/alternatives to [RFC7030] may be indicated through
>      objective-value.  Future non-backward compatible certificate renewal
>      options must use a different objective-name.

EST runs over HTTPS. What is the certificate that the server presents?


S 6.4.
>      information in the ACP Adjacency table.
>   
>      The ACP is by default established exclusively between nodes in the
>      same domain.  This includes all routing subdomains.  Appendix A.7
>      explains how ACP connections across multiple routing subdomains are
>      special.

I must be missing something, but how do you know what the routing
domain is of an ACP node? I don't see it in the message above. Is it
in some common header?


S 6.5.
>   
>      o  Once the first secure channel protocol succeeds, the two peers
>         know each other's certificates because they must be used by all
>         secure channel protocols for mutual authentication.  The node with
>         the lower Node-ID in the ACP address becomes Bob, the one with the
>         higher Node-ID in the certificate Alice.

A ladder diagram would really help me here, because I'm confused about
the order of events.

As I understand it, Alice and Bob are both flooding their AN_ACP
objectives. So, Alice sees Bob's and starts trying to connect to Bob.
But Bob may not have Alice's objective, right? So, in the case you
describe below, she just has to wait for it before she can try the
remaining security protocols?

I note that you have no downgrade defense on the meta-negotiation
between the protocols, so an attacker could potentially force you down
to the weakest joint protocol. Why did you not provide a defense here?


S 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 AES256 for encryption and SHA256 hash and MUST NOT
>      permit weaker crypto options.

This is not sufficient to guarantee interop. Also, this is an odd
cipher suite chioice.

    Why are you requiring AES-256 rather than AES-128?
    Why aren't you requiring AES-GCM?
    Why aren't you requiring specific key establishment methods (e.g.,
ECDHE with P-256...)



S 6.7.2.
>   
>      To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP
>      port is used that is announced as a parameter in the GRASP AN_ACP
>      objective to candidate neighbors.  All ACP nodes supporting DTLS as a
>      secure channel protocol MUST support AES256 encryption and MUST NOT
>      permit weaker crypto options.

This is not sufficiently specific to guarantee interoperability. Which
cipher suites? Also, why are you requiring AES-256 and not AES-128?


S 6.7.3.
>   
>      A baseline ACP node MUST support IPsec natively and MAY support IPsec
>      via GRE.  A constrained ACP node that can not support IPsec MUST
>      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 threefore the baseline and constrained profile.

These MTIs do not provide interop between constrained and baseline
nodes, because a baseline node might do IPsec and the constrained node
DTLS.


S 6.10.2.
>         hash of the routing subdomain SHOULD NOT be assumed by any ACP
>         node during normal operations.  The hash function is only executed
>         during the creation of the certificate.  If BRSKI is used then the
>         BRSKI registrar will create the domain information field in
>         response to the EST Certificate Signing Request (CSR) Attribute
>         Request message by the pledge.

you need to lay out the security assumptions here. It's not difficult
to create a new domain with the same 40bit hash. If you have a private
CA, this probably isn't an issue, but if you are sharing a public CA,
it would allow me to produce a domain with other people's addresses.


S 8.1.1.
>      configured to be put into the ACP VRF.  The ACP is then accessible to
>      other (NOC) systems on such an interface without those systems 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).

This seems pretty unclear. Is the idea that you connect natively to
the ACP Connect node and then it forwards your packets over the ACP?
Does that mean they need to be GRASP or whatever? I think that's what
you are saying below.


S 8.1.5.
>      interface is physically protected from attacks and that the connected
>      Software or NMS Hosts are equally trusted as that on other ACP nodes.
>      ACP edge nodes SHOULD have options to filter GRASP messages in and
>      out of ACP connect interfaces (permit/deny) and MAY have more fine-
>      grained filtering (e.g., based on IPv6 address of originator or
>      objective).

Given that this is an important security requirement, it seems like it
should be a normative requirement that it be filtered.


S 9.1.
>      same trust anchor, a re-merge will be smooth.
>   
>      Merging two networks with different trust anchors requires the trust
>      anchors to mutually trust each other (for example, by cross-signing).
>      As long as the domain names are different, the addressing will not
>      overlap (see Section 6.10).

Why does it require the *trust anchors* to trust each other? Can't the
endpoints just have the union of the trust anchors.

This is way underspecified for actual implementation.


S 10.2.1.
>      registrar can rely on the ACP and use Proxies to reach the candidate
>      ACP node, therefore allowing minimum pre-existing (auto-)configured
>      network services on the candidate ACP node.  BRSKI defines the BRSKI
>      proxy, a design that can be adopted for various protocols that
>      Pledges/candidate ACP nodes could want to use, for example BRSKI over
>      CoAP (Constrained Application Protocol), or proxying of Netconf.

I am finding it very difficult to work out the security properties of
this mechanism and the security considerations do not help. What can a
malicious registrar do? For that matter, you say "uncoordinated", so
does that mean anyone in the ACP can just decide to be a registrar?


S 11.
>   
>   11.  Security Considerations
>   
>      An ACP is self-protecting and there is no need to apply configuration
>      to make it secure.  Its security therefore does not depend on
>      configuration.

This is not true. You need to configure the trust anchor and the
domain name.


S 11.
>         all products.
>   
>      There is no prevention of source-address spoofing inside the ACP.
>      This implies that if an attacker gains access to the ACP, it can
>      spoof all addresses inside the ACP and fake messages from any other
>      node.

You need to be clear that the security is just group security and that
any compromised ACP node compromises the entire system.
Comment (2018-08-01 for -16)
No email
send info
S 1.
>      possibilities that where considered not to be appropriate for
>      standardization in this document but were considered important to
>      document.
>   
>      The ACP provides secure IPv6 connectivity, therefore it can not only
>      be used as the secure connectivity for self-management as required

Nit: this would be clearer as "can be used not only"


S 2.
>         equally be used in simple ANI networks (with no other Autonomic
>         Functions) or completely by itself.
>   
>      ACP address:  An IPv6 address assigned to the ACP node.  It is stored
>         in the domain information field of the ->"ACP domain certificate"
>         ().

Something wrong here.


S 2.
>   
>      domain information (field):  An rfc822Name information element (e.g.,
>         field) in the domain certificate in which the ACP relevant
>         information is encoded: the domain name and the ACP address.
>   
>      ACP Loopback interface:  The Loopback interface in the ACP VRF that

Please expand VRF on first use.


S 2.
>         routing and forwarding in the node other than the ACP VRF.  In a
>         simple ACP or ANI node, the Data-Plane is typically provisioned
>         non-autonomic, for example manually (including across the ACP) or
>         via SDN controllers.  In a fully Autonomic Network node, the Data-
>         Plane is managed autonomically via Autonomic Functions and Intent.
>         Note that other (non-ANIMA) RFC use the Data-Plane to refer to

Nit: RFCs


S 4.
>             protocols of the ANI.  Clients of the ACP MUST NOT be tied to
>             a particular application or transport protocol.
>   
>      ACP5:  The ACP MUST provide security: Messages coming through the ACP
>             MUST be authenticated to be from a trusted node, and SHOULD
>             (very strong SHOULD) be encrypted.

Why isn't this a MUST? Once you have done the key setup, the
encryption is very cheap.



S 4.
>      between nodes, but only GRASP connectivity.  Nevertheless, because
>      ACP also intends to support non-AN networks, it it is crucial to
>      support IPv6 layer connectivity across the ACP to support any
>      transport and application layer protocols.
>   
>      Th eACP operates hop-by-hop, because this interaction can be built on

Nit: The ACP


S 6.1.1.
>      hash collisions.  If the operator does not own any FQDN, it should
>      choose a string (in FQDN format) that intends to be equally unique.
>   
>      "routing-subdomain" is the autonomic subdomain that is used to
>      calculate the hash for the ULA Global ID of the ACP address of the
>      node.  "rsub" is optional; its syntax is defined in this document,

This section about the hash isn't clear without referencing some
future section.


S 6.1.1.
>      In this specification, the "acp-address" field is REQUIRED, but
>      future variations (see Appendix A.8) may use local information to
>      derive the ACP address.  In this case, "acp-address" could be empty.
>      Such a variation would be indicated by an appropriate "extension".
>      If "acp-address" is empty, and "rsub" is empty too, the "local-part"
>      will have the format "rfcSELF + + extension(s)".  The two plus

Are these spaces part of local-part? They appear to be forbidden by
the ABNF


S 6.1.1.
>      The subjectAltName / rfc822Name encoding of the ACP domain name and
>      ACP address is used for the following reasons:
>   
>      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

Is this really not normative?


S 6.1.3.5.
>      protocols used by the ACP registrars.
>   
>      Please refer to Section 6.10.7 for explanations about ACP registrars
>      and vouchers as used in the following text.
>   
>      When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re-

I think you mean "i.e.", not "aka".


S 6.1.3.5.
>      certificate or the IDevID, the re-enrolling candidate ACP node SHOULD
>      authenticate the BRSKI registrar during TLS connection setup based on
>      its existing trust anchor/certificate chain information associated
>      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.

This is all pretty hard to understand without having read BRSKI


S 6.1.3.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

I don't understand the thing on the other side of this "or". I'm
supposed to conclude based on some remote diagnostic that my cert is
bad>


S 6.1.3.6.
>      or any of its signing certificates could have been revoked or may
>      have expired, but the ACP node can not self-diagnose this condition
>      directly.  Revocation information or clock synchronization may only
>      be available across the ACP, but the ACP node can not build ACP
>      secure channels because ACP peers reject the ACP node's domain
>      certificate.

Is the idea here that I'm supposed to inspect the TLS alerts?


S 6.3.
>      dependencies, including ACP.  Please ensure that references to I-
>      D.ietf-anima-grasp that include section number references (throughout
>      this document) will be updated in case any last-minute changes in
>      GRASP would make those section references change.
>   
>      DULL GRASP is a limited subset of GRASP intended to operate across an

Please expand DULL


S 6.4.
>   
>      o  ACP connections across domains with different Certificate
>         Authorities (CA) could establish a common ACP by installing the
>         alternate domains' CA into the trusted anchor store.  This is an
>         executive management action that could easily be accomplished
>         through the control channel created by the ACP.

How would you know if other domains had a given CA?


S 6.5.
>      version 1.2", see [RFC6347]) because that code exists already on them
>      for end-to-end security, but low-end in-ceiling L2 switches may only
>      want to support Media Access Control Security (MacSec, see 802.1AE
>      ([MACSEC]) because that is also supported in their chips.  Only a
>      flexible gateway device may need to support both of these mechanisms
>      and potentially more.

Why are you mentioning MACSEC? Your negotiation syntax doesn't support
it.


S 6.5.
>      version 2", see [RFC7296].  It is now up to Alice to decide how to
>      proceed.  Even if the IPsec connection from Bob succeeded, Alice
>      might prefer another secure protocol over IPsec (e.g., FOOBAR), and
>      try to set that up with Bob.  If that preference of Alice succeeds,
>      she would close the IPsec connection.  If no better protocol attempt
>      succeeds, she would keep the IPsec connection.

When would you get partial failrues?


S 6.7.1.2.
>      support IPsec transport mode with next protocol equal to GRE (47)
>      followed by the offer for native IPsec as described above (because
>      that option is mandatory to support).
>   
>      If IKEv2 initiator and responder support GRE, it will be selected.
>      The version of GRE to be used must the according to [RFC7676].

See above interop comments.


S 6.7.3.
>      An ACP secure channel MUST immediately be terminated when the
>      lifetime of any certificate in the chain used to authenticate the
>      neighbor expires or becomes revoked.  Note that this 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.

How does this interact with reissue? I am supposed to reconnect?


S 6.8.2.
>           Figure 7: ACP as security and transport substrate for GRASP
>   
>      GRASP unicast messages inside the ACP always use the ACP address.
>      Link-local ACP addresses 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

Again, why AES256/SHA256?



S 6.8.2.1.
>      original objective in GRASP when it is a MITM and act as an
>      application level proxy.  This of course requires that the
>      compromised ACP node understand the semantics of the GRASP
>      negotiation to an extent that allows it to proxy it without being
>      detected, but in an ACP environment this is quite likely public
>      knowledge or even standardized.

Just to make sure I'm clear: you would know you were talking to A and
not B (because the certificate) so that would be of some use, right?


S 6.8.2.1.
>      encryption.  Future work optimizations could avoid this but it is
>      unclear how beneficial/feasible this is:
>   
>      o  The security considerations for GRASP change against attacks from
>         non-ACP (e.g., "outside") nodes: TLS is subject to reset attacks
>         while secure channel protocols may be not (e.g., IPsec is not).

I don't think the distinction here is between "secure channel" and
"TLS"; usually I would call TLS a secure channel protocol. Maybe
"secure transport" or "L3"?

Note that QUIC would not have this problem.


S 6.12.5.
>      the same.  The difference happens when Bob and Carol receive their
>      packet.  If they use ACP point-to-point virtual interfaces, their
>      GRASP instance would forward the packet from Alice to each other as
>      part of the GRASP flooding procedure.  These packets are unnecessary
>      and would be discarded by GRASP on receipt as duplicates (by use of
>      the GRASP Session ID).  If Bob and Charly's ACP would emulate a

Charly? Do you mean Carol?


S 7.1.
>      create ACP point-to-point virtual interfaces for these secure
>      channels.
>   
>   7.  ACP support on L2 switches/ports (Normative)
>   
>   7.1.  Why

This hed could be better.


S 8.1.1.
>      explicit configuration.  To support connections to adjacent non-ACP
>      nodes, an ACP node must support "ACP connect" (sometimes also called
>      "autonomic connect"):
>   
>      "ACP connect" is a function on an autonomic node that is called an
>      "ACP edge node".  With "ACP connect", interfaces on the node can be

This sentence is confusing.  Perhaps first explain what an edge node
is and then say ACP connect is a function of it.


S 8.1.2.
>      only even more trusted software components will get access to both
>      the ACP virtual subnet and the Data-Plane (because those ACP users
>      could leak traffic between ACP and Data-Plane).  This trust could be
>      established for example through cryptographic means such signed
>      software packages.  The specification of these mechanisms is subject
>      to future work.

This all seems pretty handwavingly speculative. I would remove it


S 8.1.4.
>      legacy NMS Hosts that support only one IP interface.
>   
>      To provide a single subnet into both ACP and Data-Plane, the ACP Edge
>      node needs to de-multiplex packets from NMS hosts into ACP VRF and
>      Data-Plane.  This is sometimes called "VRF select".  If the ACP VRF
>      has no overlapping IPv6 addresses with the Data-Plane (as it should),

Does this mean it should have no overlapping addresses or it should
have overlapping addresses? The text here is kind of unclear though I
believe from context it is "should have no"


S 9.2.2.
>      under attack.
>   
>   9.2.2.  From the inside
>   
>      The security model of the ACP is based on trusting all members of the
>      group of nodes that do receive an ACP domain certificate for the same

Nit: "receive", not "do receive"


S 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 was compromised.  And without additional centralized tracking of
>      assigned certificates there is no way to do this - assuming one can
>      not retrieve this information from the .

from the .?


S 10.2.4.
>      In situations, where either of the above two limitations are an
>      issue, ACP registrars could also be sub-CAs.  This removes the need
>      for connectivity to a root-CA whenever an ACP node is enrolled, and
>      reduces the need for connectivity of such an ACP registrar to a root-
>      CA to only those times when it needs to renew its own certificate.
>      The ACP registrar would also now use its own (sub-CA) certificate to

When you say "sub CA" do you mean "intermediate"?


S 10.3.2.1.
>      provides also a high level of security because it only permits ACP/
>      ANI operations which are both well secured.  Ultimately, it is
>      subject to security review for the deployment whether "admin down" is
>      a feasible replacement for "physical down".
>   
>      The need to trust into the security of ACP/ANI operations need to be

"trust into" is not grammatical


S 10.3.4.
>      whether or not to set "ACP/ANI enable".
>   
>      The goal of automatically setting "ACP/ANI enable" on interfaces
>      (native or not) is to eliminate unnecessary "touches" to the node to
>      make its operation as much as possible "zero-touch" with respect to
>      ACP/ANI.  If there are "unavoidable touches" such a creating/

such as


S 10.3.5.
>      parameters on SIM card shipped to remote location), then the default
>      should be to enable ACP/ANI.
>   
>   10.3.5.  Node Level ACP/ANI enable
>   
>      A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI

I got lost here. In what context does this command exist?


S 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 network where the operator

"In networks"


S 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

This also seems handwavy.


S 15.2.
>      because it is not quite clear yet what exactly the implications are
>      to make GRASP flooding depend on RPL DODAG convergence and how
>      difficult it would be to let GRASP flooding access the DODAG
>      information.
>   
>   A.6.  Extending ACP channel negotiation (via GRASP)

This section seems like it's entirely speculative. I recommend
removing it.

That said, I don't really understand the rationale for multiple
concurrent security protocols. If you have clear UDP on the network
(and you must or none of this works), then you can do DTLS and IKEv2,
so you should be able to have one side decide which to negotiate and
negotiate that. Why does this not work?


S 15.2.
>   
>      If multiple independent networks choose the same domain name but had
>      their own CA, these would not form a single ACP domain because of CA
>      mismatch.  Therefore there is no problem in choosing domain names
>      that are potentially also used by others.  Nevertheless it is highly
>      recommended to use domain names that one can have high probability to

Are these normative?


S 15.2.
>      If different domains have different CAs, they should start to trust
>      each other by intent injected into both domains that would add the
>      other domains CA as a trust point during the ACP connection setup -
>      and then following up with the previous point of inter-domain
>      connections across domains with the same CA (e.g., GRASP
>      negotiation).

This all seems speculative (and hard to analyze at this state of
handwaving). I suggest removal.


S 15.2.
>      other domains CA as a trust point during the ACP connection setup -
>      and then following up with the previous point of inter-domain
>      connections across domains with the same CA (e.g., GRASP
>      negotiation).
>   
>   A.8.  Adopting ACP concepts for other environments

I would also remove this appendix.

(Terry Manderson) Yes

Deborah Brungard No Objection

Comment (2018-05-21 for -13)
No email
send info
I noted in the different versions the content of section 10 floated between an
appendix and as part of the document (current version). Considering Section 10's
intro, I agree with Mirja, this content seems more suitable (and
will ease the readability) as an appendix. Section 10.5 still says "This appendix..".

(Ben Campbell) No Objection

Comment (2018-08-01 for -16)
No email
send info
Substantive Comments:

- I agree with Alissa's comment about "future" things.

§4: What do the normative keywords in this section apply to? If this document fulfills the requirements, it seems odd to continue to state them normatively. Normally such keywords are intended for implementors and sometimes administrators; protocol requirements don't really fit the RFC 2119/8174 definitions. If you need to use them in a non 2119/8174 sense, please mention that somewhere.

§4, ACP5: SHOULD is SHOULD. If it needs to be stronger than a normal SHOULD, consider a MUST. (But see my previous comment.)

§6.1.1: I'm a bit surprised to see the syntax burn 7 characters on the literal RFC name.

In §6.1.1, the statement "If the operator does not own any FQDN, it should
   choose a string (in FQDN format) that intends to be equally unique." seems problematic without further guidance about how to actuall make them "equally unique" For example, how does one ensure this does not collide with real FQDNs?

§6.1.2: Please describe how one actually checks for cert validity (e.g.  explicit field comparisons) In the second bullet, how does one check for private key ownership. If the answer is "PKI", then how does that requirement differ from the following one?)

§6.1.3, first paragraph: The 2nd MUST seems like a statement of fact in light of the first MUST.

§6.10.1, first bullet: Does this mean the address spaces can overlap?
-- last bullet: "not expected to be an end-user device" and "stay within a domain (of trust)" are both tricky assumptions. Is there a mechanism to ensure the assumptions are not violated?

Editorial Comments:

- IDNits reports several outdated or unused references--please check.
- General: Some sections are marked as "Normative", but there are unmarked sections with normative keywords in them. Please be consistent in such labeling. (Personally, I suggest not labeling sections this way unless you think they are more likely to be misunderstood than normal.)
§1.1: Please expand "RPL" on first mention.
§2, definition of MIC: Why include a definition to say you don't use it in the doc? Also, please use the boilerplate from 8174 rather than rolling your own.
§3 and §4: Are these sections useful to the average reader not involved in the standards process? It seems like they might be better off in an appendix or even a wg wiki, especially considering the document length.
§4: This section contains a lot of sentence fragments, which I suspect were intentional. Please use complete sentences when writing in paragraph form.
§6.1: Paragraphs 2 and 3 contain comma splices.

§6.1.3.4: "Certificate lifetime may be set to shorter lifetimes than customary
   (1 year) because certificate renewal is fully automated via ACP and
   EST. "
Are you proposing setting it to one year, or are you suggesting one year is customary?

§6.1.3.4, 2nd paragraph: "allowing to simplify" is grammatically incorrect. Consider "allowing [something] to simplify" or "allowing the simplification"

§6.1.3.6: The first paragraph is hard to parse. Please do not use "/" as a shortcut for a conjunction.

Alissa Cooper (was Discuss) No Objection

Comment (2019-08-01)
Thanks for addressing my DISCUSS. Original COMMENT is left below.

General:

Please address the Gen-ART reviewer's latest round of comments.

There are a bunch of places in this document where it seems like there is a tension between specifying a limited set of functionality here and being able to support a wider variety of deployment scenarios. This is noted in Section 1 but I think in general it would be clearer if uses of the term "future" throughout the document could be more surgical as well as more specific about whether they mean "people might deploy this differently in the future" or "standards would need to be developed in the future." I've made a few suggestions about some of these turns of phrase below but would suggest someone do a full edit pass with this in mind because there are a large number of mentions of "future work." Of course there is always more work to do, but every bit of "future work" need not be mentioned in this document, and in cases where it is mentioned I think there should be a specific reason for doing so that bears on people implementing this specification. I don't think this fits in the DISCUSS criteria but for a document that intends to be published on the standards track I would expect it to be crisper about the dividing line between the normative behavior being specified here versus changes or extensions that may or may not be made in the future.

"Intent" is used both capitalized and in lower case throughout the document and I'm unclear if this is meant to signify a distinction or not.

Section 2: 

Please remove the -->"..."() notation.

Please use the exact boilerplate from RFC 8174, not a variation.

It seems like RFC citations should appear for IKEv2 and DTLS upon first use in this section. Otherwise, it seems they are first cited at different future points in the document (Section 6.3 and 6.7, respectively).

Section 3.3:

"The ACP provides reachability that is independent of the Data-Plane
   (except for the dependency discussed in Section 6.12.2 which can be
   removed through future work),"

Isn't this kind of a big exception, given that there is meant to be a secure channel between pairs of nodes in the ACP and that developing future encapsulations is non-trivial? It seems like phrasing this the other way around (the ACP is dependent on the Data-Plane for <XYZ> but is otherwise independent of it) would be more accurate.

Section 6:

"Indestructible" seems like an overstatement. Maybe "resilient" would be more accurate?

Section 6.1.1:

s/Such methods are subject to future work though./No such methods have been defined at the time of publication of this document./

s/to build ACP channel/to build ACP channels/

s/that intends to be equally unique/that it intends to be equally unique/ 

""rsub" is optional; its syntax is defined in this document,
   but its semantics are for further study.  Understanding the benefits
   of using rsub may depend on the results of future work on enhancing
   routing for the ACP."

What is the point of defining this now when it is unclear if or how it will be used? There are already means for nodes to do error handling, so it seems like defining a new field in the future if/when it is needed would work fine and be cleaner. Appendix A.7 seems to assume some semantics for this field, which makes the way it is specified here even more confusing IMO. 

"In this specification, the "acp-address" field is REQUIRED, but
   future variations (see Appendix A.8) may use local information to
   derive the ACP address.  In this case, "acp-address" could be empty.
   Such a variation would be indicated by an appropriate "extension".
   If "acp-address" is empty, and "rsub" is empty too, the "local-part"
   will have the format "rfcSELF + + extension(s)".  The two plus
   characters are necessary so the node can unambiguously parse that
   both "acp-address" and "rsub" are empty."

This seems contradictory. Either "acp-address" is REQUIRED in which case there are no exceptions, or it's not; if it's not, then the expected syntax for cases when it's not present should be specified.

Section 6.1.2:

s/If the node certificates indicates/If the node certificate indicates/

Section 6.3:

It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS.

Section 6.4:

This is a good example of a section where the blurring between the specified behavior and expectations for the future is unhelpful IMO. Why specify the current default and then spend a lot of words (including Appendix A.7) talking about how it will be different in the future?

Section 6.10.3.1:

s/We do not think this is required at this point/This is not currently required/

Section 6.12.2:

s/may specify additional layer 2 or layer encapsulations/may specify additional layer 2 or layer 3 encapsulations/ (I think?)

Section 8.2.1:

This seems extraneous: "Future work could transform this into a YANG ([RFC7950]) data
   model."
   
Appendix A.8:

"Secure channels may
   even be replaced by simple neighbor authentication to create
   simplified ACP variations for environments where no real security is
   required but just protection against non-malicious misconfiguration."
   
I think experience has shown that even environments where it is assumed that security is not required prove to need it. I would suggest removing this text or changing this implication.

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Warren Kumari (was Discuss) No Objection

Comment (2018-06-11 for -16)
No email
send info
Thank you for addressing my DISCUSS concerns so quickly and well.

I've cleared.

 (Actually wrote this a few days back, but forgot to hit the confirm button :- ( )


-- Original DISCUSS for hysterical raisins -- 
I'm balloting DISCUSS, but I think that this should be relatively simple to address:
The document says things like:"Today, the management and control plane of networks typically runs in
the global routing table, which is dependent on correct configuration
and routing." and "Context separation improves security, because the ACP is not
   reachable from the global routing table. "

The term "global routing table" is widely used and understood to mean the global BGP routing table, or Internet global routing table. I understand that you are using it in the "default VRF" meaning, but I think that it is really important to clarify / disambiguate this the first time you use it.

----------






Thank you very much for writing this document -- it is comprehensive...

A rich text version of my review is here: https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and pasted below for tooling, email, etc.

--- 
draft-ietf-anima-autonomic-control-plane.txt:212
   network nodes that is not the ACP, and therefore considered to be
   dependent on (mis-)configuration.  This data-plen includes both the
   traditional forwarding-plane, as well as any pre-existing control-
Nit: data-plane


draft-ietf-anima-autonomic-control-plane.txt:508
   certificate.  This does not require any configuration on intermediate
   nodes, because they can communicate zero-touch and securely through
   the ACP.
I understand what you are trying to say, but "zero-touch" is not an adverb. 


draft-ietf-anima-autonomic-control-plane.txt:518
   the data-plane is operational, will the other planes work as
   expected.
This is *sometimes* an undesirable dependency, but is usually viewed as a feature (by operational people) -- having the control plane share fate with the dataplane is something that is usually a feature - this drives at least part of the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF relying on v4 dataplane avoids blackholes if the v4 dataplane stops working.
(This is sometimes, but less often used as an argument against ISIS).

I understand why it is useful in this context, but it would be useful to clarify/make it clear that you understand the subtleties.

Also, nit: "is operational, will the" -- the comma feel weird here.


draft-ietf-anima-autonomic-control-plane.txt:526
   management session is running can lock an admin irreversibly out of
   the device.  Traditionally only console access can help recover from
   such issues.
"only console access or OOB".

You may be using "console access" to mean OOB, but much (most?) OOB is now not console based.


draft-ietf-anima-autonomic-control-plane.txt:531
   Operations Center") such as SDN controller applications: Certain
   network changes are today hard to operate, because the change itself
   may affect reachability of the devices.  Examples are address or mask
I think that this was an editing issue -- you don't "operate" changes. Perhaps "implement"?


draft-ietf-anima-autonomic-control-plane.txt:858
   o  If the node certificates indicate a CDP (or OCSP) then the peer's
      certificate must be valid according to those criteria. e.g.: OCSP
You expand CDP further in the document, but this is the first time it is used.


draft-ietf-anima-autonomic-control-plane.txt:994
   ACP neighbors.  Native interfaces (e.g.: physical interfaces on
   physical nodes) SHOULD be brought up automatically enough so that ACP
   discovery can be performed and any native interfaces with ACP
I don't have a suggestion, but "automatically enough" doesn't sound right - "automatically configured enough" ?


draft-ietf-anima-autonomic-control-plane.txt:1067
   In the above (recommended) example the period of sending of the
   objective could be 60 seconds the indicated ttl of 180000 msec means
   that the objective would be cached by ACP nodes even when two out of
Editing fail -- missing some punctuation or words.


draft-ietf-anima-autonomic-control-plane.txt:1933
   for reachability.  The use of the autonomic control plane specific
   context eliminates the probable clash with the global routing table
   and also secures the ACP from interference from the configuration
IMPORTANT: The term "global routing table" has a well known meaning in operations -- it is the global BGP table. I strongly suggest using a different term, or having a very clear statement in the terminology section, AND the first time you use it in the document. This will help minimize confusion.

draft-ietf-anima-autonomic-control-plane.txt:3081
10.2.  ACP (and BRSKI) Diagnostics
Just a note that I like / appreciate this section - having guidance on how to troubleshoot is very helpful.


draft-ietf-anima-autonomic-control-plane.txt:3416
10.3.2.2.  Fast state propagation and Diagnostics

   "Physical down" state propagates on many interface types (e.g.:
When I saw the "physically brought down" I started composing a long soapbox rant on the fact that this will slow down state propagation -- I like that that document anticipates and addresses this. It might be useful to have a pointer in the previous section (like "(see below)" or similar.)


draft-ietf-anima-autonomic-control-plane.txt:3482
   for 5 seconds to probe if there is an ACP neighbor on the remote end
   every 500 seconds = 1% power consumption.
I believe that this is sufficiently incorrect that you should remove the 1% result (or, better yet the whole last sentence).

Various interfaces (especially long reach) take a significant amount of time (and additional power) when bringing up interfaces -- things like DWDM optics and amplifiers sometimes need significant power for heating elements to lock the frequency / wavelength, and so the power consumption is not linear with interface uptime.

Mirja Kühlewind No Objection

Comment (2018-05-18 for -13)
No email
send info
1) I would like to see a slightly stronger statement here in section 6.1.3:
"The M_FLOOD message MUST be sent periodically.  The default SHOULD be
   60 seconds, the value SHOULD be operator configurable."
Maybe the following instead:
"The M_FLOOD message MUST be sent periodically.  The default MUST be
   60 seconds, the value SHOULD be operator configurable but SHOULD be
   not smaller than 60 seconds."
Or even a MUST for the minimum value is that acceptable for the desired use cases.

2) Also in section 6.5, I would like to seem some rate limiting/pacing:
"An ACP node may choose to attempt initiate the different feasible ACP
   secure channel protocols it supports according to its local policies
   sequentially or in parallel,..."

3) Sec 6.7.3: How are baseline ACP and constrained ACP nodes defined?

4) sec 6.10.6:
"With the current allocations, only 2 more schemes are
   possible, so the last addressing scheme should consider to be
   extensible in itself (e.g.: by reserving bits from it for further
   extensions."
Maybe use a normative MUST here:
"With the current allocations, only 2 more schemes are
   possible, so the last addressing scheme MUST be
   extensible in itself (e.g.: by reserving bits from it for further
   extensions."

5) I guess section 10 could be moved to the appendix.

Alexey Melnikov No Objection

Comment (2018-08-02 for -16)
No email
send info
I haven't finished reading the whole document. I agree with Benjamin and Ekr that some security aspects are underspecified.

A few extra comments/questions of my own:

1) Where is locator-option formally defined?

2) 
6.10.2.  The ACP Addressing Base Scheme

   o  The 40 bits ULA "global ID" (term from [RFC4193]) for ACP
      addresses carried in the domain information field of domain
      certificates are the first 40 bits of the SHA256 hash of the
      routing subdomain from the same domain information field.

I think you need to make clear that one needs to canonicalize (e.g. to lowercase) the routing subdomain before applying hash.
You don't want some nodes using "example.com" and other "EXAMPLE.com".

      In the
      example of Section 6.1.1, the routing subdomain is
      "area51.research.acp.example.com" and the 40 bits ULA "global ID"
      89b714f3db.

3) A.6:

   When Alice and Bob successfully establish the GRASP/TSL session, they

typo: TSL --> TLS

   will negotiate the channel mechanism to use using objectives such as
   performance and perceived quality of the security.  After agreeing on
   a channel mechanism, Alice and Bob start the selected Channel
   protocol.  Once the secure channel protocol is successfully running,
   the GRASP/TLS connection can be kept alive or timed out as long as
   the selected channel protocol has a secure association between Alice
   and Bob.  When it terminates, it needs to be re-negotiated via GRASP/
   TLS.

Adam Roach No Objection

Ignas Bagdonas Recuse

Comment (2018-08-02 for -16)
No email
send info
I was involved in this for a while.

Roman Danyliw No Record

Barry Leiba No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record