Hi, Please find my comments of the draft-i2rs-architecture's security considerations:
Comment 1: "Two of existing protocol which the I2RS WG has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. The I2RS protocol design process is to specify additional requirements which will include security for an existing protocol in order to support the I2RS architecture." We should make clear why NETCONF or RESTCONF have been selected in this section. More specifically, if NETCONF or RESTCONF has some interesting security properties, they should be exposed here. In addition, the scope of the security consideration section should be protocol independent. Comment 2 "Due to the re-use strategy of the I2RS architecture, this security section describes the assumed security environment for I2RS with additional detail on:" I believe security should be introduced within the i2rs scope. I would propose the following text: “At first I2RS should consider its interactions with existing interfaces that manipulate the routing system resources, like the management plane or the routing control plane for example. The scope of identifying these interactions is to limit how I2RS impacts these already existing interfaces as well as how these existing interfaces impact I2RS. Within the I2RS architecture, there is a strong need that the routing system resource remain protected. This means that strong Authentication Authorization and Access control policies should be enforced between the different entities involved in the I2RS architecture. This includes considerations on Identity, Authentication, Authorization. Then in order to be enforced, these policies should rely on a robust and highly available I2RS architecture. This describes I2RS security with additional details on:" Comment 3 " To support numerous and speedy interactions between the I2RS Agent and I2RS Client, it is assumed that the I2RS Agent can also cache that particular I2RS Clients are trusted and their associated [page break] authorized scope. This implies that the permission information may be old either in a pull model until the I2RS Agent re-requests it, or in a push model until the authentication and authorization channel can notify the I2RS Agent of changes." This does not seems to me a security issue, but instead a performance aspect. One option is to remove these lines. If performance still got its place here, I would propose the following text: "In order to provide the AAA enforcement policies a similar scalability as the scalability provided by the I2RS Client broker architecture, some means should be provided in order to distribute the authorization policies among the I2RS Clients. More specifically, an I2RS Client should be able to retrieve the I2RS Agent AAA policies that apply to itself. When an application sends a resource access to the I2RS Client that would be rejected by the I2RS Agent, this request could be rejected by the I2RS Client instead. This avoids loading unnecessarily the network and the I2RS Agent. On the other hand, as AAA of the I2RS Agent are subject to changes, the I2RS Client should be informed when these changes occurs." Comment 4 "An I2RS Client is not automatically trustworthy" I would propose the following rewordings, which seems at least for me clearer: “I2RS Agent do not inherently trust I2RS Client.” Comment 5 " If the I2RS Client is acting as a broker for multiple applications, managing the security, authentication and authorization for that communication is out of scope;" I would propose the following words: "If the I2RS Client is acting as a broker for multiple applications, managing the security, authentication and authorization for that application is out of scope of I2RS;" Comment 6 "Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. " I would probably add this where “Mutual authentication” is discussed. In addition those two paragraphs could be placed in section 4.1. I found confusing to speak about different levels as we do not consider weak, strong or no authentication/encryption. Thus I would rather propose to say “Authentication or Encryption are not mandatory” instead of talking about levels. The proposed text would be: "Different security mechanisms for integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. “Authentication or Encryption are not always mandatory" Comment 7 "For example, a I2RS client may request notifications of certain events and the agent will open a communication channel to report such events." I understand that it is possible for example for an I2RS Client to open a communication so event are reported to a third party, for example a shared repository. This prevents that the same flow is being sent to multiple I2RS Clients requesting for it. In this case, I do not think that authentication is sufficient. Instead the destination of the flow must agree to receive the flow. Suppose multiple authenticated I2RS Client opens a channel on shared_repo_x. As shared_rep_x has not been part of the negotiation, it may become overloaded. Comment 8 section 4.1 "While those applications' identities are not needed for authentication or authorization, " I would propose the following text: "The secondary identities are not used for authentication or authorization purpose by the I2RS Agent. In fact the I2RS Agent only authenticate the I2RS Client. On the other hand, for tracking attribution of operations to support functionality such as troubleshooting and logging of network changes, the I2RS Client may provide the secondary identities to the I2RS Agent. " Comment 9 section 4.3 "I2RS must support client redundancy. At the simplest, this can be handled by having a primary and a backup network application that both use the same client identity and can successfully authenticate as such." I suggest that “network application” be replaced by “I2RS Client”. Additional Comments A) Section 1.1 It is not very clear to me what is an ephemeral state: "Such an interface also facilitates the injection of ephemeral state into the routing system." The explanation of ephemeral state comes in section 6.2.1. Unless, this is well known vocabulary, I would clarify this at the first time it appears, and so directly in this section 1.1. B) Section 3 I suppose "... and because the performance and scaling requires varies based on the particular use-cases." should be replaced by "... and because the performance and scaling requirements varie based on the particular use-cases." C) Section 4.1 I suppose "even information" should be replaced by “event information” D) Section 4.2 I suppose "can be specify" should be replaced by "can be specified" I suppose "is linked a" should be replaced by "is linked to" I suppose 'that contained' should be replaced by "that is contained" I suppose "This scope policy is can be" should be replaced by "This scope policy can be" E) Section 6.2.1 In the section NOTIFICATION_I2RS_AGENT_STARTING: It look sto me the following sentence is wrong : "... The agent-boot-count allows an I2RS Client to determine if the I2RS Agent has restarted". Instead, it should be replaced by "... The agent-boot-count allows an I2RS Client to determine if the I2RS Agent has restarted since the routing element has restarted" -- Daniel Migault Ericsson
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
