Re: [I2nsf] Is the "Security Service Function (SSF)" in draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the I2NSF-problem-and-use-cases?

Daniel Migault <daniel.migault@ericsson.com> Wed, 21 September 2016 13:11 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 83BA712B40E for <i2nsf@ietfa.amsl.com>; Wed, 21 Sep 2016 06:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 aIvKw3JPZYFw for <i2nsf@ietfa.amsl.com>; Wed, 21 Sep 2016 06:11:32 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 0114712B4B1 for <i2nsf@ietf.org>; Wed, 21 Sep 2016 06:07:32 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id n143so49384590ita.1 for <i2nsf@ietf.org>; Wed, 21 Sep 2016 06:07:32 -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=6QJOIRHR58ilrBMudm367xMjxbffufaG89QUW8DWddA=; b=ZPrg2pQgYE9mqeEVAEv6kEZzs7zbWzQIO+JtaGjT1YOQ8DiViP4Hh+D2WAwlaRlGfG svtLyJQ+JXXb3mxC0ykdCt/Iywx4jgCdUYlgT4TgCBvGHq8ELlzKOJi2AX6bVCTIt3rD tCDH7UOKb4VwQu+RIKI+wzuD/YepPKx2C9XV+NcEJRdqN+QEfAPAq4hxKXtfX58KJ5Y2 HlmUDjhqbTvDQMPOuVyOaHz0fZBKg9RXl8r6X5Pi4qTL9tDOMDesiOiXIcZJAyST2loa bTBbqg39pZVcpCK/kRpBgQDKxRU2pQR9Sbi9Qf3ykc1RG5GTl9EkJVuPjDhap0OkAjwo oqFQ==
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=6QJOIRHR58ilrBMudm367xMjxbffufaG89QUW8DWddA=; b=PmFLmGUUDqHdN8FT5QqJqBxlrlvgABvkblo78MBBSxq9bSP2bkL5rdnw/nQJRoy2by gy4D80svniYTQkWiGCYKKW9ov9AO18ZNZnWBYv4xgalJbT5tNBx2C9dD+5tqOmn4TDaU 8L9i4iHFFTZ21zNGzbCkOnjiLJtJD0jk7wq0PYkZ7wHxkYtJ0oTP1LQyTf2fwxv/ihtq iF/dnxhFYiw5jHtw+Sby9+jzCUIEobHG7tFudo+LlcEaVBg976RXGwZLOAF8EL+r6PRD JD37Q98yUsQt32r1XU2p6FaPLH3H9GglfitP1YKOk6MHIWmC/MSVqw7xEDjs8KsKhRS4 Z4vQ==
X-Gm-Message-State: AE9vXwNa48A3WBeKP0bB4H8naV43J2ghjUeYvzoZg/qUQj87xX04sljFAgLsFKDh8iOmHrRZMzJTBQsdghMI6Q==
X-Received: by 10.36.112.11 with SMTP id f11mr3998910itc.57.1474463252310; Wed, 21 Sep 2016 06:07:32 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.170.38 with HTTP; Wed, 21 Sep 2016 06:07:31 -0700 (PDT)
In-Reply-To: <01b701d20df4$9ac1d020$d0457060$@ndzh.com>
References: <4A95BA014132FF49AE685FAB4B9F17F657F35F07@dfweml501-mbb> <01b701d20df4$9ac1d020$d0457060$@ndzh.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 21 Sep 2016 09:07:31 -0400
X-Google-Sender-Auth: PjYWYv1vakniQlTyygmigNMekAo
Message-ID: <CADZyTk=mAH=fRWQV5Y+P3NdCFt39QKu9Z98qoj3cZt9AVtPvdQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="001a113f6ff2636f52053d043a40"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/iCAsMLfeR6H59dEOd7oMMPOhU8g>
Cc: i2nsf@ietf.org, Alireza Ranjbar <alireza.ranjbar@ericsson.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [I2nsf] Is the "Security Service Function (SSF)" in draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the 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, 21 Sep 2016 13:11:35 -0000

