Re: [Netconf] [i2rs] 1 week extension to WG Adoption call for draft-mglt-i2rs-security-environments
Daniel Migault <daniel.migault@ericsson.com> Fri, 02 October 2015 14:45 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFF61B2BD4; Fri, 2 Oct 2015 07:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.122
X-Spam-Level: *
X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju-iIHgPqWrx; Fri, 2 Oct 2015 07:45:54 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AE71A6F61; Fri, 2 Oct 2015 07:45:53 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so37260071wic.0; Fri, 02 Oct 2015 07:45:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SSLBZ680a2iYMcPAcULsKrPBxsMQWwVm5tuMf9ymr5Q=; b=rFj6SAkyfLQ4eEIYsAqqoKkvpPWgU3ICAO50x1IpoEALAiUXg8KURNHeZYS0Cs9IM3 4TpLm2AnAy6Pjlps9QItjoEft96cBX8tHrOjoVlRwPjFYXi0NIAbWIuhsLf+iFYBsJ2w MuWukFUr27tusxalWtTZOtRr2obg1ID+3GeagG/Kgyx7W4FMK2ocYT/52TrodJqkYtDQ XehHOD1bBQbLq0TAnTFwmC0wGUkya8cvmJwFomndH9RfLXhuMOYRfE7PTrcvHbo4aZcY XNEYHbGEzfxv5ZnBPromPcKAMyNi0lluV9AyWYObATUk2VAEIpIHs99LPXtW0vyl3oya KlTw==
MIME-Version: 1.0
X-Received: by 10.180.23.134 with SMTP id m6mr5096215wif.32.1443797152387; Fri, 02 Oct 2015 07:45:52 -0700 (PDT)
Sender: mglt.ietf@gmail.com
Received: by 10.194.88.98 with HTTP; Fri, 2 Oct 2015 07:45:52 -0700 (PDT)
In-Reply-To: <004201d0e5e0$280537d0$780fa770$@ndzh.com>
References: <005101d0e4d8$fb07ddd0$f1179970$@ndzh.com> <4A95BA014132FF49AE685FAB4B9F17F657D1D986@dfweml701-chm> <004201d0e5e0$280537d0$780fa770$@ndzh.com>
Date: Fri, 02 Oct 2015 10:45:52 -0400
X-Google-Sender-Auth: bN38larIUzZAsmeLrnW6H_91mMA
Message-ID: <CADZyTkmFoceQVk=i43xM6jZHyvsis66Au-cu+uK+7Kuqjj8Acg@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="e89a8f6430cc655a690521203808"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netconf/ZxY_49KWIEVJHc_sfH31Jxd8uPM>
Cc: i2rs@ietf.org, Netconf <netconf@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [Netconf] [i2rs] 1 week extension to WG Adoption call for draft-mglt-i2rs-security-environments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 14:45:57 -0000
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 <shares@ndzh.com> wrote: > Linda > > <co-author hat on> > > We will include closed environments in the revised document. > > > > Sue > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Linda Dunbar > *Sent:* Wednesday, September 02, 2015 12:54 PM > *To:* Susan Hares; i2rs@ietf.org > *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:i2rs-bounces@ietf.org <i2rs-bounces@ietf.org>] *On > Behalf Of *Susan Hares > *Sent:* Tuesday, September 01, 2015 12:10 PM > *To:* i2rs@ietf.org > *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 > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > >
- [Netconf] 1 week extension to WG Adoption call fo… Susan Hares
- Re: [Netconf] [i2rs] 1 week extension to WG Adopt… Linda Dunbar
- Re: [Netconf] [i2rs] 1 week extension to WG Adopt… Susan Hares
- Re: [Netconf] [i2rs] 1 week extension to WG Adopt… Daniel Migault