Hi Linda, Thank you for your comments. I agree we need to address more specifically or explicitly the "most common" use case. I agree with your comments and we will consider them to improve and clarify the text of the next version. Thank you. To me the i2rs plane provides a limited number of functionnalities that may be provided to different independant tenants.
BR, Daniel On Mon, Aug 24, 2015 at 1:37 PM, Linda Dunbar <[email protected]> wrote: > Joel, > > Agree with you that “we don’t need to build different protocol stacks for > the different deployments”. > But the “environment-req” draft is not about “Protocol”, but about > security issues under different “environment”. > > Among all our customers who are interested in I2RS, majority of them > (>90%) will deploy them in a closed environment, i.e. physically secured > connection between I2RS agent and I2RS client. Therefore, it is important > to “provides an analysis of the security issues of” of this commonly > deployed environment. > > I suggest adding this Figure to Section 1 of the document: > > Closed (over open Chnl ###>) Open (over secure Chnl --->) > +---------------------------------+ > | *********************** | *********************** | > | * Application A * | * Application B * | > | * * | * * | > | * +----------------+ * | * +----------------+ * | > | * | Client A | * | * | Client B | * | > | * +----------------+ * | * +----------------+ * | > | ******* ^ ************* | ***** ^ ****** ^ ****** | > | # | | | | > | # | | | |-----| > | # | | | > | ************ v * * * * ********| ***************** v * v ******** > | * +---------------------+ | * +---------------------+ * > | * | Agent 1 | | * | Agent 2 | * > | * +---------------------+ | * +---------------------+ * > | * ^ ^ ^ ^ | * ^ ^ ^ ^ * > > > > Just think about this fact: today’s router configuration in production > environment can only be performed by a few authorized people with EMS/NMS > physically and securely separated. If the majority of the I2RS environment > requirement is about open connection, I2RS WG will spend a lot energy > developing the very sophisticated protocols which is expensive to develop > and harder to deploy. > > I am not against this development, but IMHO, to gain wider and quicker > I2RS deployment in production environment, it is necessary to have a very > *lean* I2RS solution first, and to have a well documented security > requirement for the common deployment environment. E.g. a single Controller > (or the I2RS client) directly connected to their devices via their internal > network, where the connection is physically isolated from other network and > protected by separate mechanisms. Also remember, many operators will use > I2RS to control a small number of selective routers (mostly routers at > ingress/egress boundary) for value added services. > > > > Some of my detailed questions and comments to the “security-requirements” > are still applicable to the “environment-req” document because they have > the same text. Plus a few more for the “environment-req” document. Hope the > authors can address them. > > > Section 3: > > 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 are all applicable to the security > requirement to I2RS plane . If you think that they are very different, can > you elaborate more? > > Section 3.4 has title “Recommendations”, but the content are all > requirements. Why not name the section “Requirement”? > > REQ 2: Does it that a different IP address than the one used by the > management system? > > REQ 21: is more about I2RS requirement, less about “Security” requirement. > > REQ 24: isn’t it the general goal of I2RS? Not really security per se. > (should be included in the general I2RS requirement or architecture). > > > REQ 26: simply controlling the resource can hardly prevent DoS. Malicious > client can occupy the resource while the valid one can't access. > > Thanks for your consideration, > Linda > > > -----Original Message----- > From: i2rs [mailto:[email protected] <[email protected]>] On > Behalf Of Joel M. Halpern > Sent: Friday, August 21, 2015 12:20 PM > To: Linda Dunbar; [email protected] > Cc: 'Jeffrey Haas'; [email protected]; 'Alia Atlas' > Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG > adoption call (8/17 to 8/31) > > Yes, one of the two last calls is for the environment document. > > Having a dedicated physical channel is one of the ways identified in the > draft to provide the required isolation. > > While such an environment is clearly supportable, I do not think we should > reduce the internal protocol requirements (such as MTI security for the > control channel) just because there are circumstances where such it won't > be needed. I don't expect that we will build different protocol stacks for > the different deployments. > > The purpose of this draft is to describe the environmental assumptions, > which assumptions can be met in various ways. > > Yours, > Joel > > On 8/21/15 12:56 PM, Linda Dunbar wrote: > > Joel, > > > > If it is the "environmental one", it is more important to differentiate > the requirements for different environments on how the I2RS client & Agent > are connected. > > > > One of our customers stated that their environment has a single > Controller (or the I2RS client) directly connected to their devices via > their internal network, where the connection is physically isolated from > other network and protected by separate mechanisms, they don't need all > those sophisticated authentication procedure. > > > > We need to address this environment, i.e. having a simpler security > requirement for this environment than the environment where I2RS Client is > connected via public network. > > > > Linda > > > > > > -----Original Message----- > > From: Joel Halpern Direct [mailto:[email protected] > <[email protected]>] > > Sent: Friday, August 21, 2015 10:53 AM > > To: Linda Dunbar; [email protected] > > Cc: 'Jeffrey Haas'; [email protected]; 'Joel Halpern'; 'Alia > Atlas' > > Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG > > adoption call (8/17 to 8/31) > > > > First, there may be some confusion because the announcement. I presume > that you are talking about the -environments documents. > > > > If the WG concludes that a different chapter structure is useful, we can > of course change it. Given that the goal is environment description, I am > not sure your proposed structure is significantly better than the existing > one. > > > > I believe your comment about the text reading "where security functions > may be hosted" is well taken, and we should remove that text when we next > revise the document. > > > > The isolation text is about the need to keep things separate, and the > various possible means are degrees / approaches to separation. > > Isolation is not about treating things differently, nor is it explicitly > about using different protocols. So the point of isolation is not that > there are different security requirements, but that in order to avoid > corss-effects, things should be kept separate. > > > > Yours, > > Joel > > > > On 8/20/15 6:42 PM, Linda Dunbar wrote: > >> I support the WG adoption because I think the I2RS WG needs it. > >> However, I hope the authors can consider/address the following > suggestions/comments: > >> > >> When you think about the I2RS security, there are following > >> different > >> aspects: > >> > >> -Communication channel between I2RS client and Agent (and the channel > >> between I2RS client and applications): > >> > >> The channel can be > >> > >> oVia physical Private network (e.g. within a secured direct connect > >> within one site), > >> > >> owithin one administrative domain, via virtual private network > >> > >> oSecured connection, such as TLS or IPSec > >> > >> oPublic internet > >> > >> o.. > >> > >> -Authentication & Authorization > >> > >> othe 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) > >> > >> 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. > >> > >> -Encryption for the actual content between Client and Agent > >> > >> -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) > >> > >> 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" . > >> > >> 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? > >> > >> 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? > >> > >> Section 3.4 has title "Recommendations", but the content are all > >> requirements. Why not name the section "Requirement"? > >> > >> REQ 2: Does it that a different IP address than the one used by the > >> management system? > >> > >> How is REQ 22 different from REQ 21? > >> > >> 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"? > >> > >> REQ 30: simply controlling the resource can hardly prevent DoS. > >> Malicious client can occupy the resource while the valid one can't > access. > >> > >> Thanks for consideration, > >> > >> Linda > >> > >> *From:*i2rs [mailto:[email protected] <[email protected]>] *On > Behalf Of *Susan Hares > >> *Sent:* Monday, August 17, 2015 12:50 PM > >> *To:* [email protected] > >> *Cc:* 'Jeffrey Haas'; [email protected]; 'Joel Halpern'; > >> [email protected]; 'Alia Atlas' > >> *Subject:* [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG > >> adoption call (8/17 to 8/31) > >> > >> This begins a 2 week WG adoption call for > >> draft-mglt-i2rs-security-requirements. This draft discusses the > >> security requirements for the I2RS environment. You can find the draft > at: > >> > >> https://tools.ietf.org/html/draft-mglt-i2rs-security-environment-reqs > >> - > >> 00 > >> > >> A security reviewer will review this draft during the time 8/20 to > >> 8/25. We will post the security directorate review to this discussion. > >> > >> Sue Hares > >> > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
