Re: [I2nsf] relationship between draft-baspez-i2nsf-capabilities-00 & draft-xia-i2nsf-capability-interface-im

Aldo Basile <cataldo.basile@polito.it> Wed, 05 October 2016 20:30 UTC

Return-Path: <cataldo.basile@polito.it>
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 8904912989A for <i2nsf@ietfa.amsl.com>; Wed, 5 Oct 2016 13:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.197
X-Spam-Level:
X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jgz8bPsu2QiL for <i2nsf@ietfa.amsl.com>; Wed, 5 Oct 2016 13:30:06 -0700 (PDT)
Received: from fm1nodo5.polito.it (fm1nodo5.polito.it [130.192.180.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1EF12949D for <i2nsf@ietf.org>; Wed, 5 Oct 2016 13:30:06 -0700 (PDT)
Received: from polito.it (frontmail2.polito.it [130.192.180.42]) by fm1nodo5.polito.it with ESMTP id u95KTv7e017562-u95KTv7g017562 (version=TLSv1.0 cipher=DHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Wed, 5 Oct 2016 22:29:57 +0200
Received: from [151.32.124.111] (account d011649@polito.it HELO [192.168.0.4]) by polito.it (CommuniGate Pro SMTP 6.1.9) with ESMTPSA id 53203871; Wed, 05 Oct 2016 22:29:57 +0200
To: Linda Dunbar <linda.dunbar@huawei.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, John Strassner <strazpdj@gmail.com>, "Xialiang (Frank)" <frank.xialiang@huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F657F4EE19@dfweml501-mbb> <70161564-cea3-3081-63db-72eecd71a21c@polito.it> <4A95BA014132FF49AE685FAB4B9F17F657F4EFFE@dfweml501-mbb>
From: Aldo Basile <cataldo.basile@polito.it>
Message-ID: <bb150443-3fa0-90c7-cb29-d288b2c2c690@polito.it>
Date: Wed, 05 Oct 2016 22:29:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F4EFFE@dfweml501-mbb>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080703020204000400000709"
X-FEAS-SYSTEM-WL: 130.192.180.42
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/mCCOhEBgW-NlEdLYUpRitBx6Wd0>
Subject: Re: [I2nsf] relationship between draft-baspez-i2nsf-capabilities-00 & draft-xia-i2nsf-capability-interface-im
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, 05 Oct 2016 20:30:14 -0000

Dear Linda,

we discussed and agreed in Berlin that the two drafts will form a new 
one, which will merge the content of both I-Ds. We have (at least from 
my side) slowly started to work on the new I-D.

The new draft will roughly contain two parts:

- one part that describes the dynamic and management aspects of the 
"capability" owned by a NSF, that is, how a function publishes 
capabilities, how it is possible to push configurations to it, and all 
the (event-based) management life cycle of a NSF. This part mainly 
builds from the draft-xia-i2nsf-capability-interface-im and contributed 
by John and Frank (which may be more precise during the call), and

- one part that describes the static aspects of the security policies 
(i.e., the configurations) that can be pushed to an NSF, that is, the 
actions that an NSF can enforce and the way to ask it to enforce these 
actions on specific traffic (=conditions, resolutions, default actions, 
etc.). This part mainly builds from the baspez draft.

Regards,
Aldo


On 05/10/2016 22:11, Linda Dunbar wrote:
> Aldo,
>
> Thank you very much for the detailed explanation.
>
> You mentioned about merging with John and Frank Xia's draft. Will you merge some content to the "draft-xia-i2nsf-capability-interface-im"?
>
> Or some content from "draft-xia-i2nsf-capability-interface-im" will be merged to yours?
>
>
> Using the I2NSF WG agreed terminologies, (i.e. "NSF-facing-interface" and "Client-facing-interface), the "draft-xia-i2nsf-capability-interface-im" not only describes the "capability" information from NSFs, but also the "dynamic rules over the NSF-facing-interface.
>
> At today's Interim meeting, can you, John, and Frank explain the partition of the drafts?
>
> Thank you very much.
>
> Linda
> -----Original Message-----
> From: Aldo Basile [mailto:cataldo.basile@polito.it]
> Sent: Wednesday, October 05, 2016 1:56 PM
> To: Linda Dunbar; i2nsf@ietf.org
> Subject: Re: Questions about draft-baspez-i2nsf-capabilities-00
>
> Dear Linda,
>
> this ambiguity is a consequence of my bad relation with the textual
> syntax of I-D, while I usually work with LaTeX and I conceive formulas
> in LaTeX format (and, honestly, I still don't understand why it is not
> also adopted by IETF).
>
> I'm sorry for this, I'll work to improve formulas readability for the
> version 01 or for the merged version (the one we are working on with
> John Strassner and Frank Xialiang).
>
> 1) AC (both capital letters) is the set of all the existing actions,
> thus AC will include "permit", "deny", "redirect", "log", "alert", and
> all the actions that may describe any of the enforcement activities
> performed by whatever security function.
>
> 2) Ac is a subset of AC that represents the actions actually available
> at the security function we want to describe.
> Therefore, for a basic packet filter it will most likely include only
> "permit", "deny", and "redirect", while more sophisticated functions
> will have their own set of actions (that, to make the model coherent,
> should nevertheless be also replicated in the AC that will contain all
> of them).
>
> "[" graphically depicts the LaTeX symbol \subseteq (look at the relation
> symbols here http://web.ift.uib.no/Teori/KURS/WRK/TeX/symALL.html) which
> I used to depict the subset relation (a [ b means that the left one
> contains a subset of the elements in b but it may possibly contain the
> same elements as b).
> I added a sentence in the draft explaining this use, but it was probably
> very vague.
>
> Hope this clarifies the and hope I can solve editing issues in the next
> versions.
>
> Regards,
> Aldo
>
>
> On 05/10/2016 19:12, Linda Dunbar wrote:
>>
>>
>> Aldo and Diego,
>>
>>
>>
>>
>>
>> The section 4.1 of your draft has this expression:
>>
>>
>>
>> Our capabilities are defined by a 4-tuple:
>>
>> (Ac; Cc; RSc; Dc) [ (AC; CC; RSC; DC)= K
>>
>>
>>
>> Is it intentional to have "[" without the matching one "]"?
>>
>>
>>
>> What is the relationship between "Ac" and "AC"? are they the same?
>>
>>
>>
>> If a NSF supports more actions than the simple "permit" or "deny" (e.g.
>> "redirect", "log", "alert", etc), will then be listed in "AC" or "Ac"?
>>
>>
>>
>> Thanks, Linda
>>
>
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>