Re: [IPsec] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt

Rafa Marin-Lopez <rafa@um.es> Fri, 16 October 2020 08:19 UTC

Return-Path: <rafa@um.es>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10D63A0DEF; Fri, 16 Oct 2020 01:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
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 TUr1DF2iDyfV; Fri, 16 Oct 2020 01:19:56 -0700 (PDT)
Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3203A0DDA; Fri, 16 Oct 2020 01:19:55 -0700 (PDT)
Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx02.puc.rediris.es with ESMTP id 09G8Jrii027967-09G8Jrij027967; Fri, 16 Oct 2020 10:19:53 +0200
Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id E0F5420040; Fri, 16 Oct 2020 10:19:53 +0200 (CEST)
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 U5ZseB_1jcLm; Fri, 16 Oct 2020 10:19:53 +0200 (CEST)
Received: from [192.168.1.33] (135.red-79-150-250.dynamicip.rima-tde.net [79.150.250.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 0E0631FF41; Fri, 16 Oct 2020 10:19:51 +0200 (CEST)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <D9E7F4D7-E6EC-4268-B989-F764CEE34B2B@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_70C4207B-C17E-40FE-A432-F907BCC6A079"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Fri, 16 Oct 2020 10:19:50 +0200
In-Reply-To: <160252655236.514.5675626677635075934@ietfa.amsl.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, ipsec@ietf.org, yang-doctors@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org
To: i2nsf@ietf.org
References: <160252655236.514.5675626677635075934@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-FEAS-SPF: spf-result=pass, ip=155.54.212.167, helo=xenon41.um.es, mailFrom=rafa@um.es
Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.167 as permitted sender) smtp.mailfrom=rafa@um.es
X-FE-Policy-ID: 2:15:0:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=bEQuieDtiSROx5aMushaXJBL+yWOJV/k9x4j8cKPLiw=; b=w8xJ6ULp9a/hXZByfS4nnohMv1+VAiBIQ4GnihikOOyEQL7mq4VkrrMw9CWw9Ur19YcWEOZg2Y6H ufAD6VvOD1V3+PhI2jRlpz8aQvrySuNF89wj8dHRoYMMXyXtIJvVePvtfXOknldJ2Ys8ld9fWh4b xFNQk+ZYo2ZgwNJaL8coU7Pl8uU5P2+FO4YocfFk+n7+9m/WpPgWJkDRsaExExEpqvN6+IPzADUW PIrFMn605Tyi9V16Z2SOzbRIpSApRBwXPbOcIbNWQFD9iBZNTHPEv+F4jw/gRr9jGvA+4vrNB2AH vrA2buIKQInnKwqaZfaKzaOCzatdugenDV/Zow==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Atlq-8goJhIk2xQf0azWoOaXmkA>
Subject: Re: [IPsec] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2020 08:20:03 -0000

Dear all:

Recently we submitted v09. We would like to summarize the status:

- We have applied all the comments we received so far (except one, see below). In particular, we would like to highlight that we have renamed the modules as a consequence of some comments. In particular:

ietf-ipsec-common —> ietf-i2nsf-ikec
ietf-ipsec-ike —> ietf-i2nsf-ike
ietf-ipsec-ikeless -> ietf-i2nsf-ikeless

- Moreover we made a minor change. We realized that encryption algorithms should also have a key-length. For example, it is not enough to say the algorithm is AES-CBC without specifying the key-length (e.g. 128 bits). 

- Regarding the pending comment, as you may have followed in the mailing list, it has been proposed to add a feature ikeless-notification and the corresponding if ikeless-notification in each notification to indicate whether notifications are implemented by the NSF. The goal here is to ensure broader applicability of the ikeless module. If there is no objection, we can include this feature adding a description about the motivation behind this and prepare v10 very quickly.

"To ensure broader applicability of this module, the notifications are marked as a feature. For the implementation of ikeless case, the NSF is expected to implement this feature.";

The result would be (in tree format):

notifications:
    +---n sadb-acquire {ikeless-notification}?
    |  +--ro ipsec-policy-name    string
    |  +--ro traffic-selector
    |     +--ro local-subnet      inet:ip-prefix
    |     +--ro remote-subnet     inet:ip-prefix
    |     +--ro inner-protocol?   ipsec-inner-protocol
    |     +--ro local-ports* [start end]
    |     |  +--ro start    inet:port-number
    |     |  +--ro end      inet:port-number
    |     +--ro remote-ports* [start end]
    |        +--ro start    inet:port-number
    |        +--ro end      inet:port-number
    +---n sadb-expire {ikeless-notification}?
    |  +--ro ipsec-sa-name           string
    |  +--ro soft-lifetime-expire?   boolean
    |  +--ro lifetime-current
    |     +--ro time?      uint32
    |     +--ro bytes?     uint32
    |     +--ro packets?   uint32
    |     +--ro idle?      uint32
    +---n sadb-seq-overflow {ikeless-notification}?
    |  +--ro ipsec-sa-name    string
    +---n sadb-bad-spi {ikeless-notification}?
       +--ro spi    uint32


Best Regards.  

> El 12 oct 2020, a las 20:15, internet-drafts@ietf.org escribió:
> 
> 
> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
> has been successfully submitted by Rafa Marin-Lopez and posted to the
> IETF repository.
> 
> Name:		draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Revision:	09
> Title:		Software-Defined Networking (SDN)-based IPsec Flow Protection
> Document date:	2020-10-12
> Group:		i2nsf
> Pages:		92
> URL:            https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Htmlized:       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
> 
> Abstract:
>   This document describes how to provide IPsec-based flow protection
>   (integrity and confidentiality) by means of an Interface to Network
>   Security Function (I2NSF) controller.  It considers two main well-
>   known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
>   host.  The service described in this document allows the
>   configuration and monitoring of IPsec Security Associations (SAs)
>   from a I2NSF Controller to one or several flow-based Network Security
>   Functions (NSFs) that rely on IPsec to protect data traffic.
> 
>   The document focuses on the I2NSF NSF-facing interface by providing
>   YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
>   and IKEv2.  This allows IPsec SA establishment with minimal
>   intervention by the network administrator.  It does not define any
>   new protocol.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

-------------------------------------------------------
Rafa 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
-------------------------------------------------------