Re: [I2nsf] Comments/questions about draft-ietf-i2nsf-problem-and-use-cases
Daniel Migault <daniel.migault@ericsson.com> Wed, 02 November 2016 10:00 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B271A129A85 for <i2nsf@ietfa.amsl.com>; Wed, 2 Nov 2016 03:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fAhPBuHojZ2s for <i2nsf@ietfa.amsl.com>; Wed, 2 Nov 2016 03:00:34 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 A1A96129A7E for <i2nsf@ietf.org>; Wed, 2 Nov 2016 03:00:31 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id u205so26364182itc.0 for <i2nsf@ietf.org>; Wed, 02 Nov 2016 03:00:31 -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:from:date:message-id :subject:to:cc; bh=XhrXW7BPcolWhLRqwHJlOfLe+Bpc3/xgNSU8yKWNVKk=; b=yjOMG2wMH/lkTYDeaWpN6HSfkxDfXUlgi+cOekTlTmj+Rt2moDBAkgp1m8eRIRN25M fvK+NSefI90R4EKB76zJijphDBxKKUJuJ5l+EjfTi6KRlBvsPKR3Jg9W/Kl80dxslDTw pnfDtAReO3xuarOaeHptjcaBqA1BDhqZTTT1S7QRC8+Pa2pTTgSp85DNsspWS2tMHpDa wG+zTa5gHvCb+Ai8LQB56f3JsuGIJHtb+Px/hhCYQo8cRXWqPe0dzbnc1bBzmEU2Ny/H uA3HDKQoZwWJy6G38f7+FhrNATRyvC6GQ8fHxY9aYyzFK97swS8UYx2SKY8cmHVwx/gN WjBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XhrXW7BPcolWhLRqwHJlOfLe+Bpc3/xgNSU8yKWNVKk=; b=HEOX6ubT7VopqwH83dWmXQl4CP/0Fk1XFebN4JsxziD4X8POWXH+t0qI30aRA+7Dt5 VScMOW6Vv75cth3etnNFz08jZaOeC34htyqA+gMsSeVdkVunaWuKRg8eFGthWJ3Mimc0 Oxw4r5evvYwVIMwnRDT0nVopm9MSCZEkO84d+dx2Q7UwdAccnrc6FaieXtpFo5RPlxzd 97xMxUL7nUNIWQxHxwZn07l8vzlG13Bm1UH9NQeX26+p2kX81Upc6MjAS+ojBBd0gpDf EoS0YYM5tDJ63CKdHW2PVCJzjUd8TGBXjXlhjmcEvzfDbgX53tYc41okV9KZlTwo9IRU Fbug==
X-Gm-Message-State: ABUngvfVPXZiYqM87JsJ5hIcY9lWYlWedDN/Hbjq7YqnC+n6WqyR1P6f6ExvWvdZIrcogFJaTAhL424aKsev4w==
X-Received: by 10.36.2.196 with SMTP id 187mr1836780itu.120.1478080830266; Wed, 02 Nov 2016 03:00:30 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.188.4 with HTTP; Wed, 2 Nov 2016 03:00:29 -0700 (PDT)
In-Reply-To: <FD60E1DF-FF8A-4F3E-9C64-FF10089F5332@um.es>
References: <FD60E1DF-FF8A-4F3E-9C64-FF10089F5332@um.es>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 02 Nov 2016 06:00:29 -0400
X-Google-Sender-Auth: n64Wn6T1Vv-k4EFbPx1Kdd8dZoE
Message-ID: <CADZyTk=qdk9-JfvAPPPskb6tmbbMOTs=XCEvS=CZCNFWCZK+MA@mail.gmail.com>
To: Rafa Marin Lopez <rafa@um.es>
Content-Type: multipart/alternative; boundary="001a1143d4a2d6628305404e82b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/u4JEKGtXo5S5BUsZcdgueVW48fg>
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] Comments/questions about draft-ietf-i2nsf-problem-and-use-cases
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2016 10:00:39 -0000
Hi, I read the doument and here are my comments. Yours, Daniel 3. Problem Space 3.1. Challenges Facing Security Service Providers 3.1.1. Diverse Types of Security Functions Internal Data and Content Protection: Examples of this function are encryption, authorization, and public/private key management for internal database. Given the diversity of security functions, the contexts in which these functions can be deployed, and the constant evolution of these Hares, et al. Expires April 8, 2017 [Page 5] Internet-Draft I2NSF Problem/Use Case October 2016 functions, standardizing all aspects of security functions is challenging, and most probably not feasible. Fortunately, it is not necessary to standardize all aspects. For example, from an I2NSF perspective, there is no need to standardize on how firewall filters are created or applied. MGLT: Maybe that woudl also be helpful to specify what I2NSF needs to define. More specifically, I2NSF should define a high level description of the interface that is implementation and vendor independent. What is not so clear to me is, in the casse of the firewall what kind of interaction are in the scope of I2NSF. From reading the gap analysis document it seems to me that provisionning and configuring the firewall with rules is not in the scope of I2NSF yet. Instead the I2NSF is interested in capabilities of the fucntions. Typically the support of IPv6 could be a capability for the firewall. 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting. MGLT: "what it cannot view" is not clear to me. It might be helpful to be more positive and define what it can monitor. That said, what was confusing for me is whether viewing is achieved by configuring the appropriated firewall rules or because ther is a need to provide feedbacks or status on the firewall activity. 3.1.3. More Distributed NSFs and vNSFs The security functions which are invoked to enforce a security policy can be located in different equipment and network locations. The European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, and network security functions (vNSF). A vNSF has higher risk of failure, migrating, and state changes as their hosting VMs are being created, moved, or decommissioned. MGLT: Given that statement I believe it would be helpful to understand how I2NSF is related to that challenge and how it expects to address that challenge. I also believe that such clarification could be provide for other issues. 3.1.6. Lack of Characterization of NSFs and Capability Exchange Today, there is no standard method for vendors to describe the capabilities of their security functions. Without a common technical framework to describe the capabilities of security functions, service providers cannot automate the process of selecting NSFs by different vendors to accommodate customer's requirements. MGLT: I like the current text of this section. It is much clearer than in the previous version. ;-) and clearly state how I2NSF is expected to address this issue. Hares, et al. Expires April 8, 2017 [Page 7] Internet-Draft I2NSF Problem/Use Case October 2016 3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles Many security functions depend on signature files or profiles to perform (e.g., IPS/IDS signatures, DOTS filters). Different policies might need different signatures or profiles. Today, the construction and use of black list databases can be a win-win strategy for all parties involved. There might be Open Source-provided signature/ profiles (e.g., by Snort or others) in the future. MGLT: I am not sure there is a consensus on what DOTS fileters are. I believe it would hep th ereader to clarify or illustrate what the profile is. I understand profile as the correlation of observations. There is a need to have a standard envelop (i.e., the format) to allow NSFs to use external profiles. MGLT: Would'nt it a YANG models that makes possible the definition of profiles. A profile would be in that case the speciifc instantiation of a YANG model (the set of values associated to the model). These models will be used by I2NSF to derive the actions from the Customer Interfcae which is excpected to use a more abstract description and designate the profile by a common name. 3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs There is a need for a controller to distribute various keys to distributed NSFs. To distribute various keys, the keys must be created and managed. While there are many key management methods and key derivation functions (KDF), there is a lack of standard interface to provision and manage keys. The keys may be used for message authentication and integrity in order to protect data flows. In addition, keys may be used to secure Hares, et al. Expires April 8, 2017 [Page 8] Internet-Draft I2NSF Problem/Use Case October 2016 the protocol and messages in the core routing infrastructure ([RFC4948]) As of now there is not much focus on an abstraction for keying information that describes the interface between protocols, operators, and automated key management. The ability to utilize keys when routing protocols send or receive messages will be enhanced by having an abstract key table maintained by a security service. Conceptually, there must be an interface defined for routing/signaling protocols to make requests for automated key management when it is being used, to notify the protocols when keys become available in the key table. An abstract key service will work under the following conditions: 1. I2NSF needs to design the key table abstraction, the interface between key management protocols and routing/other protocols, and possibly security protocols at other layers. MGLT: It is not clear to me what "key table abstraction" is. I have little knowledge in routing protocols, but I believe this section is really routing oriented, and I hardly see any application for TLS/IPsec... other then key provisionning. Am I correct ? 3.4. Lack of Standard Interface to Inject Feedback to NSF Today, many security functions, such as IPS, IDS, DDoS and Antivirus, depend heavily on the associated profiles. They can perform more effective protection if they have the up-to-date profiles. As more sophisticated threats arise, enterprises, vendors, and service providers have to rely on each other to achieve optimal protection. Cyper Threat Alliance (CA, http://cyberthreatalliance.org/) is one of those initiatives that aim at combining efforts conducted by multiple organizations. Hares, et al. Expires April 8, 2017 [Page 12] Internet-Draft I2NSF Problem/Use Case October 2016 Today there is no standard interface to exchange security profiles between organizations. MGLT: From the text it looks that there is a need to define a catalogue of profile. I hardly believe that everyone would converge with a single set of profiles. Instead I believe that each domain will define its own profile and need to provide them to another domain. Am I correct ? 4. Use Cases 4.3. Cloud Data Center Scenario In a data center, network security mechanisms such as firewalls may need to be dynamically added or removed for a number of reasons. These changes may be explicitly requested by the user, or triggered by a pre-agreed upon Service Level Agreement (SLA) between the user and the provider of the service. For example, the service provider may be required to add more firewall capacity within a set timeframe whenever the bandwidth utilization hits a certain threshold for a specified period. This capacity expansion could result in adding new instances of firewalls on existing machines or provisioning a completely new firewall instance in a different machine. The on-demand, dynamic nature of security service delivery essentially encourages that the network security "devices" be in software or virtual form factors, rather than in a physical appliance form. This requirement is a provider-side concern. Users of the firewall service are agnostic (as they should) as to whether or not the firewall service is run on a VM or any other form factor. Indeed, they may not even be aware that their traffic traverses firewalls. Furthermore, new firewall instances need to be placed in the "right zone" (domain). The issue applies not only to multi-tenant environments where getting the tenant in the right domain is of paramount importance, but also in environments owned and operated by a single organization with its own service segregation policies. For example, an enterprise may mandate that firewalls serving Internet traffic and Business-to-Business (B2B) traffic be separated. Another example is that IPS/IDS services for investment banking and non- banking traffic may be separated for regulatory reasons. MGLT: Maybe it woudl be nice to position I2NSF toward this use case as in the prvious sub-sections. 4.3.2. Firewall Policy Deployment Automation Firewall rule setting is often a time consuming, complex and error- prone process even within a single organization/enterprise framework. It becomes far more complex in provider-owned cloud networks that serve myriads of customers. Firewall rules today are highly tied with ports and addresses that identify traffic. This makes it very difficult for clients of cloud data centers to construct rules for their own traffic as the clients only see the virtual networks and the virtual addresses. The customer-visible virtual networks and addresses may be different from the actual packets traversing the FWs. Even though most vendors support similar firewall features, the actual rule configuration keywords are different from vendors to vendors, making it difficult for automation. Automation works best when it can leverage a common set of standards that will work across NSFs by multiple vendors. Without automation, it is virtually impossible for clients to dynamically specify their desired rules for their traffic. MGLT: My understanding is that provisionning the firewall with rules with a YANG model is not in the scoep of i2NSF. Instead I2NSF deals with a abstract description provided by the Client which shoudl ends in the same rules being deployed into the firewalls of different vendors. I2NSF use defines the high level requirements of the Customer as well as the derivation in YANG model to configure the rules. As YANG models are vendor independent the high level description is deployed similarly in the multiple firewalls. Is that what the text means ? Hares, et al. Expires April 8, 2017 [Page 18] Internet-Draft I2NSF Problem/Use Case October 2016 4.3.3. Client-Specific Security Policy in Cloud VPNs Clients of service provider-operated cloud data centers need not only to secure Virtual Private Networks (VPNs) but also virtual security functions that apply the clients' security policies. The security policies may govern communication within the clients' own virtual networks as well as communication with external networks. For example, VPN service providers may need to provide firewall and other security services to their VPN clients. Today, it is generally not possible for clients to dynamically view (let alone change) what, where and how security policies are implemented on their provider- operated clouds. Indeed, no standards-based framework exists to allow clients to retrieve/manage security policies in a consistent manner across different providers. MGLT: It is not clear to me if I2NSF shoudl get these information via a direct access to the configuration of the different NSF or if that should be done via an audit service, which will report compliance with the requirements. On Mon, Oct 3, 2016 at 5:33 PM, Rafa Marin Lopez <rafa@um.es> wrote: > Dear all: > > I have reviewed draft-ietf-i2nsf-problem-and-use-cases and I have a few > comments/questions (my apologies if these have been already discussed in > the past). > > ----------------------- > > Section 3.1.1 > > -Security Functions in a DMZ. You refer to authentication and > authorization but also AAA. Is this not redundant? > > -At first sight, there is no example of NSFs with flow based protection. > That is, those that participate in the establishment of a security > association to protect data traffic. > > Section 3.1.10 > > - A general comment about this section is that the text seems to pay > attention to routing. In our case, for example, we have an I-D to manage > IPSec SAs based on SDNs (https://tools.ietf.org/html/ > draft-abad-i2nsf-sdn-ipsec-flow-protection-00). I guess this use case we > present in our I-D is somehow included in the text “Conceptually, there > must be an interface defined for routing/signaling protocols…” but I am not > sure. Could you clarify? > > - A suggestion I have is to revise this paragraph: > > “While there are many key management methods and > key derivation functions (KDF), there is a lack of standard interface > to provision and manage keys.” > > There is a lack not only to provision and manage keys but also to specify > additional information (e.g. low level policies) or to fill certain > information to manage, in the end, a security association. Additionally, I > am not sure about the initial sentence "While there are many key management > methods and key derivation functions (KDF)”… what do you mean with this? > > Perhaps a possible modification would say: > > —-> While there are many key management methods and > cryptographic suites (e.g. encryption algorithms, key derivation > functions, etc…), there is a lack of standard interface > to provision and manage security associations. > > > Regarding this paragraph: > > “The ability to utilize keys when routing protocols send or receive > messages will be enhanced by having an abstract key table maintained > by a security service. Conceptually, there must be an interface > defined for routing/signaling protocols to make requests for > automated key management when it is being used, to notify the > protocols when keys become available in the key table.” > > In my opinion, it seems going into a solution space: “an abstract key > table” and a mechanism to “pull” the keys, is this correct?. Why using this > key table? Why using pull method so that the protocols know when the keys > are available in the table?. Also, the text refers to routing protocols at > the beginning. I would say that there must be an interface to configure > security associations of any nature, no?. > > Section 4. In the use cases, there is no explicit text where key > distribution is required. One may think that section 4.3.2 and, most > probably, 4.3.3 may be related with key management (section 3.1.10). I > mention this because our I-D focused on key management for IPSec SAs and > VPNs is a term that may be associated to this. > > Section 7. > > When you mention AAA, are you referring to https://tools.ietf.org/html/ > rfc2904 ? > > --------- > > Best Regards. > > > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf >
- [I2nsf] Comments/questions about draft-ietf-i2nsf… Rafa Marin Lopez
- Re: [I2nsf] Comments/questions about draft-ietf-i… Gabriel Lopez
- Re: [I2nsf] Comments/questions about draft-ietf-i… Daniel Migault
- Re: [I2nsf] Comments/questions about draft-ietf-i… Susan Hares
- Re: [I2nsf] Comments/questions about draft-ietf-i… Susan Hares