Re: [i2rs] Suggested section/text to be added to draft-mglt-i2rs-security-environment-reqs-00 to address security threats in Closed Envionment.

[Daniel Migault <[e-mail]>]

Hi Linda,

Thank for the comments. I am currently addressing all comments I received..
I hope I can provide a updated version soon. I will keep you informed as
soon as I have something more or less in shape.

BR,
Daniel

On Tue, Aug 25, 2015 at 12:21 PM, Linda Dunbar <[e-mail]>
wrote:

> Daniel,
>
>
>
> I added 3 more I2RS security requirements for the “Closed Environment”,
> please use the revised section attached.
>
>
>
> Cheers,
>
> Linda
>
>
>
> *From:* i2rs [mailto:[e-mail]] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, August 24, 2015 5:09 PM
> *To:* Daniel Migault
> *Cc:* Jeffrey Haas; [e-mail]; Joel M. Halpern; Alia Atlas
> *Subject:* [i2rs] Suggested section/text to be added to
> draft-mglt-i2rs-security-environment-reqs-00 to address security threats in
> Closed Envionment.
>
>
>
> Daniel,
>
>
>
> Thank you for willing to address my comments. To make it easier for you, I
> put together a section to describe the security threats in Closed
> Environment and necessary requirement for I2RS. See the attached.
>
>
>
> Closed environment deployment can easily give people a sense of secure
> because the links between I2RS Client and I2RS Agent are guided by a
> physical “Wall”.  The false sense of “Secure” is actually more dangerous
> because it can easily make the deployment miss the crucial security
> procedure.
>
>
>
> Therefore, I think it is important to have a dedicated section on security
> threats and requirement for the Closed Environment.
>
>
>
> Linda
>
>
>
> *From:* [e-mail] [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Daniel Migault
> *Sent:* Monday, August 24, 2015 12:55 PM
> *To:* Linda Dunbar
> *Cc:* Joel M. Halpern; [e-mail]; Jeffrey Haas; Alia Atlas
> *Subject:* Re: [i2rs] Review comments to
> draft-mglt-i2rs-security-environment-reqs-00 (was RE:
> draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to
> 8/31)
>
>
>
> 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 <[e-mail]>
> 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:[e-mail] <[e-mail]>] On
> Behalf Of Joel M. Halpern
> Sent: Friday, August 21, 2015 12:20 PM
> To: Linda Dunbar; [e-mail]
> Cc: 'Jeffrey Haas'; [e-mail]; '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:[e-mail]
> <[e-mail]>]
>
> > Sent: Friday, August 21, 2015 10:53 AM
>
> > To: Linda Dunbar; [e-mail]
>
> > Cc: 'Jeffrey Haas'; [e-mail]; '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:[e-mail] <[e-mail]>] *On
> Behalf Of *Susan Hares
>
> >> *Sent:* Monday, August 17, 2015 12:50 PM
>
> >> *To:* [e-mail]
>
> >> *Cc:* 'Jeffrey Haas'; [e-mail]; 'Joel Halpern';
>
> >> [e-mail]; '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
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>