I2NSF                                                     R. Marin-Lopez
Internet-Draft                                           G. Lopez-Millan
Intended status: Standards Track                    University of Murcia
Expires: February 6, December 19, 2020                          F. Pereniguez-Garcia
                                               University Defense Center
                                                          August 5, 2019
                                                           June 17, 2020

     Software-Defined Networking (SDN)-based IPsec Flow Protection
             draft-ietf-i2nsf-sdn-ipsec-flow-protection-07
             draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Abstract

   This document describes how providing to provide IPsec-based flow protection
   (integrity and confidentiality) by means of a Software-Defined Network (SDN) controller (aka.  Security
   Controller) and establishes the requirements to support this service. an I2NSF Controller.  It
   considers two main well-known scenarios in IPsec: (i) gateway-to-
   gateway and (ii) host-to-host.  The SDN-based service described in this
   document allows the distribution configuration and monitoring of IPsec information
   from a Security I2NSF Controller to one or several flow-based Network Security
   Function (NSF).  The NSFs (NSF) that implement IPsec to protect data traffic between network resources. traffic.

   The document focuses on the NSF Facing I2NSF NSF-Facing Interface by providing
   YANG data models for configuration and state data required to allow
   the Security I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD)
   and IKEv2 to establish IPsec Security Associations with a reduced
   intervention of the network administrator.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 6, December 19, 2020.

Copyright Notice

   Copyright (c) 2019 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  SDN-based IPsec management description  . . . . . . . . . . .   6
     5.1.
     4.1.  IKE case: IKE/IPsec IKEv2/IPsec in the NSF  . . . . . . . . . . . . .   6
       5.1.1.  Interface Requirements for IKE case . . . . . . . . .   7
     5.2.
     4.2.  IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . .   7
       5.2.1.  Interface Requirements for IKE-less case  . . . . . .   8
     5.3.
   5.  IKE case vs IKE-less case . . . . . . . . . . . . . . . . . .   9
       5.3.1.
     5.1.  Rekeying process. process  . . . . . . . . . . . . . . . . . . . .  10
       5.3.2.
     5.2.  NSF state loss. . . . . . . . . . . . . . . . . . . .  12
       5.3.3.  NAT Traversal . . . . .  11
     5.3.  NAT Traversal . . . . . . . . . . . . . . .  12
       5.3.4.  NSF Discovery . . . . . . .  11
     5.4.  NSF registration and discovery  . . . . . . . . . . . . .  13  12
   6.  YANG configuration data models  . . . . . . . . . . . . . . .  13
     6.1.  IKE case model  . . . . . . . . . . . . . . . . . . . . .  14  13
     6.2.  IKE-less case model . . . . . . . . . . . . . . . . . . .  17  16
   7.  Use cases examples  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Host-to-host or gateway-to-gateway under the same
   8.  Security Controller Considerations . . . . . . . . . . . . . . . . . . .  20
     7.2.  Host-to-host or gateway-to-gateway under different
           Security Controllers  21
     8.1.  IKE case  . . . . . . . . . . . . . . . . . .  24
   8.  IANA Considerations . . . . . .  22
     8.2.  IKE-less case . . . . . . . . . . . . . . .  26
   9.  Security Considerations . . . . . . .  23
     8.3.  YANG modules  . . . . . . . . . . . .  27
     9.1.  IKE case . . . . . . . . . .  23
   9.  Acknowledgements  . . . . . . . . . . . . . .  28
     9.2.  IKE-less case . . . . . . . .  25
   10. References  . . . . . . . . . . . . . .  29
     9.3.  YANG modules . . . . . . . . . . .  25
     10.1.  Normative References . . . . . . . . . . .  29
   10. Acknowledgements . . . . . . .  25
     10.2.  Informative References . . . . . . . . . . . . . . .  31
   11. References . .  26
   Appendix A.  Common YANG model for IKE and IKE-less cases . . . .  29
   Appendix B.  YANG model for IKE case  . . . . . . . . . . . . . .  42
   Appendix C.  YANG model for IKE-less case . . . . .  31
     11.1.  Normative References . . . . . . .  61
   Appendix D.  XML configuration example for IKE case (gateway-to-
                gateway) . . . . . . . . . . .  31
     11.2.  Informative References . . . . . . . . . . .  71
   Appendix E.  XML configuration example for IKE-less case (host-
                to-host) . . . . . .  32

   Appendix A.  Appendix A: Common YANG model for IKE and IKE-less
                cases . . . . . . . . . . . . . . . .  75
   Appendix F.  XML notification examples  . . . . . . .  35
   Appendix B.  Appendix B: YANG model for IKE case . . . . . .  79
   Appendix G.  Operational use cases examples . .  48
   Appendix C.  Appendix C: YANG model for IKE-less case . . . . . .  67
   Appendix D.  Example of IKE case, tunnel mode (gateway-to-
                gateway) with X.509 certificate authentication. . .  77
   Appendix E. .  80
     G.1.  Example of IKE-less case, transport mode (host-to-
                host). IPsec SA establishment . . . . . . . . . . . .  80
       G.1.1.  IKE case  . . . . . . . . . . . . . . . . . . . . . .  81
   Appendix F.  Examples of notifications.
       G.1.2.  IKE-less case . . . . . . . . . . . . . . . . . . . .  83
     G.2.  Example of the rekeying process in IKE-less case  . . . .  85
     G.3.  Example of managing NSF state loss in IKE-less case . . .  86
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  86

1.  Introduction

   Software-Defined Networking (SDN) is an architecture that enables
   users to directly program, orchestrate, control and manage network
   resources through software.  The SDN paradigm relocates the control
   of network resources to a dedicated network element, centralized entity, namely SDN Controller.
   The SDN controller (or Security Controller in the
   context of this document) manages and configures the distributed network
   resources and provides an abstracted view of the network resources to
   the SDN applications.  The SDN application can customize and automate
   the operations (including management) of the abstracted network
   resources in a programmable manner via this interface [RFC7149]
   [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].

   Recently, several network scenarios are considering demanding a centralized way
   of managing different security aspects.  For example, Software-
   Defined WANs (SD-WAN), an SDN extension providing a software
   abstraction to create secure network overlays over traditional WAN
   and branch networks.  SD-WAN is based on IPsec [RFC4301] as an
   underlying security protocol and aims to provide flexible, automated, fast deployment
   and rapid deployment, enabling on-demand security network services services,
   such as IPsec SA management Security Association (IPsec SA) management, from a
   centralized point.  Additionally, Section 4.3.3 in [RFC8192]
   describes another example, a use case for Cloud Data Center Scenario,
   entitled Client-Specific Security Policy in Cloud VPNs, where "the
   dynamic key management is critical for securing the VPN and the
   distribution of policies".  These VPNs can be established using
   IPsec.  The management of IPsec SAs in data centers using a
   centralized entity is also an scenario of interest.

   Therefore, with the growth of SDN-based scenarios where network
   resources are deployed in an autonomous manner, a mechanism to manage
   IPsec SAs according to the SDN architecture from a centralized entity becomes more relevant.
   Thus, the SDN-based service described relevant in this document will
   autonomously deal with IPsec SAs management following the SDN
   paradigm.

   IPsec architecture [RFC4301] defines clear separation between the
   processing to provide security services
   industry.

   In response to IP packets and this need, the key
   management procedures Interface to establish the IPsec Network Security Associations.
   In Functions
   (I2NSF) charter states that the goal of this document, we working group is "to
   define a service where the key management
   procedures can be carried by an external set of software interfaces and centralized entity: the data models for controlling and
   monitoring aspects of physical and virtual Network Security Controller.

   First,
   Functions".  As defined in [RFC8192] an NSF is "a function that is
   used to ensure integrity, confidentiality, or availability of network
   communication; to detect unwanted network activity; or to block, or
   at least mitigate, the effects of unwanted activity".  This document
   pays special attention to flow-based NSFs that ensure integrity and
   confidentiality by means of IPsec.

   In fact, as Section 3.1.9 in [RFC8192] states "there is a need for a
   controller to create, manage, and distribute various keys to
   distributed NSFs.", however "there is a lack of a standard interface
   to provision and manage security associations".  Inspired in the SDN
   paradigm, the I2NSF framework [RFC8329] defines a centralized entity,
   the I2NSF Controller, which manages one or multiple NSFs through a
   I2NSF NSF-Facing interface.  In this document exposes we define a service
   allowing the requirements I2NSF Controller to support carry out the
   protection of key management
   procedures.  More specifically, we define YANG data flows using models for I2NSF
   NSF-Facing interface that allow the I2NSF Controller to configure and
   monitor IPsec-enabled flow-based NSFs.

   IPsec [RFC4301].  We have considered architecture [RFC4301] defines clear separation between the
   processing to provide security services to IP packets and the key
   management procedures to establish the IPsec Security Associations,
   which allows to centralize the key management procedures in the I2NSF
   Controller.  This document considers two typical scenarios to
   autonomously manage IPsec SAs: gateway-to-gateway and host-to-host
   [RFC6071].  In these cases, hosts, gateways or both may act as NSFs.
   Consideration for the host-to-gateway scenario is out of scope.

   For the definition of the YANG data model for I2NSF NSF-Facing
   interface, this document considers two general cases: cases, namely:

   1)  IKE case.  The Network Security Function (NSF) NSF implements the Internet Key Exchange (IKE) version 2
       (IKEv2) protocol and the IPsec databases: the Security Policy
       Database (SPD), the Security Association Database (SAD) and the
       Peer Authorization Database (PAD).  The Security I2NSF Controller is in
       charge of provisioning the NSF with the required information to IKE, in
       the SPD SPD, PAD (e.g.  IKE credential) and IKE protocol itself (e.g.
       parameters for the PAD. IKE_SA_INIT negotiation).

   2)  IKE-less case.  The NSF only implements the IPsec databases (no
       IKE implementation).  The Security I2NSF Controller will provide the
       required parameters to create valid entries in the SPD and the
       SAD into the NSF.  Therefore, the NSF will have only support for
       IPsec while automated key management functionality is moved to the Security I2NSF
       Controller.

   In both cases, an interface/protocol is required to carry a data model for the I2NSF NSF-Facing interface is
   required to carry out this provisioning in a secure manner between
   the Security I2NSF Controller and the NSF.  In particular, IKE case requires the provision of SPD and
   PAD entries, the IKE credential and information related with the IKE
   negotiation (e.g.  IKE_SA_INIT).  IKE-less case requires the
   management of SPD and SAD entries.  Based on YANG models in
   [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
   7296 [RFC7296], this document defines the required interfaces with a
   YANG model for configuration and state data for IKE, PAD, SPD and SAD
   (see Appendix A, Appendix B and Appendix C).  Examples of the usage
   of these models can be found in Appendix D, Appendix E and
   Appendix F.

   This document considers two typical scenarios to manage autonomously
   IPsec SAs: gateway-to-gateway and host-to-host [RFC6071].

   In these
   cases, hosts, gateways or both may act as NSFs.  Finally, it also
   discusses the situation where two NSFs are under the control of two
   different Security Controllers.  The analysis of summary, the host-to-gateway
   (roadwarrior) scenario is out of scope objetives of this document.

   Finally, this work pays attention to I-D are:

   o  To describe the challenge "Lack of Mechanism architecture for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the
   particular case of I2NSF-based IPsec management,
      which allows the establishment and management of IPsec SAs.  In
   fact,this I-D could be considered as a proper use case for security
      associations from the I2NSF Controller in order to protect
      specific data flows between two flow-based NSFs implementing
      IPsec.

   o  To map this
   particular challenge architecture to the I2NSF Framework.

   o  To define the interfaces required to manage and monitor the IPsec
      SAs in [RFC8192]. the NSF from a I2NSF Controller.  YANG data models are
      defined for configuration and state data for IPsec and IKEv2
      management through the I2NSF NSF-Facing interface.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].  When these words appear in lower case, they have
   their natural language meaning.

3.  Terminology

   This document uses the terminology described in [RFC7149], [RFC4301], [RFC8329], [RFC8192],
   [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow],
   [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology].  In
   addition, the The following terms are term is
   defined below: in [ITU-T.Y.3300]:

   o  Software-Defined Networking.  A set of techniques enabling to
      directly program, orchestrate, control, and manage network
      resources, which facilitates the design, delivery and operation of
      network services

   The following terms are in a dynamic and scalable manner [ITU-T.Y.3300]. defined in [RFC8192]:

   o  Flow/Data Flow.  Set of network packets sharing a set of
      characteristics, for example IP dst/src values or QoS parameters.

   o  Security Controller.  An entity that contains control plane
      functions to manage and facilitate information sharing, as well as
      execute security functions.  In the context of this document, it
      provides IPsec management information.

   o  Network Security Function (NSF).  Software that provides a set of
      security-related services.  NSF.

   o  Flow-based NSF.  A NSF that inspects network flows according to a
      set of policies intended for enforcing security properties.

   The
      NSFs considered following terms are defined in this document fall into this classification. [RFC4301]:

   o  Flow-based Protection Policy.  Peer Authorization Database (PAD).

   o  Security Associations Database (SAD).

   o  Security Policy Database (SPD).

   The set of rules defining the
      conditions under which a data flow MUST be protected with IPsec,
      and the rules that MUST be applied to the specific following term is defined in [RFC6437]:

   o  Flow/traffic flow.

   The following terms is defined in [RFC7296]:

   o  Internet Key Exchange (IKE) v2.  Protocol to establish version 2 (IKEv2).

   The following terms are defined in [RFC6241]:

   o  Configuration data.

   o  Configuration datastore.

   o  State date.

   o  Startup configuration datastore.

   o  Running configuration datastore.

4.  SDN-based IPsec
      Security Associations (SAs).  It requires information about management description

   As mentioned in Section 1, two cases are considered, depending on
   whether the
      required authentication method (i.e. raw RSA/ECDSA keys NSF ships an IKEv2 implementation or X.509
      certificates), Diffie-Hellman (DH) groups, IPsec SAs parameters not: IKE case and algorithms for
   IKE-less case.

4.1.  IKE SA negotiation, etc.

   o  Security Policy Database (SPD).  It includes information about case: IKEv2/IPsec in the NSF

   In this case, the NSF ships an IPsec policies direction (in, out), local and remote addresses
      (traffic selectors information), inbound implementation with IKEv2
   support.  The I2NSF Controller is in charge of managing and outboud applying
   IPsec SAs,
      etc.

   o  Security Associations Database (SAD).  It includes connection information
      about IPsec SAs, (determining which nodes need to start
   an IKEv2/IPsec session, identifying the type of traffic to be
   protected, deriving and delivering IKEv2 Credentials such as SPI, destination addresses,
      authentication and encryption algorithms and keys to protect IP
      flows.

   o  Peer Authorization Database (PAD).  It provides the link between
      the SPD and a security association management protocol.  It is
      used when the NSF deploys IKE implementation (IKE case).

4.  Objectives

   o  To describe the architecture for the SDN-based IPsec management,
      which implements a security service to allow the establishment and
      management of IPsec security associations from a central point, in
      order to protect specific data flows.

   o  To define the interfaces required to manage and monitor the IPsec
      Security Associations (SA) in the NSF from a Security Controller.
      YANG models are defined for configuration and state data for IPsec
      management.

5.  SDN-based IPsec management description

   As mentioned in Section 1, two cases are considered, depending on
   whether the NSF ships an IKEv2 implementation or not: IKE case and
   IKE-less case.

5.1.  IKE case: IKE/IPsec in the NSF

   In this case the NSF ships an IKEv2 implementation besides the IPsec
   support.  The Security Controller is in charge of managing and
   applying IPsec connection information (determining which nodes need
   to start an IKE/IPsec session, deriving and delivering IKE
   Credentials such as a pre-shared key, certificates, etc.), a pre-
   shared key, certificates, etc.), and applying other IKE IKEv2
   configuration parameters (e.g.  cryptographic algorithms for
   establishing an IKE IKEv2 SA) to the NSF necessary for the IKE IKEv2
   negotiation.

   With these entries, the IKEv2 implementation can operate to establish
   the IPsec SAs.  The application (administrator) I2NSF User establishes the IPsec requirements and
   information about the end points information (through the Client Facing I2NSF
   Consumer-Facing Interface, [RFC8192]), [RFC8329]), and the Security I2NSF Controller
   translates these requirements into IKE, IKEv2, SPD and PAD entries that
   will be installed into the NSF (through the NSF Facing I2NSF NSF-Facing
   Interface).  With that information, the NSF can just run IKEv2 to
   establish the required IPsec SA (when the data traffic flow needs
   protection).  Figure 1 shows the different layers and corresponding
   functionality.

               +-------------------------------------------+
               |IPsec Management/Orchestration Application
               | Client or          IPsec Management System          | I2NSF Client                     | App Gateway User
               +-------------------------------------------+
                                       |    Client Facing
                                       |  I2NSF Consumer-Facing
                                       |  Interface
               +-------------------------------------------+
      Vendor   |             Application Support
               |
      Facing<->|-------------------------------------------| Security
      Interface| IKE Credential,PAD IKEv2 Configuration, PAD and SPD entries Distr. Entries  | I2NSF
               |               Distribution                | Controller
               +-------------------------------------------+
                                       |       NSF Facing Interface
               +-------------------------------------------+
                                       |  I2NSF Agent NSF-Facing
                                       |
               |-------------------------------------------| Network  Interface
               +-------------------------------------------+
               |   IKE   IKEv2  |      IPsec(SPD,PAD)      IPsec(PAD, SPD)           | Security Network
               |-------------------------------------------| Function Security
               |    IPsec Data Protection and Forwarding   | Function
               +-------------------------------------------+

                 Figure 1: IKE case: IKE/IPsec in the NSF

5.1.1.  Interface Requirements for IKE case

   SDN-based

   I2NSF-based IPsec flow protection services provide dynamic and
   flexible management of IPsec SAs in flow-based NSFs.  In order to
   support this capability in the IKE case, the following interface requirements need to
   be met:

   o  A a YANG data model for IKEv2,
   SPD and PAD configuration data, and for IKE IKEv2 state data.

   o  In scenarios where multiple Security Controllers are implicated,
      SDN-based IPsec management services may require a mechanism to
      discover which Security Controller is managing a specific NSF.
      Moreover, an east-west interface [RFC7426] is required to exchange
      IPsec-related information.  For example, if two gateways need to
      establish an IPsec SA and both are under the control of two
      different controllers, then both Security Controllers need to
      exchange information to properly configure their own NSFs.  That
      is, the may need to agree on whether IKEv2 authentication will data MUST be
      based on raw public keys, pre-shared keys, etc.  In case of using
      pre-shared keys they will have to agree in
   defined for the PSK.

5.2. I2NSF NSF-Facing Interface.

4.2.  IKE-less case: IPsec (no IKEv2) in the NSF.

   In this case, the NSF does not deploy IKEv2 and, therefore, the
   Security I2NSF
   Controller has to perform the IKE IKEv2 security functions and management
   of IPsec SAs by populating and managing the SPD and the SAD.

               +-----------------------------------------+
               |         IPsec Management  Application         | Client or System         | I2NSF Client              | App Gateway User
               +-----------------------------------------+
                                   |   Client Facing
                                   |  I2NSF Consumer-Facing Interface
                                   |
               +-----------------------------------------+
       Vendor|             Application Support
               |
    Facing<->|-----------------------------------------| Security
    Interface|      SPD, SAD           SPD and PAD SAD Entries Distr.           | I2NSF
               |              Distribution               | Controller
               +-----------------------------------------+
                                   |   NSF Facing
                                   |  I2NSF NSF-Facing Interface
                                   |
               +-----------------------------------------+
               |              I2NSF Agent             IPsec (SPD, SAD)            | Network
               |-----------------------------------------| Security
               |   IPsec (SPD,SAD)              | Function (NSF)
             |-----------------------------------------|
             | Data Protection and Forwarding  | Function
               +-----------------------------------------+

           Figure 2: IKE-less case: IPsec (no IKE) IKEv2) in the NSF

   As shown in Figure 2, applications for flow protection run on the top
   of the Security Controller.  When when an administrator I2NSF User enforces flow-
   based flow-based
   protection policies through the Client Facing Consumer-Facing Interface, the
   Security I2NSF
   Controller translates these requirements into SPD and SAD entries,
   which are installed in the NSF.  PAD entries are not required since
   there is no IKEv2 in the NSF.

5.2.1.  Interface Requirements for IKE-less case

   In order to support the IKE-less case, the following requirements
   need to be met:

   o  A a YANG data model for configuration data for SPD and
   SAD configuration data and for SAD state data for SAD.

   o  In scenarios where multiple controllers are implicated, SDN-based
      IPsec management services may require a mechanism to discover
      which Security Controller is managing a specific NSF.  Moreover,
      an east-west interface [RFC7426] is required to exchange IPsec-
      related information.  NOTE: A possible east-west protocol for this
      IKE-less case could be IKEv2.  However, this needs to be explore
      since the IKEv2 peers would MUST be defined for the Security Controllers.
   NSF-Facing Interface.

   Specifically, the IKE-less case assumes that the SDN controller I2NSF Controller has
   to perform some security functions that IKEv2 typically does, namely
   (non-exhaustive):

   o  IV generation.

   o  Prevent counter resets for the same key.

   o  Generation of pseudo-random cryptographic keys for the IPsec SAs.

   o  Rekey  Generation of the IPsec SAs when required based on notifications
      (i.e. sadb-acquire) from the NSF (i.e.
      expire). NSF.

   o  Generation  Rekey of the IPsec SAs when required based on notifications
      (i.e. sadb-acquire) from the NSF. NSF (i.e.
      expire).

   o  NAT Traversal discovery and management.

   Additionally to these functions, another set of tasks must be
   performed by the Security I2NSF Controller (non-exhaustive list):

   o  IPsec SA's SPI random generation.

   o  Cryptographic algorithm/s selection.

   o  Usage of extended sequence numbers.

   o  Establishment of proper traffic selectors.

5.3.

5.  IKE case vs IKE-less case

   In principle, the IKE case is easier to deploy than the IKE-less case
   because current flow-based NSFs (either hosts or gateways) have
   access to IKEv2 implementations.  While gateways typically have deploy an
   IKEv2/IPsec implementation.
   Moreover implementation, hosts can install easily an IKE implementation. install it.  As
   downside, the NSF needs more resources to hold IKEv2.  Moreover, the IKEv2 implementation needs to implement an internal interface so that
   the IKE configuration sent by such as memory
   for the Security Controller can be enforced
   in runtime. IKEv2 implementation, and computation, since each IPsec
   security association rekeying MAY involve a Diffie-Hellman exchange.

   Alternatively, IKE-less case allows lighter NSFs (no IKEv2
   implementation), which benefits the deployment in resource-
   constrained NSFs.  Moreover, IKEv2 does not need to be performed in
   gateway-to-gateway and host-to-host scenarios under the same Security I2NSF
   Controller (see
   Section 7.1). Appendix G.1).  On the contrary, the overload complexity of
   creating and managing IPsec SAs is shifted to the Security I2NSF Controller
   since IKEv2 is not in the NSF.  As a consequence, this may result in
   a more complex implementation in the controller side in comparison
   with IKE case.  For example, the Security I2NSF Controller have has to deal with
   the latency existing in the path between the Security I2NSF Controller and the NSF
   NSF, in order to solve tasks such as, rekey as rekey, or creation and
   installation of new IPsec SAs.  However, this is not specific to our this
   contribution but a general aspect in any SDN-based network.  In
   summary, this overload
   may complexity MAY create some scalability and performance
   issues when the number of NSFs is high.

   Nevertheless, literature around SDN-based network management using a
   centralized Security Controller controller (like the I2NSF Controller) is aware about
   scalability and performance issues and solutions have been already
   provided and discussed (e.g.  hierarchical Security Controllers; controllers; having
   multiple replicated Security Controllers, controllers, dedicated high-speed management
   networks, etc).  In the context of SDN-based I2SNF-based IPsec management, one
   way to reduce the latency and alleviate some performance issues can
   be the installation of the IPsec policies and IPsec SAs at the same
   time (proactive mode, as described in Section 7.1) Appendix G.1) instead of
   waiting for notifications (e.g. a notification sadb-acquire when a
   new IPsec SA is required) to proceed with the IPsec SA installations installation
   (reactive mode).  Another way to reduce the overhead and the
   potential scalability and performance issues in the Security I2NSF Controller
   is to apply the IKE case described in this document, since the IPsec
   SAs are managed between NSFs without the involvement of the Security I2NSF
   Controller at all, except by the initial IKE configuration (i.e.  IKEv2,
   PAD and SPD entries) provided by the Security I2NSF Controller.  Other
   solutions, such as Controller-IKE
   [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide
   their DH public keys to the Security I2NSF Controller, so that the Security I2NSF
   Controller distributes all public keys to all peers.  All peers can
   calculate a unique pairwise secret for each other peer and there is
   no inter-NSF messages.  A rekey mechanism is further described in
   [I-D.carrel-ipsecme-controller-ike].

   In terms of security, IKE case provides better security properties
   than IKE-less case, as we discuss in section Section 9. 8.  The main
   reason is that the NSFs are generating generate the session keys and not the
   Security I2NSF
   Controller.

5.3.1.

5.1.  Rekeying process

   Performing a rekey for IPsec SAs is an important operation during the
   IPsec SAs management.  With the YANG data models defined in this
   document the I2NSF Controller can configure and conduct the rekey
   process.  Depending on the case, the rekey process is different.

   For the IKE case, the rekeying process is carried out by IKEv2,
   following the information defined in the SPD and SAD. SAD (i.e. based on
   the IPsec SA lifetime established by the I2NSF Controller using the
   YANG data model defined in this document).  Therefore, IPsec
   connections will live unless something different is required by the administrator
   I2NSF User or the Security I2NSF Controller detects something wrong.

   Traditionally, during a rekey process of

   For the IPSec SA using IKE, a
   bundle of inbound and outbound IPsec SAs is taken into account from IKE-less case, the perspective of one I2NSF Controller MUST take care of the NSFs.  For example, if
   rekeying process.  When the inbound IPsec SA expires both the inbound and outbound is going to expire (e.g.  IPsec
   SA are rekeyed
   at the same time in that NSF.  However, when IKE is not used, we have
   followed a different approach to avoid any packet loss during rekey:
   the Security Controller installs first the new inbound SAs in both
   NSFs and then, the outbound IPsec SAs.

   In other words, for the IKE-less case, the Security Controller needs
   to take care of the rekeying process.  When the IPsec SA is going to
   expire (e.g.  IPsec SA soft lifetime), it has to create soft lifetime), it MUST create a new IPsec SA and it MAY remove
   the old one. one (if a IPsec SA lifetime has not been defined).  This
   rekeying process starts when the
   Security I2NSF Controller receives a sadb-expire sadb-
   expire notification or it decides so, based on lifetime state data
   obtained from the NSF.

   To explain  How the rekeying I2NSF Controller implements an
   algorithm for the rekey process between two IPsec NSFs A and B, let
   assume that SPIa1 identifies is out of the inbound IPsec SA scope of this document.
   Nevertheless, an example of how this rekey could be performed is in A, and SPIb1
   Appendix G.2.

5.2.  NSF state loss.

   If one of the
   inbound IPsec SA in B.  The rekeying process NSF restarts, it will take the following
   steps:

   1.  The Security Controller chooses two random values as SPI for lose the
       new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
       These numbers MUST NOT be in conflict with any IPsec SA in A or
       B.  Then, state (affected
   NSF).  By default, the Security I2NSF Controller creates an inbound IPsec SA
       with SPIa2 in A and another inbound IPsec SA in B with SPIb2.  It can send this information simultaneously to A and B.

   2.  Once the Security Controller receives confirmation from A and B,
       the controller knows assume that all the inbound IPsec A are correctly
       installed.  Then state
   has been lost and therefore it proceeds will have to send in parallel to A IKEv2, SPD and B, the
       outbound IPsec SAs: it sends the outbound IPsec SA to A with
       SPIb2 and the outbound IPsec SA PAD
   information to B with SPIa2.  At this point
       the new IPsec SAs are ready.

   3.  Once the Security Controller receives confirmation from A and B
       that the outbound IPsec SAs have been installed, the Security
       Controller, NSF in parallel, deletes the old IPsec SAs from A
       (inbound SPIa1 and outbound SPIb1) IKE case, and B (outbound SPIa1 SPD and
       inbound SPIb1).

   If some of the operations SAD information
   in step 1 fail (e.g. the NSF A reports an
   error when the Security Controller is trying to install a new inbound
   IPsec SA) IKE-less case.

   In both cases, the Security I2NSF Controller must perform rollback operations by
   removing any new inbound SA that had been successfully installed
   during step 1.

   If step 1 is successful but some aware of the operations in step 2 fails affected NSF
   (e.g. the NSF A reports an error when NETCONF/TCP connection is broken with the Security affected NSF, the
   I2NSF Controller is
   trying to install the new outbound IPsec SA), receiving sadb-bad-spi notification from a
   particular NSF, etc.).  Moreover, the Security I2NSF Controller
   must perform keeps a rollback operation by deleting any new outbound SA list
   of NSFs that had been successfully installed during step 2 and by deleting
   the inbound have IPsec SAs created in step 1.

   If with the steps 1 an 2 are successful and affected NSF.  Therefore, it
   knows the step 3 fails affected IPsec SAs.

   In the Security IKE case, the I2NSF Controller will avoid any rollback of configure the affected NSF
   with the operations carried out in
   step 1 and step 2 since new and valid IPsec SAs were created and are
   functional.  The Security Controller may reattempt to remove the old
   inbound and outbound SAs in NSF A and NSF B several times until it
   receives a success or it gives up.  In the last case, the old IPsec
   SAs will be removed when the hard lifetime is reached.

