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
On 8/21/15 12:48 PM, Linda Dunbar wrote:
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 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]] *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
