On 10/16/2020 4:19 AM, Rafa Marin-Lopez wrote:
> If there is no objection, we can include this feature adding a
> description about the motivation behind this and prepare v10 very
quickly.
Thank you for this. I think it would be a really helpful change -- and
I support it.
Lou
(as contributor with multiple hats)
On 10/16/2020 4:19 AM, Rafa Marin-Lopez wrote:
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@xxxxxxxx
<mailto:internet-drafts@xxxxxxxx> 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
<http://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@xxxxx <mailto:rafa@xxxxx>
-------------------------------------------------------
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