5.3.2.  NSF state loss.

   If one of the NSF restarts, it will lose the IPsec state (affected
   NSF).  By default, the Security Controller can assume that all the
   state has been lost and therefore it will have to send IKEv2, SPD and
   PAD information to the NSF in the IKE case, and SPD and SAD
   information in IKE-less case.

   In both cases, the Security Controller is aware of the affected NSF
   (e.g. the NETCONF/TCP connection is broken with the affected NSF, the
   Security Controller is receiving sadb-bad-spi notification from a
   particular NSF, etc.).  Moreover, the Security Controller has a
   register about all the NSFs that have IPsec SAs with the affected
   NSF.  Therefore, it knows the affected IPsec SAs.

   In IKE case, the Security Controller will configure the affected NSF
   with the new IKEv2, SPD IKEv2, SPD and PAD information.  It has also to send new
   parameters (e.g. a new fresh PSK for authentication) to the NSFs
   which have IKEv2 SAs and IPsec SAs with the affected NSF.  Finally,
   the Security I2NSF Controller will instruct the affected NSF to start the
   IKEv2 negotiation with the new configuration.

   In IKE-less case, if

   Alternatively, IKEv2 configuration MAY be made permanent between NSFs
   reboots without compromising security by means of the Security Controller detects that startup
   configuration datastore in the NSF.  This way, each time a NSF has
   lost the IPsec SAs
   reboots it will use that configuration for each rebooting.  It would
   imply avoiding to contact with the I2NSF Controller.

   In the IKE-less case, the I2NSF Controller SHOULD delete the old
   IPsec SAs on in the non-failed
   nodes, nodes established with the failed node (step 1).  This prevents the
   non-failed nodes from leaking plaintext.  If affected NSF.
   Once the affected node comes
   to live, restarts, the Security I2NSF Controller will configure MUST take the new inbound
   necessary actions to reestablish IPsec
   SAs protected communication
   between the affected failed node and all the nodes it was talking to
   (step 2).  After these inbound those others having IPsec SAs have been established, with the
   Security
   affected NSF.  How the I2NSF Controller can configure implements an algorithm for
   managing a potential NSF state loss is out of the outbound IPsec SAs in parallel
   (step 3).

   Nevertheless other more optimized options can scope of this
   document.  Nevertheless, an example of how this could be considered (e.g.
   making performed is
   described in Appendix G.3.

5.3.  NAT Traversal

   In the IKE case, IKEv2 configuration permanent already provides a mechanism to detect whether
   some of the peers or both are located behind a NAT.  If there is a
   NAT network configured between reboots).

5.3.3. two peers, it is required to activate
   the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
   [RFC8229]).  Note that the usage of IPsec transport mode when NAT Traversal is
   required MUST NOT be used in this specification.

   In the IKE case, IKEv2 already provides a mechanism to detect whether
   some of the peers or both are located behind a NAT.  If there is a
   NAT network configured between two peers, it is required to activate
   the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
   [RFC8229]).  Note that the usage of IPsec transport mode when NAT is
   required MUST NOT be used in this specification.

   On the contrary,

   In the IKE-less case case, the NSF does not have any protocol in the
   NSFs assistance of the
   IKEv2 implementation to detect whether they are if it is located behind a NAT or not.
   However, NAT.  If the
   NSF does not have any other mechanism to detect this situation, the
   I2NSF Controller SHOULD implement a mechanism to detect that case.
   The SDN paradigm generally assumes the Security I2NSF Controller has a view of
   the network under its control.  This view is built either requesting
   information to the NSFs under its control, or because these NSFs
   inform the Security I2NSF Controller.  Based on this information, the Security I2NSF
   Controller can MAY guess if there is a NAT configured between two hosts,
   and apply the required policies to both NSFs besides activating the
   usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948],
   [RFC8229]).

   For example, the Security Controller could directly request  The interface for discovering if the NSF
   for specific data such as networking configuration, NAT support, etc.
   Protocols such as NETCONF or SNMP can be used here.  For example, RFC
   7317 [RFC7317] provides a YANG data model for system management or
   [RFC8512] is behind a data model for NAT management.  The Security Controller
   can use this NETCONF module with a NSF to collect NAT information or
   even configure a NAT network.  In any case, if this NETCONF module
   is
   not available in the NSF and out of scope of this document.

   If the Security I2NSF Controller does not have a any mechanism to know whether a
   host is behind a NAT or not, then the IKE
   case should IKE-case MUST be the right choice used and not
   the IKE-less case.

5.3.4.

5.4.  NSF registration and discovery

   NSF registration refers to the process of facilitating the I2NSF
   Controller information about a valid NSF Discovery such as certificate, IP
   address, etc.  This information is incorporated to a list of NSFs
   under its control.

   The assumption in this document is that, for both cases, before a NSF
   can operate in this system, it MUST be registered in the Security I2NSF
   Controller.  In this way, when the NSF comes to live starts and establishes a
   connection to the Security I2NSF Controller, it knows that the NSF is valid
   for joining the system.

   Either during this registration process or when the NSF connects with
   the Security I2NSF Controller, the Security I2NSF Controller MUST discover certain
   capabilities of this NSF, such as what is the cryptographic suite
   supported, authentication method, the support of the IKE case
   or and/or
   the IKE-less case, etc.  This

   The registration and discovery process is processes are out of the scope of this
   document.

6.  YANG configuration data models

   In order to support the IKE and IKE-less cases we have modeled the
   different parameters and values that must be configured to manage
   IPsec SAs.  Specifically, the IKE case requires modeling IKEv2, IKEv2
   configuration parameters, SPD and PAD, while the IKE-less case
   requires configuration models for the SPD and SAD.  We have defined
   three models: ietf-ipsec-common (Appendix A), ietf-ipsec-ike
   (Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, IKE-less
   case).  Since the model ietf-ipsec-common has only typedef and
   groupings common to the other modules, we only show a simplified view
   of the ietf-ipsec-ike and ietf-ipsec-ikeless models.

6.1.  IKE case model

   The model related to IKEv2 has been extracted from reading IKEv2
   standard in [RFC7296], and observing some open source
   implementations, such as Strongswan [strongswan] or Libreswan
   [libreswan].

   The definition of the PAD model has been extracted from the
   specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
   that many implementations integrate PAD configuration as part of the
   IKEv2 configuration).

   module: ietf-ipsec-ike
   +--rw ipsec-ike
     +--rw pad
     |  +--rw pad-entry* [name]
     |     +--rw name                           string
     |     +--rw (identity)
     |     |  +--:(ipv4-address)
     |     |  |  +--rw ipv4-address?            inet:ipv4-address
     |     |  +--:(ipv6-address)
     |     |  |  +--rw ipv6-address?            inet:ipv6-address
     |     |  +--:(fqdn-string)
     |     |  |  +--rw fqdn-string?             inet:domain-name
     |     |  +--:(rfc822-address-string)
     |     |  |  +--rw rfc822-address-string?   string
     |     |  +--:(dnx509)
     |     |  |  +--rw dnx509?                  string
     |     |  +--:(gnx509)
     |     |  |  +--rw gnx509?                  string
     |     |  +--:(id-key)
     |     |  |  +--rw id-key?                  string
     |     |  +--:(id-null)
     |     |     +--rw id-null?                 empty
     |     +--rw auth-protocol?                 auth-protocol-type
     |     +--rw peer-authentication
     |        +--rw auth-method?                auth-method-type
     |        +--rw eap-method
     |        |  +--rw eap-type                 uint8
     |        +--rw pre-shared
     |        |  +--rw secret?                  yang:hex-string
     |        +--rw digital-signature
     |           +--rw ds-algorithm?            uint8
     |           +--rw (public-key)
     |           |  +--:(raw-public-key)
     |           |  |  +--rw raw-public-key?   binary
     |           |  +--:(cert-data)
     |           |     +--rw cert-data?        ct:x509
     |           +--rw private-key?            binary
     |           +--rw ca-data*                ct:x509
     |           +--rw crl-data?               ct:crl
     |           +--rw crl-uri?                inet:uri
     |           +--rw oscp-uri?               inet:uri
     +--rw conn-entry* [name]
     |  +--rw name                                 string
     |  +--rw autostartup?                         autostartup-type
     |  +--rw initial-contact?                     boolean
     |  +--rw version?                             auth-protocol-type
     |  +--rw fragmentation?                       boolean
     |  +--rw ike-sa-lifetime-soft
     |  |  +--rw rekey-time?    uint32
     |  |  +--rw reauth-time?   uint32
     |  +--rw ike-sa-lifetime-hard
     |  |  +--rw over-time?   uint32
     |  +--rw authalg*  ic:integrity-algorithm-type
     |  +--rw encalg*   ic:encryption-algorithm-type
     |  +--rw dh-group?                            pfs-group
     |  +--rw half-open-ike-sa-timer?              uint32
     |  +--rw half-open-ike-sa-cookie-threshold?   uint32
     |  +--rw local
     |  |  +--rw local-pad-entry-name?   string
     |  +--rw remote
     |  |  +--rw remote-pad-entry-name?   string
     |  +--rw encapsulation-type
     |  |  +--rw espencap?   esp-encap
     |  |  +--rw sport?      inet:port-number
     |  |  +--rw dport?      inet:port-number
     |  |  +--rw oaddr*      inet:ip-address
     |  +--rw spd
     |  |  +--rw spd-entry* [name]
     |  |    +--rw name                   string
     |  |    +--rw ipsec-policy-config
     |  |      +--rw anti-replay-window?   uint64
     |  |      +--rw traffic-selector
     |  |      |  +--rw local-subnet      inet:ip-prefix
     |  |      |  +--rw remote-subnet     inet:ip-prefix
     |  |      |  +--rw inner-protocol?   ipsec-inner-protocol
     |  |      |  +--rw local-ports* [start end]
     |  |      |  |  +--rw start          inet:port-number
     |  |      |  |  +--rw end            inet:port-number
     |  |      |  +--rw remote-ports* [start end]
     |  |      |     +--rw start          inet:port-number
     |  |      |     +--rw end            inet:port-number
     |  |      +--rw processing-info
     |  |      |  +--rw action?         ipsec-spd-action
     |  |      |  +--rw ipsec-sa-cfg
     |  |      |    +--rw pfp-flag?              boolean
     |  |      |    +--rw ext-seq-num?           boolean
     |  |      |    +--rw seq-overflow?          boolean
     |  |      |    +--rw stateful-frag-check?   boolean
     |  |      |    +--rw mode?                  ipsec-mode
     |  |      |    +--rw protocol-parameters? ipsec-protocol-parameters
     |  |      |    +--rw esp-algorithms
     |  |      |    |  +--rw integrity*  integrity-algorithm-type
     |  |      |    |  +--rw encryption* encryption-algorithm-type
     |  |      |    |  +--rw tfc-pad?      boolean
     |  |      |    +--rw tunnel
     |  |      |       +--rw local           inet:ip-address
     |  |      |       +--rw remote          inet:ip-address
     |  |      |       +--rw df-bit?         enumeration
     |  |      |       +--rw bypass-dscp?    boolean
     |  |      |       +--rw dscp-mapping?   yang:hex-string
     |  |      |       +--rw ecn?            boolean
     |  |      +--rw spd-mark
     |  |         +--rw mark?   uint32
     |  |         +--rw mask?   yang:hex-string
     |  +--rw child-sa-info
     |  |  +--rw pfs-groups*               pfs-group
     |  |  +--rw child-sa-lifetime-soft
     |  |  |  +--rw time?      uint32
     |  |  |  +--rw bytes?     uint32
     |  |  |  +--rw packets?   uint32
     |  |  |  +--rw idle?      uint32
     |  |  |  +--rw action?    ic:lifetime-action
     |  |  +--rw child-sa-lifetime-hard
     |  |     +--rw time?      uint32
     |  |     +--rw bytes?     uint32
     |  |     +--rw packets?   uint32
     |  |     +--rw idle?      uint32
     |  +--ro state
     |     +--ro initiator?             boolean
     |     +--ro initiator-ikesa-spi?   ike-spi
     |     +--ro responder-ikesa-spi?   ike-spi
     |     +--ro nat-local?             boolean
     |     +--ro nat-remote?            boolean
     |     +--ro encapsulation-type
     |     |  +--ro espencap?   esp-encap
     |     |  +--ro sport?      inet:port-number
     |     |  +--ro dport?      inet:port-number
     |     |  +--ro oaddr*      inet:ip-address
     |     +--ro established?           uint64
     |     +--ro current-rekey-time?    uint64
     |     +--ro current-reauth-time?   uint64
     +--ro number-ike-sas
        +--ro total?               uint64
        +--ro half-open?           uint64
        +--ro half-open-cookies?   uint64

   Appendix D shows an example of IKE case configuration for a NSF, in
   tunnel mode (gateway-to-gateway), with NSFs authentication based on
   X.509 certificates.

6.2.  IKE-less case model

   For this case, the definition of the SPD model has been mainly
   extracted from the specification in section 4.4.1 and Appendix D in
   [RFC4301], though with some simplications.  For example, each changes, namely:

   o  Each IPsec policy (spd-entry) contains one traffic selector,
      instead of a list of them.  The reason is that we have observed real
      actual kernel implementations only admit a single traffic selector
      per IPsec policy.

   o  Each IPsec policy contains a identifier (reqid) to relate the
      policy with the IPsec SA.  This is common in Linux-based systems.

   o  Each IPsec policy has only one name and not a list of names.

   o  Combined algorithms has been removed because encryption algorithms
      MAY include authenticated encryption with associated data (AEAD).

   o  Tunnel information has been extended with information about DSCP
      mapping and ECN bit.  The reason is that we have observed real
      kernel implementations admit the configurations of these values.

   The definition of the SAD model has been mainly extracted from the
   specification in section 4.4.2 in [RFC4301].  Note [RFC4301] though with some changes,
   namely:

   o  Each IPsec SA (sad-entry) contains one traffic selector, instead
      of a list of them.  The reason is that this model
   not we have observed actual
      kernel implementations only allows to associate an admit a single traffic selector per
      IPsec SA.

   o  Each IPsec SA with its corresponding contains a identifier (reqid) to relate the policy through
      with the specific traffic selector but also an identifier
   (reqid). IPsec Policy.  The notifications model has reason is that we have observed real
      kernel implementations allow to include this value.

   o  Each IPsec SA has also a name in the same way as IPsec policies.

   o  Combined algorithm has been removed because encryption algorithm
      MAY include authenticated encryption with associated data (AEAD).

   o  Tunnel information has been extended with information about
      Differentiated Services Code Point (DSCP) mapping and Explicit
      Congestion Notificsation (ECN) bit.  The reason is that we have
      observed actual kernel implementations admit the configurations of
      these values.

   o  Lifetime of the IPsec SAs also include idle time and number of IP
      packets as threshold to trigger the lifetime.  The reason is that
      we have observed actual kernel implementations allow to set these
      types of lifetimes.

   o  Information to configure the type of encapsulation (encapsulation-
      type) for IPsec ESP packets in UDP ([RFC3948]), TCP ([RFC8229]) or
      TLS ([RFC8229]) has been included.

   The notifications model has been defined using as reference the
   PF_KEYv2 standard in [RFC2367].

   module: ietf-ipsec-ikeless
   +--rw ipsec-ikeless
    +--rw spd
    |  +--rw spd-entry* [name]
    |     +--rw name                   string
    |     +--rw direction?             ic:ipsec-traffic-direction
    |     +--rw reqid?                 uint64
    |     +--rw ipsec-policy-config
    |        +--rw anti-replay-window?   uint64
    |        +--rw traffic-selector
    |        |  +--rw local-subnet      inet:ip-prefix
    |        |  +--rw remote-subnet     inet:ip-prefix
    |        |  +--rw inner-protocol?   ipsec-inner-protocol
    |        |  +--rw local-ports* [start end]
    |        |  |  +--rw start          inet:port-number
    |        |  |  +--rw end            inet:port-number
    |        |  +--rw remote-ports* [start end]
    |        |     +--rw start          inet:port-number
    |        |     +--rw end            inet:port-number
    |        +--rw processing-info
    |        |  +--rw action?         ipsec-spd-action
    |        |  +--rw ipsec-sa-cfg
    |        |     +--rw pfp-flag?              boolean
    |        |     +--rw ext-seq-num?           boolean
    |        |     +--rw seq-overflow?          boolean
    |        |     +--rw stateful-frag-check?   boolean
    |        |     +--rw mode?                  ipsec-mode
    |        |     +--rw protocol-parameters?
    |        |     +--rw esp-algorithms
    |        |     |  +--rw integrity*    integrity-algorithm-type
    |        |     |  +--rw encryption*  encryption-algorithm-type
    |        |     |  +--rw tfc-pad?      boolean
    |        |     +--rw tunnel
    |        |        +--rw local           inet:ip-address
    |        |        +--rw remote          inet:ip-address
    |        |        +--rw df-bit?         enumeration
    |        |        +--rw bypass-dscp?    boolean
    |        |        +--rw dscp-mapping?   yang:hex-string
    |        |        +--rw ecn?            boolean
    |        +--rw spd-mark
    |           +--rw mark?   uint32
    |           +--rw mask?   yang:hex-string
    +--rw sad
     +--rw sad-entry* [name]
       +--rw name               string
       +--rw reqid?             uint64
       +--rw ipsec-sa-config
       |  +--rw spi                    uint32
       |  +--rw ext-seq-num?           boolean
       |  +--rw seq-number-counter?    uint64
       |  +--rw seq-overflow?          boolean
       |  +--rw anti-replay-window?    uint32
       |  +--rw traffic-selector
       |  |  +--rw local-subnet       inet:ip-prefix
       |  |  +--rw remote-subnet      inet:ip-prefix
       |  |  +--rw inner-protocol?    ipsec-inner-protocol
       |  |  +--rw local-ports*       [start end]
       |  |  |  +--rw start           inet:port-number
       |  |  |  +--rw end             inet:port-number
       |  |  +--rw remote-ports* [start end]
       |  |     +--rw start           inet:port-number
       |  |     +--rw end             inet:port-number
       |  +--rw protocol-parameters?  ic:ipsec-protocol-parameters
       |  +--rw mode?                 ic:ipsec-mode
       |  +--rw esp-sa
       |  |  +--rw encryption
       |  |  |  +--rw encryption-algorithm? ic:encryption-algorithm-type
       |  |  |  +--rw key?                    yang:hex-string
       |  |  |  +--rw iv?                     yang:hex-string
       |  |  +--rw integrity
       |  |     +--rw integrity-algorithm? ic:integrity-algorithm-type
       |  |     +--rw key?                   yang:hex-string
       |  +--rw sa-lifetime-hard
       |  |  +--rw time?      uint32
       |  |  +--rw bytes?     uint32
       |  |  +--rw packets?   uint32
       |  |  +--rw idle?      uint32
       |  +--rw sa-lifetime-soft
       |  |  +--rw time?      uint32
       |  |  +--rw bytes?     uint32
       |  |  +--rw packets?   uint32
       |  |  +--rw idle?      uint32
       |  |  +--rw action?    ic:lifetime-action
       |  +--rw tunnel
       |  |  +--rw local           inet:ip-address
       |  |  +--rw remote          inet:ip-address
       |  |  +--rw df-bit?         enumeration
       |  |  +--rw bypass-dscp?    boolean
       |  |  +--rw dscp-mapping?   yang:hex-string
       |  |  +--rw ecn?            boolean
       |  +--rw encapsulation-type
       |     +--rw espencap?   esp-encap
       |     +--rw sport?      inet:port-number
       |     +--rw dport?      inet:port-number
       |     +--rw oaddr*      inet:ip-address
       +--ro ipsec-sa-state
          +--ro sa-lifetime-current
          |  +--ro time?      uint32
          |  +--ro bytes?     uint32
          |  +--ro packets?   uint32
          |  +--ro idle?      uint32
          +--ro replay-stats
             +--ro replay-window?        uint64
             +--ro packet-dropped?       uint64
             +--ro failed?               uint32
             +--ro seq-number-counter?   uint64

    notifications:
     +---n sadb-acquire
     |  +--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
     |  +--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
     |  +--ro ipsec-sa-name           string
     +---n sadb-bad-spi
        +--ro spi                     uint32

   Appendix E shows an example of IKE-less case configuration for a NSF,
   in transport mode (host-to-host), with NSFs authentication based on
   shared secrets.  For the IKE-less case, Appendix F shows examples of
   IPsec SA expire, acquire, sequence number overflow and bad SPI
   notifications.

7.  Use cases examples  IANA Considerations

   This section explains how different traditional configurations, that
   is, host-to-host and gateway-to-gateway, are deployed using this SDN-
   based IPsec management service.  In turn, these configurations will
   be typical document registers three URIs in modern networks where, for example, virtualization will
   be key.

7.1.  Host-to-host or gateway-to-gateway under the same Security
      Controller
                      +----------------------------------------+
                      |           Security Controller          |
                      |                                        |
                   (1)|   +--------------+ (2)+--------------+ |
      Flow-based  ------> |Translate into|--->| South. Prot. | |
      Security. Pol.  |   |IPsec Policies|    |              | |
                      |   +--------------+    +--------------+ |
                      |                          |     |       |
                      |                          |     |       |
                      +--------------------------|-----|-------+
                                                 |     |
                                                 | (3) |
                       |-------------------------+     +---|
                       V                                   V
           +----------------------+         +----------------------+
           |    NSF A             |<=======>|   NSF B              |
           |IKEv2/IPsec(SPD/PAD)  |         |IKEv2/IPsec(SPD/PAD)  |
           +----------------------+  (4)    +----------------------+

        Figure 3: Host-to-host / gateway-to-gateway single Security
                       Controller for "ns" subregistry of the IKE case.

   Figure 3 describes
   IETF XML Registry [RFC3688].  Following the IKE case:

   1.  The administrator defines general flow-based security policies. format in [RFC3688], the
   following registrations are requested:

       URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common
       Registrant Contact: The Security Controller looks for I2NSF WG of the NSFs involved (NSF A and
       NSF B).

   2. IETF.
       XML: N/A, the requested URI is an XML namespace.

       URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
       Registrant Contact: The Security Controller generates IKEv2 credentials for them and
       translates I2NSF WG of the policies into SPD and PAD entries.

   3. IETF.
       XML: N/A, the requested URI is an XML namespace.

       URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
       Registrant Contact: The Security Controller inserts I2NSF WG of the IETF.
       XML: N/A, the requested URI is an IKEv2 configuration that
       includes XML namespace.

   This document registers three YANG modules in the SPD and PAD entries "YANG Module Names"
   registry [RFC6020].  Following the format in both NSF A and NSF B.  If
       some of operations with NSF A and NSF B fail [RFC6020], the following
   registrations are requested:

       Name:       ietf-ipsec-common
       Namespace:  urn:ietf:params:xml:ns:yang:ietf-ipsec-common
       Prefix:     ic
       Reference:  RFC XXXX

       Name:       ietf-ipsec-ike
       Namespace:  urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
       Prefix:     ike
       Reference:  RFC XXXX

       Name:       ietf-ipsec-ikeless
       Namespace:  urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
       Prefix:     ikeless
       Reference:  RFC XXXX

