Subject: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

From: "Susan Hares" <[email-masked]>
Date: Mon, 17 Aug 2015 13:49:33 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Aug 2015 19:54:17 +0200

> We will post the security directorate review to this discussion. 

I believe there should be at max 1 I2RS security requirements document
to avoid overlap and thus to improve overall document review and
processing efficiency.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Joe Clarke <[email-masked]>
Date: Mon, 17 Aug 2015 14:02:16 -0400

On 8/17/15 13:49, Susan Hares wrote:
> draft-mglt-i2rs-security-requirements.  This draft discusses the
> security requirements for the I2RS environment.  You can find the draft at:
>
> 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.

I support adoption of this draft.

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 17 Aug 2015 14:04:22 -0400

Juergen: 

Normally, I would agree with you.  However, these environmental security
issues are not directed at the I2RS protocol but the environment.  I thought
it would be clearer to have this split so the I2RS protocol development work
would not need to considered these hard requirements for the protocol. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, August 17, 2015 1:54 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; [email-masked]; 'Joel
Halpern'; 'Alia Atlas'
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG
adoption call (8/17 to 8/31)

> We will post the security directorate review to this discussion. 

I believe there should be at max 1 I2RS security requirements document to
avoid overlap and thus to improve overall document review and processing
efficiency.

/js

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Aug 2015 14:28:24 -0400

As a co-author, I believe this document is ready for Working Group 
Adoption.  Looking forward to comments on how to improve the document.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Aug 2015 20:34:36 +0200

> would not need to considered these hard requirements for the protocol. 

I reviewed both documents before the last IETF meeting and I believe
one document is all that is needed.

/js

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 17 Aug 2015 18:39:04 +0000

Yes/support

Regards,
Jeff

On Aug 17, 2015, at 10:49 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

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:

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Aug 2015 14:40:32 -0400

If others in the WG agree with you, presumably the chairs will direct 
that and we will do so.

Having tried to work on a single document, it seemed to us to be MUCH 
cleaner to have two separate ones.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 17 Aug 2015 15:38:22 -0400

Juergen: 

Thank you for letting me know you would like these two documents merged.
Your advice is always wise.  Let's see what other people think about 1
security document or two. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, August 17, 2015 2:35 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; [email-masked]; 'Joel
Halpern'; 'Alia Atlas'

On Mon, Aug 17, 2015 at 02:04:22PM -0400, Susan Hares wrote:
> Juergen: 
> 
> Normally, I would agree with you.  However, these environmental 
> security issues are not directed at the I2RS protocol but the 
> environment.  I thought it would be clearer to have this split so the 
> I2RS protocol development work would not need to considered these hard
requirements for the protocol.

I reviewed both documents before the last IETF meeting and I believe one
document is all that is needed.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 17 Aug 2015 15:38:46 -0400

Joel: 

