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

[Ballot comment]
We're down to largely editorial stuff at this point, and I'm happy with the overall
state of things.

A couple of the new bits in the -29 might benefit from targeted review (noted
inline), e.g., for CDDL, TSV, or INT-specific aspects.

Section 6.1

  TLS 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 than SHA384.  When TLS 1.3 is supported, TLS_AES_256_GCM_SHA384

One could potentially say "hash strength of less than 384 bits" instead
of anchoring the reference point at SHA384, but I'm not terribly
concerned about it.

  TLS MUST also include the "Supported Elliptic Curves" extension, it
  MUST support the NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24))
  curves [RFC4492].  In addition, TLS clients SHOULD send an
  ec_point_formats extension with a single element, "uncompressed".

We can say "TLS 1.2 clients" for the ec_point_format extension (nit: no 's').

Section 6.2.1

Thank you for clarifying the "serialNumber" attribute; I think that will
be helpful for a lot of people.

  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

I think I mentioned this previously (and sorry for the repetition if I
did), but just in case I didn't: this 256-bit group order requirement
excludes Ed25519 and friends.  If you're fine with that, that's okay; I
just want to make sure it's an informed choice.

  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.

I think "same requirements for digest usage in certificate signatures"
is more accurate.

  In support of ECDH key establishment, ACP certificates with ECC keys
  MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH): If
  the X.509v3 keyUsage extension is present, the keyAgreement bit MUST
  be set.

I think I may have failed to think about and comment on this previously,
but doing direct ECDH with the (static) key in the certificate is pretty
uncommon -- as I understand it you don't need this bit set in order to
use the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite, for
example.  To be clear, I'm not saying it's inherently wrong to make this
requirement, just that I don't think it's needed for the use-cases
presented in this document.  (It may also make it harder to get such
certificates issued in the future, though it's hard to predict what
path CA policies will take in the future.)

Section 6.2.3

It might be nice to say something about in what cases the transport
address used to reach the peer can/cannot be validated against the
acp-address in the peer's ACP certificate.  I think there are some
classes of interactions for which that check can be done and would add
value, even though there are definitely some classes of interaction for
which it is not viable.

Section 6.2.5.3

  When using a private PKI for ACP certificates, the CRL may be need-
  to-know, for example to prohibit insight into the operational
  practices of the domain by tracking the growth of the CRL.  In this
  case, HTTPS may be chosen to provide confidentiality, especially when
  making the CRL available via the Data-Plane.  Authentication and
  authorization SHOULD use ACP certificates and ACP domain membership
  check.  [...]

(I assume that the SHOULD here is still only in the case where the CRL
is need-to-know; no text changes needed if that's correct.)

Section 6.2.5.5

  To prohibit attacks that attempt to force the ACP node to forget its
  prior (expired) certificate and TA, the ACP node should alternate
  between attempting to re-enroll using its old keying material and
  attempting to re-enroll with its IDevID and requesting a voucher.

I think that as written, this doesn't fully "prohibit" such attacks (but
does make them harder and is good advice).  I suppose some nodes might
continue trying with the old key material for some time even after
obtaining a new voucher, but the state-keeping requirements for that are
big enough that we shouldn't require it.  So I'd suggest just a small
change like s/To prohibit/As a countermeasure against/.

  Maintaining existing TA information is especially important when
  enrollment mechanisms are used that unlike BRSKI do not leverage a
  mechanism (such as the voucher in BRSKI) to authenticate the ACP
  registrar and where therefore the injection of certificate failures
  could otherwise make the ACP node easily attackable remotely by
  returning the ACP node to a "duckling" state in which it accepts to
  be enrolled by any network it connects to.  The (expired) ACP
  certificate and ACP TA SHOULD therefore be maintained and used for
  re-enrollment until new keying material is enrolled.

(editorial) the wording here should probably be checked; right now it
seeems to be saying "use X for re-enrollment until [re-enrollment
succeeds]" which makes me wonder how the new keying material would come
into play.

Section 6.4

Figure 7 has some nits, now -- '|' is not a CDDL keyword.
Also, we should probably get a CDDL expert to look at it, since both
method-params and extensions are 1*any, and I'm not 100% sure what the
order of binding is (Appendix A of RFC 8610 suggests that it is a
prioritized choice in CDDL, so things after the first comma would always
be parameters, not extensions).

  Attackers on a subnet may be able to inject malicious DULL GRASP
  messages that are indistinguishable from non-malicious DULL GRASP
  messages to create Denial-of-Service (DoS) attacks that force ACP
  nodes to attempt many unsuccessful ACP secure channel connections.
  When an ACP node sees multiple AN_ACP objectives for the same secure
  channel protocol on different transport addresses, it SHOULD prefer
  connecting via the well-known transport address if the secure channel
  method has one (such as UDP port 500 for IKEv2).

This new text should probably be run by some TSV-area reviewer (e.g.,
AD).

Section 6.8.3.1

  The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP),
  MUST be support.  Reason: ECC provides a similar security level to

nit: "supported".

Section 6.8.3.2

  If IKEv2 initiator and responder support IPsec over GRE, it will be
  preferred over native IPsec because of the way how IKEv2 negotiates
  transport mode as used by this IPsec over GRE profile) versus tunnel
  mode as used by native IPsec (see [RFC7296], section 1.3.1).  The ACP

nit: missing open paren?

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 [X.520] "serialNumbers" attribute in the
      subjects field distinguished name encoding from their IDevID
      certificate.

I note we had that long ietf@ thread about terminology, that included
"whitelist" and "blacklist", and trust you to make an informed choice
about terminology usage.

Section 9.3.5.2

  When a greenfield node enables multiple enrollment/botstrap
  protocols/mechanisms in parallel, care must be taken not to terminate
  any protocol/mechanism before another one has progressed to a point
  where greenfield state is defined to end.

(editorial) Do we give a clear definition of when greenfield state is
defined to end, that would apply to arbitrary such mechanisms?  We might
want to reword a little bit.

Section 11

Wow, so much new good stuff here; thanks!

  *  For IDevIDs to securely identify the node to which it IDevID is
      assigned, the node it needs to (1) utilize hardware support such
      as a Trusted Platform Module (TPM) to protect against extraction/
      cloning of the private key of the IDevID and (2) a hardware/
      software infrastructure to prohibit execution of non authenticated
      software to protect against malicious use of the IDevID.

nit: s/node it needs to/node needs to/

  *  A malicious ACP node could declare itself to be an EST server via
      GRASP across the ACP if malicious software could be executed on
      it.  CA should therefore authenticate only known trustworthy EST
      servers, such as nodes with hardware protections against malicious
      software.  Without the ability to talk to the CA, a malicious EST
      server can still attract ACP nodes attempting to renew their
      keying material, but they will fail to perform successful renewal
      of a valid ACP certificate.  The ACP node attempting to use the
      malicious EST server can then continue to use a different EST
      server, and log a failure against a malicious EST server.

We have two copies of basically this text.  The second one (that I
quoted) does not have a note about id-kp-cmcRA, and is the one that
should be removed.

  If public CA are to be used, ACP registrars would need to prove
  ownership of the domain-name of AcpNodeNames to the public CA.
  However, maintaining the ULA based address allocation when using a
  public CA might be considered to be a violation of the private
  allocation expectation of ULA prefixes.  To avoid this issue, further
  changes to registrar address allocation procedures might be needed,
  for example using global IPv6 address prefixes owned by the public CA
  instead of ULA.

I don't expect any problems here, but it might be good to get some
INT-area (e.g., AD) eyes on this text.

Section 12

  0: ACP Zone Addressing Sub-Scheme (ACP RFC 1: ACP Vlong Addressing
  Sub-Scheme (ACP RFC Figure 12) / ACP Manual Addressing Sub-Scheme
  (ACP RFC Section 6.11.4) Section 6.11.5)

Something went awry here (maybe just formatting?), as the '1' is
supposed to be the initial value allocated by this document, not a
reference to RFC 1.

Section 16

RFC 4492 is obsoleted by RFC 8422.

Section A.6

  When the two peers successfully establish the GRASP/TSL session, they
  will negotiate the channel mechanism to use using objectives such as

nit: s/TSL/TLS/

Section A.10.9

Thank you for adding this discussion; it is a good treatment of the
issues and considerations in play.

[Ballot comment]
Thanks for addressing my DISCUSS issues and other comments in version -29.

Special thanks for the changes in the "Channel Selection" section; I find it *much* easier to follow now, with "the Decider" and "the Follower" making the roles clear.  Good work, folks!

[Ballot discuss]
[ section 2 ]

* "It is the approximate IPv6 counterpart of the IPv4 private address
  ([RFC1918])."

  I understand the intent but I don't think this statement is complete. I
  think we shouldn't let this sentence out into the wild as is since it could
  be read without any context nor even any pretense of interest in nuance.

  May I suggest:

  "It is often thought of as the approximate IPv6 counterpart of the IPv4
  private address space ([RFC1918]), though it is in fact meaningfully
  different in important and subtle ways [and upon which this document relies]."

[ section 6.10.2 ]

* Please clarify the table at the end of this section.  It looks like only
  two Types are listed, but should all 4 bit values be present?  Where are the
  Z, F, and V bits in the address?

  I realize these are defined in the following sections, so it probably
  suffices to say something like "The Z, F, and V bits are allocated from
  within the sub-scheme portion of the address according to the following
  sections..." or something.

  Unassigned/unused Type values should maybe be listed in the table as
  "Reserved"?

[ section 8.1.3 ]

* Why is an RIO for ::/0 with a lifetime of 0 required?  Doesn't it suffice
  it set the default router lifetime to 0?  Separately, are all nodes required
  to be Type C?

[Ballot comment]
[ section 1 ]

* "as good as possible" might be "as well as possible", but I'm unsure if I
  have any grammatical basis for this (adverbial phrase vs adjectival phrase?).

* "ACPs functions" -> "ACP's functions"?

* "overview how" perhaps: "overview of how"

* "propriety extensions" -> "proprietary extensions"

[ section 2 ]

* "On virtual nodes their equivalent." isn't really a complete sentence.  I
  think if you just join it to the previous sentence with ";" it works
  grammatically.

[ section 6.1.1 ]

* s/devices "serialNumber"/device's "serialNumber"/

[ section 6.1.2 ]

* The example "fd89b714F3db00000200000064000000" contains an uppercase "F"
  and therefore doesn't conform to 32HEXLC, I believe.

* 2. 2.1, "a nodes ACP" -> "a node's ACP" (it is correct in the immediately
  preceding sentence).

[ section 6.1.3 ]

* The rsub field, even if deliberately not pertinent, is a bit conspicuous by
  its absence from this section I think. It might good to state so explicitly
  (at least I, as a reader, was expecting to see some mention of it).

[ section 6.1.5.1 ]