8.  Security
       Controller will stop Considerations

   First of all, this document shares all the process and perform a rollback operation
       by deleting any IKEv2, SPD and PAD configuration security issues of SDN
   that had been
       successfully installed are specified in NSF A or B.

   4.  If the previous step is successful, "Security Considerations" section of
   [ITU-T.Y.3300] and [RFC7426].

   On the flow one hand, it is protected by
       means of important to note that there MUST exist a
   security association between the IPsec SA established with IKEv2.

                        +----------------------------------------+
                        |    (1)     Security I2NSF Controller         |
            Flow-based  |                                        |
            Security -----------|                                |
            Policy      |       V                                |
                        |  +---------------+ (2)+-------------+  |
                        |  |Translate into |--->| South. Prot.|  |
                        |  |IPsec policies |    |             |  |
                        |  +---------------+    +-------------+  |
                        |                         |     |        |
                        |                         |     |        |
                        +-------------------------| --- |--------+
                                                  |     |
                                                  | (3) |
                           |----------------------+     +--|
                           V                               V
                  +------------------+       +------------------+
                  |    NSF A         |<=====>|   NSF B          |
                  |IPsec(SPD/SAD)    |   4)  |IPsec(SPD/SAD)    |
                  +------------------+       +------------------+

        Figure 4: Host-to-host / gateway-to-gateway single Security
                       Controller for IKE-less case.

   In and the IKE-less case, flow-based security policies defined by NSFs to
   protect the
   administrator are translated into IPsec SPD entries and inserted into critical information (cryptographic keys, configuration
   parameter, etc.) exchanged between these entities.

   On the corresponding NSFs.  Besides, fresh SAD entries will other hand, if encryption is mandatory for all traffic of a
   NSF, its default policy MUST be also
   generated by the Security Controller and enforced to drop (DISCARD) packets to prevent
   cleartext packet leaks.  This default policy MUST be pre-configured
   in the NSFs.  In
   this case, startup configuration datastore in the Security Controller does not run any IKEv2
   implementation (neither NSF before the NSFs), and it provides NSF
   contacts the cryptographic
   material for I2NSF Controller.  Moreover, the IPsec SAs.  These keys will startup configuration
   datastore MUST be also distributed
   securely through pre-configured with the southbound interface.  Note required ALLOW
   policies that this allow to communicate the NSF with the I2NSF Controller
   once the NSF is
   possible because both NSFs are managed deployed.  This pre-configuration step is not carried
   out by the same Security
   Controller.

   Figure 4 describes I2NSF Controller but by some other entity before the IKE-less case, NSF
   deployment.  In this manner, when a data packet needs to be
   protected in the path between the NSF A and NSF B:

   1.  The administrator establishes starts/reboots, it will
   always first apply the flow-based security policies,
       and configuration in the Security Controller looks for the involved NSFs.

   2.  The Security Controller translates startup configuration
   before contacting the flow-based security
       policies into IPsec SPD and SAD entries.

   3.  The Security Controller inserts these entries I2NSF Controller.

   Finally, we have divided this section in two parts in order to
   analyze different security considerations for both cases: NSF A with
   IKEv2 (IKE case) and NSF B IPsec databases (SPD and SAD).  The following text
       describes how this happens between two NSFs A and B:

       *  The Security Controller chooses two random values without IKEv2 (IKE-less case).  In general,
   the I2NSF Controller, as SPIs: for
          example, SPIa1 typically in the SDN paradigm, is a target
   for NSF A different type of attacks [SDNSecServ] and [SDNSecurity].  Thus,
   the I2NSF Controller is a key entity in the infrastructure and SPIb1 for NSF B.  These numbers MUST NOT
   be in conflict with any IPsec SA in NSF A or NSF B.
          It also generates fresh protected accordingly.  In particular, the I2NSF Controller will
   handle cryptographic material for the new
          inbound/outbound IPsec SAs and their parameters and send
          simultaneously so that the new inbound IPsec SA with SPIa1 and new
          outbound IPsec SAs with SPIb1 attacker may try to access
   this information.  Although we can assume this attack will not likely
   to happen due to NSF A; and the new inbound
          IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 assumed security measurements to
          B, together with protect the corresponding IPsec policies.

       *  Once
   I2NSF Controller, it deserves some analysis in the Security Controller receives confirmation from NSF A
          and NSF B, hypothetical case
   the controller knows that attack occurs.  The impact is different depending on the IPsec SAs are
          correctly installed and ready.

       If some of the operations described above fails (e.g. IKE case
   or IKE-less case.

8.1.  IKE case

   In the NSF A
       reports an error when IKE case, the Security I2NSF Controller is trying sends IKEv2 credentials (PSK,
   public/private keys, certificates, etc.) to
       install the SPD entry, the new inbound and outbound IPsec SAs) NSFs using the Security
   security association between I2NSF Controller must perform rollback operations by
       deleting any new inbound or outbound SA and SPD entry that had
       been successfully installed in any of NSFs.  The I2NSF
   Controller MUST NOT store the IKEv2 credentials after distributing
   them.  Moreover, the NSFs (e.g NSF B) and
       stop MUST NOT allow the process (NOTE: reading of these values
   once they have been applied by the Security I2NSF Controller may retry several
       times before giving up).  Other alternative (i.e. write only
   operations).  One option is to this always return the same value (i.e. all
   0s) if a read operation is: is carried out.

   If the Security attacker has access to the I2NSF Controller sends first during the IPsec policies and new
       inbound IPsec SAs to A and B and once it obtains a successful
       confirmation period
   of these operations from NSF A and NSF B, time that key material is generated, it
       proceeds with installing might have access to the new outbound IPsec SAs.  However,
       this
   key material.  Since these values are used during NSF authentication
   in IKEv2, it may increase impersonate the latency affected NSFs.  Several
   recommendations are important.

   o  IKEv2 configurations should adhere to complete the process.  As an
       advantage, no traffic recommendations in
      [RFC8247].

   o  If PSK authentication is sent over used in IKEv2, the network until I2NSF Controller MUST
      remove the IPsec
       SAs PSK immediately after generating and distributing it.

   o  When public/private keys are completely operative.  In any case other alternatives may
       be possible.  Finally, it is worth mentioning that used, the Security I2NSF Controller associates MAY
      generate both public key and private key.  In such a lifetime case, the
      I2NSF Controller MUST remove the associated private key
      immediately after distributing them to the new IPsec SAs.  When this
       lifetime expires, NSFs.  Alternatively,
      the NSF will send a sadb-expire notification to could generate the Security Controller in order private key and export only the public
      key to start the rekeying process.

   4.  The flow is protected with I2NSF Controller.

   o  If certificates are used, the IPsec SA established by NSF MAY generate the
       Security private key and
      exports the public key for certification to the I2NSF Controller.

   Instead of installing IPsec policies in
      How the SPD NSF generates these cryptographic material (public key/
      private keys) and IPsec SAs in exports the
   SAD in step 3 (proactive mode), public key it is also possible that the Security
   Controller only installs the SPD entries in step 3 (reactive mode). out of scope of
      this document.

8.2.  IKE-less case

   In such a case, when a data packet requires to be protected with
   IPsec, the NSF that saw first the data packet will send a sadb-
   acquire notification that informs IKE-less case, the Security I2NSF Controller that needs
   SAD entries with sends the IPsec SAs SA
   information to process the data packet.  In such
   as reactive mode, since IPsec policies are already installed in the
   SPD, NSF's SAD that includes the Security private session keys
   required for integrity and encryption.  The I2NSF Controller installs first MUST NOT
   store the new IPsec SAs in NSF
   A and B with keys after distributing them.  Moreover, the operations described in step 3 but without sending
   any IPsec policies.  Again, if some NSFs receiving
   private key material MUST NOT allow the reading of these values by
   any other entity (including the operations installing I2NSF Controller itself) once they
   have been applied (i.e. write only operations) into the
   new inbound/outbound IPsec SAs fail, NSFs.
   Nevertheless, if the Security attacker has access to the I2NSF Controller stops
   during the process and performs a rollback operation by deleting any new
   inbound/outbound SAs period of time that had been successfully installed.

   Both NSFs could key material is generated, it may
   obtain these values.  In other words, the attacker might be two hosts that exchange able to
   observe the IPsec traffic and require to
   establish an end-to-end security association to protect their
   communications (host-to-host) decrypt, or two gateways (gateway-to-gateway),
   for example, within an enterprise that needs to protect even modify and re-encrypt,
   the traffic between the networks of two branch offices.

   Applicability of these configurations appear peers.

8.3.  YANG modules

   The YANG module specified in current and new
   networking scenarios.  For example, SD-WAN technologies are providing
   dynamic and on-demand VPN connections between branch offices, this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or
   between branches RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and SaaS cloud services.  Beside, IaaS services
   providing virtualization environments are deployments solutions based
   on IPsec to provide the mandatory-to-implement secure channels between virtual instances (host-
   to-host)
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and providing VPN solutions for virtualized networks
   (gateway-to-gateway).

   In general (for IKE and IKE-less cases), this system has various
   advantages:

   1.  It allows to create IPsec SAs among two NSFs, based only on the
       application of general Flow-based Security Policies at mandatory-to-implement secure transport is TLS
   [RFC8446].

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the
       application layer.  Thus, administrators can manage means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all security
       associations in available NETCONF or
   RESTCONF protocol operations and content.

   There are a centralized point with an abstracted view number of
       the network.

   2.  Any NSF deployed in the system does not need manual
       configuration, therefore allowing its deployment data nodes defined in an automated
       manner.

7.2.  Host-to-host or gateway-to-gateway under different Security
      Controllers

   It is also possible these YANG modules that two NSFs (i.e.  NSF A and NSF B)
   are under writable/creatable/deletable (i.e., config true, which is the control of two different Security Controllers.  This
   default).  These data nodes may happen,
   for example, when two organizations, namely Enterprise A and
   Enterprise B, be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have their headquarters interconnected through a WAN
   connection negative
   effect on network operations.  These are the subtrees and data nodes
   and they both have deployed a SDN-based architecture to
   provide connectivity to all their clients.

                  +-------------+           +-------------+
                  |             |           |             |
        Flow-based|   Security  |<=========>|   Security <--Flow-based
        Sec. Pol.--> Controller |  (3)      |  Controller | Sec. Pol.
              (1) |      A      |           |      B      |   (2)
                  +-------------+           +-------------+
                          |                        |
                          | (4)                (4) |
                          V                        V
              +--------------------+          +--------------------+
              |    NSF A            |<=======>|   NSF B            |
              |IKEv2/IPsec(SPD/PAD)|          |IKEv2/IPsec(SPD/PAD)|
              +--------------------+  (5)     +--------------------+

         Figure 5: Different Security Controllers in sensitivity/vulnerability:

   The YANG modules describe configuration data for the IKE case.

   Figure 5 describes IKE case when two Security Controllers are
   involved (ietf-
   ipsec-ike) and IKE-less case (ietf-ipsec-ikeless).  There is a common
   module (ietf-ipsec-common) used in both cases.

   For the process.

   1.  The A's administrator establishes general Flow-based Security
       Policies in Security Controller A.

   2. IKE case (ietf-ipsec-ike):

         /ipsec-ike: The B's administrator establishes general Flow-based Security
       Policies entire container in Security Controller B.

   3.  The Security Controller A realizes that protection this module is required
       between sensitive to
         write operations.  An attacker may add/modify the NSF A and NSF B, but credentials
         to be used for the NSF B is under authentication (e.g. to impersonate a NSF),
         the control
       of another Security Controller (Security Controller B), so it
       starts negotiations with trust root (e.g. changing the other controller to agree on trusted CA certificates), the
         cryptographic algorithms (allowing a downgrading attack), the
         IPsec SPD policies (e.g. by allowing leaking of data traffic by
         changing to a allow policy), and IKEv2 credentials for their respective
       NSFs.  NOTE: This may require extensions in general changing the East/West
       interface.

   4.  Then, both Security Controllers enforce the IKEv2 credentials,
       related parameters IKE SA
         conditions and credentials between any NSF.

   For the SPD and PAD entries in their
       respective NSFs.

   5. IKE-less case (ietf-ipsec-ikeless):

         /ipsec-ikeless: The flow entire container in this module is protected with
         sensitive to write operations.  An attacker may add/modify/
         delete any IPsec policies (e.g. by allowing leaking of data
         traffic by changing to a allow policy) in the /ipsec-ikeless/
         spd container, and add/modify/delete any IPsec SAs established with IKEv2 between both NSFs.

                   +--------------+             +--------------+
                   |              |             |              |
         Flow-based. --->        |              |         <---Flow-based
            Prot.  |   Security   |<===========>|   Security   |Sec.
            Pol.(1)|  Controller  |     (3)     |  Controller  |Pol. (2)
                   |       A      |             |       B      |
                   +--------------+             +--------------+
                           |                               |
                           | (4)                       (4) |
                           V                               V
                  +--------------+      (5)       +--------------+
                  |    NSF A     |<==============>| two
         NSF B     |
                  |IPsec(SPD/SAD)|                |IPsec(SPD/SAD)|
                  +--------------+                +--------------+

      Figure 6: Different Security Controllers in the IKE-less case.

   Figure 6 describes IKE-less case when two Security Controllers are
   involved in the process.

   1.  The A's administrator establishes general Flow Protection
       Policies by means of /ipsec-ikeless/sad container and, in Security Controller A.

   2.  The B's administrator establishes general Flow Protection
       Policies in Security Controller B.

   3.  The Security Controller A realizes that the flow between NSF B
         changing any IPsec SAs and NSF B MUST IPsec policies between any NSF.

   Some of the readable data nodes in this YANG module may be protected.  Nevertheless, it notices that NSF B considered
   sensitive or vulnerable in some network environments.  It is under the thus
   important to control of another Security Controller B, so it
       starts negotiations with the other controller read access (e.g., via get, get-config, or
   notification) to agree on these data nodes.  These are the
       IPsec SPD subtrees and SAD entries that define data
   nodes and their sensitivity/vulnerability:

   For the IPsec SAs.  NOTE: It
       would worth evaluating IKEv2 as IKE case (ietf-ipsec-ike):

         /ipsec-ike/pad: This container includes sensitive information
         to read operations.  This information should never be returned
         to a client.  For example, cryptographic material configured in
         the protocol for NSFs: peer-authentication/pre-shared/secret and peer-
         authentication/digital-signature/private-key are already
         protected by the East/West
       interface NACM extension "default-deny-all" in this case.

   4.  Once
         document.

   For the Security Controllers have agreed on IKE-less case (ietf-ipsec-ikeless):

         /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container
         includes symmetric keys for the IPsec SAs.  For example,
         encryption/key contains a ESP encryption key material value and
         encryption/iv contains a initialization vector value.
         Similarly, integrity/key has ESP integrity key value.  Those
         values must not be read by anyone and are protected by the details of the IPsec SAs, they both enforce NACM
         extension "default-deny-all" in this information
       into their respective NSFs.

   5.  The flow is protected with the IPsec SAs established by both
       Security Controllers in document.

9.  Acknowledgements

   Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan,
   David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham
   Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J.  Bernardos,
   Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez,
   Ruben Ricart and Roman Danyliw for their respective NSFs.

8.  IANA Considerations

   This document registers three URIs in the "ns" subregistry of the
   IETF XML Registry [RFC3688].  Following the format in [RFC3688], the
   following registrations are requested:

        URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common
        Registrant Contact: The I2NSF WG of the IETF.
        XML: N/A, the requested URI is an XML namespace.

        URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
        Registrant Contact: The I2NSF WG of the IETF.
        XML: N/A, the requested URI is an XML namespace.

        URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
        Registrant Contact: The I2NSF WG of the IETF.
        XML: N/A, the requested URI is an XML namespace.

   This document registers three YANG modules valuable comments.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC6020]  Bjorklund, M., Ed., "YANG Module Names"
   registry [RFC6020].  Following the format in [RFC6020], - A Data Modeling Language for
              the following
   registrations are requested:

        Name:         ietf-ipsec-common
        Namespace:    urn:ietf:params:xml:ns:yang:ietf-ipsec-common
        Prefix:       ic
        Reference:    RFC XXXX

        Name:         ietf-ipsec-ike
        Namespace:    urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
        Prefix:       ike
        Reference:    RFC XXXX

        Name:         ietf-ipsec-ikeless
        Namespace:    urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
        Prefix:       ikeless
        Reference: Network Configuration Protocol (NETCONF)", RFC XXXX

9.  Security Considerations

   First of all, this document shares all the security issues of SDN
   that are specified in the "Security Considerations" section of
   [ITU-T.Y.3300] and [RFC8192].

   On the one hand, it is important to note that there MUST exit a
   security association between the Security Controller 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NSFs to
   protect of the critical information (cryptographic keys,
   configuration parameter, etc...) exchanged between these entities.
   For example, when NETCONF is used as southbound protocol between Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8247]  Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
              "Algorithm Implementation Requirements and Usage Guidance
              for the Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8247, DOI 10.17487/RFC8247, September 2017,
              <https://www.rfc-editor.org/info/rfc8247>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security Controller (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

10.2.  Informative References

   [I-D.carrel-ipsecme-controller-ike]
              Carrel, D. and the NSFs, it is defined that TLS or SSH
   security association MUST be established between both entities.

   On the other hand, if encryption is mandatory for all traffic of B. Weiss, "IPsec Key Exchange using a
   NSF, its default policy MUST be to drop (DISCARD) packets to prevent
   cleartext packet leaks.  This default policy MUST be in the startup
   configuration datastore in the NSF before the NSF contacts with the
   Security Controller.  Moreover, the startup configuration datastore
   MUST be pre-configured with the required ALLOW policies that allow to
   communicate the NSF with the Security Controller once the NSF is
   deployed.  This pre-configuration step is not carried out by the
   Security Controller but by some other entity before the NSF
   deployment.  In this manner, when the NSF starts/reboots, it will
   always apply first the configuration in the startup configuration
   before contacting the Security Controller.

   Finally, we have divided this section in two parts
              Controller", draft-carrel-ipsecme-controller-ike-01 (work
              in order to
   analyze different security considerations for both cases: NSF with
   IKEv2 (IKE case) progress), March 2019.

   [I-D.tran-ipsecme-yang]
              Tran, K., Wang, H., Nagaraj, V., and NSF without IKEv2 (IKE-less case).  In general,
   the Security Controller, as typically in the SDN paradigm, is a
   target X. Chen, "Yang Data
              Model for different type of attacks.  Thus, the Security Controller
   is a key entity in the infrastructure and MUST be protected
   accordingly.  In particular, the Security Controller will handle
   cryptographic material so that the attacker may try to access this
   information.  Although we can assume this attack will not likely to
   happen due to the assumed security measurements to protect the Internet Protocol Security Controller, it deserves some analysis (IPsec)", draft-tran-
              ipsecme-yang-01 (work in the hypothetical
   case the attack occurs. progress), June 2015.

   [ITU-T.Y.3300]
              "Recommendation ITU-T Y.3300", June 2014.

   [libreswan]
              The impact is different depending on the IKE
   case or IKE-less case.

9.1.  IKE case

   In IKE case, the Libreswan Project, "Libreswan VPN software", August
              2019.

   [netconf-vpn]
              Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014.

   [ONF-OpenFlow]
              ONF, "OpenFlow Switch Specification (Version 1.4.0)",
              October 2013.

   [ONF-SDN-Architecture]
              "SDN Architecture", June 2014.

   [RFC2367]  McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367,
              DOI 10.17487/RFC2367, July 1998,
              <https://www.rfc-editor.org/info/rfc2367>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, DOI 10.17487/RFC3948, January 2005,
              <https://www.rfc-editor.org/info/rfc3948>.

   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security Controller sends IKE credentials (PSK,
   public/private keys, certificates, etc.) (IPsec) and
              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
              DOI 10.17487/RFC6071, February 2011,
              <https://www.rfc-editor.org/info/rfc6071>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <https://www.rfc-editor.org/info/rfc6437>.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
              <https://www.rfc-editor.org/info/rfc7149>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface to the NSFs using the
   security association between Network Security Controller Functions
              (I2NSF): Problem Statement and NSFs.  The
   general recommendation is that the Security Controller MUST NOT store
   the Use Cases", RFC 8192,
              DOI 10.17487/RFC8192, July 2017,
              <https://www.rfc-editor.org/info/rfc8192>.

   [RFC8229]  Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
              of IKE credentials after distributing them.  Moreover, and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
              August 2017, <https://www.rfc-editor.org/info/rfc8229>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
              <https://www.rfc-editor.org/info/rfc8329>.

   [SDNSecServ]
              Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "SDN
              Security: A Survey", 2013.

   [SDNSecurity]
              Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure
              and Dependable Software-Defined Networks", 2013.

   [strongswan]
              CESNET, "StrongSwan: the NSFs MUST
   NOT allow OpenSource IPsec-based VPN
              Solution", August 2019.