I agree it was much clearer as two documents. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, August 17, 2015 2:41 PM
To: [email-masked]; [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG

If others in the WG agree with you, presumably the chairs will direct that
and we will do so.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 20 Aug 2015 22:42:45 +0000

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

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

-          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)
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-masked]] On Behalf Of Susan Hares
Sent: Monday, August 17, 2015 12:50 PM
To: [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel Halpern'; [email-masked]; 'Alia Atlas'
Subject: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

Sue Hares

---

From: Daniel Migault <[email-masked]>
Date: Fri, 21 Aug 2015 09:49:06 -0400

As a co-author of the document, I believe the document is ready for
adoption. Feel free to comment so we can improve the document for its next
iteration.

BR,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Fri, 21 Aug 2015 11:26:48 -0400

Hi,

Please note that the subject of the email may be misleading as it indicates
a different draft name from the one indicated in the link. For
clarification, the draft we consider is the one indicated by the link.

BR,
Daniel

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 21 Aug 2015 11:52:43 -0400

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:
>
> -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)
>
> 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 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.
>
> *From:*i2rs [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Monday, August 17, 2015 12:50 PM
> *To:* [email-masked]
> *Cc:* 'Jeffrey Haas'; [email-masked]; 'Joel Halpern';
> [email-masked]; 'Alia Atlas'
> *Subject:* [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Aug 2015 16:48:42 +0000

Joel, 

The document that I reviewed and provided comment is " http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/"

I started to review  " draft-mglt-i2rs-security-environment-reqs-00" today, and find out it has the similar Table of content as the "draft-mglt-i2rs-security-requirements-00". What is the intent of the  "environment-reqs"? supplement to "i2rs-security-requirement" or be replaced by, or something else? 

Linda
-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 10:53 AM
To: Linda Dunbar; [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; '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:
>
> 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.
>
> "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:
>
> Section 3.4 has title "Recommendations", but the content are all 
> requirements. Why not name the section "Requirement"?
>
> 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"?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Aug 2015 12:51:45 -0400

draft-mglt-security-requirements was replaced by 
draft-mglt-i2rs-security-environment, and some of the first documents 
content were moved into Sue's document which was also last called.

When the last call was issued, it provided the correct URL, but 
accidentally copied the draft name from the earlier draft.

Once we realized this, Daniel sent his note to the list to try to explain.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Aug 2015 16:56:44 +0000

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-masked]] 
Sent: Friday, August 21, 2015 10:53 AM
To: Linda Dunbar; [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel Halpern'; 'Alia Atlas'
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Aug 2015 13:19:41 -0400

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 24 Aug 2015 17:37:09 +0000

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?

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-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, August 21, 2015 12:20 PM
To: Linda Dunbar; [email-masked]
Cc: 'Jeffrey Haas'; [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

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:
> To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
> Cc: 'Jeffrey Haas'; [email-masked]<mailto:[email-masked]>; 'Joel Halpern'; 'Alia Atlas'
>> When you think about the I2RS security,  there are following
>> different
>> aspects:
>>
>> *To:* [email-masked]<mailto:[email-masked]>
>> *Cc:* 'Jeffrey Haas'; [email-masked]<mailto:[email-masked]>; 'Joel Halpern';
>> [email-masked]<mailto:[email-masked]>; 'Alia Atlas'
>> https://tools.ietf.org/html/draft-mglt-i2rs-security-environment-reqs
>> -
>> 00
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Aug 2015 19:41:25 +0200

> But the "environment-req" draft is not about "Protocol", but about security issues under different "environment".

For me, this reads as another reason for having one security
requirements document instead of two...

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Aug 2015 11:02:43 -0700

Hi,

I will leave it to the Security ADs to decide whether a non-secure transport
for I2RS should be standardized.

The "lean" I2RS seems to be a proprietary controller and agent
with no multi-headed control support. This will almost certainly
mean that the router will not work if any "unofficial"
controller is used instead of the vendor controller.

If this really is the expected usage then why bother with a standard?

Andy

On Mon, Aug 24, 2015 at 10:37 AM, Linda Dunbar <[email-masked]>
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.
>
> 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?
>
> 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.
>
> From: i2rs [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Joel M. Halpern
> 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.
>
> > 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
> >
> >
> > From: Joel Halpern Direct [mailto:[email-masked]
> <[email-masked]>]
> 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.
> >
> may be hosted" is well taken, and we should remove that text when we next
> revise the document.
> >
> >> *From:*i2rs [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Aug 2015 16:58:41 -0400

Daniel:

I apologize for the confusion.  I plan to adopt the draft.  If you know of anyone who has strong opinions against, please let me know. 

Sue  

From: i2rs [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Friday, August 21, 2015 11:27 AM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]; Joel Halpern; Alia Atlas
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

Hi, 

Please note that the subject of the email may be misleading as it indicates a different draft name from the one indicated in the link. For clarification, the draft we consider is the one indicated by the link. 

BR, 

Daniel

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Aug 2015 17:05:46 -0400

Daniel: 

The last message was not clear.  Let me try again as it might be confusing as to which hat I was wearing. 

[2nd attempt] 

<co-chair hat on> 

I apologize for the confusion on the draft.  At this point, we’ve had lots of feedback from people on the list.  No-one has indicated we should not adopt this draft as the beginning of this work on security environments. 

Linda, Jeff, Russ and others are making great suggestions for fixing this draft.   At this point unless we get lots of complaints between now and 8/31, it appears we should adopt the draft. 

Juergen suggests we make one draft.  This might be the right long term solution, but as we work on the drafts I think we should refine the documents as two document.   In September, I will call for an opinion on whether we could converge the drafts into 1 draft. 

<co-chair hat off> 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, August 27, 2015 4:59 PM
To: 'Daniel Migault'
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel Halpern'; 'Alia Atlas'
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

Daniel:

Sue  

Hi, 

BR, 

Daniel

Sue Hares