Ballot deferred by Alissa Cooper on 2018-05-22.
Summary: Has 3 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
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?
General: Please address the Gen-ART reviewer's latest round of comments. There are a bunch of places in this document where it seems like there is a tension between specifying a limited set of functionality here and being able to support a wider variety of deployment scenarios. This is noted in Section 1 but I think in general it would be clearer if uses of the term "future" throughout the document could be more surgical as well as more specific about whether they mean "people might deploy this differently in the future" or "standards would need to be developed in the future." I've made a few suggestions about some of these turns of phrase below but would suggest someone do a full edit pass with this in mind because there are a large number of mentions of "future work." Of course there is always more work to do, but every bit of "future work" need not be mentioned in this document, and in cases where it is mentioned I think there should be a specific reason for doing so that bears on people implementing this specification. I don't think this fits in the DISCUSS criteria but for a document that intends to be published on the standards track I would expect it to be crisper about the dividing line between the normative behavior being specified here versus changes or extensions that may or may not be made in the future. "Intent" is used both capitalized and in lower case throughout the document and I'm unclear if this is meant to signify a distinction or not. Section 2: Please remove the -->"..."() notation. Please use the exact boilerplate from RFC 8174, not a variation. It seems like RFC citations should appear for IKEv2 and DTLS upon first use in this section. Otherwise, it seems they are first cited at different future points in the document (Section 6.3 and 6.7, respectively). Section 3.3: "The ACP provides reachability that is independent of the Data-Plane (except for the dependency discussed in Section 6.12.2 which can be removed through future work)," Isn't this kind of a big exception, given that there is meant to be a secure channel between pairs of nodes in the ACP and that developing future encapsulations is non-trivial? It seems like phrasing this the other way around (the ACP is dependent on the Data-Plane for <XYZ> but is otherwise independent of it) would be more accurate. Section 6: "Indestructible" seems like an overstatement. Maybe "resilient" would be more accurate? Section 6.1.1: s/Such methods are subject to future work though./No such methods have been defined at the time of publication of this document./ s/to build ACP channel/to build ACP channels/ s/that intends to be equally unique/that it intends to be equally unique/ ""rsub" is optional; its syntax is defined in this document, but its semantics are for further study. Understanding the benefits of using rsub may depend on the results of future work on enhancing routing for the ACP." What is the point of defining this now when it is unclear if or how it will be used? There are already means for nodes to do error handling, so it seems like defining a new field in the future if/when it is needed would work fine and be cleaner. Appendix A.7 seems to assume some semantics for this field, which makes the way it is specified here even more confusing IMO. "In this specification, the "acp-address" field is REQUIRED, but future variations (see Appendix A.8) may use local information to derive the ACP address. In this case, "acp-address" could be empty. Such a variation would be indicated by an appropriate "extension". If "acp-address" is empty, and "rsub" is empty too, the "local-part" will have the format "rfcSELF + + extension(s)". The two plus characters are necessary so the node can unambiguously parse that both "acp-address" and "rsub" are empty." This seems contradictory. Either "acp-address" is REQUIRED in which case there are no exceptions, or it's not; if it's not, then the expected syntax for cases when it's not present should be specified. Section 6.1.2: s/If the node certificates indicates/If the node certificate indicates/ Section 6.3: It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. Section 6.4: This is a good example of a section where the blurring between the specified behavior and expectations for the future is unhelpful IMO. Why specify the current default and then spend a lot of words (including Appendix A.7) talking about how it will be different in the future? Section 188.8.131.52: 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.
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 184.108.40.206 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.
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@<domain> 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 220.127.116.11 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 18.104.22.168 [...] 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 22.214.171.124 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 126.96.36.199 [...] 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 188.8.131.52.) 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 184.108.40.206.) Section 220.127.116.11 (Lots of this section duplicates 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 [...] 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 220.127.116.11 and Section 18.104.22.168. 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206-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.<service-name>" is intended to be used for any <service-name> 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.
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 220.127.116.11 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 18.104.22.168. > 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 22.214.171.124. > 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.
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 126.96.36.199. > 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 188.8.131.52. > 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 184.108.40.206. > > 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 220.127.116.11. > 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 18.104.22.168. > 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 22.214.171.124. > 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 126.96.36.199. > 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.
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..".
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. §188.8.131.52: "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? §184.108.40.206, 2nd paragraph: "allowing to simplify" is grammatically incorrect. Consider "allowing [something] to simplify" or "allowing the simplification" §220.127.116.11: The first paragraph is hard to parse. Please do not use "/" as a shortcut for a conjunction.
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.
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.
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.
I was involved in this for a while.