Appendix A.  Common YANG model for IKE and IKE-less cases

       <CODE BEGINS> file "ietf-ipsec-common@2019-08-05.yang"

       module ietf-ipsec-common {
           yang-version 1.1;
           namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
           prefix "ipsec-common";

           import ietf-inet-types { prefix inet; }
           import ietf-yang-types { prefix yang; }

           organization "IETF I2NSF Working Group";

           contact
           "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/about/>
            WG List: <mailto:i2nsf@ietf.org>

           Author: Rafael Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";

           description
               "Common Data model for the reading of these values once they have been applied IKE and IKE-less cases
                defined by the Security Controller (i.e. write only operations).  One option is
   to return always SDN-based IPsec flow protection service.

               Copyright (c) 2019 IETF Trust and the same value (i.e. all 0s) if a read operation is
   carried out.  If persons
               identified as authors of the attacker has access code.  All rights reserved.
               Redistribution and use in source and binary forms, with
               or without modification, is permitted pursuant to, and
               subject to the Security Controller
   during license terms contained in, the period
               Simplified BSD License set forth in Section 4.c of time that key material is generated, it might
   have access the
               IETF Trust's Legal Provisions Relating to IETF Documents
               (https://trustee.ietf.org/license-info).

               This version of this YANG module is part of RFC XXXX;;
               see the RFC itself for full legal notices.

               The key material.  Since these values are used during
   NSF authentication words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
               'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
               'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in IKEv2, it may impersonate the affected NSFs.
   Several recommendations this
               document are important.  If PSK authentication is used to be interpreted as described in IKEv2, the Security Controller MUST remove the PSK immediately
   after generating BCP 14
               (RFC 2119) (RFC 8174) when, and distributing it.  Moreover, the PSK MUST have a
   proper length (e.g.  minimum 128 bit length) only when, they appear
               in all capitals, as shown here.";

           revision "2019-08-05" {
               description "Revision 06";
               reference "RFC XXXX: YANG Groupings and strength.  When
   public/private keys are used, the Security Controller MAY generate
   both public key typedef
                          for IKE and private key.  In such IKE-less case";
           }

           typedef encryption-algorithm-type {
               type uint16;
               description
                   "The encryption algorithm is specified with a case, the Security
   Controller 16-bit
                   number extracted from IANA Registry. The acceptable
                   values MUST remove the associated private key immediately after
   distributing them to the NSFs.  Alternatively, the NSF could generate follow the private key requirement levels for
                   encryption algorithms for ESP and export only the public key to the Security
   Controller.  If certificates are used, the NSF MAY generate the
   private key IKEv2.";
               reference
                    "IANA Registry- Transform Type 1 - Encryption
                    Algorithm Transform IDs. RFC 8221 - Cryptographic
                    Algorithm Implementation Requirements and exports the public key Usage
                    Guidance for certification to the Encapsulating Security Controller.  How the NSF generates these cryptographic
   material (public key/private keys) Payload (ESP)
                    and export Authentication Header (AH) and RFC 8247 -
                    Algorithm Implementation Requirements and Usage
                    Guidance for the public key, or it
   is instructed to do so, it is out of the scope of this document.

9.2.  IKE-less case

   In the IKE-less case, the Security Controller sends the IPsec SA
   information to the NSF's SAD that includes the private session keys
   required for Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
           }

           typedef integrity-algorithm-type {
               type uint16;
               description
                   "The integrity and encryption.  The general recommendation algorithm is
   that it MUST NOT store the keys after distributing them.  Moreover,
   the NSFs receiving private key material MUST NOT allow the reading of
   these specified with a 16-bit
                   number extracted from IANA Registry.
                   The acceptable values by any other entity (including the Security Controller
   itself) once they have been applied (i.e. write only operations) into
   the NSFs.  Nevertheless, if the attacker has access to MUST follow the requirement
                   levels for encryption algorithms for ESP and IKEv2.";
               reference
                   "IANA Registry- Transform Type 3 - Integrity
                    Algorithm Transform IDs. RFC 8221 - Cryptographic
                    Algorithm Implementation Requirements and Usage
                    Guidance for Encapsulating Security
   Controller during the period of time that key material is generated,
   it may obtain these values.  In other words, the attacker might be
   able to observe the IPsec traffic Payload (ESP)
                    and decrypt, or even modify Authentication Header (AH) and re-
   encrypt the traffic between peers.

9.3.  YANG modules

   The YANG module specified in this document defines a schema RFC 8247 -
                    Algorithm Implementation Requirements and Usage
                    Guidance for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
           }

           typedef ipsec-mode {
               type enumeration {
                   enum transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure {
                       description
                           "IPsec transport is TLS
   [RFC8446].

   The mode. No Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset Address
                            Translation (NAT) support.";
                   }
                   enum tunnel {
                       description "IPsec tunnel mode.";
                   }
               }
               description
                   "Type definition of all available NETCONF IPsec mode: transport or
   RESTCONF protocol operations and content.

   There are a number of data nodes defined
                    tunnel.";
               reference
                   "Section 3.2 in these YANG modules that
   are writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable RFC 4301.";
           }

           typedef esp-encap {
               type enumeration {
                   enum espintcp {
                       description
                           "ESP in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

   The YANG modules describe configuration data for the TCP encapsulation.";
                       reference
                           "RFC 8229 - TCP Encapsulation of IKE case (ietf-
   ipsec-ike) and IKE-less case (ietf-ipsec-ikeless).  There is a common
   module (ietf-ipsec-common) used
                            IPsec Packets.";
                   }
                   enum espintls {
                       description
                           "ESP in both cases.

   For the TCP encapsulation using TLS.";
                       reference
                           "RFC 8229 - TCP Encapsulation of IKE case (ietf-ipsec-ike):

         /ipsec-ike: The entire container and
                            IPsec Packets.";
                   }
                   enum espinudp {
                       description
                           "ESP in this module is sensitive to
         write operations.  An attacker may add/modify the credentials
         to be used for the authentication (e.g. to impersonate a NSF),
         the trust root (e.g.  changing the trusted CA certificates),
         the cryptographic algorithms (allowing a downgrading attack),
         the IPsec policies (e.g. by allowing leaking UDP encapsulation.";
                       reference
                           "RFC 3948 - UDP Encapsulation of data traffic by
         changing to a allow policy), and in general changing the IKE SA
         conditions and credentials between any NSF.

   For the IKE-less case (ietf-ipsec-ikeless):

         /ipsec-ikeless: The entire container in this module is
         sensitive to write operations.  An attacker may add/modify/
         delete any IPsec policies (e.g. by allowing leaking ESP
                           Packets.";
                   }
                   enum none {
                       description
                           "NOT ESP encapsulation.";
                   }
               }
               description
                   "Types of data
         traffic by changing to a allow policy) in the /ipsec-ikeless/
         spd container, and add/modify/delete any IPsec SAs ESP encapsulation when Network Address
                    Translation (NAT) is present between two
         NSF by means NSFs.";

               reference
                   "RFC 8229 - TCP Encapsulation of /ipsec-ikeless/sad container and, in general
         changing any IPsec SAs IKE and IPsec policies between any NSF.

   Some
                    Packets and RFC 3948 - UDP Encapsulation of IPsec
                    ESP Packets.";
           }

           typedef ipsec-protocol-parameters {
               type enumeration {
                   enum esp { description "IPsec ESP protocol."; }
               }
               description
                   "Only the readable data nodes in this YANG module may Encapsulation Security Protocol (ESP) is
                    supported but it could be considered
   sensitive or vulnerable extended in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes future.";
               reference
                   "RFC 4303- IP Encapsulating Security Payload
                   (ESP).";

           }

           typedef lifetime-action {
               type enumeration {
                   enum terminate-clear {
                       description
                           "Terminates the IPsec SA and their sensitivity/vulnerability:

   For allows the IKE case (ietf-ipsec-ike):

         /ipsec-ike/pad: This container includes sensitive information
         to read operations.  This information should never be returned
         to a client.  For example, cryptographic material configured in
                            packets through.";
                   }
                   enum terminate-hold {
                       description
                           "Terminates the NSFs: peer-authentication/pre-shared/secret IPsec SA and peer-
         authentication/digital-signature/private-key are already
         protected by the NACM extension "default-deny-all" in this
         document.

   For drops the IKE-less case (ietf-ipsec-ikeless):

         /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container
         includes symmetric keys for
                            packets.";
                   }
                   enum replace  {
                       description
                           "Replaces the IPsec SAs.  For example,
         encryption/key contains a ESP encryption key value and
         encryption/iv contains SA with a initialization vector value.
         Similarly, integrity/key has ESP integrity key value.  Those
         values must not be read by anyone and are protected by new one:
                           rekey. ";
                   }
               }
               description
                   "When the NACM
         extension "default-deny-all" in this document.

10.  Acknowledgements

   Authors want lifetime of an IPsec SA expires an action
                    needs to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan,
   David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham
   Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J.  Bernardos,
   Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez be performed over the IPsec SA that
                    reached the lifetime. There are three posible
                    options: terminate-clear, terminate-hold and Ruben Ricart for their valuable comments.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use
                    replace.";
               reference
                   "Section 4.5 in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4301]  Kent, S. 4301.";
           }

           typedef ipsec-traffic-direction {
               type enumeration {
                   enum inbound {
                       description "Inbound traffic.";
                   }
                   enum outbound {
                       description "Outbound traffic.";
                   }
               }
               description
                   "IPsec traffic direction is defined in two
                    directions: inbound and K. Seo, "Security Architecture for outbound. From a NSF
                    perspective inbound means the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for traffic that enters
                    the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., NSF and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using outbound is the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, traffic that is sent
                    from the NSF.";
               reference
                   "Section 5 in RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., 4301.";
           }

           typedef ipsec-spd-action {
               type enumeration {
                   enum protect {
                       description
                           "PROTECT the traffic with IPsec.";
                   }
                   enum bypass {
                       description
                           "BYPASS the traffic. The packet is forwarded
                            without IPsec protection.";
                   }
                   enum discard {
                       description
                           "DISCARD the traffic. The IP packet is
                            discarded.";
                   }
               }
               description
                   "The Transport Layer Security (TLS) Protocol
              Version 1.3", action when traffic matches an IPsec security
                    policy. According to RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

11.2.  Informative References

   [I-D.carrel-ipsecme-controller-ike]
              Carrel, D. and B. Weiss, "IPsec Key Exchange using a
              Controller", draft-carrel-ipsecme-controller-ike-01 (work 4301 there are three
                    possible values: BYPASS, PROTECT AND DISCARD";
               reference
                   "Section 4.4.1 in progress), March 2019.

   [I-D.ietf-i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., RFC 4301.";
           }

           typedef ipsec-inner-protocol {
               type union {
                   type uint8;
                   type enumeration {
                       enum any {
                           value 256;
                           description
                               "Any IP protocol number value.";
                       }
                   }
               }
               default any;
               description
                   "IPsec protection can be applied to specific IP
                    traffic and H.
              Birkholz, "Interface layer 4 traffic (TCP, UDP, SCTP, etc.)
                    or ANY protocol in the IP packet payload. We
                    specify the IP protocol number with an uint8 or
                    ANY defining an enumerate with value 256 to Network Security Functions (I2NSF)
              Terminology", draft-ietf-i2nsf-terminology-08 (work
                    indicate the protocol number.";
               reference
                   "Section 4.4.1.1 in
              progress), July 2019.

   [I-D.tran-ipsecme-yang]
              Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data
              Model for Internet RFC 4301.
                    IANA Registry - Protocol Security (IPsec)", draft-tran-
              ipsecme-yang-01 (work Numbers.";
           }

           grouping encap {
               description
                   "This group of nodes allows to define the type of
                    encapsulation in progress), June 2015.

   [ITU-T.X.1252]
              "Baseline Identity Management Terms and Definitions",
              April 2010.

   [ITU-T.X.800]
              "Security Architecture for Open Systems Interconnection
              for CCITT Applications", March 1991.

   [ITU-T.Y.3300]
              "Recommendation ITU-T Y.3300", June 2014.

   [libreswan]
              The Libreswan Project, "Libreswan VPN software", August
              2019.

   [netconf-vpn]
              Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014.

   [ONF-OpenFlow]
              ONF, "OpenFlow Switch Specification (Version 1.4.0)",
              October 2013.

   [ONF-SDN-Architecture]
              "SDN Architecture", June 2014.

   [RFC2367]  McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367,
              DOI 10.17487/RFC2367, July 1998,
              <https://www.rfc-editor.org/info/rfc2367>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., case NAT traversal is
                    required and M.
              Stenberg, "UDP Encapsulation of IPsec port information.";
               leaf espencap {
                   type esp-encap;
                   description
                       "ESP in TCP, ESP Packets",
              RFC 3948, DOI 10.17487/RFC3948, January 2005,
              <https://www.rfc-editor.org/info/rfc3948>.

   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
              DOI 10.17487/RFC6071, February 2011,
              <https://www.rfc-editor.org/info/rfc6071>.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
              <https://www.rfc-editor.org/info/rfc7149>.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, <https://www.rfc-editor.org/info/rfc7317>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers in UDP or ESP in TLS.";
               }
               leaf sport {
                   type inet:port-number;
                   default 4500;
                   description
                       "Encapsulation source port.";
               }
               leaf dport {
                   type inet:port-number;
                   default 4500;
                   description
                       "Encapsulation destination port.";
               }

               leaf-list oaddr {
                   type inet:ip-address;
                   description
                       "If required, this is the original address that
                        was used before NAT was applied over the Packet.
                        ";

               }
               reference
                   "RFC 3947 and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface 8229.";
           }

           grouping lifetime {
               description
                   "Different lifetime values limited to Network Security Functions
              (I2NSF): Problem Statement and Use Cases", RFC 8192,
              DOI 10.17487/RFC8192, July 2017,
              <https://www.rfc-editor.org/info/rfc8192>.

   [RFC8229]  Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
              of IKE and an IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
              August 2017, <https://www.rfc-editor.org/info/rfc8229>.

   [RFC8512]  Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
              Vinapamula, S., and Q. Wu, "A YANG Module for Network
              Address Translation (NAT) and Network Prefix Translation
              (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
              <https://www.rfc-editor.org/info/rfc8512>.

   [strongswan]
              CESNET, "StrongSwan: SA.";
               leaf time {
                   type uint32;
                   default 0;
                   description
                       "Time in seconds since the OpenSource IPsec-based VPN
              Solution", August 2019.

Appendix A.  Appendix A: Common YANG model for IKE and IKE-less cases

       <CODE BEGINS> file "ietf-ipsec-common@2019-08-05.yang"

       module ietf-ipsec-common {
           yang-version 1.1;
           namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
           prefix "ipsec-common";

           import ietf-inet-types { prefix inet; IPsec SA was added.
                        For example, if this value is 180 seconds it
                        means the IPsec SA expires in 180 seconds since
                        it was added. The value 0 implies infinite.";
               }
           import ietf-yang-types
               leaf bytes { prefix yang; }

           organization "IETF I2NSF Working Group";

           contact
           "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/about/>
            WG List: <mailto:i2nsf@ietf.org>

           Author: Rafael Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";
                   type uint32;
                   default 0;
                   description
               "Common Data model for the IKE and IKE-less cases
                defined by
                       "If the SDN-based IPsec flow protection service.

               Copyright (c) 2019 IETF Trust and SA processes the persons
               identified as authors number of the code.  All rights reserved.
               Redistribution and use bytes
                       expressed in source and binary forms, with
               or without modification, is permitted pursuant to, this leaf, the IPsec SA expires and
               subject to
                       should be rekeyed. The value 0 implies
                       infinite.";
               }
               leaf packets {
                   type uint32;
                   default 0;
                   description
                       "If the license terms contained in, IPsec SA processes the
               Simplified BSD License set forth in Section 4.c number of packets
                       expressed in this leaf, the
               IETF Trust's Legal Provisions Relating to IETF Documents
               (https://trustee.ietf.org/license-info).

               This version of IPsec SA expires and
                       should be rekeyed. The value 0 implies
                       infinite.";
               }
               leaf idle {
                   type uint32;
                   default 0;
                   description
                       "When a NSF stores an IPsec SA, it
                        consumes system resources. In an idle NSF this YANG module
                        is part a waste of RFC XXXX;;
               see resources. If the RFC itself for full legal notices.

               The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
               'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
               'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in IPsec SA is idle
                        during this
               document are to number of seconds the IPsec SA
                        should be interpreted removed. The value 0 implies
                        infinite.";
               }
               reference
                   "Section 4.4.2.1 in RFC 4301.";

           }

           grouping port-range  {
               description
                   "This grouping defines a port range, such as described
                    expressed in BCP 14
               (RFC 2119) (RFC 8174) when, and only when, they appear RFC 4301. For example: 1500 (Start
                    Port Number)-1600 (End Port Number). A port range
                    is used in all capitals, as shown here.";

           revision "2019-08-05" the Traffic Selector.";

               leaf start {
                   type inet:port-number;
                   description "Revision 06";
               reference "RFC XXXX: YANG Groupings and typedef
                          for IKE and IKE-less case";
                       "Start port number.";
               }

           typedef encryption-algorithm-type
               leaf end {
                   type uint16; inet:port-number;
                   description
                       "End port number.";
               }
               reference "Section 4.4.1.2 in RFC 4301.";
           }

           grouping tunnel-grouping {
               description
                   "The encryption algorithm is specified with a 16-bit
                   number extracted from IANA Registry. parameters required to define the IP tunnel
                    endpoints when IPsec SA requires tunnel mode. The acceptable
                   values MUST follow
                    tunnel is defined by two endpoints: the requirement levels for
                   encryption algorithms for ESP and IKEv2.";
               reference
                    "IANA Registry- Transform Type 1 - Encryption
                    Algorithm Transform IDs. RFC 8221 - Cryptographic
                    Algorithm Implementation Requirements and Usage
                    Guidance for Encapsulating Security Payload (ESP)
                    and Authentication Header (AH) and RFC 8247 -
                    Algorithm Implementation Requirements local IP
                    address and Usage
                    Guidance for the Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
           }

           typedef integrity-algorithm-type remote IP address.";

               leaf local {
                   type uint16; inet:ip-address;
                   mandatory true;
                   description
                   "The integrity algorithm is specified with a 16-bit
                   number extracted from IANA Registry.
                   The acceptable values MUST follow the requirement
                   levels for encryption algorithms for ESP and IKEv2.";
               reference
                   "IANA Registry- Transform Type 3 - Integrity
                    Algorithm Transform IDs. RFC 8221 - Cryptographic
                    Algorithm Implementation Requirements and Usage
                    Guidance for Encapsulating Security Payload (ESP)
                    and Authentication Header (AH) and RFC 8247 -
                    Algorithm Implementation Requirements and Usage
                    Guidance for the Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
                       "Local IP address' tunnel endpoint.";
               }

           typedef ipsec-mode
               leaf remote {
                   type inet:ip-address;
                   mandatory true;
                   description
                       "Remote IP address' tunnel endpoint.";
               }
               leaf df-bit {
                   type enumeration {
                       enum transport clear {
                           description
                           "IPsec transport mode. No Network Address
                            Translation (NAT) support.";
                               "Disable the DF (Don't Fragment) bit
                                from the outer header. This is the
                                default value.";

                       }
                       enum tunnel set {
                           description "IPsec tunnel mode.";
                               "Enable the DF bit in the outer header.";
                       }
                       enum copy {
                           description
                               "Copy the DF bit to the outer header.";
                       }
                   }
                   default clear;
                   description
                   "Type definition of
                       "Allow configuring the DF bit when encapsulating
                        tunnel mode IPsec mode: transport or
                    tunnel."; traffic. RFC 4301 describes
                        three options to handle the DF bit during
                        tunnel encapsulation: clear, set and copy from
                        the inner IP header.";
                   reference
                       "Section 3.2 8.1 in RFC 4301.";
               }

           typedef esp-encap
               leaf bypass-dscp {
                   type enumeration {
                   enum espintcp { boolean;
                   default true;
                   description
                           "ESP
                       "If DSCP (Differentiated Services Code Point)
                        values in TCP encapsulation.";
                       reference
                           "RFC 8229 - TCP Encapsulation of IKE and the inner header have to be used to
                        select one IPsec Packets."; SA among several that match
                        the traffic selectors for an outbound packet";
                   reference
                       "Section 4.4.2.1. in RFC 4301.";
               }
                   enum espintls
               leaf dscp-mapping {
                   type yang:hex-string;
                   description
                           "ESP in TCP encapsulation using TLS.";
                       reference
                           "RFC 8229 - TCP Encapsulation of IKE and
                       "DSCP values allowed for packets carried over
                        this IPsec Packets.";
                   }
                   enum espinudp {
                       description
                           "ESP in UDP encapsulation."; SA.";
                   reference
                           "RFC 3948 - UDP Encapsulation of IPsec ESP
                           Packets.";
                       "Section 4.4.2.1. in RFC 4301.";
               }
                   enum none
               leaf ecn {
                   type boolean;
                   default false;
                   description
                           "NOT ESP encapsulation.";
                       "Explicit Congestion Notification (ECN). If true
                        copy CE bits to inner header.";
                   reference
                       "Section 5.1.2 and Annex C in RFC 4301.";
               }

           }

           grouping selector-grouping {
               description
                   "Types
                   "This grouping contains the definition of ESP encapsulation when Network Address
                    Translation (NAT) a Traffic
                    Selector, which is present between two NSFs.";

               reference
                   "RFC 8229 - TCP Encapsulation of IKE and used in the IPsec
                    Packets policies and RFC 3948 - UDP Encapsulation of
                    IPsec
                    ESP Packets.";
           }

           typedef ipsec-protocol-parameters SAs.";

               leaf local-subnet {
                   type enumeration {
                   enum esp { inet:ip-prefix;
                   mandatory true;
                   description "IPsec ESP protocol.";
                       "Local IP address subnet.";
               }
               leaf remote-subnet {
                   type inet:ip-prefix;
                   mandatory true;
                   description
                       "Remote IP address subnet.";
               }
               leaf inner-protocol {
                   type ipsec-inner-protocol;
                   default any;
                   description
                   "Only the Encapsulation Security
                       "Inner Protocol (ESP) that is
                    supported but it could going to be extended in the future.";
               reference
                   "RFC 4303- IP Encapsulating Security Payload
                   (ESP).";
                       protected with IPsec.";
               }

           typedef lifetime-action {
               type enumeration {
                   enum terminate-clear
               list local-ports {
                   key "start end";
                   uses port-range;
                   description
                           "Terminates
                       "List of local ports. When the IPsec SA inner
                        protocol is ICMP this 16 bit value represents
                        code and allows the
                            packets through."; type.";
               }
                   enum terminate-hold
               list remote-ports {
                   key "start end";
                   uses port-range;
                   description
                           "Terminates
                       "List of remote ports. When the IPsec SA and drops the
                            packets.";
                   }
                   enum replace  {
                       description
                           "Replaces the IPsec SA with a new one:
                           rekey. "; upper layer
                       protocol is ICMP this 16 bit value represents
                       code and type.";
               }
               reference
                   "Section 4.4.1.2 in RFC 4301.";
           }

           grouping ipsec-policy-grouping {
               description
                   "When the lifetime of
                   "Holds configuration information for an IPsec SA expires an action
                    needs SPD
                    entry.";

               leaf anti-replay-window {
                   type uint64;
                   default 32;
                   description
                       "A 64-bit counter used to be performed over the IPsec SA that
                    reached the lifetime. There are three posible
                    options: terminate-clear, terminate-hold and
                    replace."; determine whether an
                        inbound ESP packet is a replay.";
                   reference
                       "Section 4.5 4.4.2.1 in RFC 4301.";
               }

           typedef ipsec-traffic-direction {
               type enumeration {
                   enum inbound {
                       description "Inbound traffic.";
                   }
                   enum outbound
               container traffic-selector {
                   description "Outbound traffic.";
                   }
               }
               description
                   "IPsec traffic direction is defined in two
                    directions: inbound and outbound. From a NSF
                    perspective inbound means the traffic that enters
                       "Packets are selected for
                        processing actions based on the NSF IP and outbound is the traffic that is sent
                    from inner
                        protocol header information, selectors,
                        matched against entries in the NSF."; SPD.";
                   uses selector-grouping;
                   reference
                       "Section 5 4.4.4.1 in RFC 4301.";
               }

           typedef ipsec-spd-action {
               type enumeration {
                   enum protect
               container processing-info {
                   description
                           "PROTECT
                       "SPD processing. If the traffic with IPsec.";
                   }
                   enum bypass required processing
                        action is protect, it contains the required
                        information to process the packet.";
                   leaf action {
                       type ipsec-spd-action;
                       default discard;
                       description
                           "BYPASS the traffic. The packet
                           "If bypass or discard, container
                           ipsec-sa-cfg is forwarded
                            without IPsec protection."; empty.";
                   }
                   enum discard
                   container ipsec-sa-cfg {
                       when "../action = 'protect'";
                       description
                           "DISCARD
                           "IPsec SA configuration included in the traffic. The IP packet is
                            discarded.";
                   }
               }
               description
                   "The action when traffic matches an IPsec security
                    policy. According to RFC 4301 there are three
                    possible values: BYPASS, PROTECT AND DISCARD";
               reference
                   "Section 4.4.1 in RFC 4301.";
           }

           typedef ipsec-inner-protocol {
               type union SPD
                           entry.";
                       leaf pfp-flag {
                           type uint8;
                   type enumeration {
                       enum any {
                           value 256;
                           description
                               "Any IP protocol number value.";
                       }
                   }
               } boolean;
                           default any; false;
                           description
                   "IPsec protection can be applied
                                "Each selector has a Populate From
                                 Packet (PFP) flag. If asserted for a
                                 given selector X, the flag indicates
                                 that the IPsec SA to specific be created should
                                 take its value (local IP
                    traffic and layer 4 traffic (TCP, UDP, SCTP, address,
                                 remote IP address, Next Layer
                                 Protocol, etc.)
                    or ANY protocol for X from the value
                                 in the IP packet payload. We
                    specify packet. Otherwise, the IP protocol number with an uint8 or
                    ANY defining an enumerate with value 256 to
                    indicate IPsec SA
                                 should take its value(s) for X from
                                 the protocol number.";
               reference
                   "Section 4.4.1.1 value(s) in RFC 4301.
                    IANA Registry - Protocol Numbers.";
           }

           grouping encap {
               description
                   "This group of nodes allows to define the type of
                    encapsulation in case NAT traversal is
                    required and port information.";
               leaf espencap {
                   type esp-encap;
                   description
                       "ESP in TCP, ESP in UDP or ESP in TLS."; SPD entry.";
                       }
                       leaf sport ext-seq-num {
                           type inet:port-number; boolean;
                           default 4500; false;
                           description
                       "Encapsulation source port.";
                                "True if this IPsec SA is using extended
                                 sequence numbers. True 64 bit counter,
                                 False 32 bit.";
                       }
                       leaf dport seq-overflow {
                           type inet:port-number; boolean;
                           default 4500;
                   description
                       "Encapsulation destination port.";
               }

               leaf-list oaddr {
                   type inet:ip-address; false;
                           description
                       "If required, this is
                               "The flag indicating whether
                               overflow of the original address that
                        was used before NAT was applied over the Packet.
                        ";

               }
               reference
                   "RFC 3947 and RFC 8229.";
           }

           grouping lifetime {
               description
                   "Different lifetime values limited to an IPsec SA.";
               leaf time {
                   type uint32;
                   default 0;
                   description
                       "Time in seconds since sequence number
                               counter should prevent transmission
                               of additional packets on the IPsec
                               SA was added.
                        For example, if this value (false) and, therefore needs to
                               be rekeyed, or whether rollover is 180 seconds it
                        means the IPsec SA expires in 180 seconds since
                        it was added. The value 0 implies infinite.";
                               permitted (true). If Authenticated
                               Encryption with Associated Data
                               (AEAD) is used this flag MUST be
                               false.";
                       }
                       leaf bytes stateful-frag-check {
                           type uint32; boolean;
                           default 0; false;
                           description
                       "If the IPsec SA processes the number of bytes
                       expressed in this leaf,
                               "Indicates whether (true) or not (false)
                                stateful fragment checking applies to
                                the IPsec SA expires and
                       should to be rekeyed. The value 0 implies
                       infinite."; created.";
                       }
                       leaf packets mode {
                           type uint32; ipsec-mode;
                           default 0; transport;
                           description
                       "If the IPsec SA processes the number of packets
                       expressed in this leaf, the IPsec
                               "IPsec SA expires and
                       should has to be rekeyed. The value 0 implies
                       infinite."; processed in
                                transport or tunnel mode.";
                       }
                       leaf idle protocol-parameters {
                           type uint32; ipsec-protocol-parameters;
                           default 0; esp;
                           description
                       "When a NSF stores an IPsec SA, it
                        consumes system resources. In an idle NSF this
                        is a waste
                                "Security protocol of resources. If the IPsec SA SA:
                                Only ESP is idle
                        during this number of seconds the IPsec SA
                        should supported but it could be removed. The value 0 implies
                        infinite.";
               }
               reference
                   "Section 4.4.2.1
                                extended in RFC 4301."; the future.";
                       }

           grouping port-range
                       container esp-algorithms {
                           when "../protocol-parameters = 'esp'";
                           description
                   "This grouping defines a port range, such as
                    expressed
                                "Configuration of Encapsulating
                                Security Payload (ESP) parameters and
                                algorithms.";
                           leaf-list integrity {
                               type integrity-algorithm-type;
                               default 0;
                               ordered-by user;
                               description
                                   "Configuration of ESP authentication
                                   based on the specified integrity
                                   algorithm. With AEAD algorithms,
                                   the integrity node is not
                                   used.";
                               reference
                                   "Section 3.2 in RFC 4301. For example: 1500 (Start
                    Port Number)-1600 (End Port Number). A port range 4303.";
                           }
                           leaf-list encryption {
                               type encryption-algorithm-type;
                               default 20;
                               ordered-by user;
                               description
                                   "Configuration of ESP encryption
                                   algorithms. The default value is used
                                   20 (ENCR_AES_GCM_16).";
                               reference
                                   "Section 3.2 in the Traffic Selector."; RFC 4303.";
                           }
                           leaf start tfc-pad {
                               type inet:port-number; boolean;
                               default false;
                               description
                       "Start port number.";
                                   "If Traffic Flow Confidentiality
                                    (TFC) padding for ESP encryption
                                    can be used (true) or not (false)";
                               reference
                                   "Section 2.7 in RFC 4303.";
                           }
               leaf end
                           reference
                               "RFC 4303.";
                       }
                       container tunnel {
                   type inet:port-number;
                           when "../mode = 'tunnel'";
                           uses tunnel-grouping;
                           description
                       "End port number.";
                              "IPsec tunnel endpoints definition.";
                       }
                   }
                   reference
                       "Section 4.4.1.2 in RFC 4301.";
               }

           grouping tunnel-grouping
               container spd-mark {
                       description
                           "The parameters required Mark to define set for the IP tunnel
                    endpoints when IPsec SA requires tunnel mode. The
                    tunnel of this
                            connection. This option is defined by two endpoints: the local IP
                    address and the remote IP address."; only available
                            on linux NETKEY/XFRM kernels. It can be
                            used with iptables to create custom
                            iptables rules using CONNMARK. It can also
                            be used with Virtual Tunnel Interfaces
                            (VTI) to direct marked traffic to
                            specific vtiXX devices.";
                       leaf local mark {
                           type inet:ip-address;
                   mandatory true; uint32;
                           default 0;
                           description
                       "Local IP address' tunnel endpoint.";
                               "Mark used to match XFRM policies and
                                states.";
                       }
                       leaf remote mask {
                           type inet:ip-address;
                   mandatory true; yang:hex-string;
                           default 00:00:00:00;
                           description
                       "Remote IP address' tunnel endpoint.";
                               "Mask used to match XFRM policies and
                               states.";
                       }
               leaf df-bit
               }
           }
       }

       <CODE ENDS>

Appendix B.  YANG model for IKE case

       <CODE BEGINS> file "ietf-ipsec-ike@2019-08-05.yang"
       module ietf-ipsec-ike {
                   type enumeration
           yang-version 1.1;
           namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike";
           prefix "ike";

           import ietf-inet-types {
                       enum clear prefix inet; }
           import ietf-yang-types {
                           description
                               "Disable the DF (Don't Fragment) bit
                                from the outer header. This is the
                                default value."; prefix yang; }
                       enum set

           import ietf-crypto-types {
                           description
                               "Enable the DF bit in the outer header.";
               prefix ct;
               reference
                   "draft-ietf-netconf-crypto-types-10:
                   Common YANG Data Types for Cryptography.";
           }
                       enum copy

           import ietf-ipsec-common {
                           description
                               "Copy the DF bit to the outer header.";
               prefix ic;
               reference
                   "RFC XXXX: module ietf-ipsec-common, revision
                    2019-08-05.";
           }

           import ietf-netconf-acm {
                  prefix nacm;
                  reference
                    "RFC 8341: Network Configuration Access Control
                     Model.";
           }
                   default clear;

           organization "IETF I2NSF Working Group";

           contact
           "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/about/>
            WG List: <mailto:i2nsf@ietf.org>

           Author: Rafael Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";

           description
                       "Allow configuring the DF bit when encapsulating
                        tunnel mode

           "This module contains IPsec traffic. RFC 4301 describes
                        three options to handle IKE case model for the DF bit during
                        tunnel encapsulation: clear, set SDN-based
            IPsec flow protection service. An NSF will implement this
            module.

           Copyright (c) 2019 IETF Trust and copy from the inner IP header.";
                   reference
                       "Section 8.1 in RFC 4301.";
               }
               leaf bypass-dscp {
                   type boolean;
                   default true;
                   description
                       "If DSCP (Differentiated Services Code Point)
                        values in persons identified as
           authors of the inner header have to be used code.  All rights reserved.

           Redistribution and use in source and binary forms, with or
           without modification, is permitted pursuant to, and subject
           to
                        select one IPsec SA among several that match the traffic selectors for an outbound packet";
                   reference
                       "Section 4.4.2.1. license terms contained in, the Simplified BSD License
           set forth in Section 4.c of the IETF Trust's Legal Provisions
           Relating to IETF Documents
           (http://trustee.ietf.org/license-info).

           This version of this YANG module is part of RFC 4301.";
               }
               leaf dscp-mapping {
                   type yang:hex-string;
                   description
                       "DSCP values allowed XXXX; see
           the RFC itself for packets carried over full legal notices.

           The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
           'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
           'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this IPsec SA.";
                   reference
                       "Section 4.4.2.1.
           document are to be interpreted as described in RFC 4301."; BCP 14
           (RFC 2119) (RFC 8174) when, and only when, they appear
           in all capitals, as shown here.";

           revision "2019-08-05" {
               description "Revision 6";
               reference
                   "RFC XXXX: YANG model for IKE case.";
           }
               leaf ecn

           typedef ike-spi {
               type boolean;
                   default false; uint64 { range "0..max"; }
               description
                       "Explicit Congestion Notification (ECN). If true
                        copy CE bits to inner header.";
                   "Security Parameter Index (SPI)'s IKE SA.";
               reference
                   "Section 5.1.2 and Annex C 2.6 in RFC 4301.";
               } 7296.";
           }

           grouping selector-grouping {
               description
                   "This grouping contains the definition of a Traffic
                    Selector, which is used in the IPsec policies and
                    IPsec SAs.";

               leaf local-subnet

           typedef autostartup-type {
               type inet:ip-prefix;
                   mandatory true;
                   description
                       "Local IP address subnet.";
               }
               leaf remote-subnet enumeration {
                   enum add {
                   type inet:ip-prefix;
                   mandatory true;
                       description
                       "Remote IP address subnet.";
                           "IKE/IPsec configuration is only loaded into
                            IKE implementation but IKE/IPsec SA is not
                            started.";
                   }
               leaf inner-protocol
                   enum on-demand {
                   type ipsec-inner-protocol;
                   default any;
                       description
                       "Inner Protocol that
                           "IKE/IPsec configuration is going to be
                       protected with IPsec."; loaded
                           into IKE implementation. The IPsec policies
                           are transferred to the NSF's kernel but the
                           IPsec SAs are not established immediately.
                           The IKE implementation will negotiate the
                           IPsec SAs when the NSF's kernel requests it
                           (i.e. through an ACQUIRE notification).";
                   }
               list local-ports
                   enum start {
                   key "start end";
                   uses port-range;
                       description
                       "List of local ports. When the inner
                        protocol "IKE/IPsec configuration is ICMP this 16 bit value represents
                        code loaded
                       and type.";
               }
               list remote-ports {
                   key "start end";
                   uses port-range;
                   description
                       "List of remote ports. When transferred to the upper layer
                       protocol is ICMP this 16 bit value represents
                       code NSF's kernel, and type."; the
                       IKEv2 based IPsec SAs are established
                       immediately without waiting any packet.";
                   }
               reference
                   "Section 4.4.1.2 in RFC 4301.";
               }

           grouping ipsec-policy-grouping {
               description
                   "Holds configuration information for an IPsec SPD
                    entry.";

               leaf anti-replay-window {
                   type uint64;
                   default 32;
               description
                       "A 64-bit counter used
                   "Different policies to determine whether an
                        inbound ESP packet is a replay.";
                   reference
                       "Section 4.4.2.1 in RFC 4301."; set IPsec SA configuration
                    into NSF's kernel when IKEv2 implementation has
                    started.";
           }
               container traffic-selector

           typedef pfs-group {
               type uint16;
               description
                       "Packets are selected
                   "DH groups for
                        processing actions based on the IP IKE and inner
                        protocol header information, selectors,
                        matched against entries in the SPD.";
                   uses selector-grouping; IPsec SA rekey.";
               reference
                   "Section 4.4.4.1 3.3.2 in RFC 4301."; 7296. Transform Type 4 -
                    Diffie-Hellman Group Transform IDs in IANA Registry
                     - Internet Key Exchange Version 2 (IKEv2)
                    Parameters.";
           }
               container processing-info

           typedef auth-protocol-type {
               type enumeration {
                   enum ikev2 {
                       value 2;
                       description
                       "SPD processing. If the required processing
                        action
                           "IKEv2 authentication protocol. It is protect, it contains the required
                        information to process the packet.";
                   leaf action {
                       type ipsec-spd-action;
                       default discard;
                       description
                           "If bypass or discard, container
                           ipsec-sa-cfg
                            only defined right now. An enum is empty."; used for
                            further extensibility.";
                   }
               }
                   container ipsec-sa-cfg {
                       when "../action = 'protect'";
               description
                           "IPSec SA configuration included
                   "IKE authentication protocol version specified in the SPD
                           entry.";
                       leaf pfp-flag {
                           type boolean;
                           default false;
                           description
                                "Each selector has a Populate From
                                 Packet (PFP) flag. If asserted for a
                                 given selector X, the flag indicates
                                 that the IPSec SA
                    Peer Authorization Database (PAD). It is defined as
                    enumerate to be created should
                                 take its value (local IP address,
                                 remote IP address, Next Layer
                                 Protocol, etc.) for X from the value
                                 in the packet. Otherwise, the IPsec SA
                                 should take its value(s) for X from
                                 the value(s) allow new IKE versions in the SPD entry.";
                    future.";
               reference
                   "RFC 7296.";
           }
                       leaf ext-seq-num

           typedef auth-method-type {
               type boolean;
                           default false;
                           description
                                "True if this IPsec SA is using extended
                                 sequence numbers. True 64 bit counter,
                                 False 32 bit.";
                       }
                       leaf seq-overflow enumeration {
                   enum pre-shared {
                           type boolean;
                           default false;
                       description
                               "The flag indicating whether
                               overflow of the sequence number
                               counter should prevent transmission
                               of additional packets on
                           "Select pre-shared key as the IPsec
                               SA (false) and, therefore needs to
                               be rekeyed, or whether rollover is
                               permitted (true). If Authenticated
                               Encryption with Associated Data
                               (AEAD) is used this flag MUST be
                               false.";
                           authentication method.";
                       reference
                           "RFC 7296.";
                   }
                       leaf stateful-frag-check
                   enum eap {
                           type boolean;
                           default false;
                       description
                               "Indicates whether (true) or not (false)
                                stateful fragment checking applies to
                           "Select EAP as the IPsec SA to be created."; authentication method.";
                       reference
                           "RFC 7296.";
                   }
                       leaf mode
                   enum digital-signature {
                           type ipsec-mode;
                           default transport;
                       description
                               "IPsec SA has to be processed in
                                transport or tunnel mode.";
                           "Select digital signature method.";
                       reference
                           "RFC 7296 and RFC 7427.";
                   }
                       leaf protocol-parameters
                   enum null {
                           type ipsec-protocol-parameters;
                           default esp;
                       description
                                "Security protocol of the IPsec SA:
                                Only ESP is supported but it could be
                                extended
                           "Null authentication.";
                       reference
                           "RFC 7619.";
                   }

               }
               description
                   "Peer authentication method specified in the future."; Peer
                    Authorization Database (PAD).";
           }

           container esp-algorithms ipsec-ike {
                           when "../protocol-parameters = 'esp'";
               description
                                "Configuration of Encapsulating
                                Security Payload (ESP) parameters
                   "IKE configuration for a NSF. It includes PAD
                    parameters, IKE connections information and
                                algorithms.";
                           leaf-list integrity state
                    data.";

               container pad {
                               type integrity-algorithm-type;
                               default 0;
                               ordered-by user;
                   description
                      "Configuration of ESP authentication
                                   based on Peer Authorization Database
                       (PAD). The PAD contains information about IKE
                       peer (local and remote). Therefore, the specified integrity
                                   algorithm. With AEAD algorithms, Security
                       Controller also stores authentication
                       information for this NSF and can include
                       several entries for the integrity node is local NSF not
                                   used.";
                               reference
                                   "Section 3.2 in RFC 4303.";
                           }
                           leaf-list encryption only
                       remote peers. Storing local and remote
                       information makes possible to specify that this
                       NSF with identity A will use some particular
                       authentication with remote NSF with identity B
                       and what are the authentication mechanisms
                       allowed to B.";
                   list pad-entry {
                               type encryption-algorithm-type;
                               default 20;
                       key "name";
                       ordered-by user;
                       description
                                   "Configuration of ESP encryption
                                   algorithms. The default value
                           "Peer Authorization Database (PAD) entry. It
                            is
                                   20 (ENCR_AES_GCM_16).";
                               reference
                                   "Section 3.2 in RFC 4303.";
                           } a list of PAD entries ordered by the
                            I2NSF Controller.";
                       leaf tfc-pad name {
                           type boolean;
                               default false; string;
                           description
                                   "If Traffic Flow Confidentiality
                                    (TFC) padding for ESP encryption
                               "PAD unique name to identify this
                                entry.";
                       }
                       choice identity {
                           mandatory true;
                           description
                               "A particular IKE peer will be
                               identified by one of these identities.
                               This peer can be used (true) a remote peer or not (false)"; local
                               peer (this NSF).";
                           reference
                               "Section 2.7 4.4.3.1 in RFC 4303.";
                           }
                           reference
                               "RFC 4303.";
                       }
                       container tunnel 4301.";
                           case ipv4-address{
                               leaf ipv4-address {
                           when "../mode = 'tunnel'";
                           uses tunnel-grouping;
                                   type inet:ipv4-address;
                                   description
                              "IPsec tunnel endpoints definition.";
                       }
                                       "Specifies the identity as a
                                        single four (4) octet.";
                               }
                   reference
                       "Section 4.4.1.2 in RFC 4301.";
                           }
               container spd-mark
                           case ipv6-address{
                               leaf ipv6-address {
                                   type inet:ipv6-address;
                                   description
                           "The Mark to set for
                                       "Specifies the IPsec SA of this
                            connection. This option identity as a
                                        single sixteen (16) octet IPv6
                                        address. An example is only available
                            on linux NETKEY/XFRM kernels. It can be
                            used with iptables to create custom
                            iptables rules using CONNMARK. It can also
                            be used with Virtual Tunnel Interfaces
                            (VTI) to direct marked traffic to
                            specific vtiXX devices.";
                                        2001:DB8:0:0:8:800:200C:417A.";
                               }
                           }
                           case fqdn-string {
                               leaf mark fqdn-string {
                                   type uint32;
                           default 0; inet:domain-name;
                                   description
                               "Mark used to match XFRM policies and
                                states.";
                                       "Specifies the identity as a
                                        Fully-QualifiedDomain Name
                                        (FQDN) string. An example is:
                                        example.com. The string MUST
                                        NOT contain any terminators
                                        (e.g., NULL, CR, etc.).";
                               }
                           }
                           case rfc822-address-string {
                               leaf mask rfc822-address-string {
                                   type yang:hex-string;
                           default 00:00:00:00; string;
                                   description
                               "Mask used to match XFRM policies and
                               states.";
                       }
               }
                                       "Specifies the identity as a
                                        fully-qualified RFC822 email
                                        address string. An example is,
                                        jsmith@example.com. The string
                                        MUST NOT contain any
                                        terminators e.g., NULL, CR,
                                        etc.).";
                                   reference
                                       "RFC 822.";
                               }
                           }

       <CODE ENDS>

Appendix B.  Appendix B: YANG model for IKE
                           case

       <CODE BEGINS> file "ietf-ipsec-ike@2019-08-05.yang"
       module ietf-ipsec-ike dnx509 {
           yang-version 1.1;
           namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike";
           prefix "ike";

           import ietf-inet-types
                               leaf dnx509 { prefix inet;
                                   type string;
                                   description
                                       "Specifies the identity as a
                                        ASN.1 X.500 Distinguished
                                        Name. An example is
                                        C=US,O=Example
                                        Organisation,CN=John Smith.";
                                   reference
                                       "RFC 2247.";
                               }
           import ietf-yang-types
                           }
                           case gnx509 { prefix yang;
                               leaf gnx509 {
                                   type string;
                                   description
                                       "ASN.1 X.509 GeneralName. RFC
                                        3280.";
                               }

           import ietf-crypto-types
                           }
                           case id-key {
               prefix ct;
               reference
                   "draft-ietf-netconf-crypto-types-10:
                   Common YANG Data Types
                               leaf id-key {
                                   type string;
                                   description
                                       "Opaque octet stream that may be
                                        used to pass vendor-specific
                                        information for Cryptography."; proprietary
                                        types of identification.";
                                   reference
                                       "Section 3.5 in RFC 7296.";
                               }

           import ietf-ipsec-common
                           }
                           case id-null {
               prefix ic;
                               leaf id-null {
                                   type empty;
                                   description
                                       "ID_NULL identification used
                                        when IKE identification payload
                                        is not used." ;
                                   reference
                                       "RFC XXXX: module ietf-ipsec-common, revision
                    2019-08-05."; 7619.";
                               }

           import ietf-netconf-acm
                           }
                       }
                       leaf auth-protocol {
                  prefix nacm;
                  reference
                    "RFC 8341: Network Configuration Access Control
                     Model.";
                           type auth-protocol-type;
                           default ikev2;
                           description
                               "Only IKEv2 is supported right now but
                                other authentication protocols may be
                                supported in the future.";
                       }

           organization "IETF I2NSF Working Group";

           contact
           "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/about/>
            WG List: <mailto:i2nsf@ietf.org>

           Author: Rafael Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";
                       container peer-authentication {
                           description
                               "This module contains IPSec IKE case model for container allows the SDN-based
            IPsec flow protection service. An NSF Security
                                Controller to configure the
                                authentication method (pre-shared key,
                                eap, digitial-signature, null) that
                                will implement this
            module.

           Copyright (c) 2019 IETF Trust use a particular peer and the persons identified as
           authors of
                                credentials, which will depend on the code.  All rights reserved.

           Redistribution and use in source and binary forms, with or
           without modification, is permitted pursuant to, and subject
           to the license terms contained in, the Simplified BSD License
           set forth in Section 4.c of the IETF Trust's Legal Provisions
           Relating to IETF Documents
           (http://trustee.ietf.org/license-info).

           This version of this YANG module is part of RFC XXXX; see
           the RFC itself for full legal notices.

           The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
           'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
           'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
           document are to be interpreted as described in BCP 14
           (RFC 2119) (RFC 8174) when, and only when, they appear
           in all capitals, as shown here.";

           revision "2019-08-05"
                                selected authentication method.";
                           leaf auth-method {
                              type auth-method-type;
                              default pre-shared;
                              description "Revision 6";
                                   "Type of authentication method
                                   (pre-shared, eap, digital signature,
                                    null).";
                              reference
                   "RFC XXXX: YANG model for IKE case.";
                                  "Section 2.15 in RFC 7296.";
                           }

           typedef ike-spi
                           container eap-method {
               type uint64
                               when "../auth-method = 'eap'";
                               leaf eap-type { range "0..max";
                                   type uint8;
                                   mandatory true;
                                   description
                                       "EAP method type. This
                                       information provides the
                                       particular EAP method to be
                                       used. Depending on the EAP
                                       method, pre-shared keys or
                                       certificates may be used.";
                               }
                               description
                   "Security Parameter Index (SPI)'s IKE SA.";
                                   "EAP method description used when
                                   authentication method is 'eap'.";
                               reference
                                   "Section 2.6 2.16 in RFC 7296.";
                           }

           typedef autostartup-type {
               type enumeration {
                   enum add
                           container pre-shared {
                       description
                           "IKE/IPsec configuration is only loaded into
                            IKE implementation but IKE/IPsec SA is not
                            started.";
                   }
                   enum on-demand
                               when
                                   "../auth-method[.='pre-shared' or
                                    .='eap']";
                               leaf secret {
                                   nacm:default-deny-all;
                                   type yang:hex-string;
                                   description
                           "IKE/IPsec configuration is loaded
                           into IKE implementation.
                                       "Pre-shared secret value. The IPsec policies
                           are transferred
                                        NSF has to the NSF's kernel but the
                           IPsec SAs are not established immediately.
                           The IKE implementation will negotiate the
                           IPsec SAs when the NSF's kernel requests it
                           (i.e. through an ACQUIRE notification)."; prevent read access
                                        to this value for security
                                        reasons.";
                               }
                   enum start {
                               description "IKE/IPsec configuration is loaded
                       and transferred to the NSF's kernel, and the
                       IKEv2
                                   "Shared secret value for PSK or
                                    EAP method authentication based IPsec SAs are established
                       immediately without waiting any packet.";
                   } on
                                    PSK.";
                           }
               description
                   "Different policies to set IPsec SA configuration
                    into NSF's kernel
                           container digital-signature {
                               when IKEv2 implementation has
                    started.";
           }

           typedef pfs-group
                                "../auth-method[.='digital-signature'
                               or .='eap']";
                               leaf ds-algorithm {
                                   type uint16; uint8;
                                   description
                   "DH groups for IKE
                                       "The digital signature
                                       algorithm is specified with a
                                       value extracted from the IANA
                                       Registry. Depending on the
                                       algorithm, the following leafs
                                       must contain information. For
                                       example if digital signature
                                       involves a certificate then leaf
                                       'cert-data' and IPsec SA rekey."; 'private-key'
                                       will contain this information.";
                                   reference
                   "Section 3.3.2 in RFC 7296. Transform Type 4
                                       "IKEv2 Authentication Method -
                    Diffie-Hellman Group Transform IDs in
                                        IANA Registry - Internet Key
                                        Exchange Version 2 (IKEv2)
                                        Parameters.";
                               }

           typedef auth-protocol-type {
               type enumeration

                               choice public-key {
                   enum ikev2
                                   mandatory true;
                                   leaf raw-public-key {
                       value 2;
                                       type binary;
                                       description
                           "IKEv2 authentication protocol. It is
                                         "A binary that contains the
                            only defined right now. An enum is used for
                            further extensibility.";
                   }
               }
               description
                   "IKE authentication protocol version specified in
                                         value of the
                    Peer Authorization Database (PAD). It public key.  The
                                         interpretation of the content
                                         is defined as
                    enumerate to allow new IKE versions in by the
                    future.";
               reference
                   "RFC 7296.";
           }

           typedef auth-method-type {
               type enumeration {
                   enum pre-shared {
                       description
                           "Select pre-shared digital
                                         signature algorithm. For
                                         example, an RSA key is
                                         represented as the
                           authentication method.";
                       reference
                           "RFC 7296.";
                   }
                   enum eap {
                       description
                           "Select EAP RSAPublicKey as
                                         defined in RFC 8017, and an
                                         Elliptic Curve Cryptography
                                         (ECC) key is represented
                                         using the authentication method.";
                       reference
                           "RFC 7296.";
                   }
                   enum digital-signature {
                       description
                           "Select digital signature method."; 'publicKey'
                                         described in RFC 5915.";
                                   reference
                                         "RFC 7296 and RFC 7427."; XXX: Common YANG Data
                                         Types for Cryptography.";
                                   }
                   enum null
                                   leaf cert-data {
                                       type ct:x509;
                                       description
                           "Null authentication.";
                                           "X.509 certificate data -
                                            PEM4.";
                                       reference
                                           "RFC 7619.";
                   }

               }
               description
                   "Peer authentication method specified in the Peer
                    Authorization Database (PAD).";
           }

           container ipsec-ike {
               description
                   "IKE configuration XXX: Common YANG Data
                                           Types for a NSF. It includes PAD
                    parameters, IKE connections information and state
                    data.";

               container pad { Cryptography.";

                                   }
                                   description
                      "Configuration of Peer Authorization Database
                       (PAD). The PAD contains information about IKE
                       peer (local and remote). Therefore,
                                       "If the Security I2NSF Controller also stores authentication
                       information for this NSF and can include
                       several entries for
                                        knows that the local NSF not only
                       remote peers. Storing local and remote
                       information makes possible
                                        already owns a private key
                                        associated to specify that this public key
                                        (the NSF with identity A will use some particular
                       authentication with remote NSF with identity B
                       and what are generated the authentication mechanisms
                       allowed to B.";
                   list pad-entry { pair
                                        public key/private key "name";
                       ordered-by user;
                       description
                           "Peer Authorization Database (PAD) entry. It
                            is a list out of
                                        band), it will only configure
                                        one of PAD entries ordered by the
                            Security Controller."; leaf name of this
                                        choice. The NSF, based on
                                        the public key value can know
                                        the private key to be used.";
                               }
                               leaf private-key {
                                   nacm:default-deny-all;
                                   type string; binary;
                                   description
                               "PAD unique name to identify this
                                entry.";
                                       "A binary that contains the
                                        value of the private key. The
                                        interpretation of the content
                                        is defined by the digital
                                        signature algorithm. For
                                        example, an RSA key is
                                        represented as RSAPrivateKey as
                                        defined in RFC 8017, and an
                                        Elliptic Curve Cryptography
                                        (ECC) key is represented as
                                        ECPrivateKey as defined in RFC
                                        5915.";
                                   reference
                                       "RFC XXX: Common YANG Data
                                       Types for Cryptography.";
                               }
                       choice identity
                               leaf-list ca-data {
                           mandatory true;
                                   type ct:x509;
                                   description
                               "A particular IKE peer will be
                               identified by one
                                       "List of these identities.
                               This peer can be a remote peer or local
                               peer (this NSF)."; trusted Certification
                                       Authorities (CA) certificates
                                       encoded using ASN.1
                                       distinguished encoding rules
                                       (DER).";
                                   reference
                               "Section 4.4.3.1 in RFC 4301.";
                           case ipv4-address{
                                       "RFC XXX: Common YANG Data
                                       Types for Cryptography.";
                               }
                               leaf ipv4-address crl-data {
                                   type inet:ipv4-address; ct:crl;
                                   description
                                       "Specifies the identity
                                      "A CertificateList structure, as a
                                        single four (4) octet.";
                               }
                                       specified in RFC 5280,
                                       encoded using ASN.1
                                       distinguished encoding rules
                                       (DER),as specified in ITU-T
                                       X.690.";
                                   reference
                                       "RFC XXX: Common YANG Data Types
                                        for Cryptography.";
                               }
                           case ipv6-address{
                               leaf ipv6-address crl-uri  {
                                   type inet:ipv6-address; inet:uri;
                                   description
                                       "Specifies the identity as a
                                        single sixteen (16) octet IPv6
                                        address. An example is
                                        2001:DB8:0:0:8:800:200C:417A.";
                               }
                                       "X.509 CRL certificate URI.";
                               }
                           case fqdn-string {
                               leaf fqdn-string oscp-uri {
                                   type inet:domain-name; inet:uri;
                                   description
                                       "Specifies the identity as a
                                        Fully-QualifiedDomain Name
                                        (FQDN) string. An example is:
                                        example.com. The string MUST
                                        NOT contain any terminators
                                        (e.g., NULL, CR, etc.).";
                                       "OCSP URI.";
                               }
                               description
                                   "Digital Signature container.";

                           } /*container digital-signature*/
                       }
                           case rfc822-address-string {
                               leaf rfc822-address-string /*container peer-authentication*/
                   }
               }

               list conn-entry {
                                   type string;
                   key "name";
                   description
                                       "Specifies
                       "IKE peer connection information. This list
                       contains the identity as a
                                        fully-qualified RFC822 email
                                        address string. An example is,
                                        jsmith@example.com. The string
                                        MUST NOT contain any
                                        terminators e.g., NULL, CR,
                                        etc.).";
                                   reference
                                       "RFC 822.";
                               }
                           }
                           case dnx509 { IKE connection for this peer
                       with other peers. This will be translated in
                       real time by IKE Security Associations
                       established with these nodes.";
                   leaf dnx509 name {
                       type string;
                       mandatory true;
                       description
                                       "Specifies the identity as a
                                        ASN.1 X.500 Distinguished
                                        Name. An example is
                                        C=US,O=Example
                                        Organisation,CN=John Smith.";
                                   reference
                                       "RFC 2247.";
                               }
                           "Identifier for this connection
                            entry.";
                   }
                           case gnx509 {
                   leaf gnx509 autostartup {
                         type string; autostartup-type;
                         default add;
                         description
                                       "ASN.1 X.509 GeneralName. RFC
                                        3280.";
                               }
                             "By-default: Only add configuration
                              without starting the security
                              association.";
                   }
                           case id-key {
                   leaf id-key initial-contact {
                       type string; boolean;
                       default false;
                       description
                                       "Opaque octet stream that may be
                                        used
                           "The goal of this value is to pass vendor-specific
                                        information for proprietary
                                        types deactivate the
                           usage of identification.";
                                   reference
                                       "Section 3.5 in RFC 7296.";
                               } INITIAL_CONTACT notification
                           (true). If this flag remains to false it
                           means the usage of the INITIAL_CONTACT
                           notification will depend on the IKEv2
                           implementation.";
                   }
                           case id-null {
                   leaf id-null version {
                       type empty; auth-protocol-type;
                       default ikev2;
                       description
                                       "ID_NULL identification used
                                        when IKE identification payload
                          "IKE version. Only version 2 is not used." ;
                                   reference
                                       "RFC 7619.";
                               }
                           } supported
                          so far.";
                   }
                   leaf auth-protocol fragmentation {
                       type auth-protocol-type; boolean;
                       default ikev2; false;
                       description
                               "Only IKEv2 is supported right now but
                                other authentication protocols may be
                                supported in the future.";
                           "Whether or not to enable IKE
                            fragmentation as per RFC 7383 (true or
                            false).";
                       reference
                           "RFC 7383.";
                   }
                   container peer-authentication ike-sa-lifetime-soft {
                       description
                               "This container allows
                           "IKE SA lifetime soft. Two lifetime values
                            can be configured: either rekey time of the Security
                                Controller to configure
                            IKE SA or reauth time of the
                                authentication method (pre-shared key,
                                eap, digitial-signature, null) that
                                will use a particular peer and IKE SA. When
                            the
                                credentials, which will depend on rekey lifetime expires a rekey of the
                                selected authentication method.";
                            IKE SA starts. When reauth lifetime
                            expires a IKE SA reauthentication starts.";
                      leaf auth-method rekey-time {
                           type auth-method-type; uint32;
                           default pre-shared; 0;
                           description
                                   "Type of authentication method
                                   (pre-shared, eap, digital signature,
                                    null).";
                              reference
                                  "Section 2.15
                               "Time in RFC 7296."; seconds between each IKE SA
                               rekey.The value 0 means infinite.";
                      }
                           container eap-method {
                               when "../auth-method = 'eap'";
                      leaf eap-type reauth-time {
                           type uint8;
                                   mandatory true; uint32;
                           default 0;
                           description
                                       "EAP method type. This
                                       information provides the
                                       particular EAP method to be
                                       used. Depending on the EAP
                                       method, pre-shared keys or
                                       certificates may be used.";
                             "Time in seconds between each IKE SA
                             reauthentication. The value 0 means
                             infinite.";
                      }
                               description
                                   "EAP method description used when
                                   authentication method is 'eap'.";
                      reference
                          "Section 2.16 2.8 in RFC 7296.";
                   }
                   container pre-shared ike-sa-lifetime-hard {
                               when
                                   "../auth-method[.='pre-shared' or
                                    .='eap']";
                       description
                           "Hard IKE SA lifetime. When this
                            time is reached the IKE SA is removed.";
                       leaf secret over-time {
                                   nacm:default-deny-all;
                           type yang:hex-string; uint32;
                           default 0;
                           description
                                       "Pre-shared secret value.
                               "Time in seconds before the IKE SA is
                                removed. The
                                        NSF has to prevent read access
                                        to this value for security
                                        reasons."; 0 means infinite.";
                       }
                               description
                                   "Shared secret value for PSK or
                                    EAP method authentication based on
                                    PSK.";
                       reference
                           "RFC 7296.";
                   }
                           container digital-signature {
                               when
                                "../auth-method[.='digital-signature'
                               or .='eap']";
                               leaf ds-algorithm
                   leaf-list authalg {
                       type uint8; ic:integrity-algorithm-type;
                       default 12;
                       ordered-by user;
                       description
                                       "The digital signature
                          "Authentication algorithm for establishing
                          the IKE SA. This list is specified with a
                                       value extracted ordered following
                          from the IANA
                                       Registry. Depending on the
                                       algorithm, higher priority to lower priority.
                          First node of the following leafs
                                       must contain information. For
                                       example if digital signature
                                       involves a certificate then leaf
                                       'cert-data' and 'private-key' list will contain be the algorithm
                          with higher priority. If this information.";
                                   reference
                                       "IKEv2 Authentication Method -
                                        IANA Registry - Internet Key
                                        Exchange Version 2 (IKEv2)
                                        Parameters."; list is empty
                          the default integrity algorithm value assumed
                          is NONE.";
                   }

                               choice public-key {
                                   mandatory true;
                                   leaf raw-public-key
                   leaf-list encalg {
                       type binary; ic:encryption-algorithm-type;
                       default 12;
                       ordered-by user;
                       description
                                         "A binary that contains
                          "Encryption or AEAD algorithm for the
                                         value of IKE
                          SAs. This list is ordered following
                          from the public key.  The
                                         interpretation higher priority to lower priority.
                          First node of the content list will be the algorithm
                          with higher priority. If this list is defined by empty
                          the digital
                                         signature algorithm. For
                                         example, an RSA key default encryption value assumed is
                                         represented as RSAPublicKey as
                                         defined in RFC 8017, and an
                                         Elliptic Curve Cryptography
                                         (ECC)
                          NULL.";
                   }
                   leaf dh-group {
                       type pfs-group;
                       default 14;
                       description
                           "Group number for Diffie-Hellman
                           Exponentiation used during IKE_SA_INIT
                           for the IKE SA key is represented
                                         using exchange.";
                   }
                   leaf half-open-ike-sa-timer {
                       type uint32;
                       description
                           "Set the 'publicKey'
                                         described half-open IKE SA timeout
                            duration.";
                       reference
                           "Section 2 in RFC 5915.";
                                   reference
                                         "RFC XXX: Common YANG Data
                                         Types for Cryptography."; 7296.";
                   }

                   leaf cert-data half-open-ike-sa-cookie-threshold {
                       type ct:x509; uint32;
                       description
                                           "X.509 certificate data -
                                            PEM4.";
                           "Number of half-open IKE SAs that activate
                            the cookie mechanism." ;
                       reference
                                           "RFC XXX: Common YANG Data
                                           Types for Cryptography.";
                           "Section 2.6 in RFC 7296.";
                   }
                   container local {
                       leaf local-pad-entry-name {
                           type string;
                           description
                                       "If the Security Controller
                                        knows that the NSF
                                        already owns a private key
                                        associated
                               "Local peer authentication information.
                                This node points to this public key
                                        (the NSF generated a specific entry in
                                the pair
                                        public key/private key out of
                                        band), it will only configure
                                        one of PAD where the leaf of authorization
                                information about this
                                        choice. The NSF, based on
                                        the public key value can know
                                        the private key to be used."; particular local
                                peer is stored. It MUST match a
                                pad-entry-name.";
                       }
                       description
                           "Local peer authentication information.";
                   }
                   container remote {
                       leaf private-key remote-pad-entry-name {
                                   nacm:default-deny-all;
                           type binary; string;
                           description
                                       "A binary that contains the
                                        value of
                               "Remote peer authentication information.
                                This node points to a specific entry in
                                the private key. The
                                        interpretation of PAD where the content authorization
                                information about this particular
                                remote peer is defined by stored. It MUST match a
                                pad-entry-name.";
                       }
                       description
                           "Remote peer authentication information.";
                   }
                   container encapsulation-type
                   {
                       uses ic:encap;
                       description
                           "This container carries configuration
                           information about the digital
                                        signature algorithm. For
                                        example, an RSA key is
                                        represented as RSAPrivateKey as
                                        defined in RFC 8017, source and an
                                        Elliptic Curve Cryptography
                                        (ECC) key destination
                           ports of encapsulation that IKE should use
                           and the type of encapsulation that
                           should use when NAT traversal is represented as
                                        ECPrivateKey required.
                           However, this is just a best effort since
                           the IKE implementation may need to use a
                           different encapsulation as defined
                           described in RFC
                                        5915."; 8229.";
                       reference
                           "RFC XXX: Common YANG Data
                                       Types for Cryptography."; 8229.";
                   }
                               leaf-list ca-data
                   container spd {
                                   type ct:x509;
                       description
                                       "List
                           "Configuration of trusted Certification
                                       Authorities (CA) certificates
                                       encoded using ASN.1
                                       distinguished encoding rules
                                       (DER).";
                                   reference
                                       "RFC XXX: Common YANG Data
                                       Types for Cryptography.";
                               }
                               leaf crl-data {
                                   type ct:crl;
                                   description
                                      "A CertificateList structure, as
                                       specified in RFC 5280,
                                       encoded using ASN.1
                                       distinguished encoding rules
                                       (DER),as specified the Security Policy
                           Database (SPD). This main information is
                           placed in ITU-T
                                       X.690.";
                                   reference
                                       "RFC XXX: Common YANG Data Types
                                        for Cryptography.";
                               }
                               leaf crl-uri  {
                                   type inet:uri;
                                   description
                                       "X.509 CRL certificate URI.";
                               }
                               leaf oscp-uri {
                                   type inet:uri;
                                   description
                                       "OCSP URI.";
                               }
                               description
                                   "Digital Signature container.";

                           } /*container digital-signature*/
                       } /*container peer-authentication*/
                   }
               } the grouping
                           ipsec-policy-grouping.";
                       list conn-entry spd-entry {
                           key "name";
                   description
                       "IKE peer connection information. This list
                       contains the IKE connection for this peer
                       with other peers. This will be translated in
                       real time by IKE Security Associations
                       established with these nodes.";
                           ordered-by user;
                           leaf name {
                               type string;
                               mandatory true;
                               description
                           "Identifier for this connection
                            entry.";
                                   "SPD entry unique name to identify
                                   the IPsec policy.";
                           }
                   leaf autostartup
                           container ipsec-policy-config {
                         type autostartup-type;
                         default add;
                               description
                             "By-default: Only add configuration
                              without starting
                                   "This container carries the security
                              association.";
                                   configuration of a IPsec policy.";
                               uses ic:ipsec-policy-grouping;
                           }
                   leaf initial-contact {
                       type boolean;
                       default false;
                           description
                           "The goal
                               "List of this value is to deactivate entries which will constitute
                               the
                           usage representation of INITIAL_CONTACT notification
                           (true). If the SPD. Since we
                               have IKE in this flag remains to false case, it
                           means the usage of is only
                               required to send a IPsec policy from
                               this NSF where 'local' is this NSF and
                               'remote' the INITIAL_CONTACT
                           notification other NSF. The IKE
                               implementation will depend install IPsec
                               policies in the NSF's kernel in both
                               directions (inbound and outbound) and
                               their corresponding IPsec SAs based on
                               the IKEv2
                           implementation."; information in this SPD entry.";
                       }
                   leaf version
                       reference
                           "Section 2.9 in RFC 7296.";
                   }
                   container child-sa-info {
                       leaf-list pfs-groups {
                           type auth-protocol-type; pfs-group;
                           default ikev2; 0;
                           ordered-by user;
                           description
                          "IKE version. Only version 2
                               "If non-zero, it is supported
                          so far.";
                   }
                   leaf fragmentation {
                       type boolean;
                       default false;
                       description
                           "Whether or not to enable IKE
                            fragmentation as per RFC 7383 (true or
                            false).";
                       reference
                           "RFC 7383.";
                   }
                   container ike-sa-lifetime-soft {
                       description
                           "IKE SA lifetime soft. Two lifetime values
                            can be configured: either rekey time of the
                            IKE SA or reauth time of the IKE required perfect
                                forward secrecy when requesting new
                                IPsec SA. When
                            the rekey lifetime expires a rekey of the
                            IKE SA starts. When reauth lifetime
                            expires a IKE SA reauthentication starts.";
                      leaf rekey-time {
                           type uint32;
                           default 0;
                           description
                               "Time in seconds between each IKE SA
                               rekey.The value 0 means infinite.";
                      }
                      leaf reauth-time {
                           type uint32;
                           default 0;
                           description
                             "Time in seconds between each IKE SA
                             reauthentication. The non-zero value 0 means
                             infinite.";
                      }
                      reference
                          "Section 2.8 in RFC 7296.";
                   }
                   container ike-sa-lifetime-hard {
                       description
                           "Hard IKE SA lifetime. When this
                            time is reached the IKE SA is removed.";
                       leaf over-time {
                           type uint32;
                           default 0;
                           description
                               "Time in seconds before the IKE SA is
                                removed. The value 0 means infinite.";
                       }
                       reference
                           "RFC 7296.";
                   }
                   leaf-list authalg {
                       type ic:integrity-algorithm-type;
                       default 12;
                       ordered-by user;
                       description
                          "Authentication algorithm for establishing
                                the IKE SA. required group number. This list is
                                ordered following from the higher
                                priority to lower priority. First node
                                of the list will be the algorithm
                                with higher priority. If this list is empty
                          the default integrity algorithm value assumed
                          is NONE."; priority.";
                       }
                   leaf-list encalg
                       container child-sa-lifetime-soft {
                       type ic:encryption-algorithm-type;
                       default 12;
                       ordered-by user;
                           description
                          "Encryption or AEAD algorithm for
                               "Soft IPsec SA lifetime soft.
                                After the IKE
                          SAs. This list lifetime the action is ordered following
                          from the higher priority to lower priority.
                          First node of the list will be the algorithm
                          with higher priority. If
                                defined in this list is empty container
                                in the default encryption value assumed is
                          NULL.";
                   } leaf dh-group action.";
                           uses ic:lifetime;
                           leaf action {
                               type pfs-group; ic:lifetime-action;
                               default 14; replace;
                               description
                           "Group number for Diffie-Hellman
                           Exponentiation used during IKE_SA_INIT
                           for
                                   "When the IKE lifetime of an IPsec SA key exchange.";
                   }
                   leaf half-open-ike-sa-timer {
                       type uint32;
                       description
                           "Set
                                    expires an action needs to be
                                    performed over the half-open IKE IPsec SA timeout
                            duration."; that
                                    reached the lifetime. There are
                                    three possible options:
                                    terminate-clear, terminate-hold and
                                    replace.";
                           reference
                               "Section 2 4.5 in RFC 4301 and Section 2.8
                                in RFC 7296.";
                           }

                   leaf half-open-ike-sa-cookie-threshold
                       }
                       container child-sa-lifetime-hard {
                       type uint32;
                           description
                           "Number of half-open IKE SAs that activate
                               "IPsec SA lifetime hard. The action will
                                be to terminate the cookie mechanism." ; IPsec SA.";
                           uses ic:lifetime;
                           reference
                               "Section 2.6 2.8 in RFC 7296.";
                       }
                       description
                           "Specific information for IPsec SAs
                           SAs. It includes PFS group and IPsec SAs
                           rekey lifetimes.";
                   }
                   container local state {
                       config false;

                       leaf local-pad-entry-name initiator {
                           type string; boolean;
                           description
                               "Local peer authentication information.
                                This node points to a specific entry in
                                the PAD where the authorization
                                information about this particular local
                                peer
                               "It is stored. It MUST match a
                                pad-entry-name."; acting as initiator for this
                                connection.";
                       }
                       leaf initiator-ikesa-spi {
                           type ike-spi;
                           description
                           "Local peer authentication information.";
                               "Initiator's IKE SA SPI.";
                       }
                   container remote
                       leaf responder-ikesa-spi {
                           type ike-spi;
                           description
                               "Responder's IKE SA SPI.";
                       }
                       leaf remote-pad-entry-name nat-local {
                           type string; boolean;
                           description
                               "Remote peer authentication information.
                                This node points to a specific entry in
                                the PAD where the authorization
                                information about this particular
                                remote peer
                               "True, if local endpoint is stored. It MUST match behind a
                                pad-entry-name.";
                                NAT.";
                       }
                       leaf nat-remote {
                           type boolean;
                           description
                           "Remote peer authentication information.";
                               "True, if remote endpoint is behind
                               a NAT.";
                       }
                       container encapsulation-type
                       {
                           uses ic:encap;
                           description
                               "This container carries configuration provides information
                               about the source and destination
                               ports of encapsulation that IKE should use is
                               using, and the type of encapsulation that
                           should use
                               when NAT traversal is required.
                           However, this is just a best effort since
                           the IKE implementation may need to use a
                           different encapsulation as
                           described in RFC 8229."; required.";
                           reference
                               "RFC 8229.";
                       }
                   container spd
                       leaf established {
                           type uint64;
                           description
                           "Configuration of the Security Policy
                           Database (SPD). This main information is
                           placed in the grouping
                           ipsec-policy-grouping.";
                       list spd-entry
                               "Seconds since this IKE SA has been
                                established.";
                       }
                       leaf current-rekey-time {
                           key "name";
                           ordered-by user;
                           type uint64;
                           description
                               "Seconds before IKE SA must be rekeyed.";
                       }
                       leaf name current-reauth-time {
                           type string;
                               mandatory true; uint64;
                           description
                                   "SPD entry unique name to identify
                                   the IPsec policy.";
                               "Seconds before IKE SA must be
                                re-authenticated.";
                       }
                       description
                           "IKE state data for a particular
                            connection.";
                   } /* ike-sa-state */
               } /* ike-conn-entries */

               container ipsec-policy-config number-ike-sas {
                   config false;
                   leaf total {
                       type uint64;
                       description
                                   "This container carries the
                                   configuration
                           "Total number of a IPsec policy.";
                               uses ic:ipsec-policy-grouping; active IKE SAs.";
                   }
                   leaf half-open {
                       type uint64;
                       description
                               "List
                           "Number of entries which will constitute
                               the representation half-open active IKE SAs.";
                   }
                   leaf half-open-cookies {
                       type uint64;
                       description
                           "Number of half open active IKE SAs with
                            cookie activated.";
                   }
                   description
                       "General information about the SPD. Since we
                               have IKE in this case, SAs. In
                       particular, it is only
                               required to send a IPsec policy from
                               this NSF where 'local' is this NSF and
                               'remote' provides the other NSF. The current number of
                       IKE
                               implementation will install IPsec
                               policies in the NSF's kernel in both
                               directions (inbound and outbound) and
                               their corresponding IPsec SAs based on
                               the information in this SPD entry."; SAs.";
               }
                       reference
                           "Section 2.9 in RFC 7296.";
           }  /* container child-sa-info ipsec-ike */
       }

       <CODE ENDS>

