Hi Linda,
Thank you for your feed back. We considered them - with all other feed
backs we receievd. We beleive the new version address all of them. Feel
free to let us know if we missed something. Here is a small recap of the
modifications performed to address your comments.
BR,
The co-authors
Comments / Responses for Linda's comments:
- 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 ..
MGLT: Thank for the clarification. I think that our REQ1 catches these
aspects as a way to isolate the I2RS plane from other. For communications
themselves, this version mostly redirects to hares-securtity
I-D.hares-i2rs-auth-trans.
Please let me know if you think we do not address your purpose.
- 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)
MGLT: Thank you for the comment. We have re-written the section 4 and I
hope the current section 4 on access control considers these aspects with
the following sections:
4.1. I2RS Access Control architecture . . . . . . . . . . . . 8
4.2. I2RS Agent Access Control policies . . . . . . . . . . . 12
4.3. I2RS Client Access Control policies . . . . . . . . . . . 13
4.4. Application and Access Control policies . . . . . . . . . 14
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.
MGLT: Thank you for pointing out the split. the section 4.4 has been
removed and outsourced to the I2RS Access Control and in the
draft-ietf-ares-protocol security requirements draft.
- Encryption for the actual content between Client and Agent
MGLT: Similarly, we have moved to the I2RS Access Control and in the
draft-ietf-ares-protocol security requirements
- 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)
MGLT: The reference to the draft has been added. However, the
recommendations were mostly pointing to the text from the i2rs architecture
document.
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†.
MGLT: I agree with your comment and we have removed the text from the
section.
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?
MGLT: Each plane has a specific scope of function.
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?
MGLT: Thanks for the remark. Here is the text we added. Feel free to us
know is you think it is not clear enough.
"The I2RS plane purpose is to provide a standard programmatic interface of
the routing system resources to network oriented applications. Control
plane and forwarding planes are related to routing protocols, and I2RS is
based on top of those. The management plane is usually vendor specific,
provides a broader control over the networking equipment such as system
service. Given its associated privileges it is expected to be reserved to
highly trusted users like network administrators."
Section 3.4 has title “Recommendationsâ€, but the content are all
requirements. Why not name the section “Requirement�
MGLT: I prefer "Recommendation" at least for this section, as the way they
are implemented and enforce vary widely according to the environment.
However, I am open for discussion, and it could be moved to Requirements in
the future.
REQ 2: Does it that a different IP address than the one used by the
management system?
MGLT: Yes, we recommend that having a dedicated IP address or dedicated NIC
to enforce isolation.
How is REQ 22 different from REQ 21?
MGLT: Agree, they are very closed. We have outsourced these requirements to
the transport requirements.
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"?
MGLT: Agree. This is much better. However, we have outsourced this
requirements to the transport requirements.
REQ 30: simply controlling the resource can hardly prevent DoS. Malicious
client can occupy the resource while the valid one can't access.
MGLT:
This is true, however, what I meant here was to control resource so one
tenant does not over consume resources.
On Wed, Sep 2, 2015 at 8:33 PM, Susan Hares <[email protected]> wrote:
> Linda
>
> <co-author hat on>
>
> We will include closed environments in the revised document.
>
>
>
> Sue
>
>
>
> *From:* i2rs [mailto:[email protected]] *On Behalf Of *Linda Dunbar
> *Sent:* Wednesday, September 02, 2015 12:54 PM
> *To:* Susan Hares; [email protected]
> *Cc:* 'Jeffrey Haas'; 'Netconf'
> *Subject:* Re: [i2rs] 1 week extension to WG Adoption call for
> draft-mglt-i2rs-security-environments
>
>
>
> Can the authors address my comments and the suggested changes to add a
> section on security threats and the associated requirements with Closed
> Environment?
>
>
>
> 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.
>
>
>
> Attached is my suggested text.
>
>
>
> Linda
>
>
>
> *From:* i2rs [mailto:[email protected] <[email protected]>] *On
> Behalf Of *Susan Hares
> *Sent:* Tuesday, September 01, 2015 12:10 PM
> *To:* [email protected]
> *Cc:* 'Jeffrey Haas'; 'Netconf'
> *Subject:* [i2rs] 1 week extension to WG Adoption call for
> draft-mglt-i2rs-security-environments
>
>
>
> This is a 1 week extension to the WG adoption call for
> draft-mglt-i2rs-security. Due error in the initial call email, the exact
> text to review was unclear (
> https://mailarchive.ietf.org/arch/msg/i2rs/wwv1o8_mwurB05dN4D2yjr9tNFg).
>
>
>
> In reviewing the email, it appears that the authors have agree to change
> or delete most of the concerns except for combining this draft with
> draft-hares-i2rs-auth-trans-04.txt. The chairs have decided to adopt both
> drafts as WG drafts, and make a subsequent WG calls to determine if the
> drafts should be combined.
>
>
>
> This draft is at:
>
>
>
> https://www.ietf.org/id/draft-mglt-i2rs-security-environment-reqs-00.txt
>
>
>
> Daniel has indicated several changes on the list. If you would like to
> see a revised draft for further comments, please indicate this on the list.
>
>
>
> Sue Hares and Jeff Haas
>
> I2RS co-chairs
>
>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
