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)

From: Daniel Migault <[email-masked]>
Date: Mon, 24 Aug 2015 13:55:01 -0400

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

---

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

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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Monday, August 24, 2015 12:55 PM
To: Linda Dunbar
Cc: Joel M. Halpern; [email-masked]; 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 <[email-masked]<mailto:[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?

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

-----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]<mailto:[email-masked]>
Cc: 'Jeffrey Haas'; [email-masked]<mailto:[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:
> 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
>
>
> From: Joel Halpern Direct [mailto:[email-masked]]
> To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
> Cc: 'Jeffrey Haas'; [email-masked]<mailto:[email-masked]>; 'Joel Halpern'; 'Alia Atlas'
> 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
>
>> However, I hope the authors can consider/address the following suggestions/comments:
>>
>> on the subject. I think 4.4.1 and 4.42 can be separated out of the section.
>>
>> security requirement/issues? Or does it mean they need different protocols?
>>
>> send any information beyond what have been defined by the I2RS data model"?
>>
>> Malicious client can occupy the resource while the valid one can't access.
>>
>> *From:*i2rs [mailto:[email-masked]] *On Behalf Of *Susan Hares
>> *To:* [email-masked]<mailto:[email-masked]>
>> *Cc:* 'Jeffrey Haas'; [email-masked]<mailto:[email-masked]>; 'Joel Halpern';
>> [email-masked]<mailto:[email-masked]>; 'Alia Atlas'
>> security requirements for the I2RS environment.  You can find the draft at:
>>

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

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

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 25 Aug 2015 16:21:04 +0000

Daniel,

I added 3 more I2RS security requirements for the “Closed Environment”, please use the revised section attached.

Cheers,
Linda

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, August 24, 2015 5:09 PM
To: Daniel Migault
Cc: Jeffrey Haas; [email-masked]; 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,

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Monday, August 24, 2015 12:55 PM
To: Linda Dunbar
Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; 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,

Section 3:

-----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]<mailto:[email-masked]>
Cc: 'Jeffrey Haas'; [email-masked]<mailto:[email-masked]>; 'Alia Atlas'
Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

Yours,
Joel

---

From: Daniel Migault <[email-masked]>
Date: Tue, 25 Aug 2015 13:04:10 -0400

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 <[email-masked]>
wrote:

> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, August 24, 2015 5:09 PM
> *To:* Daniel Migault
> *Cc:* Jeffrey Haas; [email-masked]; 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:* [email-masked] [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Daniel Migault
> *Sent:* Monday, August 24, 2015 12:55 PM
> *To:* Linda Dunbar
> *Cc:* Joel M. Halpern; [email-masked]; 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,
>

---

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

Linda: 

I think that addressing the difference between machines in a closed system (sometimes called a “systems within a garden wall”) is important to address in the environmental draft. 

I will work with Daniel to insert this in our draft.   I believe the draft is a good start for a environmental draft. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, August 24, 2015 6:09 PM
To: Daniel Migault
Cc: Jeffrey Haas; [email-masked]; 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, 

Linda

Hi Linda, 

BR, 

Daniel

On Mon, Aug 24, 2015 at 1:37 PM, Linda Dunbar <[email-masked]> wrote:

Joel, 

|       *                     *   |      *                     *  |

|               #                 |            |        |         |

|               #                 |            |        |   |-----|

|               #               |                     |   |

 

 

 

Section 3: 

 

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)

Yours,

Joel

> Cc: 'Jeffrey Haas'; [email-masked]; 'Joel Halpern'; 'Alia Atlas'

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

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

Linda: 

Thank you for your additional thoughts on the closed system (garden wall system) vs. open system. 

REQ c+2: The I2RS Client should have preconfigured threshold for each category that can be requested or changed by its allowed applications. When the prefigured threshold is crossed, alarms should be generated. 

By pre-configured threshold category – I suspect you category of security errors or warnings. 

Sue 

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2015 12:21 PM
To: Linda Dunbar; Daniel Migault
Cc: Jeffrey Haas; [email-masked]; Joel M. Halpern; Alia Atlas; Susan Hares
Subject: RE: [i2rs] Suggested section/text to be added to draft-mglt-i2rs-security-environment-reqs-00 to address security threats in Closed Envionment.

Daniel, 

Cheers, 

Linda

Daniel, 

Linda

Hi Linda, 

BR, 

Daniel

Joel, 

|       *                     *   |      *                     *  |

|               #                 |            |        |         |

|               #                 |            |        |   |-----|

|               #               |                     |   |

 

 

 

Section 3: 

 

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)

Yours,

Joel

i2rs mailing list