Appendix C.  YANG model for IKE-less case

       <CODE BEGINS> file "ietf-ipsec-ikeless@2019-08-05.yang"

       module ietf-ipsec-ikeless {
                       leaf-list pfs-groups

           yang-version 1.1;
           namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";

           prefix "ikeless";

           import ietf-yang-types {
                           type pfs-group;
                           default 0;
                           ordered-by user;
                           description
                               "If non-zero, it is required perfect
                                forward secrecy when requesting new
                                IPsec SA. The non-zero value is
                                the required group number. This list is
                                ordered following from the higher
                                priority to lower priority. First node
                                of the list will be the algorithm
                                with higher priority."; prefix yang; }
                       container child-sa-lifetime-soft

           import ietf-ipsec-common {
                           description
                               "Soft
               prefix ic;
               reference
                   "Common Data model for SDN-based IPsec SA lifetime soft.
                                After the lifetime the action is
                                defined in this container
                                in the leaf action.";
                           uses ic:lifetime;
                           leaf action
                    configuration.";
           }

           import ietf-netconf-acm {
                               type ic:lifetime-action;
                               default replace;
                  prefix nacm;
                  reference
                    "RFC 8341: Network Configuration Access Control
                     Model.";
           }

           organization "IETF I2NSF Working Group";
           contact
           "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/about/>
            WG List: <mailto:i2nsf@ietf.org>

           Author: Rafael Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";

           description
                                   "When
               "Data model for IKE-less case in the lifetime of an SDN-base IPsec SA
                                    expires an action needs to be
                                    performed over flow
                protection service.

                Copyright (c) 2019 IETF Trust and the IPsec SA that
                                    reached persons
                identified as authors of the lifetime. There are
                                    three possible options:
                                    terminate-clear, terminate-hold code.  All rights reserved.
                Redistribution and
                                    replace.";
                           reference
                               "Section 4.5 use in RFC 4301 source and Section 2.8
                                in RFC 7296.";
                           }
                       }
                       container child-sa-lifetime-hard {
                           description
                               "IPsec SA lifetime hard. The action will
                                be binary forms, with
                or without modification, is permitted pursuant to, and
                subject to terminate the IPsec SA.";
                           uses ic:lifetime;
                           reference
                               "Section 2.8 license terms contained in, the
                Simplified BSD License set forth in Section 4.c of the
                IETF Trust's Legal Provisions Relating to IETF Documents
                (https://trustee.ietf.org/license-info).

                This version of this YANG module is part of RFC 7296."; XXXX;;
                see the RFC itself for full legal notices.

                The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
                'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
                'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
                document are to be interpreted as described in BCP 14
                (RFC 2119) (RFC 8174) when, and only when, they appear
                in all capitals, as shown here.";

           revision "2019-08-05" {
               description "Revision 06";
               reference "RFC XXXX: YANG model for IKE case.";
           }

           container ipsec-ikeless {
               description
                           "Specific information
                   "Container for configuration of the IKE-less
                    case. The container contains two additional
                    containers: 'spd' and 'sad'. The first allows the
                    I2NSF Controller to configure IPsec SAs
                           SAs. It includes PFS group policies in
                    the Security Policy Database SPD, and the second
                    allows to configure IPsec SAs
                           rekey lifetimes.";
                   } Security Associations
                    (IPsec SAs) in the Security Association Database
                    (SAD).";
               reference "RFC 4301.";
               container state {
                       config false;

                       leaf initiator spd {
                           type boolean;
                   description
                               "It is acting as initiator for this
                                connection.";
                       }
                       "Configuration of the Security Policy Database
                        (SPD.)";
                   reference "Section 4.4.1.2 in RFC 4301.";

                   list spd-entry {
                       key "name";
                       ordered-by user;
                       leaf initiator-ikesa-spi name {
                           type ike-spi; string;
                           mandatory true;
                           description
                               "Initiator's IKE SA SPI.";
                               "SPD entry unique name to identify this
                                entry.";
                       }
                       leaf responder-ikesa-spi direction {
                           type ike-spi; ic:ipsec-traffic-direction;
                           description
                               "Responder's IKE SA SPI.";
                               "Inbound traffic or outbound
                                traffic. In the IKE-less case the
                                I2NSF Controller needs to
                                specify the policy direction to be
                                applied in the NSF. In the IKE case
                                this direction does not need to be
                                specified since IKE
                                will determine the direction that
                                IPsec policy will require.";
                       }
                       leaf nat-local reqid {
                           type boolean; uint64;
                           default 0;
                           description
                               "True, if local endpoint
                               "This value allows to link this
                                IPsec policy with IPsec SAs with the
                                same reqid. It is behind a
                                NAT.";
                       }
                       leaf nat-remote {
                           type boolean;
                           description
                               "True, if remote endpoint only required in
                                the IKE-less model since, in the IKE
                                case this link is behind
                               a NAT."; handled internally
                                by IKE.";
                       }
                       container encapsulation-type ipsec-policy-config {
                           uses ic:encap;
                           description
                               "This container provides information
                               about carries the source and destination
                               ports
                               configuration of encapsulation that IKE a IPsec policy.";
                           uses ic:ipsec-policy-grouping;
                       }
                       description
                           "The SPD is
                               using, and the type represented as a list of encapsulation
                               when NAT traversal is required.";
                           reference
                               "RFC 8229."; SPD
                            entries, where each SPD entry represents an
                            IPsec policy.";
                   } /*list spd-entry*/
               } /*container spd*/

               container sad {
                   description
                       "Configuration of the IPsec Security Association
                        Database (SAD)";
                   reference "Section 4.4.2.1 in RFC 4301.";
                   list sad-entry {
                       key "name";
                       ordered-by user;
                       leaf established name {
                           type uint64; string;
                           description
                               "Seconds since
                               "SAD entry unique name to identify this IKE SA has been
                                established.";
                                entry.";
                       }
                       leaf current-rekey-time reqid {
                           type uint64;
                           default 0;
                           description
                               "Seconds before IKE
                               "This value allows to link this
                                IPsec SA must be rekeyed."; with an IPsec policy with
                                the same reqid.";
                       }

                       container ipsec-sa-config {
                           description
                               "This container allows configuring
                               details of an IPsec SA.";
                           leaf current-reauth-time spi {
                               type uint64; uint32 { range "0..max"; }
                               mandatory true;
                               description
                               "Seconds before IKE SA must be
                                re-authenticated.";
                       }
                       description
                           "IKE state data for a particular
                            connection.";
                   } /* ike-sa-state */
                                   "Security Parameter Index (SPI)'s
                                    IPsec SA.";
                           } /* ike-conn-entries */

               container number-ike-sas {
                   config false;
                           leaf total ext-seq-num {
                               type uint64; boolean;
                               default true;
                               description
                           "Total number of active IKE SAs.";
                                   "True if this IPsec SA is using
                                    extended sequence numbers. True 64
                                    bit counter, FALSE 32 bit.";
                           }
                           leaf half-open seq-number-counter {
                               type uint64;
                               default 0;
                               description
                           "Number of half-open active IKE SAs.";
                                    "A 64-bit counter when this IPsec
                                    SA is using Extended Sequence
                                    Number or 32-bit counter when it
                                    is not. It used to generate the
                                    initial Sequence Number field
                                    in ESP headers.";
                           }
                           leaf half-open-cookies seq-overflow {
                               type uint64; boolean;
                               default false;
                               description
                           "Number
                                   "The flag indicating whether
                                    overflow of half open active IKE SAs with
                            cookie activated.";
                   }
                   description
                       "General information about the IKE SAs. In
                       particular, it provides the current sequence number
                                    counter should prevent transmission
                                    of
                       IKE SAs."; additional packets on the IPsec
                                    SA (false) and, therefore needs to
                                    be rekeyed, or whether rollover is
                                    permitted (true). If Authenticated
                                    Encryption with Associated Data
                                    (AEAD) is used this flag MUST BE
                                    false.";
                           }
                           leaf anti-replay-window {
                               type uint32;
                               default 32;
                               description
                                   "A 32-bit counter and a bit-map (or
                                    equivalent) used to determine
                                    whether an inbound ESP packet is a
                                    replay. If set to 0 no anti-replay
                                    mechanism is performed.";
                           }  /*
                           container ipsec-ike */
       }

       <CODE ENDS>

Appendix C.  Appendix C: YANG model for IKE-less case

       <CODE BEGINS> file "ietf-ipsec-ikeless@2019-08-05.yang"

       module ietf-ipsec-ikeless {

           yang-version 1.1;
           namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";

           prefix "ikeless";

           import ietf-yang-types traffic-selector { prefix yang;
                               uses ic:selector-grouping;
                               description
                                   "The IPsec SA traffic selector.";
                           }

           import ietf-ipsec-common
                           leaf protocol-parameters {
               prefix ic;
               reference
                   "Common Data model for SDN-based IPSec
                    configuration.";
                               type ic:ipsec-protocol-parameters;
                               default esp;
                               description
                                   "Security protocol of IPsec SA: Only
                                   ESP so far.";
                           }

           import ietf-netconf-acm
                           leaf mode {
                  prefix nacm;
                  reference
                    "RFC 8341: Network Configuration Access Control
                     Model.";
                               type ic:ipsec-mode;
                               description
                                   "Tunnel or transport mode.";
                           }
           organization "IETF I2NSF Working Group";

           contact
           "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/about/>
            WG List: <mailto:i2nsf@ietf.org>

           Author: Rafael Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";
                           container esp-sa {
                               when "../protocol-parameters =
                            'esp'";
                               description
               "Data model for IKE-less
                                   "In case in the SDN-base IPsec flow
                protection service.

                Copyright (c) 2019 IETF Trust and the persons
                identified as authors of the code.  All rights reserved.
                Redistribution and use in source and binary forms, with
                or without modification, SA is permitted pursuant to, and
                subject to the license terms contained in, the
                Simplified BSD License set forth in Section 4.c of the
                IETF Trust's Legal Provisions Relating to IETF Documents
                (https://trustee.ietf.org/license-info).

                This version of this YANG module
                                    Encapsulation Security Payload
                                    (ESP), it is part of RFC XXXX;;
                see the RFC itself for full legal notices.

                The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
                'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
                'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
                document are required to be interpreted as described in BCP 14
                (RFC 2119) (RFC 8174) when, specify
                                    encryption and only when, they appear
                in all capitals, as shown here.";

           revision "2019-08-05" integrity
                                    algorithms, and key material.";

                               container encryption {
                                   description "Revision 06";
               reference "RFC XXXX: YANG model
                                       "Configuration of encryption or
                                        AEAD algorithm for IKE case.";
           }

           container ipsec-ikeless {
               description
                   "Container for configuration of the IKE-less
                    case. The container contains two additional
                    containers: 'spd' and 'sad'. The first allows the
                    Security Controller to configure IPsec policies in
                    the Security Policy Database SPD, and the second
                    allows to configure IPsec Security Associations
                    (IPsec SAs) in the Security Association Database
                    (SAD).";
               reference "RFC 4301.";
               container spd IPsec
                                        Encapsulation Security Payload
                                        (ESP).";

                                   leaf encryption-algorithm {
                                     type ic:encryption-algorithm-type;
                                     description
                                           "Configuration of ESP
                                            encryption. With AEAD
                                            algorithms, the Security Policy Database
                        (SPD.)";
                   reference "Section 4.4.1.2 in RFC 4301.";

                   list spd-entry {
                       key "name";
                       ordered-by user; integrity
                                            node is not used.";
                                   }

                                   leaf name key {
                                       nacm:default-deny-all;
                                       type string;
                           mandatory true; yang:hex-string;
                                       description
                               "SPD entry unique name to identify this
                                entry.";
                                           "ESP encryption key value.";
                                    }
                                   leaf direction iv {
                                       nacm:default-deny-all;
                                       type ic:ipsec-traffic-direction; yang:hex-string;
                                       description
                               "Inbound traffic or outbound
                                traffic. In the IKE-less case the
                                           "ESP encryption IV value.";
                                   }
                               }
                               container integrity {
                                   description
                                       "Configuration of integrity for
                                        IPsec Encapsulation Security Controller needs
                                        Payload (ESP). This container
                                        allows to
                                specify the policy direction configure integrity
                                        algorithm when no AEAD
                                        algorithms are used, and
                                        integrity is required.";
                                    leaf integrity-algorithm {
                                       type ic:integrity-algorithm-type;
                                       description
                                           "Message Authentication Code
                                           (MAC) algorithm to be
                                applied provide
                                           integrity in the NSF. In the IKE case
                                this direction does not need to be
                                specified since IKE
                                will determine the direction that
                                IPsec policy will require."; ESP.";
                                   }
                                   leaf reqid key {
                                       nacm:default-deny-all;
                                       type uint64;
                           default 0; yang:hex-string;
                                       description
                               "This value allows to link this
                                IPsec policy with IPsec SAs with the
                                same reqid. It is only required in
                                the IKE-less model since, in the IKE
                                case this link is handled internally
                                by IKE.";
                                           "ESP integrity key value.";
                                   }
                               }
                           } /*container esp-sa*/

                           container ipsec-policy-config sa-lifetime-hard {
                               description
                               "This container carries the
                               configuration of a IPsec policy.";
                                   "IPsec SA hard lifetime. The action
                                   associated is terminate and
                                   hold.";
                               uses ic:ipsec-policy-grouping; ic:lifetime;
                           }
                           container sa-lifetime-soft {
                               description
                           "The SPD is represented as a list of SPD
                            entries, where each SPD entry represents an
                            IPsec policy.";
                                   "IPsec SA soft lifetime.";
                               uses ic:lifetime;
                               leaf action {
                                   type ic:lifetime-action;
                                   description
                                       "Action lifetime:
                                        terminate-clear,
                                        terminate-hold or replace.";
                               } /*list spd-entry*/
                           } /*container spd*/
                           container sad tunnel {
                               when "../mode = 'tunnel'";
                               uses ic:tunnel-grouping;
                               description
                       "Configuration
                                    "Endpoints of the IPSec Security Association
                        Database (SAD)";
                   reference "Section 4.4.2.1 IPsec tunnel.";
                           }
                           container encapsulation-type
                           {
                               uses ic:encap;
                               description
                                   "This container carries
                                    configuration information about
                                    the source and destination ports
                                    which will be used for ESP
                                    encapsulation that ESP packets the
                                    type of encapsulation when NAT
                                    traversal is in RFC 4301.";
                   list sad-entry place.";
                           }
                       } /*ipsec-sa-config*/

                       container ipsec-sa-state {
                       key "name";
                       ordered-by user;
                       leaf name
                           config false;
                           description
                               "Container describing IPsec SA state
                               data.";
                           container sa-lifetime-current {
                           type string;
                               uses ic:lifetime;
                               description
                                   "SAD entry unique name to identify this
                                entry."; lifetime current.";
                           }
                           container replay-stats {
                               description
                                   "State data about the anti-replay
                                    window.";
                               leaf reqid replay-window {
                                   type uint64;
                           default 0;
                                   description
                               "This value allows to link this
                                IPsec SA with an IPsec policy with
                                       "Current state of the same reqid."; replay
                                        window.";
                               }

                       container ipsec-sa-config
                               leaf packet-dropped {
                                   type uint64;
                                   description
                               "This container allows configuring
                               details
                                       "Packets detected out of an IPsec SA."; the
                                        replay window and dropped
                                        because they are replay
                                        packets.";
                               }
                               leaf spi failed {
                                   type uint32 { range "0..max"; }
                               mandatory true; uint32;
                                   description
                                   "Security Parameter Index (SPI)'s
                                    IPsec SA.";
                                       "Number of packets detected out
                                        of the replay window.";
                               }
                               leaf ext-seq-num seq-number-counter {
                                   type boolean;
                               default true; uint64;
                                   description
                                   "True if this IPsec SA is using
                                    extended sequence numbers. True 64
                                    bit counter, FALSE 32 bit.";
                           }
                           leaf seq-number-counter {
                               type uint64;
                               default 0;
                               description
                                    "A 64-bit counter when
                                       "A 64-bit counter when this
                                        IPsec SA is using Extended
                                        Sequence Number or 32-bit
                                        counter when it is not. It used to generate the
                                    initial Sequence Number field
                                    in ESP headers.";
                           }
                           leaf seq-overflow {
                               type boolean;
                               default false;
                               description
                                   "The flag indicating whether
                                    overflow
                                        Current value of the sequence number
                                    counter should prevent transmission
                                        number.";
                               }
                           } /* container replay-stats*/
                       } /*ipsec-sa-state*/

                       description
                           "List of additional packets on SAD entries that conforms the SAD.";
                   } /*list sad-entry*/
               } /*container sad*/
           }/*container ipsec-ikeless*/

           /* Notifications */
           notification sadb-acquire {
               description
                   "An IPsec SA (false) and, therefore needs to
                                    be rekeyed, or whether rollover is
                                    permitted (true). If Authenticated
                                    Encryption with Associated Data
                                    (AEAD) is used this flag MUST BE
                                    false.";
                           } required. The traffic-selector
                    container contains information about the IP packet
                    that triggers the acquire notification.";
               leaf anti-replay-window ipsec-policy-name {
                   type uint32;
                               default 32; string;
                   mandatory true;
                   description
                                   "A 32-bit counter and a bit-map (or
                                    equivalent) used to determine
                                    whether an inbound ESP
                       "It contains the SPD entry name (unique) of
                        the IPsec policy that hits the IP packet
                        required IPsec SA. It is assumed the
                        I2NSF Controller will have a
                                    replay. If set to 0 no anti-replay
                                    mechanism copy of the
                        information of this policy so it can
                        extract all the information with this
                        unique identifier. The type of IPsec SA is performed.";
                        defined in the policy so the Security
                        Controller can also know the type of IPsec
                        SA that must be generated.";
               }
               container traffic-selector {
                               uses ic:selector-grouping;
                    description
                        "The IP packet that triggered the acquire
                         and requires an IPsec SA traffic selector.";
                           }
                           leaf protocol-parameters {
                               type ic:ipsec-protocol-parameters;
                               default esp;
                               description
                                   "Security SA. Specifically it
                         will contain the IP source/mask and IP
                         destination/mask; protocol of IPsec SA: Only
                                   ESP so far."; (udp, tcp,
                         etc...); and source and destination
                         ports.";
                    uses ic:selector-grouping;
                }
                           leaf mode
           }

           notification sadb-expire {
                               type ic:ipsec-mode;
               description
                                   "Tunnel "An IPsec SA expiration (soft or transport mode.";
                           }
                           container esp-sa hard).";
               leaf ipsec-sa-name {
                               when "../protocol-parameters =
                            'esp'";
                   type string;
                   mandatory true;
                   description
                                   "In case
                       "It contains the SAD entry name (unique) of
                        the IPsec SA that has expired.  It is
                                    Encapsulation Security Payload
                                    (ESP), it is required to specify
                                    encryption assumed
                        the I2NSF Controller will have a copy of the
                        IPsec SA information (except the cryptographic
                        material and integrity state data) indexed by this name
                        (unique identifier) so it can know all the
                        information (crypto algorithms, and key material.";

                               container encryption {
                                   description
                                       "Configuration of encryption etc.) about
                        the IPsec SA that has expired in order to
                        perform a rekey (soft lifetime) or
                                        AEAD algorithm for IPSec
                                        Encapsulation Security Payload
                                        (ESP)."; delete it
                        (hard lifetime) with this unique identifier.";
               }
               leaf encryption-algorithm soft-lifetime-expire {
                   type ic:encryption-algorithm-type; boolean;
                   default true;
                   description
                                           "Configuration of ESP
                                            encryption. With AEAD
                                            algorithms,
                       "If this value is true the integrity
                                            node lifetime expired is not used.";
                        soft. If it is false is hard.";
               }

                                   leaf key
               container lifetime-current {
                                       nacm:default-deny-all;
                                       type yang:hex-string;
                   description
                                           "ESP encryption key value.";
                       "IPsec SA current lifetime. If
                        soft-lifetime-expired is true this container is
                        set with the lifetime information about current
                        soft lifetime.";
                   uses ic:lifetime;
               }
                                   leaf iv
           }
           notification sadb-seq-overflow {
                                       nacm:default-deny-all;
                                       type yang:hex-string;
               description
                                           "ESP encryption IV value.";
                                   }
                               }
                               container integrity "Sequence overflow notification.";
               leaf ipsec-sa-name {
                   type string;
                   mandatory true;
                   description
                                       "Configuration
                       "It contains the SAD entry name (unique) of integrity for
                                        IPSec Encapsulation Security
                                        Payload (ESP). This container
                                        allows
                        the IPsec SA that is about to configure integrity
                                        algorithm when no AEAD
                                        algorithms are used, have sequence
                        number overflow and
                                        integrity rollover is required.";
                                    leaf integrity-algorithm {
                                       type ic:integrity-algorithm-type;
                                       description
                                           "Message Authentication Code
                                           (MAC) algorithm to provide
                                           integrity in ESP.";
                                   }
                                   leaf key {
                                       nacm:default-deny-all;
                                       type yang:hex-string;
                                       description
                                           "ESP integrity key value.";
                                   }
                               }
                           } /*container esp-sa*/

                           container sa-lifetime-hard {
                               description
                                   "IPsec SA hard lifetime. The action
                                   associated not permitted.
                        It is terminate and
                                   hold.";
                               uses ic:lifetime;
                           }
                           container sa-lifetime-soft {
                               description
                                   "IPSec SA soft lifetime.";
                               uses ic:lifetime;
                               leaf action {
                                   type ic:lifetime-action;
                                   description
                                       "Action lifetime:
                                        terminate-clear,
                                        terminate-hold or replace.";
                               }

                           }
                           container tunnel {
                               when "../mode = 'tunnel'";
                               uses ic:tunnel-grouping;
                               description
                                    "Endpoints assumed the I2NSF Controller will have
                        a copy of the IPsec tunnel.";
                           }
                           container encapsulation-type
                           {
                               uses ic:encap;
                               description
                                   "This container carries
                                    configuration SA information about (except the source
                        cryptographic material and destination ports
                                    which will be used for ESP
                                    encapsulation that ESP packets state data) indexed
                        by this name (unique identifier) so the it can
                        know all the information (crypto algorithms,
                        etc.) about the
                                    type of encapsulation when NAT
                                    traversal is in place.";
                           }
                       } /*ipsec-sa-config*/

                       container ipsec-sa-state {
                           config false;
                           description
                               "Container describing IPsec SA state
                               data.";
                           container sa-lifetime-current {
                               uses ic:lifetime;
                               description
                                   "SAD lifetime current."; that has expired in
                        order to perform a rekey of the IPsec SA.";
               }
                           container replay-stats
           }
           notification sadb-bad-spi {
               description
                                   "State data about
                   "Notify when the anti-replay
                                    window."; NSF receives a packet with an
                    incorrect SPI (i.e. not present in the SAD).";
               leaf replay-window spi {
                   type uint64; uint32 { range "0..max"; }
                   mandatory true;
                   description
                                       "Current state of the replay
                                        window.";
                               }
                               leaf packet-dropped {
                                   type uint64;
                                   description
                                       "Packets detected out of the
                                        replay window and dropped
                                        because they are replay
                                        packets.";

                               }
                               leaf failed {
                                   type uint32;
                                   description
                                       "Number of packets detected out
                                        of
                       "SPI number contained in the replay window.";
                               }
                               leaf seq-number-counter {
                                   type uint64;
                                   description
                                       "A 64-bit counter when this erroneous IPsec SA is using Extended
                                        Sequence Number or 32-bit
                                        counter when it is not.
                                        Current value of sequence
                                        number.";
                               }
                           } /* container replay-stats*/
                       } /*ipsec-sa-state*/

                       description
                           "List of SAD entries that conforms the SAD.";
                        packet.";
               } /*list sad-entry*/
           } /*container sad*/
           }/*container ipsec-ikeless*/

           /* Notifications */
           notification sadb-acquire {
               description
                   "An IPsec SA is required. The traffic-selector
                    container contains information about the IP packet
                    that triggers the acquire notification.";
               leaf ipsec-policy-name {
                   type string;
                   mandatory true;
                   description
                       "It contains the SPD entry name (unique) of
                        the IPsec policy that hits the IP packet
                        required IPsec SA. It is assumed
       }/*module ietf-ipsec*/

       <CODE ENDS>

Appendix D.  XML configuration example for IKE case (gateway-to-gateway)

   This example shows a XML configuration file sent by the
                        Security I2NSF
   Controller will have to establish a copy of the
                        information of this policy so it can
                        extract all the information with this
                        unique identifier. The type of IPsec SA is
                        defined Security Association between two NSFs
   (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP,
   authentication based on X.509 certificates and applying the policy so the Security IKE case.

                              +------------------+
                              | I2NSF Controller can also know the type of IPsec
                        SA that must be generated.";
               }
               container traffic-selector {
                    description
                        "The IP packet that triggered |
                              +------------------+
                       I2NSF NSF-Facing |
                              Interface |
                     /------------------+-----------------\
                    /                                      \
                   /                                        \
       +----+  +--------+                            +--------+  +----+
       | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 |
       +----+  +--------+                            +--------+  +----+
              :1        :100                       :200       :1

    (2001:DB8:1:/64)          (2001:DB8:123:/64)       (2001:DB8:2:/64)

    Figure 3: IKE case, tunnel mode , X.509 certificate authentication.

   <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"
   xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <pad>
       <pad-entry>
         <name>nsf_h1_pad</name>
         <ipv6-address>2001:DB8:123::100</ipv6-address>
         <peer-authentication>
            <auth-method>digital-signature</auth-method>
            <digital-signature>
               <cert-data>base64encodedvalue==</cert-data>
               <private-key>base64encodedvalue==</private-key>
               <ca-data>base64encodedvalue==</ca-data>
            </digital-signature>
         </peer-authentication>
       </pad-entry>
       <pad-entry>
         <name>nsf_h2_pad</name>
         <ipv6-address>2001:DB8:123::200</ipv6-address>
         <auth-protocol>ikev2</auth-protocol>
         <peer-authentication>
           <auth-method>digital-signature</auth-method>
           <digital-signature>
             <!-- RSA Digital Signature -->
             <ds-algorithm>1</ds-algorithm>
             <cert-data>base64encodedvalue==</cert-data>
             <ca-data>base64encodedvalue==</ca-data>
           </digital-signature>
         </peer-authentication>
       </pad-entry>

     </pad>
     <conn-entry>
        <name>nsf_h1-nsf_h2</name>
        <autostartup>start</autostartup>
        <version>ikev2</version>
        <initial-contact>false</initial-contact>
        <fragmentation>true</fragmentation>
        <ike-sa-lifetime-soft>
           <rekey-time>60</rekey-time>
           <reauth-time>120</reauth-time>
        </ike-sa-lifetime-soft>
        <ike-sa-lifetime-hard>
           <over-time>3600</over-time>
        </ike-sa-lifetime-hard>
        <authalg>7</authalg>
        <!--AUTH_HMAC_SHA1_160-->
        <encalg>3</encalg>
        <!--ENCR_3DES -->
        <dh-group>18</dh-group>
        <!--8192-bit MODP Group-->
        <half-open-ike-sa-timer>30</half-open-ike-sa-timer>
        <half-open-ike-sa-cookie-threshold>
           15
        </half-open-ike-sa-cookie-threshold>
        <local>
            <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
        </local>
        <remote>
            <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
        </remote>
        <spd>
          <spd-entry>
             <name>nsf_h1-nsf_h2</name>
             <ipsec-policy-config>
               <anti-replay-window>32</anti-replay-window>
               <traffic-selector>
                  <local-subnet>2001:DB8:1::0/64</local-subnet>
                  <remote-subnet>2001:DB8:2::0/64</remote-subnet>
                  <inner-protocol>any</inner-protocol>
                  <local-ports>
                    <start>0</start>
                    <end>0</end>
                  </local-ports>
                  <remote-ports>
                    <start>0</start>
                    <end>0</end>
                  </remote-ports>
               </traffic-selector>
               <processing-info>
                  <action>protect</action>
                  <ipsec-sa-cfg>
                     <pfp-flag>false</pfp-flag>
                     <ext-seq-num>true</ext-seq-num>
                     <seq-overflow>false</seq-overflow>
                     <stateful-frag-check>false</stateful-frag-check>
                     <mode>tunnel</mode>
                     <protocol-parameters>esp</protocol-parameters>
                     <esp-algorithms>
                        <!-- AUTH_HMAC_SHA1_96 -->
                        <integrity>2</integrity>
                        <!-- ENCR_AES_CBC -->
                        <encryption>12</encryption>
                        <tfc-pad>false</tfc-pad>
                     </esp-algorithms>
                     <tunnel>
                        <local>2001:DB8:123::100</local>
                        <remote>2001:DB8:123::200</remote>
                        <df-bit>clear</df-bit>
                        <bypass-dscp>true</bypass-dscp>
                        <ecn>false</ecn>
                    </tunnel>
                  </ipsec-sa-cfg>
               </processing-info>
             </ipsec-policy-config>
          </spd-entry>
        </spd>
        <child-sa-info>
           <!--8192-bit MODP Group -->
           <pfs-groups>18</pfs-groups>
           <child-sa-lifetime-soft>
              <bytes>1000000</bytes>
              <packets>1000</packets>
              <time>30</time>
              <idle>60</idle>
              <action>replace</action>
           </child-sa-lifetime-soft>
           <child-sa-lifetime-hard>
              <bytes>2000000</bytes>
              <packets>2000</packets>
              <time>60</time>
              <idle>120</idle>
           </child-sa-lifetime-hard>
        </child-sa-info>
      </conn-entry>
   </ipsec-ike>

Appendix E.  XML configuration example for IKE-less case (host-to-host)

   This example shows a XML configuration file sent by the acquire
                         and requires an I2NSF
   Controller to establish a IPsec SA. Specifically it
                         will contain the IP source/mask and IP
                         destination/mask; protocol (udp, tcp,
                         etc...); and source Security Association between two NSFs
   (see Figure 4) in transport mode (host-to-host) with ESP, and destination
                         ports.";
                    uses ic:selector-grouping;
                }
           }

           notification sadb-expire {
               description "An IPsec SA expiration (soft or hard).";
               leaf ipsec-sa-name {
                   type string;
                   mandatory true;
                   description
                       "It contains
   applying the SAD entry name (unique) IKE-less case.

                            +------------------+
                            | I2NSF Controller |
                            +------------------+
                    I2NSF NSF-Facing |
                           Interface |
                /--------------------+-------------------\
               /                                          \
              /                                            \
         +--------+                                    +--------+
         | nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 |
         +--------+                                    +--------+
                 :100        (2001:DB8:123:/64)       :200

                 Figure 4: IKE-less case, transport mode.

   <ipsec-ikeless
     xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <spd>
       <spd-entry>
           <name>
              in/trans/2001:DB8:123::200/2001:DB8:123::100
           </name>
           <direction>inbound</direction>
           <reqid>1</reqid>
           <ipsec-policy-config>
              <traffic-selector>
                <local-subnet>2001:DB8:123::200/128</local-subnet>
                <remote-subnet>2001:DB8:123::100/128</remote-subnet>
                <inner-protocol>any</inner-protocol>
                   <local-ports>
                      <start>0</start>
                      <end>0</end>
                   </local-ports>
                   <remote-ports>
                      <start>0</start>
                      <end>0</end>

                    </remote-ports>
              </traffic-selector>
              <processing-info>
                 <action>protect</action>
                 <ipsec-sa-cfg>
                   <ext-seq-num>true</ext-seq-num>
                   <seq-overflow>true</seq-overflow>
                   <mode>transport</mode>
                   <protocol-parameters>esp</protocol-parameters>
                   <esp-algorithms>
                      <!--AUTH_HMAC_SHA1_96-->
                      <integrity>2</integrity>
                      <!--ENCR_AES_CBC -->
                      <encryption>12</encryption>
                   </esp-algorithms>
                 </ipsec-sa-cfg>
               </processing-info>
             </ipsec-policy-config>
           </spd-entry>
           <spd-entry>
             <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
             <direction>outbound</direction>
             <reqid>1</reqid>
             <ipsec-policy-config>
               <traffic-selector>
                 <local-subnet>2001:DB8:123::100/128</local-subnet>
                 <remote-subnet>2001:DB8:123::200/128</remote-subnet>
                 <inner-protocol>any</inner-protocol>
                 <local-ports>
                   <start>0</start>
                   <end>0</end>
                 </local-ports>
                 <remote-ports>
                   <start>0</start>
                   <end>0</end>
                 </remote-ports>
               </traffic-selector>
               <processing-info>
                 <action>protect</action>
                 <ipsec-sa-cfg>
                   <ext-seq-num>true</ext-seq-num>
                   <seq-overflow>true</seq-overflow>
                   <mode>transport</mode>
                   <protocol-parameters>esp</protocol-parameters>
                   <esp-algorithms>
                     <!-- AUTH_HMAC_SHA1_96 -->
                     <integrity>2</integrity>
                     <!-- ENCR_AES_CBC -->
                     <encryption>12</encryption>
                   </esp-algorithms>
                  </ipsec-sa-cfg>
                </processing-info>
              </ipsec-policy-config>
           </spd-entry>
        </spd>
        <sad>
          <sad-entry>
            <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
            <reqid>1</reqid>
            <ipsec-sa-config>
               <spi>34501</spi>
               <ext-seq-num>true</ext-seq-num>
               <seq-number-counter>100</seq-number-counter>
               <seq-overflow>true</seq-overflow>
               <anti-replay-window>32</anti-replay-window>
               <traffic-selector>
                 <local-subnet>2001:DB8:123::100/128</local-subnet>
                 <remote-subnet>2001:DB8:123::200/128</remote-subnet>
                    <inner-protocol>any</inner-protocol>
                    <local-ports>
                       <start>0</start>
                       <end>0</end>
                    </local-ports>
                    <remote-ports>
                       <start>0</start>
                       <end>0</end>
                    </remote-ports>
                </traffic-selector>
                <protocol-parameters>esp</protocol-parameters>
                <mode>transport</mode>
                <esp-sa>
                  <encryption>
                     <!-- //ENCR_AES_CBC -->
                     <encryption-algorithm>12</encryption-algorithm>
                     <key>01:23:45:67:89:AB:CE:DF</key>
                     <iv>01:23:45:67:89:AB:CE:DF</iv>
                  </encryption>
                  <integrity>
                     <!-- //AUTH_HMAC_SHA1_96 -->
                     <integrity-algorithm>2</integrity-algorithm>
                     <key>01:23:45:67:89:AB:CE:DF</key>
                  </integrity>
                </esp-sa>
            </ipsec-sa-config>
          </sad-entry>
          <sad-entry>
             <name>in/trans/2001:DB8:123::200/2001:DB8:123::100</name>
             <reqid>1</reqid>
             <ipsec-sa-config>
                 <spi>34502</spi>
                 <ext-seq-num>true</ext-seq-num>
                 <seq-number-counter>100</seq-number-counter>
                 <seq-overflow>true</seq-overflow>
                 <anti-replay-window>32</anti-replay-window>
                 <traffic-selector>
                    <local-subnet>2001:DB8:123::200/128</local-subnet>
                    <remote-subnet>2001:DB8:123::100/128</remote-subnet>
                    <inner-protocol>any</inner-protocol>
                    <local-ports>
                       <start>0</start>
                       <end>0</end>
                    </local-ports>
                    <remote-ports>
                       <start>0</start>
                       <end>0</end>
                    </remote-ports>
                 </traffic-selector>
                 <protocol-parameters>esp</protocol-parameters>
                 <mode>transport</mode>
                 <esp-sa>
                    <encryption>
                       <!-- //ENCR_AES_CBC -->
                       <encryption-algorithm>12</encryption-algorithm>
                       <key>01:23:45:67:89:AB:CE:DF</key>
                       <iv>01:23:45:67:89:AB:CE:DF</iv>
                    </encryption>
                    <integrity>
                       <!-- //AUTH_HMAC_SHA1_96 -->
                       <integrity-algorithm>2</integrity-algorithm>
                       <key>01:23:45:67:89:AB:CE:DF</key>
                    </integrity>
                  </esp-sa>
                  <sa-lifetime-hard>
                     <bytes>2000000</bytes>
                     <packets>2000</packets>
                     <time>60</time>
                     <idle>120</idle>
                  </sa-lifetime-hard>
                  <sa-lifetime-soft>
                     <bytes>1000000</bytes>
                     <packets>1000</packets>
                     <time>30</time>
                     <idle>60</idle>
                     <action>replace</action>

                  </sa-lifetime-soft>
            </ipsec-sa-config>
          </sad-entry>
       </sad>
   </ipsec-ikeless>

Appendix F.  XML notification examples

   Below we show several XML files that represent different types of
   notifications defined in the IPsec SA that has expired.  It is assumed IKE-less YANG model, which are sent by
   the Security Controller will have a copy of NSF to the I2NSF Controller.  The notifications happen in the
   IKE-less case.

   <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
   <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
   </ipsec-sa-name>
       <soft-lifetime-expire>true</soft-lifetime-expire>
          <lifetime-current>
             <bytes>1000000</bytes>
             <packets>1000</packets>
             <time>30</time>
             <idle>60</idle>
          </lifetime-current>
   </sadb-expire>

              Figure 5: Example of sadb-expire notification.

   <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
       <ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
       </ipsec-policy-name>
       <traffic-selector>
           <local-subnet>2001:DB8:123::200/128</local-subnet>
           <remote-subnet>2001:DB8:123::100/128</remote-subnet>
           <inner-protocol>any</inner-protocol>
            <local-ports>
                 <start>0</start>
                 <end>0</end>
            </local-ports>
            <remote-ports>
                 <start>0</start>
                 <end>0</end>
            </remote-ports>
       </traffic-selector>
   </sadb-acquire>

              Figure 6: Example of sadb-acquire notification.

   <sadb-seq-overflow
       xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
         <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
         </ipsec-sa-name>
   </sadb-seq-overflow>

           Figure 7: Example of sadb-seq-overflow notification.

   <sadb-bad-spi
            xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
           <spi>666</spi>
   </sadb-bad-spi>

              Figure 8: Example of sadb-bad-spi notification.

Appendix G.  Operational use cases examples

G.1.  Example of IPsec SA information (except establishment

   This appendix exemplifies the cryptographic
                        material applicability of IKE case and state data) indexed by this name
                        (unique identifier) so it can know all the
                        information (crypto algorithms, etc.) about
                        the IKE-less
   case to traditional IPsec SA configurations, that has expired is, host-to-host and
   gateway-to-gateway.  The examples we show in order to
                        perform a rekey (soft lifetime) or delete it
                        (hard lifetime) with this unique identifier.";
               }
               leaf soft-lifetime-expire {
                   type boolean;
                   default true;
                   description
                       "If this value is true the lifetime expired is
                        soft. If it is false is hard.";
               }
               container lifetime-current {
                   description
                       "IPsec SA current lifetime. If
                        soft-lifetime-expired is true this container is
                        set with the lifetime information about current
                        soft lifetime.";
                   uses ic:lifetime;
               }
           }
           notification sadb-seq-overflow {
               description "Sequence overflow notification.";
               leaf ipsec-sa-name {
                   type string;
                   mandatory true;
                   description
                       "It contains following assume the SAD entry name (unique)
   existence of
                        the two NSFs needing to establish an end-to-end IPsec SA to
   protect their communications.  Both NSFs could be two hosts that is about
   exchange traffic (host-to-host) or gateways (gateway-to-gateway), for
   example, within an enterprise that needs to have sequence
                        number overflow and rollover is not permitted.
                        It is assumed protect the Security Controller will have
                        a copy of traffic
   between the networks of two branch offices.

   Applicability of these configurations appear in current and new
   networking scenarios.  For example, SD-WAN technologies are providing
   dynamic and on-demand VPN connections between branch offices, or
   between branches and SaaS cloud services.  Beside, IaaS services
   providing virtualization environments are deployments solutions based
   on IPsec SA information (except the
                        cryptographic material to provide secure channels between virtual instances (host-
   to-host) and state data) indexed
                        by this name (unique identifier) so the it can
                        know all providing VPN solutions for virtualized networks
   (gateway-to-gateway).

   As we will show in the information (crypto algorithms,
                        etc.) about following, the I2NSF-based IPsec SA that has expired in
                        order management
   system (for IKE and IKE-less cases), exhibits various advantages:

   1.  It allows to perform a rekey of the create IPsec SA.";
               }
           }
           notification sadb-bad-spi {
               description
                   "Notify when SAs among two NSFs, based only on the NSF receives
       application of general Flow-based Protection Policies at the
       I2NSF User.  Thus, administrators can manage all security
       associations in a packet centralized point with an
                    incorrect SPI (i.e. not present in abstracted view of
       the SAD).";
               leaf spi {
                   type uint32 { range "0..max"; }
                   mandatory true;
                   description
                       "SPI number contained network.

   2.  Any NSF deployed in the erroneous IPsec
                        packet.";
               }
           }
       }/*module ietf-ipsec*/

       <CODE ENDS>

