IETF Logo Mail Archive

Re: [I2nsf] Reviewing sdn-ipsec-flow-protection

Gabriel Lopez <gabilm@um.es> Thu, 24 January 2019 14:24 UTC

Return-Path: <gabilm@um.es>
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 D9CAB124BE5 for <i2nsf@ietfa.amsl.com>; Thu, 24 Jan 2019 06:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 t3VzDIAxMLx7 for <i2nsf@ietfa.amsl.com>; Thu, 24 Jan 2019 06:24:33 -0800 (PST)
Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id D28A1123FFD for <i2nsf@ietf.org>; Thu, 24 Jan 2019 06:24:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 59BC424E3A; Thu, 24 Jan 2019 15:24:31 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon41.um.es
Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ARXADWJw0TBz; Thu, 24 Jan 2019 15:24:31 +0100 (CET)
Received: from inf-205-56.inf.um.es (inf-205-56.inf.um.es [155.54.205.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 8287024DDD; Thu, 24 Jan 2019 15:24:30 +0100 (CET)
From: Gabriel Lopez <gabilm@um.es>
Message-Id: <97DDB750-B98B-43DA-847B-F8203BC8DD33@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B3AC6404-99FC-43BB-853F-8D9AAA54779A"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 24 Jan 2019 15:24:29 +0100
In-Reply-To: <6839D47C-4074-486F-9350-8EB7B378036C@um.es>
Cc: Gabriel Lopez <gabilm@um.es>, Yoav Nir <ynir.ietf@gmail.com>, i2nsf@ietf.org, Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>
To: Rafa Marin Lopez <rafa@um.es>
References: <A881C135-9BF7-4E93-BB7A-75EB3D1FF605@gmail.com> <6839D47C-4074-486F-9350-8EB7B378036C@um.es>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/ss6Gi6V50A8rBOajZE8ARIl3ZZs>
Subject: Re: [I2nsf] Reviewing sdn-ipsec-flow-protection
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 24 Jan 2019 14:24:36 -0000

Hi all.

> El 14 nov 2018, a las 10:30, Rafa Marin-Lopez <rafa@um.es> escribió:
> 
> Hi Yoav:
> 
>> El 8 nov 2018, a las 17:11, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> escribió:
>> 
>> Hi, all
>> 
>> 
> 
>> The interaction between Controller and NSF
>> There’s no way for the controller to retrieve NSF capabilities. What if the NSF does not implement rc5?  It’s fine if we say that the Controller knows in advance what the capabilities of each NSF are, but it should be stated.
> 
> Agree. Nevertheless, I would say that the most correct way is when the controller asks the NSF about capabilities after NSF and controller connect. 


Regarding this question, we wonder how the controller knows about the capabilities provided by each IPsec NSF. As Rafa pointed out, one way is that the NSF could provide them by itself during the NSF’s registration process into the controller. Another way is that the controller receives the capabilities for a set of NSFs from an external entity. Following the I2NSF Reference Model in RFC 8329, it is assumed this role is assigned to the “Developer’s Management System”.

In our concrete example where a NSF provides IPsec-based security functions, our understanding of that IPsec capabilities refer the set of features a IPsec NSF node is able to support. A (non-exhaustive) list is: 
-	IKE support
-	IKEless support
-	For IKE case: authentication and encryption algorithms, dh_groups, authentication method, NAT traversal support, etc. 
-	For IKEless case: authentication, integrity and encryption algorithms, AH support, etc.

We would like to draw attention to IPsec-based NSFs and suggest authors of these drafts to consider the usage of the capabilities model to inform the security controller about IPsec capabilities.

Thanks in advance and best regards, Gabi.


> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gabilm@um.es

v2.23.0 | Report a Bug | By Email