Hi Susan,

I deeply apology for not having read carefully the
draft-hares-i2nsf-ddos-yang-dm-00, but my understanding is that our
protocol would – for example – end up in agreeing using inter-cloud-ddos
NSF with the inter-cloud-ddos NETCONF/YANG model. The remaining
configuration NETCONF/YANG will be done outside of our protocol.

We wondered whether using YANG or JSON and we decided to use JSON as
YANG seemed to us non appropriated for our protocol. That said we
might be completely wrong and would be happy to change if necessary.
The reasoning behind was:
I saw NETCONF/YANG as one way to get operational data or to push a
configuration. In our case, the collaboration agreement seemed
different from a configuration file as a given attribute may have a
preset of values. “A”, “B”, “C” and “D”, but the cloud and the
cloudlet may have different policies regarding the attribute. For
example the cloud only accepts “A” “B” and “C” and the cloudlet only
accepts “C” and “D”. In that sense, the purpose of the our protocol is
to let the cloud announce to the cloudlet that it only accepts answers
that are in “A” “B” “C” , and let the cloudlet responds with “C”.

One way to do that in YANG would be to have attributes like:

Attribute-proposal-list and Attribute-chosen, but I am not sure that
is really appropriated.


We are happy to receive feed back on your opinion using YANG/JSON!

BR,
Daniel


On Tue, Sep 13, 2016 at 3:25 PM, Susan Hares <shares@ndzh.com> wrote:

> Linda and Daniel:
>
>
>
> To follow-up on Linda’s second question,  this draft appears to be similar
> to the draft-inter-cloud-DDOS Yang model (draft-hares-i2nsf-ddos-yang-dm-00).
> Is it reasonable to have to different yang models or to make one an
> augmentation of the other data model?
>
>
>
> It might make sense to have a general collaboration model for inter-domain
> SSF functions with the DDOS Yang model as a sub-function.  I’ll send some
> Yang model interactions offline.
>
>
>
> Sue
>
>
>
> *From:* I2nsf [mailto:i2nsf-bounces@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, September 12, 2016 5:59 PM
> *To:* 'Daniel Migault'; Alireza Ranjbar; i2nsf@ietf.org
> *Subject:* [I2nsf] Is the “Security Service Function (SSF)” in
> draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the
> I2NSF-problem-and-use-cases?
>
>
>
> Daniel and Alirezza,
>
>
>
> Is the “Security Service Function (SSF)” in your draft equivalent to the
> Network Security Function (NSF) defined in https://www.ietf.org/id/draft-
> ietf-i2nsf-problem-and-use-cases-01.pdf  ?
>
>
>
>
>
> NSF: Network Security Function. An NSF is a function that detects abnormal
> activity and blocks/mitigates the effect of such abnormal activity in order
> to preserve the availability of a network or a service. In addition, the
> NSF can help in supporting communication stream integrity and
> confidentiality.
>
>
>
> Flow-based NSF: An NSF which inspects network flows according to a
>
> security policy. Flow-based security also means that packets are
>
> inspected in the order they are received, and without altering
>
> packets due to the inspection process (e.g., MAC rewrites, TTL
>
> decrement action, or NAT inspection or changes).
>
>
>
>
>
> If they are the same, can you change the terminology? If they are
> different, can you elaborate the differences in your draft?
>
>
>
>
>
> Second question:
>
> When the “Cloud based services” need network provider to enforce certain
> flow rules for the traffic destined to (originated from) the “Cloud based
> services”, do you anticipate those flow rules to be applied to specific
> SSFs belonging to different administrators?  Or can those rules be to the
> “controller” of the SSFs belonging to network providers?  As described by
> https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-
> framework/ ?
>
>
>
>
>
> Thanks,
>
> Linda
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>