Appendix D.  Example of IKE case, tunnel mode (gateway-to-gateway) with
             X.509 certificate authentication.

   This example shows a XML configuration file sent by the Security
   Controller to establish a IPsec Security Association between two NSFs system does not need manual
       configuration, therefore allowing its deployment in tunnel mode (gateway-to-gateway) with ESP, and authentication
   based on X.509 certificates using IKEv2.

                        Security an automated
       manner.

G.1.1.  IKE case
                 +----------------------------------------+
                 |  I2NSF User  (IPsec Management System) |
                 +----------------------------------------+
                           |
                  (1)    Flow-based    I2NSF Consumer-Facing
                      Protection Policy       Interface
                           |
                 +---------|------------------------------+
                 |         |                              |
                 |         |   I2NSF Controller           |
                 /---- Southbound interface -----\
                /                                 \
               /                                   \
              /                                     \
                 |         V                              |
                 |   +--------------+ (2)+--------------+ |
                 |   |Translate into|--->|   NETCONF/   | |
                 |   |IPsec Policies|    |   RESTCONF   | |
                 |   +--------------+    +--------------+ |
                 |                          |     |       |
                 |                          |     |       |
                 +--------------------------|-----|-------+
                                            |     |
                I2NSF NSF-Facing Interface  |     |
                                            | (3) |
                  |-------------------------+     +---|
                  V                                   V
          +----------------------+         +----------------------+
          |       NSF A          |         |        NSF B         |
          | IKEv2/IPsec(SPD/PAD) |         | IKEv2/IPsec(SPD/PAD) |
          +----------------------+         +----------------------+

       Figure 9: Host-to-host /                                       \
            nsf_h1                                  nsf_h2
    h1---- (:1/:100)===== IPsec_ESP_Tunnel_mode =====(:200/:1)-------h2
    2001:DB8:1:/64       (2001:DB8:123:/64)           2001:DB8:2:/64 gateway-to-gateway for the IKE case.

   Figure 7: 9 describes the application of the IKE case, tunnel mode , X.509 certicate authentication.

   <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"
   xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <pad>
       <pad-entry>
         <name>nsf_h1_pad</name>
         <ipv6-address>2001:DB8:123::100</ipv6-address>
         <peer-authentication>
            <auth-method>digital-signature</auth-method>
            <digital-signature>
               <cert-data>base64encodedvalue==</cert-data>
               <private-key>base64encodedvalue==</private-key>
               <ca-data>base64encodedvalue==</ca-data>
            </digital-signature>
         </peer-authentication>
       </pad-entry>
       <pad-entry>
         <name>nsf_h2_pad</name>
         <ipv6-address>2001:DB8:123::200</ipv6-address>
         <auth-protocol>ikev2</auth-protocol>
         <peer-authentication>
           <auth-method>digital-signature</auth-method>
           <digital-signature>
             <!-- RSA Digital Signature -->
             <ds-algorithm>1</ds-algorithm>
             <cert-data>base64encodedvalue==</cert-data>
             <ca-data>base64encodedvalue==</ca-data>
           </digital-signature>
         </peer-authentication>
       </pad-entry>
     </pad>
     <conn-entry>
        <name>nsf_h1-nsf_h2</name>
        <autostartup>start</autostartup>
        <version>ikev2</version>
        <initial-contact>false</initial-contact>
        <fragmentation>true</fragmentation>
        <ike-sa-lifetime-soft>
           <rekey-time>60</rekey-time>
           <reauth-time>120</reauth-time>
        </ike-sa-lifetime-soft>
        <ike-sa-lifetime-hard>
           <over-time>3600</over-time>
        </ike-sa-lifetime-hard>
        <authalg>7</authalg>
        <!--AUTH_HMAC_SHA1_160-->
        <encalg>3</encalg>
        <!--ENCR_3DES -->
        <dh-group>18</dh-group>
        <!--8192-bit MODP Group-->
        <half-open-ike-sa-timer>30</half-open-ike-sa-timer>
        <half-open-ike-sa-cookie-threshold>
           15
        </half-open-ike-sa-cookie-threshold>
        <local>
            <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
        </local>
        <remote>
            <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
        </remote>
        <spd>
          <spd-entry>
             <name>nsf_h1-nsf_h2</name>
             <ipsec-policy-config>
               <anti-replay-window>32</anti-replay-window>
               <traffic-selector>
                  <local-subnet>2001:DB8:1::0/64</local-subnet>
                  <remote-subnet>2001:DB8:2::0/64</remote-subnet>
                  <inner-protocol>any</inner-protocol>
                  <local-ports>
                    <start>0</start>
                    <end>0</end>
                  </local-ports>
                  <remote-ports>
                    <start>0</start>
                    <end>0</end>
                  </remote-ports>
               </traffic-selector>
               <processing-info>
                  <action>protect</action>
                  <ipsec-sa-cfg>
                     <pfp-flag>false</pfp-flag>
                     <ext-seq-num>true</ext-seq-num>
                     <seq-overflow>false</seq-overflow>
                     <stateful-frag-check>false</stateful-frag-check>
                     <mode>tunnel</mode>
                     <protocol-parameters>esp</protocol-parameters>
                     <esp-algorithms>
                        <!-- AUTH_HMAC_SHA1_96 -->
                        <integrity>2</integrity>
                        <!-- ENCR_AES_CBC -->
                        <encryption>12</encryption>
                        <tfc-pad>false</tfc-pad>
                     </esp-algorithms>
                     <tunnel>
                        <local>2001:DB8:123::100</local>
                        <remote>2001:DB8:123::200</remote>
                        <df-bit>clear</df-bit>
                        <bypass-dscp>true</bypass-dscp>
                        <ecn>false</ecn>
                    </tunnel>
                  </ipsec-sa-cfg>
               </processing-info>
             </ipsec-policy-config>
          </spd-entry>
        </spd>
        <child-sa-info>
           <!--8192-bit MODP Group -->
           <pfs-groups>18</pfs-groups>
           <child-sa-lifetime-soft>
              <bytes>1000000</bytes>
              <packets>1000</packets>
              <time>30</time>
              <idle>60</idle>
              <action>replace</action>
           </child-sa-lifetime-soft>
           <child-sa-lifetime-hard>
              <bytes>2000000</bytes>
              <packets>2000</packets>
              <time>60</time>
              <idle>120</idle>
           </child-sa-lifetime-hard>
        </child-sa-info>
      </conn-entry>
   </ipsec-ike>

Appendix E.  Example of IKE-less case, transport mode (host-to-host).

   This example shows case when a XML configuration file sent by the Security
   Controller data packet
   needs to establish be protected in the path between the NSF A and NSF B:

   1.  The I2NSF User defines a IPsec Security association general flow-based protection policy
       (e.g. protect data traffic between two NSF A and B).  The I2NSF
       Controller looks for the NSFs involved (NSF A and NSF B).

   2.  The I2NSF Controller generates IKEv2 credentials for them and
       translates the policies into SPD and PAD entries.

   3.  The I2NSF Controller inserts an IKEv2 configuration that includes
       the SPD and PAD entries in transport mode (host-to-host) both NSF A and NSF B.  If some of
       operations with ESP.

                             Security NSF A and NSF B fail the I2NSF Controller
                                       |
                        /---- Southbound interface -----\
                       /                                 \
                      /                                   \
                     /                                     \
                    /                                       \
                 nsf_h1                                    nsf_h2
                 (:100)===== IPsec_ESP_Transport_mode =====(:200)
                               (2001:DB8:123:/64)

                 Figure 8: will
       stop the process and perform a rollback operation by deleting any
       IKEv2, SPD and PAD configuration that had been successfully
       installed in NSF A or B.

   If the previous steps are successful, the flow is protected by means
   of the IPsec SA established with IKEv2 between NSF A and NSF B.

