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)

[Daniel Migault <[e-mail]>]

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
>
>