Dear Roman: First of all, thank you so much for your extensive review. This is really appreciated.
Please see inline our comments. NOTE: We skip editorial comments in our answer. > El 11 may 2020, a las 23:52, Roman Danyliw <[email protected]> escribió: > > Hi! > > I performed an AD review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 and > my feedback is as follows: > > (1) As written, it wasn't clear to me how this document fits into the I2NSF > architecture. There were a number of places in the document that the > underlying reference architecture does not appear to link to the one > specified in I2NSF. The text at times reads like I2NSF, an SDN architecture > or a generic configuration of IPSec. This document needs additional text to > frame the work for I2NSF so that it fits into the charter -- if it > generalizes to other use cases, I don't see this as an issue. The following > is a non-exhaustive list where I saw dissidence. [Authors] Before getting into the specific comments, a general comment is important. As we mention in the abstract, this document focuses in flow-based NSF Network Security Function (NSF) which protect data traffic with integrity and confidentiality between network resources by using IPsec. This draft is related with the I2NSF architecture in the following ways: - The beginning of I2NSF charter and Section 2 in RFC 8192 defines a NSF as "a function that is used to ensure integrity, confidentiality, or availability of network communication; to detect unwanted network activity; or to block, or at least mitigate, the effects of unwanted activity.". A flow-based NSF based on IPsec ensures integrity and confidentiality of network communications. Our document is useful for that type of NSFs. - Section 3.1.1 in RFC 8192 identifies diverse types of Security Functions: "Security Gateways and VPN Concentrators: Examples of these functions are IPsec gateways, secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows." and "Internal Data and Content Protection: Examples of this function are encryption, authorization, and public/private key management for internal databases.". These functions are related to an IPsec-based NSF and this I-D provides the I2NSF NSF-facing interface required to deal with these functions. - It covers one of the problems identified in RFC 8129 "3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs". - It is related to one of the use cases also identified in RFC 8129 "4.3.3 Client-Specific Security Policy in Cloud VPNs" when the VPN is established with IPsec. Due to the importance this use case and others such as SD-WAN and data center scenarios (https://tools.ietf.org/html/draft-nir-i2nsf-ipsec-dc-prof-00), this type of centralized IPsec management has raised significant interest in the industry. - As such, the data model defined in this I-D fits in the definition given to I2NFS NSF-Facing interface in Section 3.2 - RFC 8329. "The I2NSF NSF-Facing Interface (NSF-Facing Interface for short) is used to specify and monitor flow-based security policies enforced by one or more NSFs." In draft-ietf-i2nsf-sdn-ipsec-flow-protection the flow-based NSF allows to provide integrity and confidentiality to flows by using IPsec. > > -- Section 1. What is the relationship between the SDN controller referenced > here and the I2NSF NOMS per Figure 1 of RFC8329? [Authors] Actually as such the SDN (Security) controller refers to I2NSF controller in RFC 8329. If we follow the Figure 1 the SDN controller is the NOMS. Considering the type of security service addressed in this draft, we believe the term "I2NSF Controller" is closer than NOMS. In fact, for example, this is also done in draft-ietf-i2nsf-applicability-18 (see Figure 1). We will change SDN controller or Security controller by the term I2NSF controller along the document. > > -- Section 1 makes no reference to I2NSF. [Authors] We will rewrite this section to reference to I2NSF. > > -- Section 5. Does the proposed architecture cited in Figure 1 and 2 conform > to the "I2NSF Reference Architecture" depicted in Figure 1 of RFC8329. It > seems like it should. However: > > o this document doesn't cite it. It does however cite RFC8192. In Figure 1 > and 2 of this document, there is a "client facing interface"/"vendor facing > interface"/"Security Controller", but RFC8329 has a "consumer facing > interface"/"registration interface"/"Network Operator Management System” [Authors] Yes, the interface naming must be updated to be aligned with the one used in the I2NSF framework. Regarding the use of "Security Controller", other WG documents also use this term. However, considering you suggestion, since RFC 8392 also refers to NOMS as "I2NSF controller", we propose to use the term "I2NSF controller" along the document. > o In Figure 1 and 2 of this document there is an I2NSF agent in the NSF which > isn't described elsewhere. [Authors] Correct. That was extracted from the old I-D draft-ietf-i2nsf-terminology-08, which we have removed now from the I-D. We have removed the term "I2NSF Agent”. > o The Client-Facing Interface is cited as RFC8192. What is the relationship > between this interface and draft-ietf-i2nsf-consumer-facing-interface-dm? [Authors] Correct. Figure 1 and 2 should read Consumer-Facing Interface instead of Client-Facing interface. > o What is the relationship between the NSF Facing Interface in Figure 1 and > draft-ietf-i2nsf-nsf-facing-interface-dm? [Authors] This I-D (draft-ietf-i2nsf-sdn-ipsec-flow-protection) defines a data model to be used between the I2NSF Controller and the NSFs. It is important to note that this data model is complementary to the one described in the draft-ietf-i2nsf-nsf-facing-interface-dm. The draft-ietf-i2nsf-nsf-facing-interface-dm defines a data model for Firewall, IDS and IPS security policies. The draft-ietf-i2nsf-sdn-ipsec-flow-protection defines a data model for IPsec policy and security associations following the specification in RFC4301 and RFC7296. A NSF could play the role of IPsec host/gateway and or Firewall/IDS/IP by supporting one or both data models. > > -- Section 5.1.1. How does the scenario of multiple Security Controllers and > gateways relate to the I2NSF architecture? [Authors] Certainly RFC 8329 does not seem to mention the possibility of having two I2NSF controllers cooperating. However, we think it is a realistic case for different reasons (for example load balancing). In any case, since RFC 8329 does not describe this case, to be aligned with it, we will remove it. The same for section 7.2. > > -- Section 5.2. Per "As shown in Figure 2, applications for flow protection > run on top of the Security Controller", can you clarify what this means? Is > it that the functionality associated with translating the policy shared by > I2NSF client is built into the security controller? [Authors] Basically we meant the I2NSF user (applications), which uses the consumer-facing interface to communicate with the I2NSF controller. Let us change that text to be aligned with that terminology. > > -- Section 5.3. Per "In principle, IKE case is easier to deploy than > IKE-less case because current gateways ..." > o s/IKE case is/the IKE case is/ > o s/than IKE-less case/than the IKE-less case/ > o what gateway is being referenced here - it isn't in Figure 1, 2 or RFC8329. > RFC8192 defines a security gateway be subsequently doesn't use it again [Authors] It is referring to "security gateways" such as defined in IPsec architecture RFC 4301. In I2NSF terminology, it translates to a flow-based NSF implementing IPsec. In line with previous comments, we can change it to NSF but clarifying its correspondence to IPsec architecture (RFC 4301) to facilitate the readability for those coming from the IPsec world. > > -- Section 5.3. Per "Moreover hosts can install easily an IKE > implementation": > o s/can install easily/can easily install/ > o What are hosts in this context? How are they related to the NSFs? [Authors] Hosts are also defined in IPsec architecture. In fact there are different configurations: host-to-host, gateway-to-gateway and gateway-to-host (not covered in our I-D after a consensus in the I2NSF WG.). A host is still a flow-based NSF. The difference with the gateway is that the host does not forward traffic between different networks. The source of the IPsec traffic is the own NSF and the destination is another flow-based NSF which does not forward that traffic. From RFC 4301: " IPsec can be used to protect one or more "paths" (a) between a pair of hosts, (b) between a pair of security gateways, or (c) between a security gateway and a host." As mentioned in our previous answer, we will review this section to clarify the correspondence between I2NSF and IPsec entities. > > -- Section 5.3.1. "However, when IKE is not used, we have followed a > different approach to avoid any packet loss during rekey: the Security > Controller installs first the new inbound SAs in both NSFs and then, the > outbound IPsec SAs." This text mentions multiple NSFs (i.e., "in both > NSFs"), but the I2NSF is scoped to the interface between the controller and > NSFs (but not between NSFs). [Authors] In order to configure a IPsec flow between two NSFs, both NSFs have to be configured by the I2NSF controller. The interfaces involved here are: (1) the I2NSF NSF facing interface between the I2NSF controller and one NSF; and (2) the I2NSF NSF facing interface between the I2NSF controller and the other NSF. Therefore, there is no I2NSF interface between both NSFs. > > -- Section 7. How do these use cases relate to the I2NSF architecture? > There appears to be a set of actions taken by an administrator that is at a > different level of abstraction that specified by I2NSF [Authors] The administrator provides high-level security policies (e.g. I want to protect data traffic with confidentiality and integrity between these two networks). Referring to I2NSF architecure, the administrator should be allowed to do that acting as I2NSF User. We can clarify this or simply state the I2NSF User in our text. In any case, the I2NSF User would be an IPsec management system. > o Section 7.1 and 7.2 discuss communication between NSFs which isn't covered > in I2NSF [Authors] We included step 4 in Fig. 3 for completeness. Certainly that step 4 is out of scope of IN2SF. In fact it is only describing what finally happens after the configuration in steps 1-3. If it helps we can remove step 4 or stating that is out of scope of I2NSF. Same happens with Fig. 4. > o Section 7.2 discusses communication though an "east-west" interface between > controllers which isn't covered in I2NSF [Authors] Yes, that's right. That is a common terminology in the SDN world (see https://tools.ietf.org/html/rfc7426). Since this may create confusion we will get rid of the text related with interactions between two I2NSF controllers, and keep the text for only one controller. > o I also couldn't find a reference to I2NSF interactions where there are > multiple controllers operated by different administrative entities. [Authors] Correct. We will remove now the case for multiple controllers. > > (2) Abstract. Editorial. The sentence "This document describing ..." does > not parse for me and I recommend tying it to the I2NSF architecture: > OLD: > This document describes how providing IPsec-based flow protection by > means of a Software-Defined Network (SDN) controller (aka. Security > Controller) and establishes the requirements to support this service. > NEW: > This document describes how to provide IPsec-based flow protection by means > of a Software-Defined Network (SDN) controller (I2NSF Security Controller) > and establishes the requirements to support this service. [Authors] Ok, done. > > (3) Abstract. Per "The document focuses on the NSF Facing Interface ....", > which NSF Facing Interface? I2NSF or something more generic? [Authors] It defines a data model which is complementary to the defined in draft-ietf-i2nsf-nsf-facing-interface-dm-09. As such, it defines a I2NSF NSF-Facing Interface for IPsec management. > > (4) Section 1. Per "Recently, several network scenarios are considering a > centralized way ...", this sentence notes that there are several network > scenarios motivating the work but only names one, SD-WAN. Either enumerate > the others or note SD-WAN only. [Authors] Ok. We will include a reference to RFC 8192 (Section 4.3.3) and the data center use case commented here https://tools.ietf.org/html/draft-nir-i2nsf-ipsec-dc-prof-00 > > (5) Section 1. Editorial. > OLD: > SD-WAN is based on IPsec as underlying security > protocol and aims to provide flexible, automated, fast deployment and > on-demand security network services such as IPsec SA management from > a centralized point. > NEW: > SD-WAN is based on IPsec as an underlying security protocol and aims to > provide flexible, automated, and rapid deployment; and enable on-demand > security network services such as IPsec SA management from a centralized > point. > > (6) Section 1. "First, this document exposes the requirements to support the > protection of data flows using IPsec [RFC4301].", I had trouble identifying > the SDN-specific requirements in the text. In what section is state stated? [Authors] They are in section 5.1.1 and 5.2.1. > > (7) Section 1. Editorial s/manage autonomously/autonomously manage/ > > (8) Section 1. Per "The analysis of the host-to-gateway (roadwarrior) > scenario is out of scope ...", > -- Consider using a different, less colloquial phrase than “roadwarrior" [Authors] Ok, we will remove it since the term "host-to-gateway" clarifies enough the IPsec operation mode. > > -- EDITORIAL: > OLD: > The analysis of the host-to-gateway (roadwarrior) scenario is out of scope of > this document > > NEW: > Consideration for the host-to-gateway (roadwarrior) scenario is out of scope > of this document > > (9) Section 1. Editorial. s/pays attention to the challenge/addresses the > challenge of the/ > > (10) Section 3. Per [I-D.ietf-i2nsf-terminology]: > -- [I-D.ietf-i2nsf-terminology] is expired. Are you sure you want to use? [Authors] We use it because RFC 8329 also references it. But, certainly, it seems not advisable to refer an expired draft. So we will remove this reference. > > -- Is there a reason to redefine NSF here as it is defined in > [I-D.ietf-i2nsf-terminology] [Authors] True. There is no need. We could refer to I-D.ietf-i2nsf-terminology, but as you suggest, it is expired. Should it be enough to refer RFC 8329. > > (11) Section 3. Editorial. s/dst\/src/destination\/source/ > > (12) Section 3. Typo. s/outboud/outbound/ > > (13) Section 4. This section was a helpful scoping. I would have benefit > from reading it earlier (Section 1) [Authors] Ok. We can integrate this text in Section 1. > > (14) Section 4. Per "... in order to protect specific data flows", between > what parts of the I2NSF infrastructure? [Authors] This text refers to the protection of data traffic exchanged between two flow-based NSFs implementing IPsec. We will clarify this. > > (15) Section 5.1. Editorial > OLD > In this case the NSF ships an IKEv2 implementation besides the IPsec support. > > > NEW > In this case, the NSF ships an IPSec implementation with IKEv2 support. > > (16) Section 5.1.1. Per Figure 1 (and applies to Figure 2) > -- What is the "application support”? [Authors] It basically means the component in the Security Controller that handles the specificities of IPsec management. But we agree that it may create confusion. We can remove it from the Figure. > -- What is the "SPD entries Distr." Is that "distribution”? [Authors] Yes, it is distribution. We will change Figure 1 to clarify this. > -- What's "data protection and forwarding”? [Authors] Applying IPsec over data packets and, after that, forwarding of these protected packet. > > (17) Per Section 5.1.1. Per "In order to support this capability in IKE > cases, the following interface requirements need to be met:" > -- To what interfaces is this referring? [Authors] The interface between the NSF and the I2NSF Controller, i.e, the I2SNF NSF-facing interface. > -- Editorial: s/in IKE case/in the IKE case/ > > (18) Section 5.2.1. The text references an SDN controller. Is that the > Security Controller per Figure 2? I recommend consistent language. [Authors] We agree. To be consistent we think it would be better to say "I2NSF controller" eveywhere, despite we have observed other WG documents also using the term "Security Controller”. > > (19) Section 5.3. Per "As downside, the NSF needs more resources to hold > IKEv2", what does "hold IKEv2" mean in this context? Is it an observation > that the NSF will need more memory? Storage? Compute? [Authors] Yes, the NSF will need more resources. On one hand, memory for the IKEv2 implementation. On the other computation since, each IPsec security association rekeying, may involve a Diffie-Hellman exchange. We will clarify this aspect. > > (20) Section 5.3. Per "Moreover, the IKEv2 implementation needs to implement > an internal interface" - what is an internal interface in this architecture? [Authors] This is the interface that IKEv2 implementation needs to enforce the configuration sent by the Security Controller. However we understand that it might be confusing. It is a detail that can be omitted. > > (21) Section 5.3. Recommend something more precise than "lighter NSFs”. [Authors] Yes. It is related to our answer in (19). We believe resource-constrained NSFs is the right description. > > (22) Section 5.3. Per "On the contrary, the overload of creating and > managing ...", "overload", to me, implies that the demand for a resource is > out stripping the supply. Do you mean "the overhead of creating ...."? Also > see the last sentence of this paragraph, "In summary, this overload may …" [Authors] The right word would be “complexity”. > > (23) Section 5.3.2. Per "Moreover, the Security Controller has a register > about all the NSFs ...", what is "has a register"? Is the intent to say that > the controller keeps a list of NSFs? [Authors] Yes. Your suggestion is better. > > (24) Section 5.3.2. "In IKE-less case, if the Security Controller detects > that a NSF has lost the IPsec SAs it will delete the old IPsec SAs on the > non-failed nodes, established with the failed node (step 1). This prevents > the non-failed nodes from leaking plaintext." > -- Is there a reason why normative language isn't used to require this clean > up (i.e., deleting the old IPSec SAs)? [Authors] Yes, it is a SHOULD: "In the IKE-less case, if the I2NSF Controller detects that a NSF has lost the IPsec SAs it SHOULD delete the old IPsec SAs on the non-failed nodes, established with the failed node (step 1). This prevents the non-failed nodes from leaking plaintext. We include SHOULD since the IPsec SAs still has a lifetime that will make the IPsec SAs be removed automatically without the I2NSF controller involvement. > -- Are there constraints on how quickly this needs to happen? [Authors] There are not, as far as we know. As we mentioned the IPsec SAs still have a lifetime associated. > > (25) Section 5.3.2. Per "Nevertheless other more optimized options can be > considered", what is the guidance to implementors with this statement? [Authors] We wanted to highlight that implementors may decide to add configuration permanent between NSFs reboots without compromising security. For example, if the IKEv2 configuration is in the startup-config , each time a NSF reboots it will use that configuration for each rebooting. It would imply avoiding to contact with the I2NSF controller. This “optimization” would be for the IKEv2-case. Since this text is more related with IKEv2 we can move it and expand it with this explanation. In the IKEv2-less case, the process described tries to avoid any packet loss. However, step 2 and step 3 can be performed at the same time at the cost of a potential packet loss. If this is not critic then it is an optimization since the number of exchanges is lower (in fact, we have implemented this behavior as well). We can add some text about this. > > (26) Section 5.3.3. Per "On the contrary, the IKE-less case does not have > any protocol in the NSFs to detect whether they are located behind a NAT or > not.", it seems odd to make assumptions about the code in the NSFs. [Authors] IKEv2 has a mechanism to detect if it is operating behind a NAT. With IKE-less, the NSF does not have IKE implementation since, under that standpoint, the NSF does not have any (IPsec-related) protocol to do it. However, we agree that the NSF may have a protocol that allows it to detect it is behind a NAT. We can rephrase that sentence. “In the IKE-less case, the NSF does not have the assistance of the IKEv2 implementation to detect if it is located behind a NAT." > > (27) Section 5.3.3. The normative behavior of the IKE-less NAT detection > isn't clear. The paragraphs "On the contrary, ..." and "For example ..." > don't articulate what's to be done in the NAT case. [Authors] We can rephrase this text as follows: In the IKE case, IKEv2 already provides a mechanism to detect whether some of the peers or both are located behind a NAT. If there is a NAT network configured between two peers, it is required to activate the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],[RFC8229]). Note that the usage of IPsec transport mode when NAT is required MUST NOT be used in this specification. In the IKE-less case, the NSF does not have the assistance of the IKEv2 implementation to detect it is located behind a NAT. If the NSF does not have any other mechanism to detect if it is behind a NAT, the Security Controller SHOULD implement a mechanism to detect that case. The SDN paradigm generally assumes the Security Controller has a view of the network under its control. This view is built either requesting information to the NSFs under its control, or because these NSFs inform the Security Controller. Based on this information, the Security Controller MAY guess if there is a NAT configured between two hosts, and apply the required policies to both NSFs besides activating the usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]). The interface for discovering if the NSF is behind a NAT is out of scope of this document. If the Security Controller does not have any mechanism to know whether a host is behind a NAT or not, then the IKE-case MUST be used and not the IKE-less case." > > (28) Section 5.3.4. Per "The assumption in this document is that, for both > cases, before a NSF can operate in this system, it MUST be registered in the > Security Controller. In this way, when the NSF comes to live and establishes > a connection to the Security Controller, it knows that the NSF is valid for > joining the system." > -- how does this registration and validation occur? I see the text later > says "This discover process is out of scope ...", but registration seems > different than discovery. [Authors] Yes, both process are different. Registration refers to the process of facilitating the I2NSF controller information about a valid NSF such as certificate, IP address, etc. This information is incorporated to a list of NSFs under its control. On the contrary, discovery represents the process followed by the I2NSF controller to detect the capabilities supported by a concrete NSF (cryptographic algorithms, supported authentication methods, etc.). We believe both processes are independent of the content of document. We will make this clearer in this section. We will also mention that the registration process is out of scope. > -- (editorially) I stumbled over "when the NSF comes to live", maybe "when > the NSF starts" > > (29) Section 6.2. Is the spd-entry having only a single traffic selector the > only simplification of RFC4301. If not, list all of the divergences. > Otherwise, I recommend explicitly saying only this edit was made. [Authors] Ok. We will list them. > > (30) Section 6.2. Typo. s/instead a list/instead of a list/ > > (31) Section 6.2. Editorial. s/admit a traffic selector per IPsec > policy/admit a single traffic selector per IPSec policy/ > > (32) Section 7. Are the use cases normative text? If not, please say so. > Consider moving them to an appendix outside of the normative flow of the > text. If the text is normative, then I'll have more feedback as they are > underspecified for standards track text. [Authors] Yes, we think moving them to an appendix should be ok. This is just describing examples about how it would operate. > > (33) Section 7.1. "Besides, fresh SAD entries will be also generated by the > Security Controller and enforced in the NSFs. In this case, the Security > Controller does not run any IKEv2 implementation (neither the NSFs), and it > provides the cryptographic material for the IPsec SAs." > > Editorially, what the "beside" is referencing and the double negative in the > second sentence created confusion for me. Recommend: > > NEW: > Fresh SAD entries will be also generated by the Security Controller and > enforced in the NSFs. As the Security Controller is not running IKEv2, it > provide the cryptographic materials for the IPSec SAs. [Authors] Ok, perfect. Thank you. > > (34) Section 7.2. Step 3. What does "NOTE: This may require extensions in > the East/West interface." mean? [Authors] We understand this is not well explained. Assuming an east-west interface that interconnects two Security Controllers, this east-west must allow the negotiation with the other controller to agree on the IPsec SPD policies and IKEv2 credentials for their respective NSFs. We can remove that note. Moreover, we agreed before that this scenario with two controllers could be removed from the I-D. > > (35) Section 9. s/MUST exit/MUST exist/ > > (36) Section 9. Typo. s/to protect of the critical/to protect the critical/ > > (37) Section 9.0 Per "For example, when NETCONF is used as southbound > protocol between the Security Controller and the NSFs, it is defined that TLS > or SSH security association MUST be established between both entities", what > is the difference between this normative language and Section 9.3's "The > lowest NETCONF layer is the secure transport layer, and the > mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The > lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure > transport is TLS [RFC8446].”? [Authors] The text included in Section 9.3 is extracted from RFC 8407 about "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models”. The text in section 9 is to state that "there MUST exit a security association between the Security Controller and the NSFs to protect of the critical information (cryptographic keys, configuration parameter, etc...) exchanged between these entities.” And then we give an example. Perhaps the MUST in "it is defined that TLS or SSH security association MUST be established between both entities” is confusing since it comes from the NETCONF RFC 6242. We can remove that sentence to avoid any confusion. > > (38) Section 9. Typo. s/This default policy MUST ... before the NSF contacts > with the Security Controller/This default policy MUST ... before the NSF > contacts the Security Controller/ > > (39) Section 9. Per "Moreover, the startup configuration datastore MUST be > pre-configured ..." > -- where is the "startup configuration datastore" defined in the architecture? [Authors] The term "startup configuration datastore” is defined in RFC 6241 (NETCONF) and used in RFC 8040 (RESTCONF). RFC 7950 (YANG 1.1) mentions the startup since it is very related to NETCONF. We can include that term in section 3 and refer to RFC 6241. > -- How is it provisioned (is this out of scope?)? [Authors] Yes, that is out of scope. That would happen before the NSF is deployed. It is an initial pre-configuration. > > (40) Section 9. Typo. s/always apply first/always first apply/ > > (41) Section 9. Per "In general, the Security Controller, as typically in the > SDN paradigm, is a target for different type of attacks . Thus, the Security > Controller is a key entity in the infrastructure and MUST be protected > accordingly ...", what are the details here? Section 13 of [ITU-T.Y.3300] > says "Moreover, a logically centralized controller can be a single point of > failure, and can be a target of malicious attacks, thus special attention is > required." and Section 7 of [8192] doesn't mention the security controller at > all. [Authors] The details about security in SDNs are in the literature, as you refer. As per your comment we can refer to [ITU-T.Y.3300] and remove [8192]. Moreover in RFC 7426, in the Security section part there is text: "That said, security is paramount in networking; thus, it should be given full consideration when designing a network architecture or operational deployment. Security in SDN is discussed in the literature, for example, in [SDNSecurity], [SDNSecServ], and [SDNSecOF]” We can also include some of these references. > > (42) Section 9.1. Should configurations adhere to the algorithm > recommendations of RFC8247? [Authors] Yes. We will add this reference. > > (43) Section 9.1 and 9.2. Per "The general recommendation is that the > Security Controller MUST NOT store ...", is this a recommendation or a > normative "MUST NOT". To me, the use of the language "general > recommendation" suggests it is optional. I recommend: > > OLD > The general recommendation is that the Security Controller MUST NOT store the > IKE credentials after distributing them. > > NEW > The Security Controller MUST NOT store the IKE credentials after distributing > them [Authors] Thank you. Your text is better. > > (44) Section 9.1. Editorial. s/One option is to return always ..../One > option is to always return .../ > > (45) Section 9.1. Per "Moreover, the PSK MUST have a proper length (e.g. > minimum 128 bit length) and strength", what is the recommended guidance - it > is that PSKs need to have 128-bit strength? The normative guidance in a > parenthetic example is not clear. [Authors] True. This is related to comment 42. Referring to RFC 8247 is proper here too. After all, the proper key length will depend on the PRF used for generating the AUTH payload in IKEv2. > > (46) Section 9.1. "How the NSF generates these cryptographic material (public > key/private keys) and export the public key, or it is instructed to do so , > it is out of the scope of this document." > -- what is meant by "or it is instructed to do so”? [Authors] In our mind, the NSF can generate automatically the public/private keys and export the public when it starts up or only when the Security Controller instructs the NSF to generate public/private keys. In any case, after your comment we think we can simplify the text removing that part: "How the NSF generates these cryptographic material (public key/private keys) and exports the public key is out of scope of this document.” > -- s/export/exports/ > -- s/it is out of the scope/is out of scope/ Best Regards and thank you very much again, authors. > > Regards, > Roman > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] -------------------------------------------------------
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