* I think the 32 hex lowercase IPv6 addresses in the examples are each missing
  a single hex character (31 instead of 32)?  Or maybe that's not what these
  fields are (or I've miscounted)?

[ section 6.3 ]

* "does not include ACP nodes ACP certificate" perhaps -> "does not include
  the ACP node's ACP certificate"

* With respect to DULL GRASP message fragmentation due to certificate
  inclusion: is it of any value to include the fingerprint of the ACP cert,
  for diagnostics...?

[ section 6.5 ]

* s/to easier distinguish/to more easily distinguish/

[ section 6.6 ]

* Feel free to phrase the backoff implementation in reference to RFC 8415
  section 15 semantics (I think: IRT = 10 seconds, MRT = 640 seconds).

[ section 6.7.3.2 ]

* Should Responder-IPv6-ACP-LL-addr be in the TSr set?

[ section 6.10.1 ]

* "not expected to be end-user host." --> "... hosts."

[ section 6.11.1.11 ]

* What does a manual configuration (6.10.4) advertise?  Just its /128?

* Where does the /96 come from?

[ section 6.12.3 ]

* "meant to be prioritize reliability" -> "meant to prioritize reliability"

[ section 6.12.5.1 ]

* s/adddress/address/

* (see Figure 15 --> (see Figure 15)

* on other type -> on other types

[ section 6.12.5.2.2 ]

* "ACP nodes MAY reduce the amount of link-local IPv6 multicast packets
  from ND by learning the IPv6 link-local neighbor address to ACP
  secure channel mapping from other messages such as the source address
  of IPv6 link-local multicast RPL messages - and therefore forego the
  need to send Neighbor Solicitation messages."

  Isn't this only true on links with configurations such that a node can trust
  that the source link layer address of the received RPL message is guaranteed
  to be that of the original sender?

[ Appendix A.1 ]

* Yeah, I gotta say I didn't understand why the acp-address scheme wouldn't
  support giving each ACP loopback its own /64 from the start.  That's
  14-16 bits of /64s in a single rsub ULA's /48 which would seem pretty simple
  to implement (a /64 per router in some deployments).

[Ballot discuss]
This DISCUSS should be easy to resolve: it's mostly that I find the text in Section 6.5 related to Bob and Alice to be confusing and unclear.  I see that EKR also found it so and asked for the step-by-step diagram, which does help.  But I find the whole Bob/Alice thing to be messy and wish you could instead use some functionally descriptive terms for the roles, rather than using arbitrary names that aren't meaningful and lead the reader to say, "Wait, which one is Bob now?"

Specifically:

— Section 6.5 —

      The node with the
      lower Node-ID in the ACP address of its ACP certificate becomes
      Bob, the one with the higher Node-ID in the certificate Alice.  A
      peer with an empty ACP address field in its ACP certificate
      becomes Bob (this specification does not define such peers, only
      the interoperability with them).

What’s with “becomes Bob” and “Alice” here?  Without any introduction I don’t know what’s going on.  Do you mean something like, ‘One node has a lower Node-ID in the ACP address of its ACP certificate than the other.  For this discussion, we will call that node “Bob”, and the other “Alice”.’ ?  Or do you mean something else?  And then what does the next sentence mean?

  For example, originally Bob could have been the initiator of one ACP
  secure channel protocol that Bob prefers and the security association
  succeeded.  The roles of Bob and Alice are then assigned and the
  connection setup is completed.

Again I’m confused: you’re talking about Bob doing something, and *then* the role of Bob is assigned?  What does that mean?  How can we talk about Bob doing something before we know who Bob is?

And are there no more descriptive terms to use here, as opposed to “Bob” and “Alice”?  Something like “initiator” and “responder”, or whatever, which might be easier to follow?


I also have a few easy-to-address issues here:

— Section 6.7.3.1.2 —

  The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP),
  listed as a SHOULD, is to be configured, along with the 2048-bit MODP
  (group 14).

I don’t understand the requirement level here, because I’m not sure what “is to be configured” means.  You mention “SHOULD”, but then “is to be configured” seems to say that it has to be supported.  And you seem to be saying that he same requirement, whatever it is, applies to both group 19 and group 14... but I’m not certain about that.  Can you please rephrase this to make the requirements clearer?

— Section 6.7.5 —

  A baseline ACP node MUST support IPsec natively and MAY support IPsec
  via GRE.  If GRE is supported, it MAY be preferred over native IPec.

But Section 6.7.3.2 says:

  If IKEv2 initiator and responder support IPsec over GRE, it has to be
  preferred over native IPsec.

Which is it?  “MAY” be preferred?  Or “has to be preferred”?

— Section 6.10.6 —

  IANA is asked need to assign a new "type" for each new addressing
  sub-scheme.  With the current allocations, only 2 more schemes are
  possible, so the last addressing scheme MUST provide further
  extensions (e.g., by reserving bits from it for further extensions).

I don’t understand the first sentence.  It doesn’t parse, for one thing, so please fix that.  And it would be better to clearly match it with the corresponding request in the IANA Considerations section.

For the second sentence (the DISCUSS part), I’m very skeptical that this is the right approach: if you’re already acknowledging that “only” 2 schemes are possible now, it seems time *now* to prepare the way for additional ones, rather than waiting.  What’s the reasoning for putting in a warning rather than just doing it, especially as you’re setting up a new registry anyway?

[Ballot comment]
We have to use “virtual out-of-band” more often, because “VOOB” is a great acronym.

— Section 1 —

  is therefore intended to combine as good as possible the resilience

Nit: this needs an adverb rather than an adjective, “as well as possible”.

  the ACPs functions instead of implementing them seperately for each

Nit: “separately”.  In the list that follows you should also put a comma after “traffic” to make it clear what the third list item is, as there are five “and”s in there.

— Section 1.1 —

  Infrastructure (PKI) code for the ACP certificate, the GRASP
  protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and

Why specifically TLS 1.2?  Probably this should say “TLS” without a version, and reference the now-current TLS 1.3 spec (8446), but it shouldn’t be tied to a specific TLS version.

Similarly, mentions of DTLS shouldn’t be tied to the version number.

Alternatively for both, they could say “version 1.2 or greater”.  I do see that some places in the document mention 1.2 as a minimum, so I'm just looking for a little clean-up here to make sure it's clear that we don't want to use <1.2, but anything from 1.2 on is fine.

  Plane itself would not need to change, it could continue to be IPv4
  only.  For such IPv4 only devices, the IPv6 protocol itself would be
  additional implementation footprint only used for the ACP.

Nit: this is a comma splice.  Either change the comma to a semicolon or change “, it” to “and”.  Also, “IPv4-only” should be hyphenated when it’s a modifier, as it is in the second case (but not the first).

I don’t understand “would be additional implementation footprint only used for the ACP.”  I think “that is only used” would help, but I also don’t think “footprint” is the right word here.

  The ACP design can be applicable to (cpu, memory) constrained devices
  and (bitrate, reliability) constrained networks

This is an odd use of parentheses, and it threw me at first, before I realized it’s an attempt at grouping and shorthand.  Better to avoid it, as you also need some hyphens anyway:

NEW1
  The ACP design can be applicable to cpu- and memory-constrained devices
  and to bitrate- and reliability- constrained networks
END

Or if you find the hyphens awkward, maybe reword to avoid using modifiers:

NEW2
  The ACP design can be applicable to devices constrained with respect
  to cpu and memory, and to networks constrained with respect to bitrate
  and reliability.
END

(And I really don’t think the rest of the sentence (“but this document...”) adds anything, and I’d just skip it.)

— Section 2 —

  Normative sections are labelled "(Normative)" and use
  [RFC2119]/[RFC8174] keywords.

A small thing you can ignore if you like, but I would skip the citations here and just say, “and use BCP 14 key words.”  You’ll have the proper citations with the boilerplate later.

      A CA uses its private key to sign the certificates
      it issues, relying parties use the public key in the CA
      certificate to validate the signature.

Comma splice; please split the sentences.

      This signing certificate
      can be considered to be an identifier of the CA, so the term CA is
      also loosely used to refer to the certificate used by the CA for
      signing.

Really?  I’ve never seen a signing cert called a “CA”.  In any case, I wouldn’t like to see that usage encouraged.  Does this really need to be here?

— Section 4 —

  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.

That last bit feels odd; I suggest instead, “and it is very strongly recommended that they be encrypted.”

  written ASA could potentially all communicate exclusively via GRASP

Nit: “ASAs”

— Section 6.1 —

  The LDevID certificate is called the ACP certificate, the TA is the
  Certification Authority (CA) root certificate of the ACP domain.

Comma splice.

— Section 6.8.2 —

  GRASP unicast messages inside the ACP are transported
  via TLS which MUST comply with [RFC7525] execept that only TLS 1.2
  ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is RECOMMENDED.

This ties into my earlier comment about text that seems to tie this to the TLS version.  I strongly recommend that you say early on (not here in 6.8.2) what’s here in the quoted text and elsewhere: that, for TLS and DTLS, 1.2 is REQUIRED, 1.3 is RECOMMENDED, and 1.1 and earlier MUST NOT be used.  Include text “up there” about backward compatibility and making sure 1.2-only situations can be accommodated via negotiation.  Possibly add a sentence about supporting post-1.3 versions when they are developed.  And then don’t say anything about versions elsewhere in the document.

— Section 6.10.1 —

  o  Addresses in the ACP are not considered sensitive on privacy
      grounds because ACP nodes are not expected to be end-user host.

Is there something missing here?  This looks like an incomplete sentence.  Or should it just be “end user hosts”?  If that’s it, I suggest wording it as “...not expected to host end users.”  It might also help to say, “ACP nodes are part of the data center infrastructure [or some such] and are not expected...”

— Section 6.11.1.7 —

  Global Repair: we assume stable links and ranks (metrics), so no need
  to periodically rebuild DODAG.  DODAG version only incremented under
  catastrophic events (e.g., administrative action).

This is one of the most egregious of the poor-grammar issues in the document.  I’m generally not happy with expecting the RPC to turn text like this into proper English, and wish that working groups would be more careful about it.  Something like this, in this case, perhaps?:

NEW
  Global Repair: we assume stable links and ranks (metrics), so there is
  no need to periodically rebuild the DODAG.  The DODAG version is only
  incremented under catastrophic events (e.g., administrative action).
END

And is administrative action really an example of a catastrophic event?  It would seem that administrative action would be a *response* to such an event.  What’s an example of an event itself?  Or is it “catastrophic” that’s the wrong word, maybe?

(The “Local Repair” paragraph also has some incomplete sentences and missing articles.)

— Section 6.12.5.1 —

  2.  IPv6 implementations do commonly not allow to assign the same

A common English usage issue: “allow to assign” (in general, “allow ”) doesn’t work in English, because the infinitive needs a subject (“allow  to assign”).  If you don’t have a subject to put there, you can say, “IPv6 implementations commonly do not allow assignment of the same...” (which also fixes the issue that “commonly” shouldn’t split “do not”).

— Section 8.1.1 —

  interface looks like a normal network interface (without any
  encryption/novel-signaling).

What is “novel-signaling”?

  This is sometimes called "RPF filtering".  This MAY be changed
  through administrative measures.

Two things here:  One is that this feels like a “may” (or “might” or “can”... a statement, not a directive) rather than a BCP 14 key word.  The other is that I don’t follow what it is that may be changed: what does “this” refer to in the second sentence?

[Ballot 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.)

[Ballot 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
                          +area51.research@acp.example.com

[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 <@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  when " means
that the only time X is used is when Y, whereas "to use only  when
" 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/?

[Ballot comment]
I found significant parts of this document tough to follow, particularly because there are many deployment variations for almost every element of the architecture. But I trust that the Security ADs will catch any remaining security issues.

I appreciate that this effort appears, refreshingly, to have security baked in from the start.

Sec 6.1.1
"it is beneficial to
  copy the device identifying fields of the node's IDevID certificate
  into the ACP certificate,... and
  the "serialNumber" contains usually device type information that may
  help to faster determine working exploits/attacks against the device."

I am not certain the 'beneficial' assertion is supportable, if the benefit is some diagnostic help but the drawback is a security vulnerability.

sec 6.5. If both nodes have empty ACP address fields, they are both Bob. What happens then?

sec 6.11.1.14. "As this requirement raises additional Data-Plane,..."
I am not sure what this clause means to say.

[Ballot comment]
The style of explaining the design choice after describing an element of the protocol was informative and helpful.  Thanks.

This document has undergone a significant amount of security review.  Thank you for incorporating all of this feedback.

Thanks for resolving my previous DISCUSS and COMMENTs.

** Section 6.8.2.1. Editorial.
OLD
The compromised ACP node would
  simply announce the objective as well, potentially filter the
  original objective in GRASP when it is a MITM and act as an
  application level proxy.

NEW
The compromised ACP node would simply announce the objective as well, potentially filter the original objective in GRASP when it is in-path and acting as an application level proxy.

** 10.2.2.  Editorial.
OLD
This minimizes man in the middle
  attacks by compromised ACP group members

NEW
This minimizes attacks by compromised ACP group members who are on-path.

** In reviewing the ballot position of my predecessor (ekr)

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

[ekr] 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.

[Roman] If the domain uses a "public CA" as a trust anchor, is there a risk of it might also be used by some other autonomic domain?

[Ballot comment]
(1) §6: "An ACP node... Initially, it MUST have...an (empty) ACP Adjacency Table..."  Is "empty" a requirement?  I'm wondering because §6.2 says that the adjacency table can also contain configured information, which I assume would be present before neighbor discovery starts.


(2) As far as I understand, events happen in this order:  The ACP Adjacency Table (§6.2) is populated with information from DULL GRASP (§6.3).  Based on that information, a candidate set of neighbors is selected (§6.4).  Is that correct?

§6.4 (Candidate ACP Neighbor Selection) says that the "ACP is established exclusively between nodes in the same domain".  However, the domain membership check is not performed until later (§6.6). 

How are the candidate nodes selected in §6.4?  Some nodes may not be chosen, right?  How can it be verified that the candidate nodes are in the same domain without performing the domain membership check first? 

§6.6 says that "the connection attempt is aborted" if the domain membership check fails -- but there is no mention about considering other candidates.  It seems to me as if it may be possible for some selected candidates to not pass the domain membership check...  What am I missing?


(3) §6.11.1.8 (Multicast): s/Not used yet but possible because of the selected mode of operations./Not used but possible if the selected MOP is 3.


(4) [nits]

s/explanation how ACP acts/explanation of how ACP acts

s/nodes ACP certificate/node's ACP certificate/g

s/nodes ACP address/node's ACP address

[Ballot discuss]
I still have more to review here -- I'm about ⅓ of the way through -- but I wanted to get this in sooner, rather than waiting.

This DISCUSS should be easy to resolve: it's mostly that I find the text in Section 6.5 related to Bob and Alice to be confusing and unclear.  I see that EKR also found it so and asked for the step-by-step diagram, which does help.  But I find the whole Bob/Alice thing to be messy and wish you could instead use some functionally descriptive terms for the roles, rather than using arbitrary names that aren't meaningful and lead the reader to say, "Wait, which one is Bob now?"

Specifically:

— Section 6.5 —

      The node with the
      lower Node-ID in the ACP address of its ACP certificate becomes
      Bob, the one with the higher Node-ID in the certificate Alice.  A
      peer with an empty ACP address field in its ACP certificate
      becomes Bob (this specification does not define such peers, only
      the interoperability with them).

What’s with “becomes Bob” and “Alice” here?  Without any introduction I don’t know what’s going on.  Do you mean something like, ‘One node has a lower Node-ID in the ACP address of its ACP certificate than the other.  For this discussion, we will call that node “Bob”, and the other “Alice”.’ ?  Or do you mean something else?  And then what does the next sentence mean?

  For example, originally Bob could have been the initiator of one ACP
  secure channel protocol that Bob prefers and the security association
  succeeded.  The roles of Bob and Alice are then assigned and the
  connection setup is completed.

Again I’m confused: you’re talking about Bob doing something, and *then* the role of Bob is assigned?  What does that mean?  How can we talk about Bob doing something before we know who Bob is?

And are there no more descriptive terms to use here, as opposed to “Bob” and “Alice”?  Something like “initiator” and “responder”, or whatever, which might be easier to follow?


I also have an easy-to-address issue here:

— Section 6.7.3.1.2 —

  The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP),
  listed as a SHOULD, is to be configured, along with the 2048-bit MODP
  (group 14).

I don’t understand the requirement level here, because I’m not sure what “is to be configured” means.  You mention “SHOULD”, but then “is to be configured” seems to say that it has to be supported.  And you seem to be saying that he same requirement, whatever it is, applies to both group 19 and group 14... but I’m not certain about that.  Can you please rephrase this to make the requirements clearer?

[Ballot comment]
We have to use “virtual out-of-band” more often, because “VOOB” is a great acronym.

— Section 1 —

  is therefore intended to combine as good as possible the resilience

Nit: this needs an adverb rather than an adjective, “as well as possible”.

  the ACPs functions instead of implementing them seperately for each

Nit: “separately”.  In the list that follows you should also put a comma after “traffic” to make it clear what the third list item is, as there are five “and”s in there.

— Section 1.1 —

  Infrastructure (PKI) code for the ACP certificate, the GRASP
  protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and

Why specifically TLS 1.2?  Probably this should say “TLS” without a version, and reference the now-current TLS 1.3 spec (8446), but it shouldn’t be tied to a specific TLS version.

Similarly, mentions of DTLS shouldn’t be tied to the version number.

Alternatively for both, they could say “version 1.2 or greater”.  I do see that some places in the document mention 1.2 as a minimum, so I'm just looking for a little clean-up here to make sure it's clear that we don't want to use <1.2, but anything from 1.2 on is fine.

  Plane itself would not need to change, it could continue to be IPv4
  only.  For such IPv4 only devices, the IPv6 protocol itself would be
  additional implementation footprint only used for the ACP.

Nit: this is a comma splice.  Either change the comma to a semicolon or change “, it” to “and”.  Also, “IPv4-only” should be hyphenated when it’s a modifier, as it is in the second case (but not the first).

I don’t understand “would be additional implementation footprint only used for the ACP.”  I think “that is only used” would help, but I also don’t think “footprint” is the right word here.

  The ACP design can be applicable to (cpu, memory) constrained devices
  and (bitrate, reliability) constrained networks

This is an odd use of parentheses, and it threw me at first, before I realized it’s an attempt at grouping and shorthand.  Better to avoid it, as you also need some hyphens anyway:

NEW1
  The ACP design can be applicable to cpu- and memory-constrained devices
  and to bitrate- and reliability- constrained networks
END

Or if you find the hyphens awkward, maybe reword to avoid using modifiers:

NEW2
  The ACP design can be applicable to devices constrained with respect
  to cpu and memory, and to networks constrained with respect to bitrate
  and reliability.
END

(And I really don’t think the rest of the sentence (“but this document...”) adds anything, and I’d just skip it.)

— Section 2 —

  Normative sections are labelled "(Normative)" and use
  [RFC2119]/[RFC8174] keywords.

A small thing you can ignore if you like, but I would skip the citations here and just say, “and use BCP 14 key words.”  You’ll have the proper citations with the boilerplate later.

      A CA uses its private key to sign the certificates
      it issues, relying parties use the public key in the CA
      certificate to validate the signature.

Comma splice; please split the sentences.

      This signing certificate
      can be considered to be an identifier of the CA, so the term CA is
      also loosely used to refer to the certificate used by the CA for
      signing.

Really?  I’ve never seen a signing cert called a “CA”.  In any case, I wouldn’t like to see that usage encouraged.  Does this really need to be here?

— Section 4 —

  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.

That last bit feels odd; I suggest instead, “and it is very strongly recommended that they be encrypted.”

  written ASA could potentially all communicate exclusively via GRASP

Nit: “ASAs”

— Section 6.1 —

  The LDevID certificate is called the ACP certificate, the TA is the
  Certification Authority (CA) root certificate of the ACP domain.

Comma splice.

[Ballot discuss]
(pruned down to the remaining issue)

** Section 11.  Per the list of factors on which ACP depends, it seems like the following are missing:

-- the security properties of the enrollment protocol

-- that the security considerations of EST and BRSKI apply (or if not, why not)

[Ballot comment]
(Preliminary ballot.  Updated to reflect all changes made in -28 in response to the 07/15/2020 ballot for the 07/16/2020 telechat which deferred this document.  Need to double check that all of ekr's discusses/comments were cleared)

The style of explaining the design choice after describing an element of the protocol was informative and helpful.  Thanks.

The this document has undergone a significant amount of security review.  Thank you for incorporating all of this feedback.

Thanks for resolving my previous DISCUSS and COMMENTs.

[Ballot comment]
Hi,

I appreciate that this document has already gone through quite a lot of reviews.  Just a few minor nits (for the version of the doc that was originally on the telechat before IETF 108):

    6.1.  ACP Domain, Certificate and Network

      This document uses the term ACP in many places where the Autonomic
      Networking reference documents [RFC7575] and
      [I-D.ietf-anima-reference-model] use the word autonomic.  This is
      done because those reference documents consider (only) fully
      autonomic networks and nodes, but support of ACP does not require
      support for other components of autonomic networks except for relying
      on GRASP and providing security and transport for GRASP.  Therefore
      the word autonomic might be misleading to operators interested in
      only the ACP.
 
Should this paragraph be somewhere earlier in the document?


    6.1.2.  ACP Certificate AcpNodeName

    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.

The latter part of this sentence doesn't seem to scan particularly well.


    6.7.3.1.1.  RFC8221 (IPsec/ESP)

    AH MUST NOT be used (because it does not provide confidentiality).

Do you need AH in the terminology or define what it means?

    6.7.4.  ACP via DTLS

      We define the use of ACP via DTLS in the assumption that it is likely
      the first transport encryption supported in some classes of
      constrained devices because DTLS is already used in those devices but
      IPsec is not, and code-space may be limited.

DTLS in the assumption => DTLS, on the assumption
This paragraph could possibly do with a little more wordsmithing.


    6.10.1.  Fundamental Concepts of Autonomic Addressing
     
For a PE device or NID, how does it know which interfaces to run ACP over?

      o  OAM protocols do not require IPv4: The ACP may carry OAM
          protocols.  All relevant protocols (SNMP, TFTP, SSH, SCP, Radius,
          Diameter, ...) are available in IPv6.  See also [RFC8368] for how
          ACP could be made to interoperate with IPv4 only OAM.
     
Should this include a YANG management protocol like NETCONF?
Radius => RADIUS (in a few places)

    6.11.1.14.  Unknown Destinations

      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.
 
The first sentence doesn't quite scan.

Nits:
retrieved bei neighboring nodes =>  retrieved by neighboring nodes
"serialNumber" contains usually => "serialNumber" usually contains
remotely sent IPv6 link-local => remotely send IPv6 link-local

Document Writeup, template from IESG area on ietf.org, dated January 19, 2017.

draft-ietf-anima-autonomic-control-plane-13 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Standards Track. The document defines a so-call "Autonomic Control Plane",
  with the primary use as a control plane for autonomic functions. It is
  self-managing and zero configuration for basic scenarios.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document defines a so-call "Autonomic Control Plane",  with the primary
  use as a control plane for autonomic functions. It is  self-managing and zero
  configuration for basic scenarios.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-behringer-anima-autonomic-control-plane  prior
  to its adoption. There was unanimous support for it in favor of adoption and
  none against, so this document was adopted in August 2015. There was
  interest in this work posts since its adoption. There was never any
  opposition for this work.

  This document went through a relevant long document development
  period (10 months for individual document period, 29 month for WG
  document period). It has been reviewed well.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by multiple participants.
 
  There are multiple implementations of ACP. There is a commercial
  implementation by Cisco, and said it was (no information for the latest
  status) available on a wide range of Cisco IOS router platforms. However,
  It may not be fully compatible with the current ACP document, given that
  the implementation was started far early than the long process of ACP
  standard document reached the final stage. Huawei had some an
  experiment implementation with linux ACP. It has done by a
  collaboration project with an university. It is mainly a prototype that
  has proved the functionalities of ACP.  It is not planned to be open source.
  One more  prototype implementation is still in ongoing process by
  Michael Richardson.

Please see attached information provided by the ACP authors to the
shepherd about experience with one of the existing pre-standard
implementations.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Terry Manderson is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document thorough once for -09 versions (and had
  other minor comments from time to time):
 
  https://www.ietf.org/mail-archive/web/anima/current/msg02979.html 
 
  The issues raised in my reviews were promptly addressed by authors
  in -09 and -10 version along with the comments from other ANIMA WG members. 
  This document -13 version is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Michael H. Behringer, Steinthor Bjarnason and Toerless Eckert
  have confirmed in writing that they are not aware of any IPR, and that any and
  all appropriate IPR disclosures required for full conformance with the provisions
  of BCP 78 and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  https://datatracker.ietf.org/ipr/2407/

  The working group chair, document shephred too, did notify the WG the existing
  of this IPR disclosure multi-times, including the WGLC. No concerns where raised
  that this IPR claim would impact the ability to proceed adopting the mechanisms
  described in this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits free.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this document.
   
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  No. All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA is requested to register the value AN_ACP and SRV.est to the GRASP
  Objectives Names Table in the GRASP Parameter Registry.

  The IANA is requested to create an ACP Parameter Registry with currently one
  registry table: the "ACP Address Type" Table (without quotes). In the "ACP
  Address Type" Table, 2 intial values are assigned for "ACP Zone Addressing
  Sub-Scheme" and "ACP Vlong Addressing Sub-Scheme" (without quotes).

  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

-------------------------------------------------------------------------------------------
Experience with a prototype implementation of GRASP confirms that a
simple interface with the ACP, based on standard UDP and TCP sockets
connected to the network interfaces provided by the ACP VRF, is necessary and sufficient.

The following information about use and deployment experience of the ACP
design was provided to the shepherd by the ACP authors:

The ACP specification draws a lot of experience and confidence in the
feasibility and value of the design from commercial implementations of
pre-standard implementations and their deployment.  It also draws experience
from open source implementations and design of components, for example
the SNBI project in OpenDaylight, which also inherits some of the work done
for one of the commercial implementations.

One series of commercial implementations specifically supports all the core aspects
of the ACP such as auto-configuration of the ACP as a separate VRF
protected from operator configuration, relying on a bootstrap provisioned domain
certificate to provide mutual authentication and authorization and domain name
derived ULA addressing for the ACP node itself. Also the RPL routing protocol
and its profile, and connectivity to non-ACP components via ACP connect interfaces.

Several aspects of the ACP did evolve from improving upon these pre-standard
experiences. This includes primarily the use of GRASP for neighbor discovery and
service/objective discovery across the ACP as opposed to a vendor proprietary
protocol and multi-hop DNS-SD inside the ACP. The GRASP and ACP authors think that
the choice of GRASP provides simplification, generalization and better mechanisms
for flooding densely used service information. This was backed by experiences with
GRASP  reference implementations, also open source (see also shepherd writeup for GRASP).

The described certificate management for the ACP including the concept of registrar
likewise is based on implementation and large-scale ACP planning with customers and
their CA infrastructure (often up to three layers).  Commercial implementations used
where relying on the older SCEP enrollment protocol instead of the IETF standard EST
(RFC7030) chosen for ACP certificate renewal.

Some enhancements over commercially available implementations where introduced
through the WG work, review and requirements raised. This includes address
auto-configuration of ACP interfaces, better structured/extensible encoding of
ACP attributes into the domain certificate and more addressing choices for the
ACP to better support various use-cases (large networks with multiple zones...
networks with ACP nodes that require many addresses inside the ACP).

[Ballot comment]
Moving back to No Record as an intermediate state, to note that the
issues in the Discuss position I filed on the -19 have all been resolved.
(My review of the -27 remains in progress.)

Thank you for the extensive efforts you put in to respond to the previous
rounds of feedback!  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.

[Ballot discuss]
** As normative behavior is specific for BRSKI (e.g., Section 6.1.5 and 6.1.5.5), please make it a normative reference

** Figure 2’s definition of acp-address is ‘acp-address = 32HEXLC | "0"’.  The following text references a 32HEXDIG but that isn’t in the definition of acp-address.

-- Section 6.1.2.  ‘Nodes complying with this specification MUST be able to receive their ACP address through the domain certificate, in which case their own ACP domain certificate MUST have the 32HEXDIG "acp-address" field.’

-- Section 6.1.3.  ‘The candidate peer certificate's acp-node-name has a non-empty acp-address field (either 32HEXDIG or 0, according to Figure 2).’

** Precision in bounding the cipher selection.

-- Section 6.7.2.  Per “Symmetric encryption for the transmission of secure channel data MUST use encryption schemes considered to be security wise equal to or better than AES256”, which property of AES-256 is being considered for this assessment?

-- Section 6.8.2.  Per “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 256bit AES or less than SHA384”, please state this more precisely.

-- Is it that AES-128 shouldn’t be used or that that AES-256 has a certain key strength to which to adhere to?

-- Is it that SHA-224 or SHA256 shouldn’t be used (staying in the SHA-2 family) or is it a certain number of bits of security ?

** The text specifies the need for physical controls.  Please be more specific on the appropriate degree of that physical control or how that decision should be made; and explicitly explain threat of concern.

-- Section 8.1.1.  “Thus, the ACP connect interface and NOC systems connected to it needs to be physically controlled/secured.”

-- Section 8.1.5.  “… the ACP connect link and the nodes connecting to it must be in a contiguous secure  environment, hence assuming there can be no physical attack against the devices.”

** (“discuss discuss”) Section 8.1.2.  What is the normative behavior being specified in this section?  Specifically, what is the additional or more restrictive behavior for the circumstance is where an ACP node is virtualized.

** Section 8.2.1.  (I’m no ABNF expert …) Per the ABNF in Figure 17, the “//=” notation isn’t valid.  I think you want:

OLD
    method //= [ "DTLS",    port ]

NEW
    method =/ [ "DTLS",    port ]

** Section 10.2.1.  Per “An attacker will not be able to join the ACP unless having a valid domain certificate, also packet injection and sniffing traffic will not be possible due to the security provided by the encryption protocol.”, please be clearer:

-- on path attacker = no packet injection
-- on path attacker = only traffic analysis when sniffing
-- compromised node = can inject traffic

** Section 11.  Per “an ACP is self-protecting and there is no need to apply configuration to make it secure”, if this assertion is going to be made:

-- please specify the security services/properties in a normative section (not in the informative text in Section 10).

-- please also be clear on what configuration is being referenced.

** Section 11.  Per the list of factors on which ACP depends, it seems like the following are missing:

-- the security properties of the enrollment protocol

-- that the security considerations of EST and BRSKI apply (or if not, why not)

[Ballot discuss]
** As normative behavior is specific for BRSKI (e.g., Section 6.1.5 and 6.1.5.5), please make it a normative reference

** Figure 2’s definition of acp-address is ‘acp-address = 32HEXLC | "0"’.  The following text references a 32HEXDIG but that isn’t in the definition of acp-address.

-- Section 6.1.2.  ‘Nodes complying with this specification MUST be able to receive their ACP address through the domain certificate, in which case their own ACP domain certificate MUST have the 32HEXDIG "acp-address" field.’

-- Section 6.1.3.  ‘The candidate peer certificate's acp-node-name has a non-empty acp-address field (either 32HEXDIG or 0, according to Figure 2).’

** Precision in bounding the cipher selection.

-- Section 6.7.2.  Per “Symmetric encryption for the transmission of secure channel data MUST use encryption schemes considered to be security wise equal to or better than AES256”, which property of AES-256 is being considered for this assessment?

-- Section 6.8.2.  Per “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 256bit AES or less than SHA384”, please state this more precisely.

-- Is it that AES-128 shouldn’t be used or that that AES-256 has a certain key strength to which to adhere to?

-- Is it that SHA-224 or SHA256 shouldn’t be used (staying in the SHA-2 family) or is it a certain number of bits of security ?

** The text specifies the need for physical controls.  Please be more specific on the appropriate degree of that physical control or how that decision should be made; and explicitly explain threat of concern.

-- Section 8.1.1.  “Thus, the ACP connect interface and NOC systems connected to it needs to be physically controlled/secured.”

-- Section 8.1.5.  “… the ACP connect link and the nodes connecting to it must be in a contiguous secure  environment, hence assuming there can be no physical attack against the devices.”

** (“discuss discuss”) Section 8.1.2.  What is the normative behavior being specified in this section?  Specifically, what is the additional or more restrictive behavior for the circumstance is where an ACP node is virtualized.

** Section 8.2.1.  (I’m no ABNF expert …) Per the ABNF in Figure 17, the “//=” notation isn’t valid.  I think you want:
OLD
    method //= [ "DTLS",    port ]

NEW
    method =/ [ "DTLS",    port ]

** Section 10.2.1.  Per “An attacker will not be able to join the ACP unless having a valid domain certificate, also packet injection and sniffing traffic will not be possible due to the security provided by the encryption protocol.”, please be clearer:

-- on path attacker = no packet injection
-- on path attacker = only traffic analysis when sniffing
-- compromised node = can inject traffic

** Section 11.  Per “an ACP is self-protecting and there is no need to apply configuration to make it secure”, if this assertion is going to be made:

-- please specify the security services/properties in a normative section (not in the informative text in Section 10).

-- please also be clear on what configuration is being referenced.

** Section 11.  Per the list of factors on which ACP depends, it seems like the following are missing:

-- the security properties of the enrollment protocol

-- that the security considerations of EST and BRSKI apply (or if not, why not)

[Ballot comment]
(Preliminary ballot.  Need to double check that all of ekr's discusses were cleared)

The style of explaining the design choice after describing an element of the protocol was informative and helpful.  Thanks.

The this document has undergone a significant amount of security review.  Thank you for incorporating all of this feedback.

** Section 6.  It doesn’t seem appropriate to call a protocol “indestructible” unless you are going to enumerate the resiliency properties more precisely – “many inadvertent changes” is vague.

** Section 6.  Per “An ACP node can be … or any other IP a capable node”, should this be “IPv6 capable node”?

** Section 6.1.1.  Per “… it is beneficial to copy the device identifying fields of the node's IDevID certificate into the ACP domain certificate …”, is there a ACP-recommended approach for that?

** Section 6.1.3.1. Per “In the absence of implementing a secured mechanism, such an ACP node MAY use a current time learned in an insecured fashion in the ACP domain membership check.”, please be clearer on how this current time is learned in the domain membership check.

** Section 6.1.5.  Per “ACP nodes SHOULD be able to remember the IPv6 locator parameters ...”, what happens if they don’t remember?

** Section 6.1.5.3.  Per “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 …”, why is this not a MUST?

** Section 6.1.5.5.  Per “An ACP node may determine that its ACP domain certificate has expired … [i]n this case, the ACP node SHOULD convert to a role of a re-enrolling candidate ACP node”, what is the alternative if it wants to connect back to the network?  Shouldn’t this be a MUST?

** Section 6.5.  It seems misplaced to describe MacSec as an option for channel security even when it is not a profiled in this document.

** Section 6.7.2. Per “Signaling of TA certificates may not be appropriate when the deployment is relying on a security model when the TA certificate content is considered confidential”, where is the requirement to signal TA certificates discussed.  How would this selection of signaling a TA work?  The entire paragraph prior seemed to explicitly discuss that the TA doesn’t need to be shared.

** Section 6.7.2.  Per “When introducing the profile for security association protocol …”, I recommend being clearer to whom you are providing this advice.  This seems to for operators of ACP infrastructure technology (not implementers/vendors of ACP technology)

** Section 6.7.3.  Per “The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set of options of the current standards-track usage guidance for IPsec    [RFC8221] and IKEv2 [RFC8247]”, should there be normative wording use (MUST) instead of a “mandates”?

** Section 6.7.3.1.1.  Per ENCR_CHACHA20_POLY1305, “[t]herefore this algorithm is only recommended”, shouldn’t it read as RECOMMENDED?

** Section 6.7.3.1.2.  Per “[RFC8247] provides a baseline recommendation for mandatory to  implement ciphers, integrity checks, pseudo-random-functions and Diffie-Hellman mechanisms.  Those recommendations, and the recommendations of subsequent documents apply well to the ACP.”, it seems like normative language should be used to adhered to.

** Section 6.10.7.3.  The paragraph/sentence starting with “ACP registrars that are aware of can use …” doesn’t parse.  The guidance isn’t clear as a result.

** Section 6.10.7.3.  Per “In a simple allocation scheme, an ACP registrar remembers persistently across reboots …”, what’s the recover step if it loses that state?

** Section 6.11.1.1.2.  Not clear what “DODAG Information Objects (DIOs) SHOULD be sent 2 .. 3 times” means – can “2 .. 3” please be clarified.

** Section 6.11.1.1.2.  A mechanism for failed ACP detected using a secure channel protocol is noted for IPSec (with IKEv2 Dead Peer Detection).  What is the equivalent for DTLS?

** Section 9.  The section notes that Section 9.1 is “derived from diagnostic of a commercially available ACP implementation”.  The shepherd report from 03/2019 notes that there are no implementations of ACP.  If this is documented somewhere, it would be very compelling to cite it.

** Section 9.1. Per “The basic diagnostics [sic] is support of (yang) data models representing the complete (auto-)configuration and operational state of all components …”, are these YANG models defined?  Are there references?

** Section 9.3.1.  Per “Whenever this document refers to enabling an interface for ACP … it only requires to permit [sic] the interface …”, this seems like normative behavior in an informative section.

** Section 9.3.2.  That this is an information section is noted.  It would benefit from describing what precisely can and cannot be done in the three states proposed – up, down and admin down.

** Section 9.3.2.1.  What is the proposed threat that using admin down is intended to mitigate?  Under what circumstance should it be invoked?

** Section 9.3.2.1.  Per ‘"Admin down" state as described above provides also a high level of security because it only permits ACP/ANI operations which are both well secured”, to what is the “both” referring? I suspect this is editorial (but just in case, noting here).

** Section 10.2.2.  Per “For example, management plane functions (transport ports) should only be reachable from the ACP but not the Data-Plane”, this seems like good guidance.  Is there a reason not to
upgrade this informative statement and put it the Security Considerations as normative guidance?

** Section 10.2.2.  Per “Protection across all potential attack vectors is typically easier to do in devices whose software is designed from the ground up with security in mind than with legacy software based systems where the ACP is added on as another feature”, no argument on the general principle.  However, as it relates to ACP:

--what’s an example of the legacy software?

-- as noted in the shepherd report from 03/2019, there are no implementations, so is there reason to believe that this is going to put on “legacy” platforms?

** Section 10.2.2.  Per “As explained above, traffic across the ACP SHOULD still …”, is RFC2119 language really intended in this informative section?

** Section 11.  Per “Security can be compromised by implementation errors (bugs), as in all products”, given the generic nature of this statement, couldn’t it also be a configuration error in the product too?

** Section 11.  Per “Higher layer service built using ACP domain certificates should not rely on undifferentiated group security …” is there a reason not to make this a normative SHOULD?

** Editorial

-- Recommend being consistent on either “ACP domain certificates” or “ACP certificates”

-- Section 1.  Editorially.  The two sentences “Section 7 defines normative how to …” and “Section 8 explain normative how …” don’t parse as the adjective normative needs a noun to modify.

-- Section 6.1.4.  Editorial.  s/These requirements can be achieved by using TA private/These requirements can be achieved by using a TA private/

-- Section 6.2.  Editorial. s/does intentionally not/intentionally does not/

-- Section 6.5.  Editorial.  Per “Note that MacSec is not required by any profiles of the ACP in this specification but just mentioned as a likely next interesting secure channel protocol.”, does not parse.

-- Section 6.10.7.  Per “ACP registrars are responsible to enroll candidate ACP nodes with ACP domain certificates and associated trust point(s)”, is a trust point the same thing as a trust anchor?    If so, I recommend being consistent.  If not, then please define it.

-- Section 6.11.1.  Please make draft-ietf-roll-applicability-template a reference.

-- Section 6.11.1.5.  Editorially.  It might be worth framing the path metric in the form of sentence.

-- Section 11. s/enemy plegdes/rogue pledges/

-- Section 11. Per “Fundamentally, security depends on avoid operator and network automation mistakes …”, this paragraph is not actionable.  Recommend removal.

** Typos
Section 1.  Typo. s/parth/path/
Section 1.  Typo. s/seperately/separately/
Section 1.  Typo. s/automaticically/ automatically/
Section 1.  Typo. s/managemenet/ management/
Section 1.  Typo. s/absene/absence/
Section 1.1.  Typo. s/solution:/solution/
Section 2.  Typo. s/netork/network/
Section 2.  Typo. s/physcially/physically/
Section 5.  Typo. s/(see (see/(see/
Section 5. Typo. s/loopack/loopback/
Section 6.1.1.  Typo. s/e.g.:signing/e.g., signing/
Section 6.1.1.  Typo. s/signalled/signaled/g
Section 6.1.1.  Typo. s/bei/by/
Section 6.1.2.  Typo. s/simpy/simply/
Section 6.1.2.  Typo. s/readible/readable/
Section 6.1.2.  Typo. s/Adresses/Addresses/
Section 6.1.2.  Typo. s/manadatory/mandatory/
Section 6.1.2. Typo. s/inapproprite/inappropriate/
Section 6.1.3.1.  Typo. s/as as/as/
Section 6.1.3.1.  Typo. /insecured/insecure/
Section 6.1.3.1.  Typo. s/likley/likely/
Section 6.2. Typo. s/IKEv2 has am/IKEv2 has an/
Section 6.7.2.  Typo. s/successfull/successful/
Section 6.7.3.1.1.  Typo.  s/superceed/superseded/
(I stopped documenting spelling errors at Section 6.7.3.1.1.  Please run a spell checker before handing this off to the RFC Editor)

[Ballot comment]
Thanks to the authors and the ANIMA WG and the numerous reviewers for this document.

After my own review late 2019, I think that the document is ready to be published.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-anima-autonomic-control-plane-24. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the GRASP Objective Names registry on the GeneRic Autonomic Signaling Protocol (GRASP) Parameters registry page located at:

https://www.iana.org/assignments/grasp-parameters/

two new registrations are to be made as follows:

Objective Name Reference
-----------------------+----------------------------
AN_ACP [ RFC-to-be; Section 6.3 ]
SRV.est [ RFC-to-be; Section 6.1.5 ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the ACP Address Type registry. The new registry is to be created on a new registry page on the IANA Matrix called the ACP Parameter Registry. This will be the first registry on the new registry page.

Values in the table are numbers between 0 and 3 inclusive, combined with a string. The registry is to be maintained via Standards Action as defined in RFC8126.

IANA Question --> IANA has a question about the initial registrations provided in Section 12 of [ RFC-to-be ]. Are there two or three initial registrations? What does the reference "ACP RFC" refer to? Could the authors provide a sample of how the registry would be laid out?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-04-21):

From: The IESG
To: IETF-Announce
CC: Sheng Jiang , jiangsheng@huawei.com, anima@ietf.org, evyncke@cisco.com, anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (An Autonomic Control Plane (ACP)) to Proposed Standard


The IESG has received a request from the Autonomic Networking Integrated
Model and Approach WG (anima) to consider the following document: - 'An
Autonomic Control Plane (ACP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-04-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Autonomic functions need a control plane to communicate, which
  depends on some addressing and routing.  This Autonomic Control Plane
  should ideally be self-managing, and as independent as possible of
  configuration.  This document defines such a plane and calls it the
  "Autonomic Control Plane", with the primary use as a control plane
  for autonomic functions.  It also serves as a "virtual out-of-band
  channel" for Operations, Administration and Management (OAM)
  communications over a network that provides automatically configured
  hop-by-hop authenticated and encrypted communications via
  automatically configured IPv6 even when the network is not
  configured, or misconfigured.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2407/

The previous IETF Last Call on this document was in February 2018 for revision -13. Since then, the authors have made substantive changes in the documents and we are now at revision -24. The authors and myself believe that the document is ready for IESG evaluation but I consider that the amount of changes require a new IETF Last Call.

Thank you for the review

-éric vyncke

[Ballot comment]
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  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.

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

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

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

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

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

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

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

Section 1

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

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

Section 2

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

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

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

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

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

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

Section 5

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

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

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

Section 6

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

Section 6.1

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

nit: comma splice

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

nit: comma splice

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

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

Section 6.1.1

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

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

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

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

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

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

and just pack that into an OCTET STRING.

Is the 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"

Document Writeup, template from IESG area on ietf.org, dated January 19, 2017.

draft-ietf-anima-autonomic-control-plane-13 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Standards Track. The document defines a so-call "Autonomic Control Plane",
  with the primary use as a control plane for autonomic functions. It is
  self-managing and zero configuration for basic scenarios.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document defines a so-call "Autonomic Control Plane",  with the primary
  use as a control plane for autonomic functions. It is  self-managing and zero
  configuration for basic scenarios.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-behringer-anima-autonomic-control-plane  prior
  to its adoption. There was unanimous support for it in favor of adoption and
  none against, so this document was adopted in August 2015. There was
  interest in this work posts since its adoption. There was never any
  opposition for this work.

  This document went through a relevant long document development
  period (10 months for individual document period, 29 month for WG
  document period). It has been reviewed well.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by multiple participants.
  So far, there is no existing implementations, but see attached information
  provided by the ACP authors to the shepherd about experience with
  existing pre-standard implementations.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Terry Manderson is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document thorough once for -09 versions (and had
  other minor comments from time to time):
 
  https://www.ietf.org/mail-archive/web/anima/current/msg02979.html 
 
  The issues raised in my reviews were promptly addressed by authors
  in -09 and -10 version along with the comments from other ANIMA WG members. 
  This document -13 version is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Michael H. Behringer, Steinthor Bjarnason and Toerless Eckert
  have confirmed in writing that they are not aware of any IPR, and that any and
  all appropriate IPR disclosures required for full conformance with the provisions
  of BCP 78 and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  https://datatracker.ietf.org/ipr/2407/

  The working group chair, document shephred too, did notify the WG the existing
  of this IPR disclosure multi-times, including the WGLC. No concerns where raised
  that this IPR claim would impact the ability to proceed adopting the mechanisms
  described in this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits free.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this document.
   
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  No. All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA is requested to register the value AN_ACP and SRV.est to the GRASP
  Objectives Names Table in the GRASP Parameter Registry.

  The IANA is requested to create an ACP Parameter Registry with currently one
  registry table: the "ACP Address Type" Table (without quotes). In the "ACP
  Address Type" Table, 2 intial values are assigned for "ACP Zone Addressing
  Sub-Scheme" and "ACP Vlong Addressing Sub-Scheme" (without quotes).

  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

-------------------------------------------------------------------------------------------
Experience with a prototype implementation of GRASP confirms that a
simple interface with the ACP, based on standard UDP and TCP sockets
connected to the network interfaces provided by the ACP VRF, is necessary and sufficient.

The following information about use and deployment experience of the ACP
design was provided to the shepherd by the ACP authors:

The ACP specification draws a lot of experience and confidence in the
feasibility and value of the design from commercial implementations of
pre-standard implementations and their deployment.  It also draws experience
from open source implementations and design of components, for example
the SNBI project in OpenDaylight, which also inherits some of the work done
for one of the commercial implementations.

One series of commercial implementations specifically supports all the core aspects
of the ACP such as auto-configuration of the ACP as a separate VRF
protected from operator configuration, relying on a bootstrap provisioned domain
certificate to provide mutual authentication and authorization and domain name
derived ULA addressing for the ACP node itself. Also the RPL routing protocol
and its profile, and connectivity to non-ACP components via ACP connect interfaces.

Several aspects of the ACP did evolve from improving upon these pre-standard
experiences. This includes primarily the use of GRASP for neighbor discovery and
service/objective discovery across the ACP as opposed to a vendor proprietary
protocol and multi-hop DNS-SD inside the ACP. The GRASP and ACP authors think that
the choice of GRASP provides simplification, generalization and better mechanisms
for flooding densely used service information. This was backed by experiences with
GRASP  reference implementations, also open source (see also shepherd writeup for GRASP).

The described certificate management for the ACP including the concept of registrar
likewise is based on implementation and large-scale ACP planning with customers and
their CA infrastructure (often up to three layers).  Commercial implementations used
where relying on the older SCEP enrollment protocol instead of the IETF standard EST
(RFC7030) chosen for ACP certificate renewal.

Some enhancements over commercially available implementations where introduced
through the WG work, review and requirements raised. This includes address
auto-configuration of ACP interfaces, better structured/extensible encoding of
ACP attributes into the domain certificate and more addressing choices for the
ACP to better support various use-cases (large networks with multiple zones...
networks with ACP nodes that require many addresses inside the ACP).

Document Writeup, template from IESG area on ietf.org, dated January 19, 2017.

draft-ietf-anima-autonomic-control-plane-13 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Standards Track. The document defines a so-call "Autonomic Control Plane",
  with the primary use as a control plane for autonomic functions. It is
  self-managing and zero configuration for basic scenarios.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document defines a so-call "Autonomic Control Plane",  with the primary
  use as a control plane for autonomic functions. It is  self-managing and zero
  configuration for basic scenarios.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-behringer-anima-autonomic-control-plane  prior
  to its adoption. There was unanimous support for it in favor of adoption and
  none against, so this document was adopted in August 2015. There was
  interest in this work posts since its adoption. There was never any
  opposition for this work.

  This document went through a relevant long document development
  period (10 months for individual document period, 29 month for WG
  document period). It has been reviewed well.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by multiple participants.
  So far, there is no existing implementations, but see attached information
  provided by the ACP authors to the shepherd about experience with
  existing pre-standard implementations.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Terry Manderson is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document thorough once for -09 versions (and had
  other minor comments from time to time):
 
  https://www.ietf.org/mail-archive/web/anima/current/msg02979.html 
 
  The issues raised in my reviews were promptly addressed by authors
  in -09 and -10 version along with the comments from other ANIMA WG members. 
  This document -13 version is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Michael H. Behringer, Steinthor Bjarnason and Toerless Eckert
  have confirmed in writing that they are not aware of any IPR, and that any and
  all appropriate IPR disclosures required for full conformance with the provisions
  of BCP 78 and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  https://datatracker.ietf.org/ipr/2407/

  The working group chair, document shephred too, did notify the WG the existing
  of this IPR disclosure multi-times, including the WGLC. No concerns where raised
  that this IPR claim would impact the ability to proceed adopting the mechanisms
  described in this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits free.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this document.
   
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  No. All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA is requested to register the value AN_ACP and SRV.est to the GRASP
  Objectives Names Table in the GRASP Parameter Registry.

  The IANA is requested to create an ACP Parameter Registry with currently one
  registry table: the "ACP Address Type" Table (without quotes). In the "ACP
  Address Type" Table, 2 intial values are assigned for "ACP Zone Addressing
  Sub-Scheme" and "ACP Vlong Addressing Sub-Scheme" (without quotes).

  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

-------------------------------------------------------------------------------------------
The following information about use and deployment experience of the ACP
design was provided to the shepherd by the ACP authors:

The ACP specification draws a lot of experience and confidence in the
feasibility and value of the design from commercial implementations of
pre-standard implementations and their deployment.  It also draws experience
from open source implementations and design of components, for example
the SNBI project in OpenDaylight, which also inherits some of the work done
for one of the commercial implementations.

One series of commercial implementations specifically supports all the core aspects
of the ACP such as auto-configuration of the ACP as a separate VRF
protected from operator configuration, relying on a bootstrap provisioned domain
certificate to provide mutual authentication and authorization and domain name
derived ULA addressing for the ACP node itself. Also the RPL routing protocol
and its profile, and connectivity to non-ACP components via ACP connect interfaces.

Several aspects of the ACP did evolve from improving upon these pre-standard
experiences. This includes primarily the use of GRASP for neighbor discovery and
service/objective discovery across the ACP as opposed to a vendor proprietary
protocol and multi-hop DNS-SD inside the ACP. The GRASP and ACP authors think that
the choice of GRASP provides simplification, generalization and better mechanisms
for flooding densely used service information. This was backed by experiences with
GRASP  reference implementations, also open source (see also shepherd writeup for GRASP).

The described certificate management for the ACP including the concept of registrar
likewise is based on implementation and large-scale ACP planning with customers and
their CA infrastructure (often up to three layers).  Commercial implementations used
where relying on the older SCEP enrollment protocol instead of the IETF standard EST
(RFC7030) chosen for ACP certificate renewal.

Some enhancements over commercially available implementations where introduced
through the WG work, review and requirements raised. This includes address
auto-configuration of ACP interfaces, better structured/extensible encoding of
ACP attributes into the domain certificate and more addressing choices for the
ACP to better support various use-cases (large networks with multiple zones...
networks with ACP nodes that require many addresses inside the ACP).

[Ballot comment]
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.

[Ballot discuss]
This is a really exciting protocol to read about -- the prospect of
dropping a bunch of just-manufactured devices in place, spinning up a
registrar (and maybe a MASA), and getting a control plane like magic is
pretty impressive.  That said, I don't believe that this document is ready
to publish as-is.  I have a list of specific points below for discussion,
but it may be more effective to strip down the document a lot (providing a
well-defined core protocol and leaving out speculative future work, along
the lines of Alissa's comments) and only then start to work on specific
rough spots.

In particular, in its current form, it's not clear to me why this document
is targeting the standards-track -- there are lots of places where
determinations of what works best or how to do some things is left for
future work.  Are there lots of implementations or consumers clamoring for
this stuff that it makes sense to go for PS as opposed to Experimental (so
as to figure out what works and nail down a slimmer protocol for the
standards track)?  I see in A.4 that the choice of RPL was motivated by
experience with a pre-standard version of ACP; it would have been great to
hear more about those deployments in an Implementation Status section (per
RFC 7942) or the Shepherd writeup.

I also think the document needs to be more clear about what security
properties it does or does not intend to provide: we hear in the abstract
and introduction that ACP will be "secure" (and similar platitudes are
repeated throughout), but we don't really get a sense of the specifics
until Section 4, with ACP5.  This has a MUST for authenticated and "SHOULD
(very strong SHOULD)" be encrypted.  But text elsewhere in the document
seems to be using "secure" to also mean encrypted, and there is even one
place that flatly asserts that "ACP mandates the use of encryption".  This
internal inconsistency needs to be resolved, at a minimum, and ideally the
intended posture more clearly conveyed.  (It's also not really stated under
what cases encryption would not be used, so that the "very strong SHOULD"
could not be a MUST.)

Section 3.2 claims that the ACP provides "additional security" for
bootstrap mechanisms due to the hop-by-hop encryption.  But in what sense
is actual additional security gained?  Against an attacker with what
capabilities?  If there is security gain from such hop-by-hop encryption,
doesn't that point to a weakness in the bootstrap scheme?

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.

The requirement in Section 6.1.2 for CRL and OCSP checks seem impossible to
satisfy for a greenfield node without non-ACP connectivity, as it must join
the ACP domain (and supposedly validate the CRL and OCSP validity before
doing so) before establishing an ACP link with its peer, but cannot
validate anything with no connectivity.

Throughout, the document seems to implicitly conflate authentication with
authorization.  I understand that the main authorization check is just the
domain membership test in Section 6.1.2; nonetheless, as a pedagogical
matter I cannot support propagating their conflation.

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?

The IANA considerations specifically do register SRV.est in the GRASP
Objective Names Table, and then follows up with a paragraph that this is
only a "proposed update".  I don't know if there's actually anything
problematic here, but the document does need clarity on what is proposed
for future work and what is to be done now.

[Ballot comment]
Some high-level comments that do not quite meet DISCUSS criteria appear
below, followed by section-by-section inline comments.  My apologies for
not splitting them between substantive and editorial, but I don't think I
have enough time left before the telechat to do that and finish the other
reviews I have remaining.

The whole premise of the ACP is for it to be almost entirely autonomic and not
require external configuration.  But some pieces/functionality do require
explicit configuration (e.g., manual ACP addresses, configured remote ACP
neighbors, etc.), so I would have liked to see a section discussing what
sort of interface might be used to inject manual configuration into the
otherwise autonomic system.  Would this be done using ACP control messages
from an NMS using an ACP connect node, or an out-of-band (serial)
management port, or something else?

I think the document needs to be more clear about its stance towards
constrained nodes: DTLS is supported (along with IKEv2+IPSEC), supposedly
for the benefit of constrained nodes, but then the more heavyweight TLS is
required for several operations within the ACP itself.

Section 1

  of the ACP (after all the details have been defined), Section 10
  provides operational recommendations, Appendix A provides additional
  explanations and describes additional details or future work
  possibilities that where considered not to be appropriate for

nit: s/where/were/

  [...] The ACP can
  be implemented and operated without any other components of autonomic
  networks, except for the GRASP protocol which it leverages.

This could probably benefit from being disambiguated between the single
ACP-wide GRASP instance and the DULL GRASP used for link-local
flooding/discovery.

Section 1.1

  [...] The ACP can operate equally on
  layer 3 equipment and on layer 2 equipment such a bridges (see
  Section 7).  The encryption mechanism used by the ACP is defined to

nit: such as

  be negotiable, therefore it can be extended to environments with
  different encryption protocol preferences.  The minimum
  implementation requirements in this document attempt to achieve
  maximum interoperability by requiring support for few options: IPsec,
  DTLS - depending on type of device.

nit: This last sentence could be reworded for clarity, "[...] requiring
support for multiple options (IPsec and DTLS), depending on the type of
device."


Section 2

  ACP address:  An IPv6 address assigned to the ACP node.  It is stored
      in the domain information field of the ->"ACP domain certificate"
      ().

nit: The "->" and "()" seem like artifacts from an editor also usable for
source code?  ("->" also appears in "ACP domain"'s definition, and both
appear in the "in band (managemnet) definition and the "(virtual)
out-of-band network" definition.)

  EST:  "Enrollment over Secure Transport" ([RFC7030]).  IETF standard
      protocol for enrollment of a node with an LDevID.  BRSKI is based
      on EST.

RFC 7030 is only Proposed Standard, so "standards-track protocol"
seems more appropriate.

  (virtual) out-of-band network:  An out-of-band network is a secondary
      network used to manage a primary network.  The equipment of the
      primary network is connected to the out-of-band network via
      dedicated management ports on the primary network equipment.
      Serial (console) management ports where historically most common,

nit: s/where/were/

Please use the actual RFC 8174 instead of attempting to reproduce (but not
exactly) its updated boilerplate.

Section 4

  ACP4:  The ACP MUST be generic.  Usable by all the functions and
          protocols of the ANI.  Clients of the ACP MUST NOT be tied to
          a particular application or transport protocol.

nit: The second sentence is only a sentence fragment.

  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.

authenticated as coming from a trusted node, or authenticated to be
from a specific node, which is known to be trusted?
Also, maybe "MUST, except for [...]" is better than "very strong
SHOULD".  (What are the execptional cases where plaintext is allowed?)
Integrity protection of authenticated traffic may be worth mentioning
explicitly.

  Th eACP operates hop-by-hop, because this interaction can be built on

nit: s/Th eACP/The ACP/

Section 5

  3.  For each node in the candidate peer list, it authenticates that
      node and negotiates a mutually acceptable channel type.

There seems to be an implicit step in here, "confirms that the node is
authorized to be a part of the same ACP domain".  Presumably this is usally
the "ACP domain membership check" of Section 6.1.2; a forward reference
seems in order.


Section 6.1.1

It's slightly jarring to use ABNF to specify the contents of an
ASN.1 field.

hex-dig is case-insensitive; is that intended?

"acp-address" seems under-specified and maybe over-constrained, in
that it does not say how to get what digits to put there, and in
that limiting to 32 hex digits may prevent the use of alternative
ACP address schemes in the future, as is suggested as a possibility
in the body text.

  [...] If the operator does not own any FQDN, it should
  choose a string (in FQDN format) that intends to be equally unique

I don't know if it's worth cautioning against making up fake
TLD-equivalents, given how this has bitten people as new TLDs come
online.

I'm not sure that "people implementing our stuff have an easier
time" is a great reason to stuff randomly-shaped stuff into an
existing hole, especially when there's this nice otherName-shaped
hole available right next to it.

  o  The format of the rfc822Name is chosen so that an operator can set
      up a mailbox called  rfcSELF@ that would receive emails
      sent towards the rfc822Name of any node inside a domain.  This is
      possible because in many modern mail systems, components behind a
      "+" character are considered part of a single mailbox.  In other
      words, it is not necessary to set up a separate mailbox for every
      ACP node, but only one for the whole domain.

This is effectively codifying that foo+bar@baz === foo@baz in email
addresses, which perhaps merits some broader discussion (especially in the
context of security issues when different providers disagree about whether
local components of email addresses differing after a '+' are the same or
not!).

Section 6.1.2

  o  The peer's certificate is signed by one of the trust anchors
      associated with the ACP domain certificate.

This seems to preclude having a PKI structure that is common in the web
world, of a highly secure, offline trust anchor that only certifies
intermediate CA certificates, with the intermediates certifying end-entity
certificates.  Perhaps the intention is that the peer's certificate chains
to such a trust anchor?

  o  The peers certificate has a syntactically valid domain information
      field (subjectAltName / rfc822Name)  and the domain name in that
      peers domain information field is the same as in this ACP node
      certificate.

Is this supposed to be an exact byte-for-byte match, or is some form of
insensivity allowed that would require normalization/canonicalization prior
to comparison?


Section 6.1.3

I had noted (in my local notes) on the -13 that using the ACP address and
only storing one EST server makes for a single point of failure; the
situation seems somewhat improved in the -16 in that the remebmered value
is used as the first attempt for renewal, but presumably with GRASP
announcement as a fallback there is less of a single point of failure.

Section 6.1.3.1

Does the example need a comma after 255 to indicate the absent
objective-value?  (Also, putting the example after the CDDL might help the
reader know what they're looking at.)

The "formal CDDL definition" of flood-message seems somewhat
informal at times, e.g,. for loop-count.

Using both "[t]he objective value" and an "objective-value" field for
different things is needlessly confusing; can the body text be clarified
somewhat about the value "SRV.est"?

Can "negligbile traffic" be quantified?

Section 6.1.3.3

  [...] If the CDP URL uses an IPv6 address (ULA address when using
  the addressing rules specified in this document), the ACP node will
  connect to the CDP via the ACP.

Seems to be duplicated?

  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

Presumably only if the CDP URL listed an IPv6 address.
(Also, nit: full stop at end of sentence.)

Section 6.1.3.4

A reference to draft-ietf-acme-star and/or draft-nir-saag-star might be
useful to inform the reader of related work.  (Note that the latter was not
adopted by the LAMPS WG yet, with the indication that some changes were
needed before it would be appropriate for adoption.)


Section 6.2

  [...] An ACP node MUST
  maintain this adjacency table up to date.

Up to date on what timescale?

  The adjacency table MAY contain information about the validity and
  trust of the adjacent ACP node's certificate.  However, subsequent
  steps MUST always start with authenticating the peer.

Also verifying that it is authorized for the operation in question?

Section 6.3

  The result of the discovery is the IPv6 link-local address of the
  neighbor as well as its supported secure channel protocols (and non-
  standard port they are running on).  It is stored in the ACP
  Adjacency Table, see Section 6.2 which then drives the further
  building of the ACP to that neighbor.

nit: "see section 6.2" is probably better in parentheses, but if commas
are used, they need to be both before and after it.

Section 6.4

  o  Build the ACP across all domains that have a common parent domain.
      For example ACP nodes with domain "example.com", nodes of
      "example.com", "access.example.com", "core.example.com" and
      "city.core.example.com" could all establish one single ACP.

If this wasn't an example it sounds like it'd need to reference the
public suffix list?

Section 6.5

  o  An ACP node may choose to attempt initiate the different feasible

nit: to attempt to initiate

Section 6.6

"Exponential backoff" requires the base of the exponent to be specified in
order to be well-defined.  (An base of, e.g., 1.0000001 is hardly any
backoff at all, over our normal timescales.)

Section 6.7.1.1

  [...] It MUST then
  support ESP with AES256 for encryption and SHA256 hash and MUST NOT
  permit weaker crypto options.

That does not fully specify cryptographic parameters for
communication security, e.g., CTR vs. CBC vs. GCM mode of AES.
(Similarly in Section 6.7.1.2.)

  In terms of IKEv2, this means the initiator will offer to support
  IPsec tunnel mode with next protocol equal 41 (IPv6).

nit: "equal to"

  ESP is used because ACP mandates the use of encryption for ACP secure
  channels.

I thought this was only a "very strong SHOULD", not mandatory.
(Similarly in Section 6.7.1.2.)

Section 6.7.1.2

(Lots of this section duplicates 6.7.1.1 and could be consolidated into
the toplevel 6.7.1.)

  If IKEv2 initiator and responder support GRE, it will be selected.
  The version of GRE to be used must the according to [RFC7676].

nit: the grammar in the last sentence is weird; maybe "must be determined
according to"?

Section 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.

You should specify actual ciphersuite, signature, and hash
algorithms.

Section 6.7.3

I would recommend calling out the "terminate channel when certificate
expires" behavior again in the security considerations, as it would be
surpirsing to readers expecting the "standard" behavior.

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

nit: s/threefore/therefore/


Section 6.8.2

The figure does not really aid my understanding absent some
additional explanation.

  GRASP unicast messages inside the ACP always use the ACP address.
  Link-local ACP addresses must not be used inside objectives.  GRASP

Link-local *ACP* addresses, or IPv6 ones?

  [...] GRASP
  unicast messages inside the ACP are transported via TLS 1.2
  ([RFC5246]) connections with AES256 encryption and SHA256.

Same comment as before about ciphersuite/etc.  Also, TLS or DTLS (noting
that constrained devices are assumed to only implement DTLS)?
Also, TLS 1.3 is in the RFC Editor's queue; is there work underway
to adapt to it?

  [...] TLS and TLS connections for GRASP in the ACP use the IANA assigned
  TCP port for GRASP (7107).

Is one of those supposed to be DTLS?  Is the IANA-assigned port
assigned for both TCP and UDP?

Section 6.8.2.1

As a side note, I don't mind seeing discussion about potential future work
to avoid the double authentication/encryption, but my intuition is that
it's not really worth pursuing.

Section 6.10.1

  o  Addresses in the ACP are not considered sensitive on privacy
      grounds because ACP nodes are not expected to be end-user devices.

I feel like this claim requires additional justification.

Section 6.10.3.1

  A node knowing it is in a zone MUST also use that Zone-ID != 0
  address in GRASP locator fields. [...]

What does "also" mean here?  Is this another requiment being placed on a
node that knows it is in a zone, or must this node use both the zone-id==0
and the zone-id!=0 addresses in GRASP locator fields (i.e., duplicating all
such)?

Section 6.10.5

  o  V: Virtualization bit: Values 0 and 1 are assigned in the same way
      as in the Zone-ID sub-scheme.

There is not a single 'V bit' -- the V field is either 8 or 16 bits long --
so saying "in the same way" is confusing.  I believe that the intent is to
distinguish between "zero" and "not-zero", with the zero value meaning the
same as the zero bit in the Zone-ID sub-scheme.  That is, the final bit
need not be 1 to indicate a "virtual" usage.  Or do I misunderstand?

Section 6.10.7.3

  In a simple allocation scheme, an ACP registrar remembers
  persistently across reboots for its currently used Registrar-ID and
  for each addressing scheme (zone with Subnet-ID 0, Vlong with /112,
  Vlong with /120), the next Node-Number available for allocation and
  increases it after successful enrollment to an ACP node.  In this
  simple allocation scheme, the ACP registrar would not recycle ACP
  address prefixes from no longer used ACP nodes.

It's probably better to say "increments it during successful enrollment"
since if the registrar crashed right after issuing a certificate but before
incrementing the next available node-number, it would issue a duplicate
when it came back up.

Section 6.10.7.4

  [...] Even when the renewing/rekeying ACP registrar is not
  the same as the one that enrolled the prior ACP certificate.  See
  Section 10.2.4 for an example.  ACP address information SHOULD also
  be maintained even after an ACP certificate did expire or failed.
  See Section 6.1.3.5 and Section 6.1.3.6.

Both the first and the last sentence quoted have grammar nits; the former
is a sentence fragment (perhaps "This holds even when [...]"), and the
second has inconsistent verb tense (perhapse "expired or failed").


Section 6.11

  All routing updates are automatically secured in transit as the
  channels of the autonomic control plane are by default secured, and
  this routing runs only inside the ACP.

Again, I thought encryption was only "very strong SHOULD".
If this "secured" only was intended to refer to authentication (and
presumably implicitly integrity protection), then "by default" is
not needed, since the latter protection is mandatory.

Section 6.11.1.1

  In summary, the profile chosen for RPL is one that expects a fairly
  reliable network reasonably fast links so that RPL convergence will
  be triggered immediately upon recognition of link failure/recovery.

Is there a missing "with" in here, or something else in order to get
it to parse?

  [...] This the same
  behavior as that of other IGPs that do not have the Data-Plane
  options as RPL.

Is this suppposed to be ", as is the case for RPL"?  (Also, "This is"?)

In general, this section has an unclear overall structure/organization and
several instances of strange grammar/wording.  The RFC Editor will be of
some help with the latter, but generally is unwilling to take the
initiative to make the sorts of changes needed to address the former.

Section 6.11.1.7

  Local Repair: As soon as link breakage is detected, send No-Path DAO
  for all the targets that where reachable only via this link.  As soon

nit: s/where/were

Section 6.11.1.9

Please don't treat "security" as some single black-box concept; there are
gradiations within it and different attributes that can be relevant.  For
example, here we would probably say something like "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".  I guess the RPL security bits needed for per-participant
authentication (as opposed to a group key) are not entirely in place yet,
so it's hard to claim that RPL security would do much better than even
hop-by-hop ACP security measures.

Section 6.11.1.12-14

These sections do not match up with the template entries I see in
draft-ietf-roll-applicability-template-09; can you explain the discrepancy?

Section 6.12.5

I'm confused about the "ACP multi-access virtual interface" -- is
this only for the initial "link-local" flooding/discovery?
Otherwise, aren't the ACP secure channels inherently two-party?  I
don't think I understand what the multi-access benefit is, since my
understanding was that RPL was running on top of these link-local
secure channels.

Section 6.12.5

  The ACP virtual interface IPv6 link local address can be derived from
  any appropriate local mechanism such as node local EUI-48 or EUI-64
  ("EUI" stands for "Extended Unique Identifier").  It MUST NOT depend
  on something that is attackable from the Data-Plane such as the IPv6
  link-local address of the underlying physical interface, which can be
  attacked by SLAAC, or parameters of the secure channel encapsulation
  header that may not be protected by the secure channel mechanism.

Is this the same EUI that might be used on the Data-Plane like the MAC
address of the physical interface?

nit: s/Charly/Carol/

Section 7.2

  The description in the previous paragraph was specifically meant to
  illustrate that on hybrid L3/L2 devices that are common in
  enterprise, IoT and broadband aggregation, there is only the GRASP
  packet extraction (by Ethernet address) and GRASP link-local
  multicast per L2-port packet injection that has to consider L2 ports
  at the hardware forwarding level.  The remaining operations are
  purely ACP control plane and setup of secure channels across the L3
  interface.  This hopefully makes support for per-L2 port ACP on those
  hybrid devices easy.

Have you talked to any hardware manufacturers that would be able to remove
the "hopefully" from this statement?

  A generic issue with ACP in L2 switched networks is the interaction
  with the Spanning Tree Protocol.  Ideally, the ACP should be built
  also across ports that are blocked in STP so that the ACP does not
  depend on STP and can continue to run unaffected across STP topology
  changes (where re-convergence can be quite slow).  The above
  described simple implementation options are not sufficient for this.
  Instead they would simply have the ACP run across the active STP
  topology and the ACP would equally be interrupted and re-converge
  with STP changes.

This "Instead" is a little unclear, perhaps "They fail because the ACP
simply runs across the active STP topology [...]"?

Section 8.1.1

  The ACP connect interface must be (auto-)configured with an IPv6
  address prefix.  Is prefix SHOULD be covered by one of the (ULA)
  prefix(es) used in the ACP.  If using non-autonomic configuration, it
  SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4).

I'm confused in what case ACP connect would be used with autonomic
configuration (and thus why the qualification is needed on the SHOULD).
I thought the whole thing was premised on the presence of a NMS that does
not implement ACP.

  In the simple case where the ACP uses only one ULA prefix and all ACP
  connect subnets have prefixes covered by that ULA prefix, NMS hosts
  can rely on [RFC6724]

Please include some exposition on the property being provided instead of
just citing the RFC.

  ACP Edge Nodes MUST only forward IPv6 packets received from an ACP
  connect interface into the ACP that has an IPv6 address from the ACP
  prefix assigned to this interface (sometimes called "RPF filtering").

This sentence is hard to parse as to what the "that has" restriction
applies to.  I think it's supposed to be that you only forward (IPv6 packets
with a source address from the ACP prefix) into the ACP, right?

  To limit the security impact of ACP connect, nodes supporting it
  SHOULD implement a security mechanism to allow configuration/use of
  ACP connect interfaces only on nodes explicitly targeted to be
  deployed with it (such as those physically secure locations like a
  NOC).  For example, the certificate of such node could include an
  extension required to permit configuration of ACP connect interfaces.

I think this would be better as "[...] could include a specific extension,
and that extension would be required to be present in order to permit
configuration [...]".  But who would enforce this requirement -- the ACP
implementation on the node that is compromised?  That does not seem to
provide the desired security property.  This also falls into Alissa's
comment about "future work".

Section 8.2.1

I think you need to include a reference for ABNF.

Section 9.1

      [...] Since the revocation check is only
      done at the establishment of a new security association, existing
      ones are not automatically torn down.  If an immediate disconnect
      is required, existing sessions to a freshly revoked node can be
      re-set.

How would the revoked node's peers know to perform such a re-set?  This
would seem to require some signaling protocol at revocation time.

  After a network partition, a re-merge will just establish the
  previous status, certificates can be renewed, the CRL is available,
  and new nodes can be enrolled everywhere.  Since all nodes use the
  same trust anchor, a re-merge will be smooth.

I believe this document has described schemes where not all nodes use the
same trust anchor [for signing their LDevID], so maybe this should be
"trust anchor(s)" plural?

  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).

Subject to the risk of a 40-bit collision in SHA256!  While not necessarily
a critical flaw at this time, the limitation should probably be mentioned.

Section 9.2.1

I think you need informative references to all the listed protocols that
the ACP could serve as protection for.

% remote attacks are impossible

Remote attacks to DoS by resource consumption the nodes involved would
still work fine, so "impossible" is probably overstating it.

Section 9.2.2

I expected to see something about the importance of being able to detect a
compromised node and revoke its certificate.  Ideally this could be
automated (with the detecting node providing proof of compromise in some
fashion), though the details of that would probably be hard to get right.

Section 9.3

"independent of configuration" is in conflict with the discussion of
configuring ACP connect, configured remote ACP neighbors, etc.

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

  [...] And without additional centralized tracking of
  assigned certificates there is no way to do this - assuming one can
  not retrieve this information from the .

Missing the end of the sentence?

Section 10.2.4

  Or let it expire and not renew it, when the certificate of the sub-CA
  is appropriately short-lived.

This sort of sentiment has been highly controversial in other contexts
(e.g., draft-nir-saag-star).  (Also, that's a sentence fragment.)

  Therefore ACP domain membership for an ACP node enrolled from a
  compromised ACP registrar will fail.

From a compromised *and detected* registrar.

Section 10.3.x

This whole section feels more like a sketch of an idea than a
well-specified model or protocol.  It might be better if spun off into a
separate document, with time spent to produce (e.g.) a YANG module or state
machines for devices in various states.

Section 10.3.5.1

  [...] Automatic enablement of ACP/ANI in networks
  where the operator does not only not want ACP/ANI but where he likely
  never even heard of it could be quite irritating to him.  Especially
  when "down" behavior is changed to "admin down".

The behavior mentioned in this last sentence really ought to be called out
more clearly in the previous section as changing the semantics of existing
administrative controls.

Section 10.3.7

The control names indicated within double quotes are mostly incomplete
references; it seems better to say, e.g., """the "up-if-only" option for
node-level ACP/ANI enablement""".

Section 11

  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.

It seems like there are some higher-level/potentially "external"
configurations needed, including but not limited to: setting up the
registrar, definng the Intent, assigning a ULA to use for the domain,
policy for the CA issuing domain certificates, and any interaction with
external systems that is needed.  (That is, a fully autonomous system would
be totally self-contained, and thereby not of much use to the humans
involved!)

"correct operation" to me usually means "this system is behaving as
expected", but I think the intended usage here is more like "being operated
and managed correctly".  I don't know if I'm enough of an outlier to make
it not worth changing the text.

I would like to see more text about the scope of damage that a compromised
ACP node can do, and suggesting detection/remediation measures.

Section 12

  Note that the objective format "SRV." is intended to be
  used for any  that is an [RFC6335] registered service
  name.  This is a proposed update to the GRASP registry subject to
  future work and only mentioned here for informational purposed to
  explain the unique format of the objective name.

I'm confused about what this is actually trying to say.  It sounds like it
is actually registering SRV.est (in the previous paragraph), but following
that up by saying that this isn't actually a real registered service name
yet, and we're just registering the objective name proactively for future
work?  If so, that does not seem like the correct thing to do.

Section A.2

  [...] This requires only that the BRSKI
  registrar honors expired domain certificates and that the pledge
  first attempts to perform TLS authentication for BRSKI bootstrap with
  its expired domain certificate - and only reverts to its IDevID when
  this fails.

The "first" is unclear -- perhaps "that the pledge attempts to perform TLS
authentication for BRSKI bootstrap using its expired domain certificate
before falling back to attempting to use its IDevID for BRSKI"?

Section A.4

      [...] RPL also has other scalability improvements,
      such as selecting only a subset of peers instead of all possible
      ones, and trickle support for information synchronization.

(But trickle support is not used in the ACP profile of RPL.)

Section A.8

This discussion of reusing preexisting MAC addresses violates the claim
that the ACP-internal addresses are not guessable from the data plane.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
Section 6.10.4:

"The value of the Interface Identifier is left for future definitions."

I don't understand how this is usable without some definition. I.e., if I assign every interface ID in my ACP to be 0, it's not going to work. Could you elaborate about what is expected in this field?

[Ballot comment]
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  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.

[Ballot comment]
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.

[Ballot comment]
Thank you for addressing my DISCUSS concerns so quickly and well.

I've cleared.




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

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
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..".

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-anima-autonomic-control-plane-13. If any part of this review is inaccurate, please let us know.

We understand that this document will require two registry actions.

First, in the GRASP Objective Names registry on the GeneRic Autonomic Signaling Protocol (GRASP) Parameters registry page located at

https://www.iana.org/assignments/grasp-parameters/

two new registrations will be made:

Objective Name: AN_ACP
Reference: [ RFC-to-be ]

Objective Name: SRV.est
Reference: [ RFC-to-be ]

Because GRASP Objective Names is a "Specification Required" registry, as described by RFC 8126, we've asked the designated expert for that registry to review the request. That review should be completed before the document is approved.

Second, we will create the following registry on a new "ACP Parameters" registry page:

Registry Name: ACP Address Type
Registration Procedure: Standards Action
Reference: [ RFC-to-be ]

Type: 0
Name: ACP Zone Addressing Sub-Scheme ([ RFC-to-be ], Figure 4) / ACP Manual Addressing Sub-Scheme
Reference: [ RFC-to-be ], Section 6.10.4

Type: 1 
Name: ACP Vlong Addressing Sub-Scheme
Reference: [ RFC-to-be ],Section 6.10.5

Types: 2-3 
Name: Unassigned

NOTE: If these aren't the exact names you want to see in the registry, please let us know.

The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist