Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and COMMENT)
Toerless Eckert <tte@cs.fau.de> Tue, 28 July 2020 15:37 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6833A0DCC; Tue, 28 Jul 2020 08:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.412
X-Spam-Level:
X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgJ5e9_QnKzK; Tue, 28 Jul 2020 08:37:47 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9873A0DFA; Tue, 28 Jul 2020 08:37:45 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3E22F548440; Tue, 28 Jul 2020 17:37:39 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 35527440043; Tue, 28 Jul 2020 17:37:39 +0200 (CEST)
Date: Tue, 28 Jul 2020 17:37:39 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-anima-autonomic-control-plane@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>
Message-ID: <20200728153739.GI1772@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <159478218035.5567.5331512017107084574@ietfa.amsl.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/YBKI4SlXvkCcv3scs9stRipUfn8>
Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 15:37:52 -0000
Thanks a lot, Roman, very helpfull review. Diff: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-27.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-28.txt Inline On Tue, Jul 14, 2020 at 08:03:00PM -0700, Roman Danyliw via Datatracker wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-27: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. Btw: WG members asked me how to determine if reviews like your raise up to the level of a DISCUSS or just to the level of very good editorial feedback. As an author, i am not interested in that meta-discussion, but with the root cause for the concern, which is the timely closure of the DISCUSS. To that end, the authors think all DISCUSS worthy points raised have been resolved or satisfatory answered and would therefore hope for a timely closure of the DISCUSS ;-)) > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > ---------------------------------------------------------------------- > 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 Hmmm... Right. At an earlier stage, we intentionally downgraded BRSKI from normative to informational, when we started to rewrite ACP so its clear how to implement it with non-BRSKI registrars and BRSKI became fully optional. Resolution: I have changed BRSKI to normative. Let me know if informative wold still be corect given the optional naure of BRSKI for ACP. > ** 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).??? Resolution: Thank you so much. Embarrassing inconsistant edit in -23 to move from 32HEXDIG to lower case 32HEXLC. Fixed. > ** 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? Key strength. Resolution: ... considered to be security wise equal to or better than 256 bit key strength, such as AES256 > -- 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. Also key strength. Resolution: MUST NOT offer options with less than 256 bit symmetric key strength or hash strength of less han SHA384 > -- 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 ? Note: If my proposed text does not fix it according to what a security expert would write, could you be so kind and propose text ? This polishing of security sentences has been going on a lot, mostly because i do not get proposed better text but just rejections of the text i attempt to write after reading a lot of security RFCs, and probably wastig a lot of time in the process. > ** 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.??? Resolution: <t>Physical controlled/secured means that attackers can gain no access to the physical device hosting the ACP Edge Node, the physical interfaces and links providing the ACP connect link nor the physical equipment constituing the NOC Device. In a simple case, ACP Edge node and NOC Device are co-located in a physcially access controlled room, such as a NOC, to which attackers can not gain physical access to.</t> > -- 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.??? Resolution: Text replaced with: See <xref target="acp-connect"/>. Aka: removed text, replaced with pointer to above enhanced text so as not to duplicate the explanatory text. > ** (???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. Resolution: No text change, but following explanation: The difference is that in the case of two physcial devices conneced with a non-encrypted link, the effort of "physical security"/access-control is a problem/requirement that makes ACP-connect a "workaround", because the overhead of physical security is higher than that of a cryptographically secured channel between the ACP nodes. When ACP-Edge-Router and NOC-Device are just e.g.: two VMs running on the same device, and the ACP connect link is a virtual linux bridge link, then this is not a workaround anymore but a good solution because: a) There is no need for physical security anymore (locked room, authenticate people who get access, etc. pp) b) it does not have to be set up manually (bysically create access protected room, wire up two devices), but can be orchestrated automatically by software. c) The remaining security problem of how to ensure that all the software components within the systems are protected against attack, including the virtual link between the NOC software component and the ACP Edge node sotware component is no different than securing the software on any ACP node. I was hoping the text was making this clear. If there is additional text you want to propose for the document to support this explanation, pls. do so, but i already felt the existing tex was a good, more compact representation of what i elaborated above. If that is not the case, then it is easier for someone like you (reader) than me to suggest text that could be better understood. > ** 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 ] Resolution: fixed text Thanks a lot. No idea how this happened. Maybe i was confused with CDDL... Too many formal languages all slightly different *sigh* > ** 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 Resolution: Proposed fixed text: <t>Attacker will not be able to join the ACP unless they have a valid ACP domain certificate. On-path attackers without a valid ACP domain certificate can not inject packets into the ACP due to ACP secure channels. They can also not decrypt ACP traffic except if they can crack the encryption. They can attempt behavioral traffic analysis on the encrypted ACP traffic.</t> > -- compromised node = can inject traffic Actually, we aim higher. Resolution: <t>The degree to which compromised ACP nodes can impact the ACP depends on the implementation of the ACP nodes and their impairment. When an attacker has only gained administrative privileges to configure ACP nodes remotely, the attacker can disrupt the ACP only through one of the few configuration options to disable it, see <xref target="enabling-acp"/>, or by configuring of non-autonomic ACP options if those are supported on the impaired ACP nodes, see <xref target="workarounds"/>. Injecting or ectracting traffic into/from an impaired ACP node is only possible when an impaired ACP node supports ACP connect (see <xref target="ACPconnect"/>) and the attacker can control traffic into/from one of the ACP nodes interfaces, such as by having physical access to the ACP node.</t> This should be a fair assessment. Of course this is not inclusive of attacks against aspects of the node which are outside the AP spec. [ Note that there are of course ideas for extension work to overcome these issues. ] > ** 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: Proposed rewrite of this paragraph: <t>A set of ACP nodes with ACP certificates for the same ACP domain and with ACP functionaliy enabled is automatically "self-building": The ACP is automatically established between neighboring ACP nodes. It is also "self-protecting": The ACP secure channels are authenticated and encrypted.</t> Aka: removed reference to registrar etc... (see explanation below), and "no configuration required". Primarily because "no configuration required" is somewhat duplicate from "automatically". > > -- please specify the security services/properties in a normative section (not > in the informative text in Section 10). Statements of high level security properties do IMHO not have to be normative text because they are an assessment, not a definition. I think this is quite common for security consideration sections from what i read in other RFCs. The definitions of protocol machinery and properties of data objects like certificates to achieve those claimed properties on the other hand have to be normative, and they are - in section 6. > > -- please also be clear on what configuration is being referenced. > Much easier to remove as done above. I was thinking of the typical config that would be required to create an ACP on a non-ACP device, e.g.: VRF (lite), virtual/loopback interfaces, IPv6 addressing, IPSec config, RPL routing config, but not enough value IMHO to elaborate about this here. Of course, not 100% the same, non-autonomic nodes would not have the new GRASP protocol for discovery. But for the rest, you could get pretty cloe on an existing non-ACP capable router through config. After all thats the idea of ANIMA being in OPS - reuse what we have experience with. > ** 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) Resolution: No change, but the following explanations: The ACP is explicitly defined to be a set of nodes with ACP domain certificates, enrollment/BRSKI is really out of scope. Normative ACP nodes start their existance with an ACP cert. How they got it is part of a prior life. BRSKI security properties are covered in BRSKI draft. I struggled long how to well define registrars given that ACP does not mandate/ specify any specific protocol. The solution in the document is that there is only a very abstract definition of the normative requirements against registrars in 6.10.7, pretty much simple requirements against the resulting certificates such as registrar MUST NOT assign same addresses to multiple nodes for example. Think of a registrar abstractely as this: https://datatracker.ietf.org/meeting/102/materials/slides-102-dinrg-dinrg-anima-toerless-eckert-00 Slide 10 While funny, its not far away from a possible reality of a network operator being a registrar, provisioning ACP certificates manually into ACP nodes, and performing all the backend operations (CA, MASA, adressing database). BRSKI is of course the ANIMA preferred enrollment protocol, and if it is used, an ACP node is called an ANI node (ACP+BRSKI). Section 3.2 makes the security property of the ACP for any such bootstrap protocol. For example in communities outside of ANIMA, NetConf ZeroTouch might be preferred over BRSKI. The only mandatory ACP part of your above list is EST ONLY for renewal of certificates, an that of course is specified in the normative section. The BRSKI draft itself defines how it integrates with ACP (GRASP objective etc.). Hope this answers satisfactory the concern. > > ---------------------------------------------------------------------- > 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. Thanks. If the feedack from the security reviewers would have included more proposed text it would have been faster. Maybe i wouldn't have learned as much about security as i did this way, but it was kinda painfull for the WG because it was lengthy. > ** 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. ACP is not a protocol. Its a system and node-wide design with the goal to be "indestructible". Obviously, this is a name-calling to summarize a wide range of benefits, hence it is in parenthesis. Proposed text: <t>This section describes the components and steps to set up an ACP and highlights the key properties which make it "indestructible" against most changes to the Data-Plane, including misconfigurations of routing, addressing, NAT, firewall or any other traffic policy filters that inadvertently or otherwise unavoidably would also impact the management plane traffic, such as the actual operator CLI session or controller NetConf session through which the configuration changes to the data-plane are executed. Physical misconfiguration of wiring between ACP nodes will also not break the ACP as long as there is a transitive path between ACP nodes, the ACP should be able to recover given that it automatically operates across all interfaces of a ACP nodes. Attacks against the network via incorrect routing or addressing information for the data-plane will not impact the ACP. Even impaired ACP nodes will have a significantly reduced attack surface against malicious misconfiguration because only very limited ACP or interface up/down configuration can affect the ACP, and pending on their specific designs these type of attacks could also be eliminated. See more in <xref target="enabling-acp"/> and <xref target="security"/>.</t> > ** Section 6. Per ???An ACP node can be ??? or any other IP a capable node???, > should this be ???IPv6 capable node???? Fixed. I was coming from practical experience, where devices are sold as IPv4 only for price/market differentiation. Those devices could typically easily add the IPv6-only ACP even though the Data-Plane was IPv4 only. I hope by now those sales/marketing models are not possible anymore ;-) > ** 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? No, because its part of what the registrar does, and even though ANIMA defines BRSKI to be the preferred registrar protocol, ACP itself and to be be widely reuseable describes registrar behavior as abstract as possible. For example, IETF also has NetConf zerotouch, which could be used or any proprietary mechanism. Its IMHO easy in all cases given how the expectation is that the registrar needs to knows the pledges IDevID to securely identify the pledge, and in all protocols i have seen, the registrar is in the position to make sure the pledges pledges certificate has components in it that are needed. For BRSKI this is specified in BRSKI. > ** 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. Proposed text: <t>Current time MAY for example be learned via NTP (<xref target="RFC5905"/>) over the same link-local IPv6 addresses used for the ACP from neighboring ACP nodes. ACP nodes that that do provide NTP insecure over their link-local addresses SHOULD primarily run NTP across the ACP and provide NTP time across the ACP only when they have a secure time source. Details for such NTP procedures are beyond the scope of this specification.</t> There is obviously a chicken&egg problem: If you have a bunch of cheap no-RTC routers waking up from total power faillure and trying to get together again, the best outcome to have is to build ACP like it is Jan 1 1970. If at least one of those devices does have an RTC, it would start NTP across the ACP and the others would sync to it. The details of all of this are another extension RFC to ACP, although i guess it can become quite convoluted to describe the autoconfig and all corner cases. Hence i tried to avoid going down this path in this doc too much. The text above is roughly what i've used in practice with enterprise IPsec VPN setups where alas a lot of spoke routers didn't hve RTC. > ** Section 6.1.5. Per ???ACP nodes SHOULD be able to remember the IPv6 locator > parameters ...???, what happens if they don???t remember? ACP is meant to support many, even uncoordinated registrars. That is why the addressing scheme has a registrar-ID in the client addresses so that registrars can independently of each other assign ACP addresses to clients via their certs without conflicting with each other. If you only do renewal via EST then it is purely a simplification of diagnostic that you are doing renewal always with the registrar you originally got your cert from. The renewal would easily be the same going to any other registrar, but the logs on the registrar would then not nicely have only the info about the clients that they initially enrolled. When clients expire their certs and need to re-enroll, it gets harder to get the same ACP address again if you do not go to the same original registrar. There is text for that later in the doc explaining how registrars can still attempt to honor the original cert ACP address, but this functionality is probably something we need anothre extension document for with LAMPS involved (registrars honoring expired certs for the purpose of renewal). Changing ACP address under such circumstances is fine for ACP itself, but more work for a backend system having to track such change of addresses (having to keep track of e.g.: IDevID and changing LDevID/ACP-address). > ** 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? Unlike non-CRL setups, i have no practical deployment experience with CRL. To the best of my understanding, the content of a CRL itself is protected such that you can have it relayed through e.g.: caches or the like. Hence the additional address is just another layer of security whose added value vs the additional limitations for deployability it may bring are unclear. Hence a SHOULD. Eg.: In one example, i had to build an ACP connect through IPv6/IPv4 NAT because some backend in customers NOC did not support IPv6. > ** 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? This goes back to above mentioned IMHO more desirable, but not yet not documented or well enough discussed option of simply permitting renewal instead of re-enrollment with an expired cert. Logically the argument for that is that the lifetime in a cert does not necessarily have to be a limiter to the registrar+CA renewal operations because that is not a normal "use" of the certificate, and that is whats to be imited by the lifetime. When i was operating an enterprise VPN headend for a while i recurringly had the eperience that long-time switched off VPN spokes where reactivated, then the user asked in email why his VPN router does not work, and then in the absence of better options i had to disable lifetime checks for this cert on the headend temporarily to get renewal working. (obviuosly, the phone call was the additional attestation for the node with the expired cert to be assumed to be still "trusted"). Re-enrollment can vary widely in complexity based on the registrar used - even with BRSKI, there are lot of MASA options, So it can be ACP career limiting for specific type of registrars if this was a MUST. There is one specifically preferred option which would have to go into a followup document, which is to use BRSKI and BRSKI proxy together with the expired cert to renew. This exactly would only involve the registrar having to honor the expired cert, but not the ACP. So its not really re-enrolling (which would use the IDevID and MASA), but it would use the BRSKI enrollment infra (BRSKI-proxy). > ** 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. I disagree. It is IMHO important to provide important fundamental explanations of the extension points of the ACP architecture, and that is most easily done through examples. MacSec is a highly desirable extension option because it is the most widely cross-platform HW-accelerated encryption option, so it is a good example to use in a sentence. Remember, this is an OPS area system specification where operational and architecture aspects are important. Also we where asked not to have a separate architecture document by the initial AD to the WG. > ** 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. The previous paragraph to the one you are citing explicitly says: | Nevertheless, for use with ACP secure channel setup, | there SHOULD be the option to include the TA certificate in the signaling | to aid troubleshooting, see <xref target="ta-troubleshoot"/>. I had exhaustive discussions about this on the ipsec mailing list to derive at the acceptable option, whose details are in the IPsec section of the ACP (aka: including the TA in the signalled IKEv2 messages without having to extend IKEv2, but just relying on permissible existing IKEv2 options). > ** 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) Actually it is definition of extension point requirements for implementers, so i am sad to learn it is misreadable as an operator related text. Proposed fix: <t>When specifying additional security association protocol for ACP secure channel use beyond those covered in this document, protocol options SHOULD be eliminated that are not necessary to support devices that are expected to be able to support the ACP. > ** 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???? The actual normative (rfc2119) requirements of the IPsec profile are later in the section. This initial text gives just the overview. Saying something like "you MUST comply with the normative requirements described later on in this text" would be only confusing and not helpfull. > ** Section 6.7.3.1.1. Per ENCR_CHACHA20_POLY1305, ???[t]herefore this algorithm > is only recommended???, shouldn???t it read as RECOMMENDED? Again avoiding IMHO unhelpfull duplication of rfc2119 language. The normative requirement was earlier in the section: | ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher performance | than ENCR_AES_GCM_16. If that performance is not feasible, it MAY be supported. The paragraph you mention is explanation of that prior normative requirement. > ** 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. Oops. With the rewrite of this section in the last revisions, the MUST 8247 actually vanished. Great catch. The text above is introduction, the proposed fix is after that paragraph: | ACP Nodes supporting IKEv2 MUST comply with <xref target="RFC8247"/> amended by | the following requirements which constitute a policy statement as permitted by | <xref target="RFC8247"/>. > ** 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. Apologies. trash left fixing the sentence. Fixed text and added explanation: ACP registrars that are aware of the IDevID certificate of a candidate ACP device... ... The PID for example could identify type of devices allowing for specialized ASA requiring multiple addresses or non-autonomic VMs for services and those nodes could receive Vlong sub-address scheme ACP addresses.</t> > ** 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? Proposed added text: <t>If allocated addresses can not be remembered by registrars, then it is necessary to either use a new value for the Register-ID field in the ACP addresses, or determine allocated ACP addresses from polling the ACP network nodes. Non-tracked ACP addresses can be reclaimed by revoking or not renewing their certificates and instead handing out new certificate with new addresses (for example with a new Registrar-ID value). Note that such strategies may require coordination amongst registrars.</t> > ** 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. proposed fix: SHOULD be sent 2 or 3 times (actual value 2 or 3 left for experimentation, this seems to be a necessary and sufficient range from similar protocol experiences). > ** 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? Good question. If you know someone who could suggest an equivalent, please bring her in. Given how this is a performance optimization, i don't think we need to bother too much. I hope we can learn from implementation/deployment experience (i only hve that for IPsec) and then write update text later with such refinements. > ** 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. I have deleted that sentence again. This was not appropriate for the RFC, we can discuss this on the list or offline. > ** 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? Changed to: Basic standardized diagnostics would require support for (yang) models ... Wrt to the question: The existing components used by ACP should have YANG models given how long they have been in use, but they don't necessarily seem to have them. Eg there as some IPSECME targeted draft like draft-tran-ipsecme-yang-01.txt, not sure why that died, one could maybe use rfc8049 to represent the VRF for ACP (not sure), there is an initial dradt for RPL (draft-ietf-roll-mpl-yang-02). From talking to Kent Watson, the situation for certificates looks better, e.g.: draft-ietf-netconf-trust-anchors. Once we have these ACP/GRASP/BRSKI specification RFCs out, we'll be looking for interested Yang geeks to help with ACP/GRASP yang models. The existing spec intends to be an informal starting point towards such future yang work, but there will no more detailling of what is or is not available in IETF yang world. Thts a job by itself best done fofr an acp yang rfc. I have some work i started from 3 years ago lying around... > ** 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. What is the purpose of the [sic] notation ? IETF does not allow to raise normative requirements against informal operator interface decription, which is what this section is. I guess that would require a formal CLI model which we don't have. Hence the normative requirements could only come from a YANG model. Hence this section is informational. It is also good to not formalize a normative operator interface without first having enough experience collected IMHO. > ** 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. Hmm... i think it says everything it can say, except... see your following point. > ** 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? Great. I remember we went several times through this text especially with routing directorate, but nobody noticed that the simple core example was not explicitly written down. Instead we had good discuss about the proposed how (separartion of down insto adin-down/physcial down). Which is a good reason too not to have this section normative yet. But i digress. I added the following paragraph to the section. The configuration summary section actually already summarizes this core reason as well, but it really needs to be in this section. <t>One of the common problems of remote management is for the operator or SDN controller to cut its own connectivity to the remote node by a configuration impacting its own management connection into the node. The ACP itself should have no dedicated configuration other than aforementioned enablement of the ACP on brownfield ACP nodes. This leaves configuration that can not distinguish between ACP and Data-Plane as sources of configuration mistakes as these commands will impact the ACP even though they should only impact the Data-Plane. The one ubiquitous type of commands that do this on many type of routers are interface "down" commands/configurations. When such a command applied on the interface through which the ACP provides access for remote management it would cut the remote management connection through the ACP because (as outlined above), the "down" commands typically impact the physical layer too and not only the Data-Plane services.</t> <t>To provide ACP/ANI resilience against such operator misconfiguration, ... > ** 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). Added sentence in before for more missing explanation: <t>An example of non-ACP but ANI traffic that should be permitted to pass even in "admin-down" state is BRSKI enrollment traffic between BRSKI pledge and a BRSKI proxy.</t> Now the answer to your question is that the "both" in the sentence you ask about refers to ACP/ANI (both ACP and ANI). If this is not good english, pls. let me know. > ** 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? Give it time. We're in round 1: Existing router management plane host stacks may have severe issues separating out access by VRF context. I remember some of the per-VRF SMI work. Enterprise operators may have severe issues with this short-term. For example, the typical solution would be for network admins to have to VPN back into some headend from where the ACP is accessible. That is a lot of pain especially when you are trying to troubleshoot locally and the headend is remote. To make future network admin staff work not more convoluted because of ACP, but actually more secure AND easier, we need some easily useable ACP-access method for e.g. network admin notebooks. Given how i at times had 4 VPNs on my notebook and at most 2 VPN would work at the same time, i am not sure if this documents IPsec spec would be good for operator notebooks. But maybe an ACP acces method via 802.1x... TBD. > ** 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: Changed text "security in mind" -> "ACP in mind". I think there a initiatives looking at secure devices, but thats not the same as stricter isolation between ACP and the rest of the system. > --what???s an example of the legacy software? I had a presentation about designs for ACP a few years back in an IEEE conference touching those aspects. To me, legacy is probably most router software infra today, where you would need to implement ACP as one of many VRFs that the software may already already support as part of e.g.: L3VPN or similar services. Non-legacy is something where the router is actually a VM or container running on a hypervisor. And ACP would be part of the hypervisor (e.g.: linux). Or where ACP does not even run on the same CPU/FPE as the router, but on e.g.: BMC HW/software (OpenBoot etc..). Lots of interesting design choices possible. > -- 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? Lets use different mail threads to discuss this. > ** Section 10.2.2. Per ???As explained above, traffic across the ACP SHOULD > still ??????, is RFC2119 language really intended in this informative section? Fixed to lower case. Thanks. > ** 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? ;-) Not really because the claim of ACP is that all the core parts of ACP have no configuration. See section 9.5. Given how more than 50% of the whole document to me feel like talking about security, i do have a hard time figuring out a mandatory logic of what belongs into section 11. My solution was that it is a mixture of important summaries and then tidbits that didn't have a better place to be explained. Given how the topic of configuration and misconfiguration of ACP was exhaustively discussed in prior sections, i didn't feel the need to add it here again. But always happy to consider proposed text. > ** 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? section 11 is not normative, and actual normative requirements for new stuff across the ACP is something that was not in charter when we defined this document, aka: i wouldn't have a logical place in this doc for this beside as a general security considerartion. Writing normative about ASA IMHO just became possible after recharter of WG last year, so i would want to put normative requirements about this probably into ASA docs we are starting to write. > ** Editorial > > -- Recommend being consistent on either ???ACP domain certificates??? or ???ACP > certificates??? 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. Fixed by putting (normative) at the end of the sentences. > -- 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/ fixed > -- Section 6.2. Editorial. s/does intentionally not/intentionally does not/ fixed > -- 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. Fixed by separating sentences: Instead, MacSec is mentioned as ... > > -- 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. Oops. how did that slip through. Thought i had fied all points to be anchors. Fixed now. > -- Section 6.11.1. Please make draft-ietf-roll-applicability-template a > reference. Already in -27. > -- Section 6.11.1.5. Editorially. It might be worth framing the path metric > in the form of sentence. Fixed to: Use Hopcount according to xref target="RFC6551" > > -- Section 11. s/enemy plegdes/rogue pledges/ Was already fixed in -27 to "malicious registrar" (on prior reviewer suggestion i think) > -- Section 11. Per ???Fundamentally, security depends on avoid operator and > network automation mistakes ??????, this paragraph is not actionable. Recommend > removal. Fixed with proposed replacement paragraph: <t>Operators and provisioning software developers need to be aware of how the provisioning/configuration of network devices impacts the ability of the operator / provisioning software to remotely access the network nodes. By using the ACP, most of the issues of configuration/provisioning caused loss of connectivity for remote provisioning/configuration will be eliminated, see <xref target="self-creation"/>. Only few exceptions such as explicit physical interface down configuration will be left <xref target="admin-down"/>.</t> First sentence should now be actionable to operators/developers. Second summarizes benefits of ACP. Third gives example of limitations. Core value proposition of ACP hence useful to not just eliminate in security section (assuming certain readers will primarily read security section). This answers the actionable point. whether or not misconfiguration that makes a network become unmanage is a security issue, i can't judge, because i am not sure i know a precise definition of "security" > ** 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) Sorry for this editorial trouble. I was hoping that you would not spend time on this. Yes, of course i will do a more thorough check before RFC editor. My excuse for not doing it on every rev is quite lame, but i have not found a spell checker that remembers all the non-standard words correctly, so a few changes in a 160 page document is terrible each time... Thanks so much for the excellent review! Please consider removing the discuss. Cheers Toerless
- [Anima] Roman Danyliw's Discuss on draft-ietf-ani… Roman Danyliw via Datatracker
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Toerless Eckert
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Brian E Carpenter
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Toerless Eckert