An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-30
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-05-07
|
30 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-04-12
|
30 | (System) | RFC Editor state changed to AUTH48 |
2021-02-22
|
30 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2021-01-25
|
30 | (System) | RFC Editor state changed to REF from RFC-EDITOR |
2021-01-25
|
30 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-12-09
|
30 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-11-10
|
30 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-11-10
|
30 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-11-05
|
30 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-11-02
|
30 | (System) | RFC Editor state changed to EDIT |
2020-11-02
|
30 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-11-02
|
30 | (System) | Announcement was received by RFC Editor |
2020-11-02
|
30 | (System) | IANA Action state changed to In Progress |
2020-11-02
|
30 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-11-02
|
30 | Amy Vezza | IESG has approved the document |
2020-11-02
|
30 | Amy Vezza | Closed "Approve" ballot |
2020-11-02
|
30 | Amy Vezza | Ballot approval text was generated |
2020-11-02
|
30 | Amy Vezza | Ballot writeup was changed |
2020-11-02
|
30 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-10-30
|
30 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-30
|
30 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-30.txt |
2020-10-30
|
30 | (System) | New version accepted (logged-in submitter: Toerless Eckert) |
2020-10-30
|
30 | Toerless Eckert | Uploaded new revision |
2020-10-13
|
29 | Éric Vyncke | All DISCUSS points are now cleared but authors want to clean up the text for grammar and typos. |
2020-10-13
|
29 | Éric Vyncke | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2020-10-07
|
29 | Erik Kline | [Ballot comment] Thanks for addressing things! |
2020-10-07
|
29 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to Yes from Discuss |
2020-10-01
|
29 | Benjamin Kaduk | [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 … [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. |
2020-10-01
|
29 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss |
2020-09-18
|
29 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-09-11
|
29 | Barry Leiba | [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 … [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! |
2020-09-11
|
29 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2020-09-11
|
29 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-11
|
29 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-09-11
|
29 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-29.txt |
2020-09-11
|
29 | (System) | New version approved |
2020-09-11
|
29 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , Michael Behringer , anima-chairs@ietf.org, Steinthor Bjarnason |
2020-09-11
|
29 | Toerless Eckert | Uploaded new revision |
2020-08-13
|
28 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-08-13
|
28 | Erik Kline | [Ballot discuss] [ section 2 ] * "It is the approximate IPv6 counterpart of the IPv4 private address ([RFC1918])." I understand … [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? |
2020-08-13
|
28 | Erik Kline | [Ballot comment] [ section 1 ] * "as good as possible" might be "as well as possible", but I'm unsure if I have any … [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). |
2020-08-13
|
28 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2020-08-12
|
28 | Barry Leiba | [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 … [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? |
2020-08-12
|
28 | Barry Leiba | [Ballot comment] We have to use “virtual out-of-band” more often, because “VOOB” is a great acronym. — Section 1 — is therefore intended to … [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? |
2020-08-12
|
28 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2020-08-12
|
28 | Benjamin Kaduk | [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 … [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.) |
2020-08-12
|
28 | Benjamin Kaduk | [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 … [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/? |
2020-08-12
|
28 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Discuss from No Record |
2020-08-12
|
28 | Martin Duke | [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 … [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. |
2020-08-12
|
28 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-08-12
|
28 | Roman Danyliw | [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 … [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? |
2020-08-12
|
28 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2020-08-12
|
28 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-08-12
|
28 | Alvaro Retana | [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 … [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 |
2020-08-12
|
28 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-08-12
|
28 | Barry Leiba | [Ballot discuss] I still have more to review here -- I'm about ⅓ of the way through -- but I wanted to get this in … [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? |
2020-08-12
|
28 | Barry Leiba | [Ballot comment] We have to use “virtual out-of-band” more often, because “VOOB” is a great acronym. — Section 1 — is therefore intended to … [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. |
2020-08-12
|
28 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2020-08-10
|
28 | Roman Danyliw | [Ballot discuss] (pruned down to the remaining issue) ** Section 11. Per the list of factors on which ACP depends, it seems like the following … [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) |
2020-08-10
|
28 | Roman Danyliw | [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 … [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. |
2020-08-10
|
28 | Roman Danyliw | Ballot comment and discuss text updated for Roman Danyliw |
2020-08-10
|
28 | Robert Wilton | [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 … [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 |
2020-08-10
|
28 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-08-03
|
28 | Éric Vyncke | IESG members should have more time to review this time ;-) + revised I-D fixing Roman's DISCUSS points. |
2020-08-03
|
28 | Éric Vyncke | IESG state changed to IESG Evaluation from IESG Evaluation - Defer |
2020-07-30
|
28 | Sheng Jiang | 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 … 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). |
2020-07-29
|
28 | Toerless Eckert | Added to session: IETF-108: anima Thu-1100 |
2020-07-28
|
28 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-07-28
|
28 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-28.txt |
2020-07-28
|
28 | (System) | New version accepted (logged-in submitter: Toerless Eckert) |
2020-07-28
|
28 | Toerless Eckert | Uploaded new revision |
2020-07-22
|
27 | Benjamin Kaduk | [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 … [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. |
2020-07-22
|
27 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Record from Discuss |
2020-07-15
|
27 | Barry Leiba | Telechat date has been changed to 2020-08-13 from 2020-07-16 |
2020-07-15
|
27 | Barry Leiba | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2020-07-14
|
27 | Roman Danyliw | [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 … [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) |
2020-07-14
|
27 | Roman Danyliw | Ballot discuss text updated for Roman Danyliw |
2020-07-14
|
27 | Roman Danyliw | [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 … [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) |
2020-07-14
|
27 | Roman Danyliw | [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 … [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) |
2020-07-14
|
27 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-07-10
|
27 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-07-02
|
27 | Éric Vyncke | [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 … [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. |
2020-07-02
|
27 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2020-07-02
|
27 | Éric Vyncke | Telechat date has been changed to 2020-07-16 from 2018-08-02 |
2020-07-02
|
27 | Éric Vyncke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2020-07-02
|
27 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-27.txt |
2020-07-02
|
27 | (System) | New version approved |
2020-07-02
|
27 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2020-07-02
|
27 | Toerless Eckert | Uploaded new revision |
2020-07-01
|
26 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-01
|
26 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-26.txt |
2020-07-01
|
26 | (System) | New version approved |
2020-07-01
|
26 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Michael Behringer , Toerless Eckert , Steinthor Bjarnason |
2020-07-01
|
26 | Toerless Eckert | Uploaded new revision |
2020-07-01
|
25 | Éric Vyncke | Still need to replace rfc822Name by an alternate choice. Authors and WG have clear understanding on how to address the remaining DISCUSS. |
2020-07-01
|
25 | Éric Vyncke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup |
2020-06-23
|
25 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-06-23
|
25 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-06-23
|
25 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-25.txt |
2020-06-23
|
25 | (System) | New version approved |
2020-06-23
|
25 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Michael Behringer , Steinthor Bjarnason |
2020-06-23
|
25 | Toerless Eckert | Uploaded new revision |
2020-04-24
|
24 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK |
2020-04-21
|
24 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-04-21
|
24 | Sabrina Tanamal | (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 … (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 |
2020-04-21
|
24 | Éric Vyncke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2020-04-21
|
24 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-04-09
|
24 | Joel Halpern | Request for Last Call review by RTGDIR Completed: Not Ready. Reviewer: Joel Halpern. Sent review to list. |
2020-04-08
|
24 | Min Ye | Request for Last Call review by RTGDIR is assigned to Joel Halpern |
2020-04-08
|
24 | Min Ye | Request for Last Call review by RTGDIR is assigned to Joel Halpern |
2020-04-07
|
24 | Alvaro Retana | Requested Last Call review by RTGDIR |
2020-04-07
|
24 | Amy Vezza | 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, … 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/ |
2020-04-07
|
24 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested::AD Followup |
2020-04-07
|
24 | Amy Vezza | Last call announcement was generated |
2020-04-07
|
24 | Éric Vyncke | Last call was requested |
2020-04-07
|
24 | Éric Vyncke | 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 … 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 |
2020-04-07
|
24 | Éric Vyncke | IESG state changed to Last Call Requested::AD Followup from AD Evaluation::AD Followup |
2020-03-09
|
24 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-24.txt |
2020-03-09
|
24 | (System) | New version approved |
2020-03-09
|
24 | (System) | Request for posting confirmation emailed to previous authors: Michael Behringer , Toerless Eckert , Steinthor Bjarnason , anima-chairs@ietf.org |
2020-03-09
|
24 | Toerless Eckert | Uploaded new revision |
2020-03-09
|
23 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-23.txt |
2020-03-09
|
23 | (System) | New version approved |
2020-03-09
|
23 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , Steinthor Bjarnason , anima-chairs@ietf.org, Michael Behringer |
2020-03-09
|
23 | Toerless Eckert | Uploaded new revision |
2020-02-03
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-02-03
|
22 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-22.txt |
2020-02-03
|
22 | (System) | New version approved |
2020-02-03
|
22 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2020-02-03
|
22 | Toerless Eckert | Uploaded new revision |
2020-01-03
|
21 | Éric Vyncke | Off-list comments sent by Eric to the authors |
2020-01-03
|
21 | Éric Vyncke | IESG state changed to AD Evaluation::Revised I-D Needed from IESG Evaluation - Defer::AD Followup |
2019-11-18
|
21 | Sheng Jiang | Added to session: IETF-106: anima Tue-1710 |
2019-11-17
|
21 | Alissa Cooper | Shepherding AD changed to Éric Vyncke |
2019-11-03
|
21 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-21.txt |
2019-11-03
|
21 | (System) | New version accepted (logged-in submitter: Toerless Eckert) |
2019-11-03
|
21 | Toerless Eckert | Uploaded new revision |
2019-08-13
|
20 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Joel Jaeggli was marked no-response |
2019-08-01
|
20 | Alissa Cooper | [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 … [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. |
2019-08-01
|
20 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2019-07-22
|
20 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-20.txt |
2019-07-22
|
20 | (System) | New version approved |
2019-07-22
|
20 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2019-07-22
|
20 | Toerless Eckert | Uploaded new revision |
2019-07-22
|
19 | Sheng Jiang | Removed from session: IETF-105: anima Tue-1330 |
2019-07-21
|
19 | Sheng Jiang | Added to session: IETF-105: anima Tue-1330 |
2019-07-16
|
19 | Benjamin Kaduk | [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 … [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? |
2019-07-16
|
19 | Benjamin Kaduk | [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. … [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" |
2019-07-16
|
19 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-03-27
|
19 | Sheng Jiang | 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 … 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). |
2019-03-26
|
19 | Toerless Eckert | 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 … 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). |
2019-03-25
|
19 | Sheng Jiang | Added to session: IETF-104: anima Tue-1350 |
2019-03-11
|
19 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-19.txt |
2019-03-11
|
19 | (System) | New version approved |
2019-03-11
|
19 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2019-03-11
|
19 | Toerless Eckert | Uploaded new revision |
2018-09-17
|
18 | Pascal Thubert | Request for Early review by IOTDIR Completed: Ready. Reviewer: Pascal Thubert. |
2018-08-07
|
18 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-18.txt |
2018-08-07
|
18 | (System) | New version approved |
2018-08-07
|
18 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2018-08-07
|
18 | Toerless Eckert | Uploaded new revision |
2018-08-07
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-08-07
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-08-07
|
17 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-17.txt |
2018-08-07
|
17 | (System) | New version approved |
2018-08-07
|
17 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2018-08-07
|
17 | Toerless Eckert | Uploaded new revision |
2018-08-02
|
16 | Cindy Morgan | IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer |
2018-08-02
|
16 | Ignas Bagdonas | [Ballot comment] I was involved in this for a while. |
2018-08-02
|
16 | Ignas Bagdonas | [Ballot Position Update] New position, Recuse, has been recorded for Ignas Bagdonas |
2018-08-02
|
16 | Alexey Melnikov | [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 … [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. |
2018-08-02
|
16 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-08-01
|
16 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-08-01
|
16 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-08-01
|
16 | Benjamin Kaduk | [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 … [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. |
2018-08-01
|
16 | Benjamin Kaduk | [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 … [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. |
2018-08-01
|
16 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-08-01
|
16 | Eric Rescorla | [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. … [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. |
2018-08-01
|
16 | Eric Rescorla | [Ballot comment] S 1. > possibilities that where considered not to be appropriate for > standardization in this document but were … [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. |
2018-08-01
|
16 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2018-08-01
|
16 | Ben Campbell | [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 … [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. |
2018-08-01
|
16 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-08-01
|
16 | Alissa Cooper | [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. … [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? |
2018-08-01
|
16 | Alissa Cooper | [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 … [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. |
2018-08-01
|
16 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2018-07-31
|
16 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list. |
2018-07-31
|
16 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-07-22
|
16 | Liang Xia | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Liang Xia. Sent review to list. |
2018-07-19
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Liang Xia |
2018-07-19
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Liang Xia |
2018-07-18
|
16 | Sheng Jiang | Added to session: IETF-102: anima Wed-0930 |
2018-07-17
|
16 | Magnus Westerlund | Closed request for Telechat review by TSVART with state 'Team Will not Review Version' |
2018-07-17
|
16 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Wesley Eddy |
2018-07-17
|
16 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Wesley Eddy |
2018-07-12
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2018-07-12
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2018-07-09
|
16 | Amy Vezza | Placed on agenda for telechat - 2018-08-02 |
2018-06-11
|
16 | Warren Kumari | [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 … [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. |
2018-06-11
|
16 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2018-06-08
|
16 | Warren Kumari | [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, … [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. |
2018-06-08
|
16 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2018-06-08
|
16 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-16.txt |
2018-06-08
|
16 | (System) | New version approved |
2018-06-08
|
16 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2018-06-08
|
16 | Toerless Eckert | Uploaded new revision |
2018-06-06
|
15 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-15.txt |
2018-06-06
|
15 | (System) | New version approved |
2018-06-06
|
15 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2018-06-06
|
15 | Toerless Eckert | Uploaded new revision |
2018-06-06
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-06-06
|
14 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-14.txt |
2018-06-06
|
14 | (System) | New version approved |
2018-06-06
|
14 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2018-06-06
|
14 | Toerless Eckert | Uploaded new revision |
2018-06-06
|
13 | Warren Kumari | [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 , … [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. |
2018-06-06
|
13 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2018-06-06
|
13 | Warren Kumari | [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 … [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. |
2018-06-06
|
13 | Warren Kumari | [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 … [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. |
2018-06-06
|
13 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2018-06-03
|
13 | Terry Manderson | Removed from agenda for telechat |
2018-05-22
|
13 | Alissa Cooper | Telechat date has been changed to 2018-06-07 from 2018-05-24 |
2018-05-22
|
13 | Alissa Cooper | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2018-05-21
|
13 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-05-21
|
13 | Deborah Brungard | [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). … [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..". |
2018-05-21
|
13 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-05-18
|
13 | Mirja Kühlewind | [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 … [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. |
2018-05-18
|
13 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-03-21
|
13 | Terry Manderson | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-03-21
|
13 | Terry Manderson | Placed on agenda for telechat - 2018-05-24 |
2018-03-21
|
13 | Terry Manderson | Ballot has been issued |
2018-03-21
|
13 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2018-03-21
|
13 | Terry Manderson | Created "Approve" ballot |
2018-03-21
|
13 | Terry Manderson | Ballot writeup was changed |
2018-03-01
|
13 | Joel Halpern | Request for Telechat review by RTGDIR Completed: Ready. Reviewer: Joel Halpern. Sent review to list. |
2018-02-28
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Joel Halpern |
2018-02-28
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Joel Halpern |
2018-02-28
|
13 | Elwyn Davies | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Elwyn Davies. |
2018-02-26
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-02-23
|
13 | Liang Xia | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Liang Xia. Sent review to list. |
2018-02-22
|
13 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-02-20
|
13 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-20
|
13 | Amanda Baber | (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 … (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 |
2018-02-16
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-02-16
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-02-16
|
13 | Tero Kivinen | Request for Early review by SECDIR is assigned to Liang Xia |
2018-02-16
|
13 | Tero Kivinen | Request for Early review by SECDIR is assigned to Liang Xia |
2018-02-15
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2018-02-15
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2018-02-15
|
13 | Brian Carpenter | Assignment of request for Last Call review by GENART to Brian Carpenter was rejected |
2018-02-15
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-02-15
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-02-13
|
13 | Ari Keränen | Request for Early review by IOTDIR is assigned to Pascal Thubert |
2018-02-13
|
13 | Ari Keränen | Request for Early review by IOTDIR is assigned to Pascal Thubert |
2018-02-12
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Matthew Bocci |
2018-02-12
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Matthew Bocci |
2018-02-12
|
13 | Alvaro Retana | Requested Telechat review by RTGDIR |
2018-02-12
|
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-12
|
13 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-02-26): From: The IESG To: IETF-Announce CC: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , terry.manderson@icann.org, … The following Last Call announcement was sent out (ends 2018-02-26): From: The IESG To: IETF-Announce CC: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com Reply-To: ietf@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 ietf@ietf.org mailing lists by 2018-02-26. 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 Management and 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 OAM (Operations Administration and Management) communications over a network that is secure and reliable even when the network is not configured, or not 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 document contains these normative downward references. See RFC 3967 for additional information: draft-behringer-anima-autonomic-control-plane: An Autonomic Control Plane (None - ) draft-carpenter-anima-ani-objectives: Technical Objective Formats for the Autonomic Network Infrastructure (None - ) draft-behringer-autonomic-control-plane: An Autonomic Control Plane (None - ) draft-ietf-roll-applicability-template: ROLL Applicability Statement Template (None - IETF stream) draft-behringer-anima-autonomic-addressing: An Autonomic IPv6 Addressing Scheme (None - ) |
2018-02-12
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-12
|
13 | Amy Vezza | Last call announcement was changed |
2018-02-11
|
13 | Terry Manderson | Requested Early review by IOTDIR |
2018-02-11
|
13 | Terry Manderson | Requested Early review by SECDIR |
2018-02-11
|
13 | Terry Manderson | Last call was requested |
2018-02-11
|
13 | Terry Manderson | Ballot approval text was generated |
2018-02-11
|
13 | Terry Manderson | Ballot writeup was generated |
2018-02-11
|
13 | Terry Manderson | IESG state changed to Last Call Requested from AD Evaluation |
2018-02-11
|
13 | Terry Manderson | Last call announcement was generated |
2018-02-11
|
13 | Terry Manderson | IESG state changed to AD Evaluation from Publication Requested |
2018-01-30
|
13 | Terry Manderson | Shepherding AD changed to Terry Manderson |
2018-01-29
|
13 | Sheng Jiang | Tag Doc Shepherd Follow-up Underway cleared. |
2018-01-29
|
13 | Sheng Jiang | 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 … 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. 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. |
2018-01-29
|
13 | Sheng Jiang | Responsible AD changed to Benoit Claise |
2018-01-29
|
13 | Sheng Jiang | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-01-29
|
13 | Sheng Jiang | IESG state changed to Publication Requested |
2018-01-29
|
13 | Sheng Jiang | IESG process started in state Publication Requested |
2018-01-29
|
13 | Sheng Jiang | Changed document writeup |
2017-12-17
|
13 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-13.txt |
2017-12-17
|
13 | (System) | New version approved |
2017-12-17
|
13 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2017-12-17
|
13 | Toerless Eckert | Uploaded new revision |
2017-11-29
|
12 | Sheng Jiang | Tag Doc Shepherd Follow-up Underway set. |
2017-10-13
|
12 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-12.txt |
2017-10-13
|
12 | (System) | New version approved |
2017-10-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2017-10-13
|
12 | Toerless Eckert | Uploaded new revision |
2017-10-13
|
11 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-11.txt |
2017-10-13
|
11 | (System) | New version approved |
2017-10-13
|
11 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Steinthor Bjarnason , Michael Behringer |
2017-10-13
|
11 | Toerless Eckert | Uploaded new revision |
2017-09-17
|
10 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-10.txt |
2017-09-17
|
10 | (System) | New version approved |
2017-09-17
|
10 | (System) | Request for posting confirmation emailed to previous authors: Michael Behringer , Toerless Eckert , Steinthor Bjarnason , anima-chairs@ietf.org |
2017-09-17
|
10 | Toerless Eckert | Uploaded new revision |
2017-08-02
|
09 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-09.txt |
2017-08-02
|
09 | (System) | New version approved |
2017-08-02
|
09 | (System) | Request for posting confirmation emailed to previous authors: Michael Behringer , Toerless Eckert , Steinthor Bjarnason , anima-chairs@ietf.org |
2017-08-02
|
09 | Toerless Eckert | Uploaded new revision |
2017-07-18
|
08 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-08.txt |
2017-07-18
|
08 | (System) | New version approved |
2017-07-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , Michael Behringer , Steinthor Bjarnason , anima-chairs@ietf.org |
2017-07-18
|
08 | Toerless Eckert | Uploaded new revision |
2017-07-03
|
07 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-07.txt |
2017-07-03
|
07 | (System) | New version approved |
2017-07-03
|
07 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , anima-chairs@ietf.org, Michael Behringer , Steinthor Bjarnason |
2017-07-03
|
07 | Toerless Eckert | Uploaded new revision |
2017-03-27
|
06 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-06.txt |
2017-03-27
|
06 | (System) | New version approved |
2017-03-27
|
06 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , anima-chairs@ietf.org, Michael Behringer , Steinthor Bjarnason |
2017-03-27
|
06 | Toerless Eckert | Uploaded new revision |
2017-01-17
|
05 | Sheng Jiang | Notification list changed to "Sheng Jiang" <jiangsheng@huawei.com> |
2017-01-17
|
05 | Sheng Jiang | Document shepherd changed to Sheng Jiang |
2017-01-17
|
05 | Sheng Jiang | Changed consensus to Yes from Unknown |
2017-01-17
|
05 | Sheng Jiang | Intended Status changed to Proposed Standard from None |
2017-01-12
|
05 | Michael Behringer | New version available: draft-ietf-anima-autonomic-control-plane-05.txt |
2017-01-12
|
05 | (System) | New version approved |
2017-01-12
|
05 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, "Toerless Eckert" , "Steinthor Bjarnason" , "Michael Behringer" |
2017-01-12
|
05 | Michael Behringer | Uploaded new revision |
2016-11-15
|
04 | Sheng Jiang | Added to session: IETF-97: anima Wed-0930 |
2016-10-31
|
04 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-04.txt |
2016-10-31
|
04 | (System) | New version approved |
2016-10-31
|
03 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, "Toerless Eckert" , "Steinthor Bjarnason" , "Michael Behringer" |
2016-10-31
|
03 | Toerless Eckert | Uploaded new revision |
2016-07-08
|
03 | Michael Behringer | New version available: draft-ietf-anima-autonomic-control-plane-03.txt |
2016-03-21
|
02 | Toerless Eckert | New version available: draft-ietf-anima-autonomic-control-plane-02.txt |
2015-10-06
|
01 | Michael Behringer | New version available: draft-ietf-anima-autonomic-control-plane-01.txt |
2015-08-18
|
00 | Toerless Eckert | This document now replaces draft-behringer-anima-autonomic-control-plane instead of None |
2015-08-17
|
00 | Michael Behringer | New version available: draft-ietf-anima-autonomic-control-plane-00.txt |