Hi, Please find the new version for the draft-mglt-i2rs-security-environment-reqs. [1]. The version has considered the comments we received on the ML. Thank you for submitting them. Here is a summary of what has been addressed.
I) Addressing Comments from Russ Housley II) Addressing Comments from Linda Dundar III) Addressing the REQ3 Discussion IV) Addressing Comments from Jeffrey Haas BR, Daniel [1] https://www.ietf.org/internet-drafts/draft-mglt-i2rs-security-environment-reqs-01.txt %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% I) Addressing comments from Russ Housley: %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In Section 1, the first sentence says: "This document addresses security considerations for the I2RS architecture." This does not seem like the right way to begin this document. This document seems to contain requirements on an implementation or deployment. They are not protocol requirements, which is what I expected from the draft file name. This context needs to be set in the Abstract and the first paragraph of the Introduction. MGLT: Thank you for the feed back. We addressed this comment by starting the introduction (Section 1) with the following sentences : This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. As a result, the requirements provided in this document are intended to provide good security practise so I2RS can be securely deployed and operated. Section 4.1 talks about the I2RS AAA architecture, but it does not cover authentication, authorization, and accounting. The section seems to be talking about roles, privileges, and role-based access control. Maybe the title of the section should be changed. MGLT The title has been changed to "I2RS Access Control for routing system resources" AAA has been replaced by Access Control. We also completely re-write the section. In Section 4.2, REQ 17, I find the use of "origin" unclear. The origin is the I2RS Client, not the application, right? MGLT: REQ 17 corresponds to REQ 16 of the draft-mglt-security-environment-reqs-00. It is unclear. I removed the term origin and distinguish two cases one when the access control is made for the I2RS Client and one for the application. The text of the whole section has been updated and hopefully clarified. The term origin and component have been removed and replaced explicitly by Application, I2RS Client or I2RS Agent or identity. In Section 4.2, REQ 19, I find the use of "component" unclear. The component is the I2RS Client, not the application, right? MGLT: component is unclear and has been removed. In section 4.3, 1st paragraph, I think this would be more clear without the use of "component". That is, the I2RS client is responsible for authentication of the applications, managing the privileges for the applications, and enforcing access control to resources by the applications. MGLT: component is unclear and it has been removed. I do not understand Section 4.4. If an I2RS Client authenticates to I2RS Agent 1 and 2, it is possible that these agents will grant different privileges to this client. Is a security domain a set of agents that are expected grant the same privileges to this client? What does availability have to do with the definition of a security domain? Maybe these two topics should be in separate sections. DoS is also talked about in Section 5.2; I think that it would help the reader if all of the availability discussions are in one place. MGLT: This section is too redundant with I-D.hares-i2rs-auth-trans. The main message was that local policies enforcement is not sufficient, and communications between points should be considered secured. This has been added in the Access Control architecture sub section. In addition, we added how transport and access control interact in the access control section. In Section 4.2, REQ 20, I think the wording needs to be clarified to indicate that I2RS Clients cane support multiple applications at the same time, and each of them needs to be authenticated. MGLT: We explicitly specify the case of multiple applications. In Section 5.1, REQ 29, It is unclear to me what part of the system is performing this monitoring. When an error is detected, what part of the system takes corrective actions? MGLT: The agent and client are expected to monitor, log, and eventually send alerts. The management plane is responsible in collecting and taking the appropriated decisions like updating Access Control policies, reconfiguring routing elements...) In Section 4.2: s/On the hand/On the other hand/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% II) Addressing Comments from Linda Dundar %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - Communication channel between I2RS client and Agent (and the channel between I2RS client and applications): The channel can be o Via physical Private network (e.g. within a secured direct connect within one site), o within one administrative domain, via virtual private network o Secured connection, such as TLS or IPSec o Public internet o .. MGLT: Thank for the clarification. I think that our REQ1 catches these aspects as a way to isolate the I2RS plane from other. For communications themselves, this version mostly redirects to hares-securtity I-D.hares-i2rs-auth-trans. Please let me know if you think we do not address your purpose. - Authentication & Authorization o the authentication & authorization requirement for different communication channels can be different. Therefore, should have separate sections to address specific requirement for each communication channels between I2RS agent <-> clients (and client <-> applications) MGLT: Thank you for the comment. We have re-written the section 4 and I hope the current section 4 on access control considers these aspects with the following sections: 4.1. I2RS Access Control architecture . . . . . . . . . . . . 8 4.2. I2RS Agent Access Control policies . . . . . . . . . . . 12 4.3. I2RS Client Access Control policies . . . . . . . . . . . 13 4.4. Application and Access Control policies . . . . . . . . . 14 The current Section 4 of the draft already has very good description on the subject. I think 4.4.1 and 4.42 can be separated out of the section. MGLT: Thank you for pointing out the split. the section 4.4 has been removed and outsourced to the I2RS Access Control and in the draft-ietf-ares-protocol security requirements draft. - Encryption for the actual content between Client and Agent MGLT: Similarly, we have moved to the I2RS Access Control and in the draft-ietf-ares-protocol security requirements - DoS Design requirement (currently in Section 5.2.1) - Management of conflict with other plane (e.g. the management plane, multi-headed control, which has been discussed extensively in ephemeral draft) MGLT: The reference to the draft has been added. However, the recommendations were mostly pointing to the text from the i2rs architecture document. I think the draft should be organized from the aspects of the security to I2RS as suggested above. Here are some detailed questions and comments to the requirements listed in the document: Section 1: The second paragraph stated the security recommendations must “specifying where security functions may be hostedâ€. First of all I don’t see the draft address this aspect. Second, I think “where security functions are hosted†is orthogonal to “I2RS security†. MGLT: I agree with your comment and we have removed the text from the section. Section 3: what does isolating two planes mean? does it mean they have different security requirement/issues? Or does it mean they need different protocols? MGLT: Each plane has a specific scope of function. What are the key differences with regard to the security requirements for I2RS plane and for management plane? Section 3.1 describes the interaction between I2RS plane and management plane. But I see the security requirement for the management plane is similar to I2RS plane . If you think that they are very different, can you elaborate more? MGLT: Thanks for the remark. Here is the text we added. Feel free to us know is you think it is not clear enough. "The I2RS plane purpose is to provide a standard programmatic interface of the routing system resources to network oriented applications. Control plane and forwarding planes are related to routing protocols, and I2RS is based on top of those. The management plane is usually vendor specific, provides a broader control over the networking equipment such as system service. Given its associated privileges it is expected to be reserved to highly trusted users like network administrators." Section 3.4 has title “Recommendationsâ€, but the content are all requirements. Why not name the section “Requirementâ€? MGLT: I prefer "Recommendation" at least for this section, as the way they are implemented and enforce vary widely according to the environment. However, I am open for discussion, and it could be moved to Requirements in the future. REQ 2: Does it that a different IP address than the one used by the management system? MGLT: Yes, we recommend that having a dedicated IP address or dedicated NIC to enforce isolation. How is REQ 22 different from REQ 21? MGLT: Agree, they are very closed. We have outsourced these requirements to the transport requirements. REQ 27 is hard to enforce. How about say something like "shouldn't send any information beyond what have been defined by the I2RS data model"? MGLT: Agree. This is much better. However, we have outsourced this requirements to the transport requirements. REQ 30: simply controlling the resource can hardly prevent DoS. Malicious client can occupy the resource while the valid one can't access. MGLT: This is true, however, what I meant here was to control resource so one tenant does not over consume resources. %%%%%%%%%%%%%%%%%%%%%%%%% %%% III) Addressing the REQ3 Discussion %%% %%%%%%%%%%%%%%%%%%%%%%%%%% Based on the discussion with Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, Alia Atlas REQ 3 has been removed. "The I2RS Client SHOULD be able to log the activity of each of the Applications. These activities SHOULD also be checked against the I2RS AAA, in order to check the I2RS Client AAA is appropriately implemented." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% IV) Addressing Comments from Jeffrey Haas %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I have some contrary thoughts on the AAA section of this document. MGLT: The AAA section has completely be re-written. Section 4.1 tries to describe requirements wherein the I2RS Clients may request for subsets of AAA policy to be exported to the Client so that the client may enforce them. While this seems like a nice way to scale the operations, in some cases disclosing those policies (even if we find a good way to encode the AAA validation in a generic enough way to distribute) may accidentally disclose information that is otherwise intended to be secure. MGLT: Thanks for pointing out this issue. Information leakage has been added in the document as something to balance with a distributed access control system. I would seek comment from the security directorate, but I suspect we don't want to do this. But in section 4.4, we try to discuss availability. The first sentence immediately says "enforcement should not remain local", while one way to enable security in some environments is to distribute and synchronize policy to be enforced locally. It then goes on to talk about general availability mechanisms and then we further dive into security against DoS. MGLT: I agree with the comment. The section 4.4 has been removed and all DoS specific consideration has been keept in a specific section to make the document more coherent. 4.4. I2RS AAA Security Domain . . . . . . . . . . . . . . . . 12 4.4.1. Available I2RS Communication Channel . . . . . . . . 12 4.4.2. Trusted I2RS Communications Channel . . . . . . . . . 14 Have been removed. I believe we may be boiling the ocean a bit to try to go into too many details about the design of secure AAA systems. It seems a bit out of scope for I2RS to do such work; we should defer to work done elsewhere on the topic, if it exists. If it doesn't exist, I'm not sure we should do it. What is right for us to point out is, "If we use a remote AAA mechanism, it must be robust in hostile environments". Expand that as you will, but being too proscriptive is not our job. MGLT: I agree with the comment. I hope the new version of the section address your comment. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Friday, October 02, 2015 9:52 AM To: Susan Hares; Joel Halpern; Joel Halpern; Daniel Migault; Daniel Migault; Susan Hares Subject: New Version Notification for draft-mglt-i2rs-security-environment-reqs-01.txt A new version of I-D, draft-mglt-i2rs-security-environment-reqs-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-i2rs-security-environment-reqs Revision: 01 Title: I2RS Environment Security Requirements Document date: 2015-10-02 Group: i2rs Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-mglt-i2rs-security-environment-reqs-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-i2rs-security-environment-reqs/ Htmlized: https://tools.ietf.org/html/draft-mglt-i2rs-security-environment-reqs-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-i2rs-security-environment-reqs-01 Abstract: This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. As a result, the requirements provided in this document are intended to provide good security practise so I2RS can be securely deployed and operated. These security requirements are designated as environment security requirements as opposed to the protocol security requirements described in [I-D.ietf-i2rs-protocol-security-requirements]. The reason to have separate document is that protocol security requirements are intended to help the design of the I2RS protocol whether the environment requirements are rather intended for deployment or implementations. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