G.1.2.  IKE-less case, transport mode.

   <ipsec-ikeless
     xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <spd>
       <spd-entry>
           <name>
              in/trans/2001:DB8:123::200/2001:DB8:123::100
           </name>
           <direction>inbound</direction>
           <reqid>1</reqid>
           <ipsec-policy-config>
              <traffic-selector>
                <local-subnet>2001:DB8:123::200/128</local-subnet>
                <remote-subnet>2001:DB8:123::100/128</remote-subnet>
                <inner-protocol>any</inner-protocol>
                   <local-ports>
                      <start>0</start>
                      <end>0</end>
                   </local-ports>
                   <remote-ports>
                      <start>0</start>
                      <end>0</end>
                    </remote-ports>
              </traffic-selector>
              <processing-info>
                 <action>protect</action>
                 <ipsec-sa-cfg>
                   <ext-seq-num>true</ext-seq-num>
                   <seq-overflow>true</seq-overflow>
                   <mode>transport</mode>
                   <protocol-parameters>esp</protocol-parameters>
                   <esp-algorithms>
                      <!--AUTH_HMAC_SHA1_96-->
                      <integrity>2</integrity>
                      <!--ENCR_AES_CBC -->
                      <encryption>12</encryption>
                   </esp-algorithms>
                 </ipsec-sa-cfg>
               </processing-info>
             </ipsec-policy-config>
           </spd-entry>
           <spd-entry>
             <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
             <direction>outbound</direction>
             <reqid>1</reqid>
             <ipsec-policy-config>
               <traffic-selector>
                 <local-subnet>2001:DB8:123::100/128</local-subnet>
                 <remote-subnet>2001:DB8:123::200/128</remote-subnet>
                 <inner-protocol>any</inner-protocol>
                 <local-ports>
                   <start>0</start>
                   <end>0</end>
                 </local-ports>
                 <remote-ports>
                   <start>0</start>
                   <end>0</end>
                 </remote-ports>
               </traffic-selector>
               <processing-info>
                 <action>protect</action>
                 <ipsec-sa-cfg>
                   <ext-seq-num>true</ext-seq-num>
                   <seq-overflow>true</seq-overflow>
                   <mode>transport</mode>
                   <protocol-parameters>esp</protocol-parameters>
                   <esp-algorithms>
                     <!-- AUTH_HMAC_SHA1_96 -->
                     <integrity>2</integrity>
                     <!-- ENCR_AES_CBC -->
                     <encryption>12</encryption>
                   </esp-algorithms>
                  </ipsec-sa-cfg>
                </processing-info>
              </ipsec-policy-config>
           </spd-entry>

        </spd>
        <sad>
          <sad-entry>
            <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
            <reqid>1</reqid>
            <ipsec-sa-config>
               <spi>34501</spi>
               <ext-seq-num>true</ext-seq-num>
               <seq-number-counter>100</seq-number-counter>
               <seq-overflow>true</seq-overflow>
               <anti-replay-window>32</anti-replay-window>
               <traffic-selector>
                 <local-subnet>2001:DB8:123::100/128</local-subnet>
                 <remote-subnet>2001:DB8:123::200/128</remote-subnet>
                    <inner-protocol>any</inner-protocol>
                    <local-ports>
                       <start>0</start>
                       <end>0</end>
                    </local-ports>
                    <remote-ports>
                       <start>0</start>
                       <end>0</end>
                    </remote-ports>
                </traffic-selector>
                <protocol-parameters>esp</protocol-parameters>
                <mode>transport</mode>
                <esp-sa>
                  <encryption>
                     <!-- //ENCR_AES_CBC -->
                     <encryption-algorithm>12</encryption-algorithm>
                     <key>01:23:45:67:89:AB:CE:DF</key>
                     <iv>01:23:45:67:89:AB:CE:DF</iv>
                  </encryption>
                  <integrity>
                     <!-- //AUTH_HMAC_SHA1_96 -->
                     <integrity-algorithm>2</integrity-algorithm>
                     <key>01:23:45:67:89:AB:CE:DF</key>
                  </integrity>
                </esp-sa>
            </ipsec-sa-config>
          </sad-entry>
          <sad-entry>
             <name>in/trans/2001:DB8:123::200/2001:DB8:123::100</name>
             <reqid>1</reqid>
             <ipsec-sa-config>
                 <spi>34502</spi>
                 <ext-seq-num>true</ext-seq-num>
                 <seq-number-counter>100</seq-number-counter>
                 <seq-overflow>true</seq-overflow>
                 <anti-replay-window>32</anti-replay-window>
                 <traffic-selector>
                    <local-subnet>2001:DB8:123::200/128</local-subnet>
                    <remote-subnet>2001:DB8:123::100/128</remote-subnet>
                    <inner-protocol>any</inner-protocol>
                    <local-ports>
                       <start>0</start>
                       <end>0</end>
                    </local-ports>
                    <remote-ports>
                       <start>0</start>
                       <end>0</end>
                    </remote-ports>
                 </traffic-selector>
                 <protocol-parameters>esp</protocol-parameters>
                 <mode>transport</mode>
                 <esp-sa>
                    <encryption>
                       <!-- //ENCR_AES_CBC -->
                       <encryption-algorithm>12</encryption-algorithm>
                       <key>01:23:45:67:89:AB:CE:DF</key>
                       <iv>01:23:45:67:89:AB:CE:DF</iv>
                    </encryption>
                    <integrity>
                       <!-- //AUTH_HMAC_SHA1_96 -->
                       <integrity-algorithm>2</integrity-algorithm>
                       <key>01:23:45:67:89:AB:CE:DF</key>
                    </integrity>
                  </esp-sa>
                  <sa-lifetime-hard>
                     <bytes>2000000</bytes>
                     <packets>2000</packets>
                     <time>60</time>
                     <idle>120</idle>
                  </sa-lifetime-hard>
                  <sa-lifetime-soft>
                     <bytes>1000000</bytes>
                     <packets>1000</packets>
                     <time>30</time>
                     <idle>60</idle>
                     <action>replace</action>
                  </sa-lifetime-soft>
            </ipsec-sa-config>
          </sad-entry>
       </sad>
   </ipsec-ikeless>

Appendix F.  Examples case

                    +----------------------------------------+
                    | I2NSF User  (IPsec Management System)  |
                    +----------------------------------------+
                              |
                   (1)   Flow-based       I2NSF Consumer-Facing
                      Protection Policy      Interface
                              |
                    +---------|------------------------------+
                    |         |                              |
                    |         |   I2NSF Controller           |
                    |         V                              |
                    |  +--------------+ (2) +--------------+ |
                    |  |Translate into|---->|   NETCONF/   | |
                    |  |IPsec Policies|     |   RESTCONF   | |
                    |  +--------------+     +--------------+ |
                    |                         |     |        |
                    +-------------------------|-----|--------+
                                              |     |
                   I2NSF NSF-Facing Interface |     |
                                              | (3) |
                       |----------------------+     +--|
                       V                               V
              +----------------+             +----------------+
              |     NSF A      |             |     NSF B      |
              | IPsec(SPD/SAD) |             | IPsec(SPD/SAD) |
              +----------------+             +----------------+

      Figure 10: Host-to-host / gateway-to-gateway for IKE-less case.

   Figure 10 describes the application of the IKE-less case when a data
   packet needs to be protected in the path between the NSF A and NSF B:

   1.  The I2NSF User establishes a general Flow-based Protection Policy
       and the I2NSF Controller looks for the involved NSFs.

   2.  The I2NSF Controller translates the flow-based security policies
       into IPsec SPD and SAD entries.

   3.  The I2NSF Controller inserts these entries in both NSF A and NSF
       B IPsec databases (SPD and SAD).  The following text describes
       how this would happen:

       *  The I2NSF Controller chooses two random values as SPIs: for
          example, SPIa1 for NSF A and SPIb1 for NSF B.  These numbers
          MUST NOT be in conflict with any IPsec SA in NSF A or NSF B.
          It also generates fresh cryptographic material for the new
          inbound/outbound IPsec SAs and their parameters.

       *  After that, the I2NSF Controller sends simultaneously the new
          inbound IPsec SA with SPIa1 and new outbound IPsec SA with
          SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and
          new outbound IPsec SA with SPIa1 to B, together with the
          corresponding IPsec policies.

       *  Once the I2NSF Controller receives confirmation from NSF A and
          NSF B, it knows that the IPsec SAs are correctly installed and
          ready.

       Other alternative to this operation is: the I2NSF Controller
       sends first the IPsec policies and new inbound IPsec SAs to A and
       B and once it obtains a successful confirmation of these
       operations from NSF A and NSF B, it proceeds with installing to
       the new outbound IPsec SAs.  Despite this procedure may increase
       the latency to complete the process, no traffic is sent over the
       network until the IPsec SAs are completely operative.  In any
       case other alternatives MAY be possible to implement step 3.

   4.  If some of the operations described above fails (e.g. the NSF A
       reports an error when the I2NSF Controller is trying to install
       the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF
       Controller must perform rollback operations by deleting any new
       inbound or outbound SA and SPD entry that had been successfully
       installed in any of the NSFs (e.g NSF B) and stop the process.
       Note that the I2NSF Controller may retry several times before
       giving up.

   5.  Otherwise, if the steps 1 to 3 are successful, the flow between
       NSF A and NSF B is protected by means of the IPsec SAs
       established by the I2NSF Controller.  It is worth mentioning that
       the I2NSF Controller associates a lifetime to the new IPsec SAs.
       When this lifetime expires, the NSF will send a sadb-expire
       notification to the I2NSF Controller in order to start the
       rekeying process.

   Instead of installing IPsec policies (in the SPD) and IPsec SAs (in
   the SAD) in step 3 (proactive mode), it is also possible that the
   I2NSF Controller only installs the SPD entries in step 3 (reactive
   mode).  In such a case, when a data packet requires to be protected
   with IPsec, the NSF that saw first the data packet will send a sadb-
   acquire notification that informs the I2NSF Controller that needs SAD
   entries with the IPsec SAs to process the data packet.  In such as
   reactive mode, upon reception of the sadb-acquire notification, the
   I2NSF Controller installs the new IPsec SAs in NSF A and B (following
   the procedure previously described in step 3) but without sending any
   IPsec policies, since IPsec policies are already installed in the
   SPD.  Again, if some of the operations installing the new inbound/
   outbound IPsec SAs fail, the I2NSF Controller stops the process and
   performs a rollback operation by deleting any new inbound/outbound
   SAs that had been successfully installed.

G.2.  Example of the rekeying process in IKE-less case

   To explain an example of the rekeying process between two IPsec NSFs
   A and B, let assume that SPIa1 identifies the inbound IPsec SA in A,
   and SPIb1 the inbound IPsec SA in B.  The rekeying process will take
   the following steps:

   1.  The I2NSF Controller chooses two random values as SPI for the new
       inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
       These numbers MUST NOT be in conflict with any IPsec SA in A or
       B.  Then, the I2NSF Controller creates an inbound IPsec SA with
       SPIa2 in A and another inbound IPsec SA in B with SPIb2.  It can
       send this information simultaneously to A and B.

   2.  Once the I2NSF Controller receives confirmation from A and B, the
       controller knows that the inbound IPsec SAs are correctly
       installed.  Then it proceeds to send in parallel to A and B, the
       outbound IPsec SAs: the outbound IPsec SA to A with SPIb2, and
       the outbound IPsec SA to B with SPIa2.  At this point the new
       IPsec SAs are ready.

   3.  Once the I2NSF Controller receives confirmation from A and B that
       the outbound IPsec SAs have been installed, the I2NSF Controller,
       in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and
       outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1).

   If some of notifications.

   Below we show the operations in step 1 fail (e.g. the NSF A reports an
   error when the I2NSF Controller is trying to install a new inbound
   IPsec SA) the I2NSF Controller must perform rollback operations by
   removing any new inbound SA that had been successfully installed
   during step 1.

   If step 1 is successful but some of the operations in step 2 fails
   (e.g. the NSF A reports an error when the I2NSF Controller is trying
   to install the new outbound IPsec SA), the I2NSF Controller must
   perform a rollback operation by deleting any new outbound SA that had
   been successfully installed during step 2 and by deleting the inbound
   SAs created in step 1.

   If the steps 1 an 2 are successful and the step 3 fails, the I2NSF
   Controller will avoid any rollback of the operations carried out in
   step 1 and step 2 since new and valid IPsec SAs were created and are
   functional.  The I2NSF Controller may reattempt to remove the old
   inbound and outbound SAs in NSF A and NSF B several XML files that represent different types times until it
   receives a success or it gives up.  In the last case, the old IPsec
   SAs will be removed when their corresponding hard lifetime is
   reached.

G.3.  Example of
   notifications defined managing NSF state loss in IKE-less case

   In the IKE-less YANG model, which are sent by case, if the I2NSF Controller detects that a NSF to has
   lost the Security Controller. IPsec state, it could follow the next steps:

   1.  The notifications happen I2NSF Controller SHOULD delete the old IPsec SAs on the non-
       failed nodes, established with the failed node.  This prevents
       the non-failed nodes from leaking plaintext.

   2.  If the affected node restarts, the I2NSF Controller configures
       the new inbound IPsec SAs between the affected node and all the
       nodes it was talking to.

   3.  After these inbound IPsec SAs have been established, the I2NSF
       Controller configures the outbound IPsec SAs in parallel.

   Step 2 and step 3 can be performed at the
   IKE-less case.

   <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
   <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
   </ipsec-sa-name>
       <soft-lifetime-expire>true</soft-lifetime-expire>
          <lifetime-current>
             <bytes>1000000</bytes>
             <packets>1000</packets>
             <time>30</time>
             <idle>60</idle>
          </lifetime-current>
   </sadb-expire>

              Figure 9: Example of sadb-expire notification.

   <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
       <ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
       </ipsec-policy-name>
       <traffic-selector>
           <local-subnet>2001:DB8:123::200/128</local-subnet>
           <remote-subnet>2001:DB8:123::100/128</remote-subnet>
           <inner-protocol>any</inner-protocol>
            <local-ports>
                 <start>0</start>
                 <end>0</end>
            </local-ports>
            <remote-ports>
                 <start>0</start>
                 <end>0</end>
            </remote-ports>
       </traffic-selector>
   </sadb-acquire>

             Figure 10: Example of sadb-acquire notification.

   <sadb-seq-overflow
       xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
         <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
         </ipsec-sa-name>
   </sadb-seq-overflow>

           Figure 11: Example same time at the cost of sadb-seq-overflow notification.

   <sadb-bad-spi
            xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
           <spi>666</spi>
   </sadb-bad-spi>

             Figure 12: Example a
   potential packet loss.  If this is not critic then it is an
   optimization since the number of sadb-bad-spi notification. exchanges between I2NSF Controller
   and NSFs is lower.

Authors' Addresses

   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 01
   EMail: rafa@um.es
   Gabriel Lopez-Millan
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 04
   EMail: gabilm@um.es

   Fernando Pereniguez-Garcia
   University Defense Center
   Spanish Air Force Academy, MDE-UPCT
   San Javier (Murcia)  30720
   Spain

   Phone: +34 968 18 99 46
   EMail: fernando.pereniguez@cud.upct.es