I2NSF                                                     R. Marin-Lopez
Internet-Draft                                           G. Lopez-Millan
Intended status: Standards Track                    University of Murcia
Expires: September 12, 2019 January 8, 2020                            F. Pereniguez-Garcia
                                               University Defense Center
                                                          March 11,
                                                            July 7, 2019

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

Abstract

   This document describes how providing IPsec-based flow protection by
   means of a Software-Defined Network (SDN) controller (aka.  Security
   Controller) and establishes the requirements to support this service.
   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 and monitoring of IPsec
   information from a Security Controller to one or several flow-based
   Network Security Function (NSF).  The NSFs implement IPsec to protect
   data traffic between network resources with IPsec. resources.

   The document focuses in on the NSF Facing Interface by providing models
   for Configuration configuration and State state data model required to allow the Security
   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
   to establish security associations 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 September 12, 2019. January 8, 2020.

Copyright Notice

   Copyright (c) 2019 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
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   4.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  SDN-based IPsec management description  . . . . . . . . . . .   6
     5.1.  IKE case: IKE/IPsec in the NSF  . . . . . . . . . . . . .   6
       5.1.1.  Interface Requirements for IKE case . . . . . . . . .   7
     5.2.  IKE-less case: IPsec (no IKEv2) in the NSF NSF. . . . . . . .   8   7
       5.2.1.  Interface Requirements for IKE-less case  . . . . . .   8
     5.3.  IKE case vs IKE-less case . . . . . . . . . . . . . . . .   9
       5.3.1.  Rekeying process process. . . . . . . . . . . . . . . . . . .  10
       5.3.2.  NSF state loss loss. . . . . . . . . . . . . . . . . . . .  11
       5.3.3.  NAT Traversal . . . . . . . . . . . . . . . . . . . .  12
       5.3.4.  NSF Discovery . . . . . . . . . . . . . . . . . . . .  12
   6.  YANG configuration data models  . . . . . . . . . . . . . . .  12  13
     6.1.  IKE case model  . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  IKE-less case model . . . . . . . . . . . . . . . . . . .  16
   7.  Use cases examples  . . . . . . . . . . . . . . . . . . . . .  21  20
     7.1.  Host-to-host or gateway-to-gateway under the same
           controller  . . . .
           Security Controller . . . . . . . . . . . . . . . . . . .  21  20
     7.2.  Host-to-host or gateway-to-gateway under different
           security controllers
           Security Controllers  . . . . . . . . . . . . . . . . . .  23  22
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
     8.1.
     9.1.  IKE case  . . . . . . . . . . . . . . . . . . . . . . . .  26
     8.2.  25
     9.2.  IKE-less case . . . . . . . . . . . . . . . . . . . . . .  26
   9.
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  27
   10.  26
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     10.1.
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     10.2.
     11.2.  Informative References . . . . . . . . . . . . . . . . .  28  27
   Appendix A.  Appendix A: Common YANG model for IKE and IKEless IKE-less
                cases  . . . . . . . . . . . . . . . . . . . . . . .  31  30
   Appendix B.  Appendix B: YANG model for IKE case  . . . . . . . .  37  43
   Appendix C.  Appendix C: YANG model for IKE-less case . . . . . .  43  62
   Appendix D.  Example of IKE case, tunnel mode (gateway-to-
                gateway) with X.509 certificate authentication.  . .  72
   Appendix E.  Example of IKE-less case, transport mode (host-to-
                host). . . . . . . . . . . . . . . . . . . . . . . .  75
   Appendix F.  Examples of notifications. . . . . . . . . . . . . .  79
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  49  81

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, namely SDN
   controller.
   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].
   [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].

   Recently, several network scenarios are considering a centralized way
   of managing different security aspects.  For example, Software-
   Defined WANs (SD-WAN) advocates (SD-WAN), an SDN extension providing a software
   abstraction to manage create secure network overlays over traditional WAN
   and branch networks.  SD-WAN is based on IPsec SAs as underlying security
   protocol and aims to provide flexible, automated, fast deployment and
   on-demand security network services such as IPsec SA management from
   a centralized point.

   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 becomes more relevant.
   Thus, the SDN-based service described in this document will
   autonomously deal with IPsec SAs management following a the SDN
   paradigm.

   An example of usage can be

   IPsec architecture [RFC4301] defines clear separation between the notion of Software Defined WAN (SD-
   WAN), SDN extension providing a software abstraction
   processing to create secure
   network overlays over traditional WAN and branch networks.  SD-WAN is
   based on IPsec as underlying security protocol and aims to provide
   flexible, automated, fast deployment and on-demand security network
   services.

   IPsec architecture [RFC4301] defines a clear separation between the
   processing to provide provide security services to IP packets and the key
   management procedures to establish the IPsec security associations. Security Associations.
   In this document, we define a service where the key management
   procedures can be carried by an external and centralized entity: the
   Security Controller.

   First, this document exposes the requirements to support the
   protection of data flows using IPsec [RFC4301].  We have considered
   two general cases:

   1)  IKE case.  The Network Security Function (NSF) implements the
       Internet Key Exchange (IKE) protocol and the IPsec databases: the
       Security Policy Database (SPD), the Security Association Database
       (SAD) and the Peer Authorization Database (PAD).  The Security
       Controller is in charge of provisioning the NSF with the required
       information to IKE, the SPD and the PAD.

   2)  IKE-less case.  The NSF only implements the IPsec databases (no
       IKE implementation).  The Security 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 controller. Security Controller.

   In both cases, an interface/protocol is required to carry out this
   provisioning in a secure manner between the Security Controller and
   the NSF.  In particular, IKE case requires the provision of SPD and
   PAD entries and entries, the IKE credential and information related with the IKE
   negotiation (e.g.  IKE_SA_INIT), and  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] [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 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].  The
   analysis of the host-to-gateway (roadwarrior) scenario is out of
   scope of this document.  In these
   cases, host or 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.

   NOTE: This  The analysis of the host-to-gateway
   (roadwarrior) scenario is out of scope of this document.

   Finally, this work pays attention to the challenge "Lack of Mechanism
   for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the
   particular case of the establishment and management of IPsec SAs.  In
   fact, this
   fact,this I-D could be considered as a proper use case for this
   particular challenge in [RFC8192].

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD 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],
   [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 following terms are defined below:

   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 in a dynamic and scalable manner [ITU-T.Y.3300].

   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.  A Controller is a management component  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.

   o  Flow-based NSF.  A NSF that inspects network flows according to a
      set of policies intended for enforcing security properties.  The
      NSFs considered in this document falls fall into this classification.

   o  Flow-based Protection Policy.  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 flow.

   o  Internet Key Exchange (IKE) v2 v2.  Protocol to establish IPsec
      Security Associations (SAs).  It requires information about the
      required authentication method (i.e. raw RSA/ECDSA keys or X.509
      certificates), DH Diffie-Hellman (DH) groups, modes IPsec SAs parameters
      and algorithms for IKE SA negotiation, etc.

   o  Security Policy Database (SPD).  It includes information about
      IPsec policies direction (in, out), local and remote addresses, addresses
      (traffic selectors information), inbound and outboud IPsec SAs,
      etc.

   o  Security Associations Database (SAD).  It includes information
      about IPsec SAs, 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 such as IKE
      or protocol.  It is
      used when the SDN-based solution described in this document. 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: 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 SPD and PAD entries (deriving 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.), and
   applying other IKE configuration parameters (e.g.  IKE_SA_INIT algorithms)  cryptographic
   algorithms for establishing an IKE SA) to the NSF for the IKE
   negotiation.

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

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

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

5.1.1.  Interface Requirements for IKE case

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

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

   o  A YANG data model PAD configuration data, and
      for IKE state data for IKE, PAD, SPD and SAD (NOTE:
      the SAD entries are created in runtime by IKEv2.) data.

   o  In scenarios where multiple controllers 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
      IPsec-related information.  For example, if two gateways need to
      establish an IPsec SA and both are under the control of two
      different controllers controllers, then both Security Controllers need to
      exchange information to properly configure their own gateways. NSFs.  That
      is, the may need to agree on whether IKEv2 authentication will be
      based on raw public keys or keys, pre-shared keys. keys, etc.  In case of using
      pre-shared keys they will have to agree in the PSK.

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

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

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

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

   As shown in Figure 2, applications for flow protection run on the top
   of the Security Controller.  When an administrator enforces flow-
   based protection policies through the Client Facing Interface, the
   Security Controller translates those 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 are
   need to be met:

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

   o  A YANG data model SAD and for
      state data for SPD and 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 be the Security Controllers.

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

   o  IV generation.

   o  prevent  Prevent counter resets for the same key.

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

   o  Rekey of the IPsec SAs based on notification notifications from the NSF (i.e.
      expire).

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

   o  NAT Traversal discovery and management.

   Additionally to these functions, another set of tasks must be
   performed by the Security 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.  IKE case vs IKE-less case

   In principle, IKE case MAY be is easier to deploy than IKE-less case because
   current gateways typically have an IKEv2/IPsec implementation.
   Moreover hosts can install easily an IKE implementation.  As
   downside, the NSF needs more resources to hold IKEv2.  Moreover, the
   IKEv2 implementation needs to implement an internal interface so that
   the I2NSF
   Agent IKE configuration sent by the Security Controller can interact with them. be enforced
   in runtime.

   Alternatively, IKE-less case allows lighter NSFs (no IKEv2
   implementation), which benefits the deployment in constrained NSFs.
   Moreover, IKEv2 does not need to be performed in gateway-to-gateway
   and host-to-host scenarios under the same Security Controller (see
   Section 7.1).  On the contrary, the overload of creating fresh IPsec
   SAs is shifted to the Security Controller since IKEv2 is not in the
   NSF.  As a consequence, this may result in a more complex
   implementation in the controller side.  This overload may create some
   scalability issues when the number of NSFs is high.

   In general, literature around SDN-based network management using a
   centralized SDN controller Security Controller is aware about scalability issues and
   solutions have been already provided (e.g. hierarchical SDN
   controllers; Security
   Controllers; having multiple replicated SDN controllers, Security Controllers, etc).
   In the context of SDN-based IPsec management, one straight way to
   reduce the overhead and the potential scalability issue in the
   Security Controller is to apply the IKE case, case described in this
   document, since the IPsec SAs are managed between NSFs without the
   involvement of the Security Controller at all, except by the initial
   IKE configuration provided by the Security Controller.  Other option with IKE-less is
   to use techniques already seen in SDN world such as, for example,
   hierarchical SDN controllers.  Other
   solutions, such as Controller-
   IKE Controller-IKE
   [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide
   their DH public keys to the Security Controller, so that the Security
   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 re-key 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 8. 9.  The main
   reason is that the Security Controller is not able to observe any NSFs are generating the session keys generated for the IPsec SAs because IKEv2 is in charge
   of negotiating and not the IPsec SAs.
   Security Controller.

5.3.1.  Rekeying process process.

   For IKE case, the rekeying process is carried out by IKEv2, following
   the information defined in the SPD and SAD.  Therefore, connections
   will live unless something different is required by the administrator
   or the Security Controller detects something wrong.

   Traditionally, during a rekey process of the IPSec SA using IKE, a
   bundle of inbound and outbound IPsec SAs is taken into account from
   the perspective of one of the NSFs.  For example, if the inbound
   IPsec SA expires both the inbound and outbound 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 a new IPsec
   SA and remove the old one.  This rekeying process starts when the
   Security Controller receives a sadb_expire sadb-expire notification or it decides
   so, based on lifetime state data obtained from the NSF.

   To explain the rekeying process between two IPsec peers A and B, let
   assume that SPIa1 identifies the inbound IPsec SA in A A, and SPIb1 the
   inbound IPsec SA in B.

   1.  The Security 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 Security 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 that the inbound SA IPsec A are correctly
       installed.  Then it proceeds to send in parallel to A and B B, the
       outbound IPsec SAs: it sends the outbound IPsec SA to A with
       SPIb2 and the outbound IPsec SA to B with SPIa2.  At this point
       the new IPsec SA is SAs are ready.

   3.  Once the Security Controller receives confirmation from A and B, B
       that the outbound IPsec SAs have been installed, the Security
       Controller
       Controller, in parallel, deletes the old IPsec SAs from A
       (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and
       inbound SPIb1) in
       parallel.  It is worth noting that if the IPsec implementation
       can itself detect traffic on the new IPsec SA, and it can delete
       the old IPsec SA itself without instruction from the Security
       Controller, then this step 3 is not required. SPIb1).

5.3.2.  NSF state loss 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 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 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.  It can
   also instruct the affected NSF to send IKEv2 INITIAL_CONTACT.  Finally,
   the Security Controller will instruct the affected NSF to start the
   IKEv2 negotiation with the new configuration.

   In IKE-less case, if the Security Controller detects that a NSF has
   lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs
   of on the non-failed nodes
   nodes, established with the failed node (step 1).  This prevents the
   non-failed nodes from leaking plaintext.  If the
   failed affected node comes
   to live, the Security Controller will configure the new inbound IPsec
   SAs between the failed affected node and all the nodes the
   failed it was talking to
   (step 2).  After these inbound IPsec SAs have been established, the
   Security Controller can configure the outbound IPsec SAs in parallel
   (step 3).

   Nevertheless other more optimized options can be considered (e.g.
   making the IKEv2 configuration permanent between reboots).

5.3.3.  NAT Traversal

   In the IKE case, IKEv2 already owns 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 of for ESP packets ([RFC3948],
   [RFC8229]).  Note that the usage of TRANSPORT IPsec transport mode when NAT is
   required is forbidden MUST NOT be used in this specification.

   On the contrary, the IKE-less case does not have any protocol in the
   NSFs to detect whether they are located behind a NAT or not.
   However, the SDN paradigm generally assumes the Security Controller
   has a view of the network it controls. under its control.  This view is built
   either requesting information to the NSFs under its control, or
   because these NSFs inform to the Security Controller.  Based on this
   information, the Security Controller can 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 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
   [I-D.ietf-opsawg-nat-yang] a data model for NAT management.  The
   Security Controller can use this NETCONF module with a gateway NSF to collect
   NAT information or even configure a NAT. NAT network.  In any case, if
   this NETCONF module is not available in the NSF and the Security
   Controller
   cannot does not have a mechanism to know if whether a host is behind
   a NAT or not, then the IKE case should be the right choice and not
   the IKE-less. IKE-less case.

5.3.4.  NSF Discovery

   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
   Controller.  In this way, when the NSF comes to live and establishes
   a connection to the Security 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 Controller, the Security 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 the IKE-less case, etc.  This discovery process is out of the
   scope of this document.

6.  YANG configuration data models

   In order to support the IKE case and IKE-less case cases we have modelled modeled the
   different parameters and values that must be configured to manage
   IPsec SAs.  Specifically, IKE requires modeling IKEv2, SPD and PAD PAD,
   while 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, in the
   following 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
   [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.) configuration).

module: ietf-ipsec-ike
  +--rw ikev2 ipsec-ike
     +--rw pad
     |  +--rw pad-entry* [pad-entry-id] [name]
     |     +--rw pad-entry-id                   uint64 name                           string
     |     +--rw (identity)? (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)  +--:(dnx509)
     |     |  |  +--rw dnX509? dnx509?                  string
     |     |  +--:(id_key)  +--:(gnx509)
     |     |  |  +--rw id_key? gnx509?                  string
     |     |  +--:(id_null)  +--:(id-key)
     |     |  |  +--rw id_null?                 empty
     | id-key?                  string
     |  +--:(user_fqdn)     |  +--:(id-null)
     |     +--rw user_fqdn?               string     |     +--rw my-identifier                  string id-null?                 empty
     |     +--rw pad-auth-protocol? auth-protocol?                 auth-protocol-type
     |     +--rw auth-method peer-authentication
     |        +--rw auth-m? auth-method?         auth-method-type
     |        +--rw eap-method
     |        |  +--rw eap-type? eap-type    uint8
     |        +--rw pre-shared
     |        |  +--rw secret?   yang:hex-string
     |        +--rw digital-signature
     |           +--rw ds-algorithm?     signature-algorithm-t           uint8
     |           +--rw raw-public-key?   yang:hex-string (public-key)
     |           +--rw key-data?         string           |           +--rw key-file?         string  +--:(raw-public-key)
     |           |           +--rw ca-data*          string  |  +--rw ca-file?          string raw-public-key?   binary
     |           |  +--:(cert-data)
     |           |     +--rw cert-data?        string        ct:x509
     |           +--rw cert-file?        string private-key?            binary
     |           +--rw ca-data*                ct:x509
     |           +--rw crl-data?         string               ct:crl
     |           +--rw crl-file?         string crl-uri?                inet:uri
     |           +--rw oscp-uri?               inet:uri
     +--rw ike-conn-entry* [conn-name] conn-entry* [name]
     |  +--rw conn-name name                                 string
     |  +--rw autostartup                          type-autostartup autostartup?                         autostartup-type
     |  +--rw initial-contact?                     boolean
     |  +--rw version?                             enumeration                             auth-protocol-type
     |  +--rw ike-fragmentation? fragmentation?                       boolean
     |  +--rw ike-sa-lifetime-hard
     |  |  +--rw time?      yang:timestamp
     |  |  +--rw idle?      yang:timestamp ike-sa-lifetime-soft
     |  |  +--rw bytes? rekey-time?    uint32
     |  |  +--rw packets? reauth-time?   uint32
     |  +--rw ike-sa-lifetime-soft
     |  |  +--rw time?      yang:timestamp
     |  |  +--rw idle?      yang:timestamp
     |  |  +--rw bytes?     uint32 ike-sa-lifetime-hard
     |  |  +--rw packets? over-time?   uint32
     |  |  +--rw action?    ic:lifetime-action
     |  +--rw ike-sa-authalg*                      ic:integrity-algorithm-t authalg*  ic:integrity-algorithm-type
     |  +--rw ike-sa-encalg*                       ic:encryption-algorithm-t encalg*   ic:encryption-algorithm-type
     |  +--rw dh_group                             uint32 dh-group?                            pfs-group
     |  +--rw half-open-ike-sa-timer?              uint32
     |  +--rw half-open-ike-sa-cookie-threshold?   uint32
     |  +--rw local
     |  |  +--rw local-pad-id?   uint64 local-pad-entry-name?   string
     |  +--rw remote
     |  |  +--rw remote-pad-id?   uint64 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* [spd-entry-id]
     |  |     +--rw spd-entry-id            uint64
     |  |     +--rw priority?               uint32
     |  |     +--rw anti-replay-window?     uint16
     |  |     +--rw names* [name]
     |  |     |  +--rw name-type?   ipsec-spd-name
     |  |     |     +--rw name                   string
     |  |     +--rw condition
     |  |     |  +--rw traffic-selector-list* [ts-number]
     | ipsec-policy-config
     |  |        +--rw ts-number               uint32
     | anti-replay-window?   uint64
     |  |        +--rw direction?              ipsec-traffic-direction traffic-selector
     |  |        |  +--rw local-subnet? local-subnet      inet:ip-prefix
     |  |        |  +--rw remote-subnet? remote-subnet     inet:ip-prefix
     |  |        |  +--rw upper-layer-protocol*   ipsec-upper-layer-proto 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-operation action?         ipsec-spd-action
     |  |        |  +--rw ipsec-sa-cfg
     |  |        |     +--rw pfp-flag?              boolean
     |  |        |     +--rw extSeqNum? ext-seq-num?           boolean
     |  |        |     +--rw seqOverflow? seq-overflow?          boolean
     |  |        |     +--rw statefulfragCheck? stateful-frag-check?   boolean
     |  |        |     +--rw security-protocol?   ipsec-protocol mode?                  ipsec-mode
     |  |        |     +--rw mode?                ipsec-mode
     |  |     |     +--rw ah-algorithms
     |  |     |     |  +--rw ah-algorithm*   integrity-algorithm-t
     |  |     |     |  +--rw trunc-length?   uint32 protocol-parameters?   ipsec-protocol-parameters
     |  |        |     +--rw esp-algorithms
     |  |        |     |  +--rw authentication*   integrity-algorithm-t integrity*   integrity-algorithm-type
     |  |        |     |  +--rw encryption*       encryption-algorithm-t encryption-algorithm-type
     |  |        |     |  +--rw tfc_pad?          uint32 tfc-pad?      boolean
     |  |        |     +--rw tunnel
     |  |        |        +--rw local? local           inet:ip-address
     |  |        |        +--rw remote? remote          inet:ip-address
     |  |        |        +--rw bypass-df?      boolean df-bit?         enumeration
     |  |        |        +--rw bypass-dscp?    boolean
     |  |        |        +--rw dscp-mapping?   yang:hex-string
     |  |        |        +--rw ecn?            boolean
     |  |        +--rw spd-lifetime-soft
     |  |     |  +--rw time?      yang:timestamp
     |  |     |  +--rw idle?      yang:timestamp
     | spd-mark
     |  |           +--rw bytes? mark?   uint32
     |  |     |           +--rw packets?   uint32 mask?   yang:hex-string
     |  +--rw child-sa-info
     |  |  +--rw action?    lifetime-action pfs-groups*               pfs-group
     |  |  +--rw spd-lifetime-hard child-sa-lifetime-soft
     |  |  |  +--rw time?      yang:timestamp      uint32
     |  |  |  +--rw idle?      yang:timestamp bytes?     uint32
     |  |  |  +--rw bytes? packets?   uint32
     |  |  |  +--rw packets? idle?      uint32
     |  |     +--ro spd-lifetime-current  |  +--rw action?    ic:lifetime-action
     |        +--ro time?      yang:timestamp  |  +--rw child-sa-lifetime-hard
     |        +--ro idle?      yang:timestamp  |     +--rw time?      uint32
     |  |        +--ro     +--rw bytes?     uint32
     |  |        +--ro     +--rw packets?   uint32
     |  +--ro ike-sa-state
     |     +--ro uptime
     |     |  +--ro running?   yang:date-and-time  |     +--rw idle?      uint32
     |  +--ro since?     yang:date-and-time state
     |     +--ro initiator?             boolean
     |     +--ro initiator-ikesa-spi?   uint64   ike-spi
     |     +--ro responder-ikesa-spi?   uint64   ike-spi
     |     +--ro nat-local?             boolean
     |     +--ro nat-remote?            boolean
     |     +--ro nat-any?               boolean 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 rekey-time? current-rekey-time?    uint64
     |     +--ro reauth-time? current-reauth-time?   uint64
     |     +--ro child-sas* []
     |        +--ro spis
     |           +--ro spi-in?    ic:ipsec-spi
     |           +--ro spi-out?   ic:ipsec-spi
     +--ro number-ike-sas
        +--ro total?               uint32               uint64
        +--ro half-open?           uint32           uint64
        +--ro half-open-cookies?   uint32   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

   The

   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].  Unlike
   existing implementations (e.g.  XFRM), it is worth mentioning that
   this model follows [RFC4301] and, consequently,
   [RFC4301], though with some simplications.  For example, each IPsec
   policy (spd-
   entry) consists of (spd-entry) contains one or more traffic selectors. selector, instead a list of
   them.  The reason is that we have observed real kernel
   implementations only admit a traffic selector per IPsec policy.

   The definition of the SAD model has been extracted from the
   specification in section 4.4.2 in [RFC4301].  Note that this model
   not only associates allows to associate an IPsec SA with its corresponding
   policy (spd-
   entry-id) but also indicates through the specific traffic selector that
   caused its establishment.  In other words, each traffic selector of a
   policy (spd-entry) generates a different IPsec SA (sad-entry). but also an identifier
   (reqid).

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

  module: ietf-ipsec-ikeless
    +--rw ietf-ipsec ipsec-ikeless
       +--rw spd
       |  +--rw spd-entry* [spd-entry-id]
       |     +--rw spd-entry-id            uint64
       |     +--rw priority?               uint32
       |     +--rw anti-replay-window?     uint16
       |     +--rw names* [name]
       |     |  +--rw name-type?   ipsec-spd-name
       |     |     +--rw name                   string
       |     +--rw condition
       | direction?             ic:ipsec-traffic-direction
       |     +--rw traffic-selector-list* [ts-number]
       | reqid?                 uint64
       |     +--rw ts-number               uint32 ipsec-policy-config
       |        +--rw anti-replay-window?   uint64
       |        +--rw direction?              ipsec-traffic-direction traffic-selector
       |        |  +--rw local-subnet? local-subnet      inet:ip-prefix
       |        |  +--rw remote-subnet? remote-subnet     inet:ip-prefix
       |        |  +--rw upper-layer-protocol*   ipsec-upper-layer-proto 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-operation action?         ipsec-spd-action
       |        |  +--rw ipsec-sa-cfg
       |        |     +--rw pfp-flag?              boolean
       |        |     +--rw extSeqNum? ext-seq-num?           boolean
       |        |     +--rw seqOverflow? seq-overflow?          boolean
       |        |     +--rw statefulfragCheck? stateful-frag-check?   boolean
       |        |     +--rw security-protocol?   ipsec-protocol
       |     |     +--rw mode?                  ipsec-mode
       |        |     +--rw ah-algorithms
       |     |     |  +--rw ah-algorithm*   integrity-algorithm-t
       |     |     |  +--rw trunc-length?   uint32 protocol-parameters?
       |        |     +--rw esp-algorithms
       |        |     |  +--rw authentication*   integrity-algorithm-t integrity*    integrity-algorithm-type
       |        |     |  +--rw encryption*       encryption-algorithm-t  encryption-algorithm-type
       |        |     |  +--rw tfc_pad?          uint32 tfc-pad?      boolean
       |        |     +--rw tunnel
       |        |        +--rw local? local           inet:ip-address
       |        |        +--rw remote? remote          inet:ip-address
       |        |        +--rw bypass-df?      boolean df-bit?         enumeration
       |        |        +--rw bypass-dscp?    boolean
       |        |        +--rw dscp-mapping?   yang:hex-string
       |        |        +--rw ecn?            boolean
       |        +--rw spd-lifetime-soft
       | spd-mark
       |           +--rw time?      yang:timestamp
       | mark?   uint32
       |           +--rw idle?      yang:timestamp
       |     | mask?   yang:hex-string
       +--rw bytes?     uint32
       |     |  +--rw packets?   uint32
       |     | sad
          +--rw action?    lifetime-action
       | sad-entry* [name]
             +--rw spd-lifetime-hard
       |     | name               string
             +--rw time?      yang:timestamp
       |     | reqid?             uint64
             +--rw idle?      yang:timestamp
       | ipsec-sa-config
             |  +--rw bytes? spi                    uint32
             |     |  +--rw packets?   uint32
       |     +--ro spd-lifetime-current
       |        +--ro time?      yang:timestamp
       |        +--ro idle?      yang:timestamp
       |        +--ro bytes?     uint32 ext-seq-num?           boolean
             |        +--ro packets?   uint32
       +--rw sad
          +--rw sad-entry* [sad-entry-id]
             +--rw sad-entry-id                uint64
             +--rw spi?                        ic:ipsec-spi  +--rw seq-number? seq-number-counter?    uint64
             |  +--rw seq-number-overflow-flag? seq-overflow?          boolean
             |  +--rw anti-replay-window?         uint16    uint32
             |  +--rw spd-entry-id?               uint64 traffic-selector
             |  |  +--rw local-subnet? local-subnet      inet:ip-prefix
             |  |  +--rw remote-subnet? remote-subnet     inet:ip-prefix
             |  |  +--rw upper-layer-protocol*       ipsec-upper-layer-proto 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 security-protocol?          ic:ipsec-protocol protocol-parameters?  ic:ipsec-protocol-parameters
             |  +--rw sad-lifetime-hard mode?                  ic:ipsec-mode
             |  +--rw time?      yang:timestamp esp-sa
             |  |  +--rw idle?      yang:timestamp 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 sad-lifetime-soft idle?      uint32
             |  +--rw time?      yang:timestamp sa-lifetime-soft
             |  |  +--rw idle?      yang:timestamp time?      uint32
             |  |  +--rw bytes?     uint32
             |  |  +--rw packets?   uint32
             |  |  +--rw idle?      uint32
             |  |  +--rw action?    ic:lifetime-action
             +--rw mode?                       ic:ipsec-mode
             +--rw statefulfragCheck?          boolean
             +--rw dscp?                       yang:hex-string
             +--rw path-mtu?                   uint16
             |  +--rw tunnel
             |  |  +--rw local? local           inet:ip-address
             |  |  +--rw remote? remote          inet:ip-address
             |  |  +--rw bypass-df?      boolean 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 sad-lifetime-current
             | ipsec-sa-state
                +--ro time?      yang:timestamp sa-lifetime-current
                |  +--ro idle?      yang:timestamp time?      uint32
                |  +--ro bytes?     uint32
                |  +--ro packets?   uint32
             +--ro stats
                |  +--ro replay-window? idle?      uint32
             |
                +--ro replay?          uint32
             | replay-stats
                   +--ro replay-window?        uint64
                   +--ro packet-dropped?       uint64
                   +--ro failed?               uint32
                   +--ro replay_state seq-number-counter?   uint64

    notifications:
      +---n sadb-acquire
      |  +--ro seq?      uint32 ipsec-policy-name    string
      |  +--ro oseq?     uint32 traffic-selector
      |     +--ro bitmap?   uint32
             +--ro replay_state_esn local-subnet      inet:ip-prefix
      |     +--ro bmp-len?         uint32 remote-subnet     inet:ip-prefix
      |     +--ro oseq?            uint32 inner-protocol?   ipsec-inner-protocol
      |     +--ro oseq-hi?         uint32 local-ports* [start end]
      |     |  +--ro seq-hi?          uint32 start    inet:port-number
      |     |  +--ro replay-window?   uint32 end      inet:port-number
      |     +--ro bmp*             uint32
             +--rw ah-sa remote-ports* [start end]
      |  +--rw integrity        +--ro start    inet:port-number
      |     +--rw integrity-algorithm?   ic:integrity-algorithm-t        +--ro end      inet:port-number
      +---n sadb-expire
      |     +--rw key?  +--ro ipsec-sa-name           string
             +--rw esp-sa
                +--rw encryption
                |  +--rw encryption-algorithm?   ic:encryption-algorithm-t
                |  +--rw key?                    yang:hex-string
                |  +--rw iv?                     yang:hex-string
                +--rw integrity
      |  +--rw integrity-algorithm?   ic:integrity-algorithm-t
                |  +--rw key?                   yang:hex-string
                +--rw combined-enc-intr?  +--ro soft-lifetime-expire?   boolean

    notifications:
      +---n spdb_expire
      |  +--ro index?   uint64
      +---n sadb_acquire
      |  +--ro base-list* [version]
      |  |  +--ro version       string
      |  |  +--ro msg_type?     sadb-msg-type
      |  |  +--ro msg_satype?   sadb-msg-satype
      |  |  +--ro msg_seq?      uint32
      |  +--ro local-subnet?           inet:ip-prefix
      |  +--ro remote-subnet?          inet:ip-prefix
      |  +--ro upper-layer-protocol*   ipsec-upper-layer-proto
      |  +--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 base-list* [version]
      |  |  +--ro version       string
      |  |  +--ro msg_type?     sadb-msg-type
      |  |  +--ro msg_satype?   sadb-msg-satype
      |  |  +--ro msg_seq?      uint32
      |  +--ro spi?                        ic:ipsec-spi
      |  +--ro anti-replay-window?         uint16
      |  +--ro encryption-algorithm?       ic:encryption-algorithm-t
      |  +--ro authentication-algorithm?   ic:integrity-algorithm-t
      |  +--ro sad-lifetime-hard
      | lifetime-current
      |     +--ro time?      yang:timestamp
      |  |  +--ro idle?      yang:timestamp
      |  |  +--ro bytes?     uint32
      |  |  +--ro packets?      uint32
      |     +--ro sad-lifetime-soft
      |  |  +--ro time?      yang:timestamp
      |  |  +--ro idle?      yang:timestamp
      |  |  +--ro bytes?     uint32
      |  |     +--ro packets?   uint32
      |     +--ro sad-lifetime-current
      |     +--ro time?      yang:timestamp
      |     +--ro idle?      yang:timestamp
      |     +--ro bytes?      uint32
      +---n sadb-seq-overflow
      |  +--ro packets?   uint32 ipsec-sa-name    string
      +---n sadb_bad-spi sadb-bad-spi
         +--ro state    ic:ipsec-spi 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

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

7.1.  Host-to-host or gateway-to-gateway under the same controller Security
      Controller

                      +----------------------------------------+
                      |           Security Controller          |
                      |                                        |
                   (1)|   +--------------+ (2)+--------------+ |
      Flow-based  ------> |Translate into|--->| South. Prot. | |
      Security. Pol.  |   |IPsec Policies|    |              | |
                      |   +--------------+    +--------------+ |
                      |                          |     |       |
                      |                          |     |       |
                      +--------------------------|-----|-------+
                                                 |     |
                                                 | (3) |
                       |-------------------------+     +---|
                       V                                   V
           +----------------------+         +----------------------+
           |    NSF1              |<=======>|   NSF2               |
           |IKEv2/IPsec(SPD/PAD)  |         |IKEv2/IPsec(SPD/PAD)  |
           +----------------------+  (4)    +----------------------+

        Figure 3: Host-to-host / gateway-to-gateway single controller flow Security
                       Controller for the IKE case.

   Figure 3 describes the case IKE case:

   1.  The administrator defines general flow-based security policies.
       The Security Controller looks for the NSFs involved (NSF1 and
       NSF2).

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

   3.  The Security Controller inserts an IKEv2 configuration that
       include the SPD and PAD entries in both NSF1 and NSF2.

   4.  The flow is protected with by means of the IPsec SA established with
       IKEv2.

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

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

   In the IKE-less case, flow-based security policies defined by the
   administrator are translated into IPsec SPD entries and inserted into
   the corresponding NSFs.  Besides, fresh SAD entries will be also
   generated by the Security Controller and enforced in the NSFs.  In
   this case, the controller Security Controller does not run any IKEv2 implementation,
   implementation (neither the NSFs), and it provides the cryptographic
   material for the IPsec SAs.  These keys will be also distributed
   securely through the southbound interface.  Note that this is
   possible because both NSFs are managed by the same
   controller. Security
   Controller.

   Figure 4 describes the IKE-less, IKE-less case, when a data packet needs to be
   protected in the path between the NSF1 and NSF2:

   1.  The administrator establishes the flow-based security policies.
       The policies,
       and the Security Controller looks for the involved NSFs.

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

   3.  The Security Controller inserts the these entries in both NSF1 and
       NSF2 IPsec databases.  It associates a lifetime to the IPsec SAs.
       When this lifetime expires, the NSF will send a sadb_expire sadb-expire
       notification to the Security Controller in order to start the
       rekeying process.

   4.  The flow is protected with the IPsec SA established by the
       Security Controller.

   Both NSFs could be two hosts that exchange traffic and require to
   establish an end-to-end security association to protect their
   communications (host-to-host) or two gateways (gateway-to-gateway),
   for example, within an enterprise

   It is also possible that needs to protect the traffic
   between, for example, Security Controller only installs the networks of two branch offices.

   Applicability of these configurations appear
   SPD entries in current and new
   networking scenarios.  For step 2.  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 Security
   Controller that SAD entries with the IPsec SAs required to process
   the data packet needs to be installed in the NSFs.

   Both NSFs could be two hosts that exchange traffic and require to
   establish an end-to-end security association to protect their
   communications (host-to-host) or two gateways (gateway-to-gateway),
   for example, within an enterprise that needs to protect the 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 to provide secure channels between virtual instances (host-
   to-host) and providing VPN solutions for virtualized networks
   (gateway-to-gateway).

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

   1.  It allows to create IPsec SAs among two NSFs, with based only on the
       application of more general flow-based security policies Flow-based Security Policies at the
       application layer.  Thus, administrators can manage all security
       associations in a centralized point with an abstracted view of
       the network.

   2.  All NSFs  Any NSF deployed after the application of in the new policies are
       NOT manually configured, system does not need manual
       configuration, therefore allowing its deployment in an automated
       manner.

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

   It is also possible that two NSFs (i.e.  NSF1 and NSF2) are under the
   control of two different Security Controllers.  This may happen, for
   example, when two organizations, namely Enterprise A and Enterprise
   B, have their headquarters interconnected through a WAN connection
   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
          +----------------------+          +----------------------+
              +--------------------+          +--------------------+
              |    NSF1            |<========>|   NSF2             |
          |IKEv2/IPsec(SPD/PAD)  |          |IKEv2/IPsec(SPD/PAD)  |
          +----------------------+
              |IKEv2/IPsec(SPD/PAD)|          |IKEv2/IPsec(SPD/PAD)|
              +--------------------+  (5)     +----------------------+     +--------------------+

         Figure 5: Different security controllers Security Controllers in the IKE case case.

   Figure 5 describes IKE case when two security controllers Security Controllers are
   involved in the process.

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

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

   3.  The Security Controller A realizes that protection is required
       between the NSF1 and NSF2, but the NSF2 is under the control of
       another Security Controller (Security Controller B), so it starts
       negotiations with the other controller to agree on the IPsec SPD
       policies and IKEv2 credentials for their respective NSFs.  NOTE:
       This may require extensions in the East/West interface.

   4.  Then, both Security Controllers enforce the IKEv2 credentials and credentials,
       related parameters and the SPD and PAD entries in their
       respective NSFs.

   5.  The flow is protected with the IPsec SAs established with IKEv2
       between both NSFs.

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

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

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

   1.  The A's administrator establishes general Flow Protection
       Policies 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 NSF1 and
       NSF2 MUST be protected.  Nevertheless, the controller it notices that NSF2 is
       under the control of another Security Controller, Controller B, so it starts
       negotiations with the other controller to agree on the IPsec SPD
       and SAD entries that define the IPsec SAs.  NOTE: It would worth
       evaluating IKEv2 as the protocol for the East/West interface in
       this case.

   4.  Once the Security Controllers have agreed on the key material and
       the details of the IPsec SAs, they both enforce this information
       into their respective NSFs.

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

8.  IANA Considerations

   TBD

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 and the NSFs to
   protect of the critical information (cryptographic keys,
   configuration parameter, etc...) exchanged between these entities.
   For example, if when NETCONF is used as southbound protocol between the
   Security Controller and the NSFs, it is defined that TLS or SSH
   security association MUST be established between both entities.

   On the other hand, we have divided this
   section in two parts to analyze different security considerations for
   both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less
   case).  In general, the Security Controller, as typically in the SDN
   paradigm, if encryption is a target mandatory for different type all traffic of attacks.  As a
   consequence, the Security Controller is a key entity in
   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 in order to
   analyze different security considerations for both cases: NSF with
   IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case).  In general,
   the Security Controller, as typically in the SDN paradigm, is a
   target for different type of attacks.  Thus, the Security Controller
   is a key entity in the infrastructure and MUST be protected
   accordingly.  In particular,
   according to this document, the Security Controller will handle
   cryptographic material so that the attacker may try to access this
   information.  Although,  Although we can assume this attack will not likely to
   happen due to the assumed security measurements to protect the
   Security Controller, it deserves some analysis in the hypothetical
   case the attack occurs.  The impact is different depending on the IKE
   case or IKE-less case.

8.1.

9.1.  IKE case

   In IKE case, the Security Controller sends IKE credentials (PSK,
   public/private keys, certificates, etc...) etc.) to the NSFs using the
   security association between Security Controller and NSFs.  The
   general recommendation is that the Security Controller SHOULD NEVER MUST NOT store
   the IKE credentials after distributing them.  Moreover  Moreover, the NSFs MUST
   NOT allow the reading of these values once they have been applied by
   the Security Controller (i.e. write only operations).  One option is
   to return always the same value (all 0s). (i.e. all 0s) if a read operation is
   carried out.  If the attacker has access to the Security Controller
   during the period of time that key material is generated, it may might
   have access to these values. the key material.  Since these values are used during
   NSF authentication in IKEv2, it may impersonate the affected NSFs.
   Several recommendations are important.  If PSK authentication is used
   in IKEv2, the Security Controller SHOULD MUST remove the PSK immediately
   after generating and distributing it.  Moreover, the PSK MUST have a
   proper length (e.g.
   minimu,  minimum 128 bit length) and strength.  If raw public  When
   public/private keys are used, the Security Controller SHOULD MAY generate
   both public key and private key.  In such a case, the Security
   Controller MUST remove the associated private key immediately after generating and
   distributing them to the NSFs.  Alternatively, the NSF could generate
   the private key and export only the public key to the Security
   Controller.  If certificates are used, the NSF may MAY generate the
   private key and exports the public key for certification to the
   Security Controller.

8.2.  How the NSF generates these cryptographic
   material (public key/private keys) and export 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 controller Security Controller sends the IPsec SA
   information to the NSF's SAD that includes the private session keys
   required for integrity and encryption (when
   ESP is used).  That key material are symmetric keys to protect data
   traffic.  The general recommendation encryption.  The general recommendation is
   that the Security Controller
   SHOULD NEVER stores it MUST NOT store the keys after distributing them.  Moreover,
   the NSFs receiving private key material MUST NOT allow the reading of
   these values by any other entity (including the Security Controller
   itself) once they have been applied by the Security Controller (i.e. write only operations). operations) into
   the NSFs.  Nevertheless, if the attacker has access to the Security
   Controller during the period of time that key material is generated,
   it may
   access to obtain these values.  In other words, it may have access to the
   key material used in attacker might be
   able to observe the distributed IPsec SAs traffic and observe decrypt, or even modify and re-
   encrypt the traffic between peers.  In any case, some escenarios with special
   secure environments (e.g. physically isolated data centers) make this
   type of attack difficult.  Moreover, some scenarios such as IoT
   networks with constrained devices, where reducing implementation and
   computation overhead is important, can apply IKE-less case as a
   tradeoff between security and low overhead at the constrained device,
   at the cost of assuming the security impact described above.

9.

10.  Acknowledgements

   Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel,
   Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda
   Dunbar, Carlos J.  Bernardos, Alejandro Perez-Mendez, Alejandro Abad-
   Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable
   comments.

10.

11.  References

10.1.

11.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>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [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>.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface 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>.

   [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>.

10.2.

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
              in progress), March 2019.

   [I-D.ietf-i2nsf-framework]
              Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", draft-ietf-i2nsf-framework-10 (work in
              progress), November 2017.

   [I-D.ietf-i2nsf-problem-and-use-cases]
              Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "I2NSF Problem Statement and Use cases",
              draft-ietf-i2nsf-problem-and-use-cases-16 (work in
              progress), May 2017.

   [I-D.ietf-i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to Network Security Functions (I2NSF)
              Terminology", draft-ietf-i2nsf-terminology-07 draft-ietf-i2nsf-terminology-08 (work in
              progress), January July 2019.

   [I-D.ietf-opsawg-nat-yang]
              Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula,
              S., and Q. Wu, "A YANG Module for Network Address
              Translation (NAT) and Network Prefix Translation (NPT)",
              draft-ietf-opsawg-nat-yang-17 (work in progress),
              September 2018.

   [I-D.jeong-i2nsf-sdn-security-services-05]
              Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee,
              "Software-Defined Networking Based Security Services using
              Interface to Network Security Functions", draft-jeong-
              i2nsf-sdn-security-services-05 (work in progress), July
              2016.

   [I-D.pfkey-spd]
              Sakane, S., "PF_KEY Extensions for IPsec Policy Management
              in KAME Stack", October 2002.

   [I-D.tran-ipsecme-yang]
              Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data
              Model for Internet Protocol Security (IPsec)", draft-tran-
              ipsecme-yang-01 (work 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", July
              2019.

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

   [netopeer]
              CESNET, CESNET., "NETCONF toolset Netopeer", November
              2016.

   [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>.

   [RFC3549]  Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov,
              "Linux Netlink as an IP Services Protocol", RFC 3549,
              DOI 10.17487/RFC3549, July 2003,
              <https://www.rfc-editor.org/info/rfc3549>.

   [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 (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 and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

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

   [strongswan]
              CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based VPN
              Solution", April 2017. July 2019.

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

       <CODE BEGINS> file "ietf-ipsec-common@2019-03-11.yang" "ietf-ipsec-common@2019-07-07.yang"

       module ietf-ipsec-common{ 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; }

                import ietf-crypto-types {
                        prefix ct;
                        reference "draft-ietf-netconf-crypto-types-01: Common YANG Dta Types for Cryptography";
                }

           organization "IETF I2NSF (Interface to Network Security Functions) Working Group";

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

           Author: Rafael Marin Lopez
                Dept. Information and Communications Engineering (DIIC)
                Faculty of Computer Science-University of Murcia
                30100 Murcia - Spain
                Telf: +34868888501
                e-mail: rafa@um.es Marin-Lopez
                   <mailto:rafa@um.es>

           Author: Gabriel Lopez Millan
                Dept. Information and Communications Engineering (DIIC)
                Faculty of Computer Science-University of Murcia
                30100 Murcia - Spain
                Tel: +34 868888504
                email: gabilm@um.es Lopez-Millan
                   <mailto:gabilm@um.es>

           Author: Fernando Pereniguez Garcia
                Department of Sciences and Informatics
                University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
                30720 San Javier - Spain
                Tel: +34 968189946
                email: fernando.pereniguez@cud.upct.es Pereniguez-Garcia
                   <mailto:fernando.pereniguez@cud.upct.es>
           ";

           description
               "Common Data model for the IKE and IKE-less cases
                defined by the SDN-based IPSec configuration."; 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, 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 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-03-11" "2019-07-07" {
               description "Revision"; "Revision 05";
               reference ""; "RFC XXXX: YANG Groupings and typedef
                          for IKE and IKE-less case";
           }

           typedef encryption-algorithm-t encryption-algorithm-type {
               type ct:encryption-algorithm-ref; uint32;
               description "typedef";
                   "The encryption algorithm is specified with a 32-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 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 and Usage
                    Guidance for the Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
           }

           typedef integrity-algorithm-t integrity-algorithm-type {
               type ct:mac-algorithm-ref; uint32;
               description
                                "This typedef enables importing modules to easily define an
                                identityref to
                   "The integrity algorithm is specified with a 32-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 'asymmetric-key-encryption-algorithm'
                                base identity."; Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
           }

           typedef ipsec-mode {
               type enumeration {
                   enum TRANSPORT transport {
                       description "Transport
                           "IPsec transport mode. No NAT Network Address
                            Translation (NAT) support.";
                   }
                   enum TUNNEL tunnel {
                       description "Tunnel mode"; "IPsec tunnel mode.";
                   }
               }
               description
                   "Type definition of IPsec mode"; mode: transport or
                    tunnel.";
               reference
                   "Section 3.2 in RFC 4301.";
           }

           typedef esp-encap {
               type enumeration {
                   enum ESPINTCP espintcp {
                       description
                           "ESP in TCP encapulation.";}
                                enum ESPINTLS { description "ESP in encapsulation.";
                       reference
                           "RFC 8229 - TCP Encapsulation of IKE and
                            IPsec Packets.";
                   }
                   enum espintls {
                       description
                           "ESP in TCP encapsulation using TLS.";} TLS.";
                       reference
                           "RFC 8229 - TCP Encapsulation of IKE and
                            IPsec Packets.";
                   }
                   enum ESPINUDP espinudp {
                       description
                           "ESP in UDP encapsulation. RFC encapsulation.";
                       reference
                           "RFC 3948 ";} - UDP Encapsulation of IPsec ESP
                           Packets.";
                   }
                   enum NONE none {
                       description
                           "NOT ESP encapsulation" ; encapsulation.";
                   }
               }
               description "type defining types
                   "Types of ESP encapsulation";
                }

                grouping encap { /* This encapsulation when Network Address
                    Translation (NAT) is defined by XFRM */
                        description "Encapsulation container";
                        leaf espencap { type esp-encap; description "ESP in TCP, ESP in present between two NSFs.";

               reference
                   "RFC 8229 - TCP Encapsulation of IKE and IPsec
                    Packets and RFC 3948 - UDP or Encapsulation of IPsec
                    ESP in TLS";}
                        leaf sport {type inet:port-number; description "Encapsulation source port";}
                        leaf dport {type inet:port-number; description "Encapsulation destination port"; }
                        leaf-list oaddr {type inet:ip-address; description "Encapsulation Original Address ";} Packets.";
           }

           typedef ipsec-protocol ipsec-protocol-parameters {
               type enumeration {
                   enum ah { description "AH Protocol"; }
                                enum esp { description "ESP Protocol"; }
                        }
                        description "type define of ipsec security protocol"; "IPsec ESP protocol."; }

                typedef ipsec-spi {
                        type uint32 { range "0..max";
               }
               description "SPI";
                   "Only the Encapsulation Security Protocol (ESP) is
                    supported but it could be extended in the future.";
               reference
                   "RFC 4303- IP Encapsulating Security Payload
                   (ESP).";

           }

           typedef lifetime-action {
               type enumeration {
                   enum terminate-clear {description "Terminate {
                       description
                           "Terminates the IPsec SA and allow allows the
                            packets through";} through.";
                   }
                   enum terminate-hold {description "Terminate {
                       description
                           "Terminates the IPsec SA and drop drops the packets";}
                            packets.";
                   }
                   enum replace  {description "Replace  {
                       description
                           "Replaces the IPsec SA with a new one";} one:
                           rekey. ";
                   }
               }
               description "Action when
                   "When the lifetime expiration"; of an IPsec SA expires an action
                    needs to be performed over the IPsec SA that
                    reached the lifetime. There are three posible
                    options: terminate-clear, terminate-hold and
                    replace.";
               reference
                   "Section 4.5 in RFC 4301.";
           }

                /*################## SPD basic groupings ####################*/

           typedef ipsec-traffic-direction {
               type enumeration {
                   enum INBOUND inbound {
                       description "Inbound traffic"; traffic.";
                   }
                   enum OUTBOUND outbound {
                       description "Outbound traffic"; traffic.";
                   }
               }
               description
                   "IPsec traffic direction"; direction is defined in two
                    directions: inbound and outbound. From a NSF
                    perspective inbound means the traffic that enters
                    the NSF and outbound is the traffic that is sent
                    from the NSF.";
               reference
                   "Section 5 in RFC 4301.";
           }

           typedef ipsec-spd-operation ipsec-spd-action {
               type enumeration {
                   enum PROTECT protect {
                       description
                           "PROTECT the traffic with IPsec"; IPsec.";
                   }
                   enum BYPASS bypass {
                       description
                           "BYPASS the traffic"; traffic. The packet is forwarded
                            without IPsec protection.";
                   }
                   enum DISCARD discard {
                       description
                           "DISCARD the traffic"; traffic. The IP packet is
                            discarded.";
                   }
               }
               description
                   "The operation action when traffic matches an IPsec security policy";
                    policy. According to RFC 4301 there are three
                    possible values: BYPASS, PROTECT AND DISCARD";
               reference
                   "Section 4.4.1 in RFC 4301.";
           }

           typedef ipsec-upper-layer-proto ipsec-inner-protocol {
               type union {
                   type uint8;
                   type enumeration {
                       enum TCP any {
                           value 256;
                           description "TCP traffic"; }
                                enum UDP { description "UDP traffic";
                               "Any IP protocol number value.";
                       }
                   }
                                enum SCTP { description "SCTP traffic";}
                                enum DCCP { description "DCCP traffic";}
                                enum ICMP { description "ICMP traffic";}
                                enum IPv6-ICMP { description "IPv6-ICMP traffic";}
                                enum GRE {description "GRE traffic";}
               }
               default any;
               description "Next
                   "IPsec protection can be applied to specific IP
                    traffic and layer proto on top of IP"; 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
                    indicate the protocol number.";
               reference
                   "Section 4.4.1.1 in RFC 4301.
                    IANA Registry - Protocol Numbers.";
           }
                typedef ipsec-spd-name

           grouping encap {
               description
                   "This group of nodes allows to define the type enumeration {
                                enum id_rfc_822_addr of
                    encapsulation in case NAT traversal is
                    required and port information.";
               leaf espencap {
                   type esp-encap;
                   description "Fully qualified user name string.";
                       "ESP in TCP, ESP in UDP or ESP in TLS.";
               }
                                enum id_fqdn
               leaf sport {
                   type inet:port-number;
                   default 4500;
                   description "Fully qualified DNS name.";
                       "Encapsulation source port.";
               }
                                enum id_der_asn1_dn
               leaf dport {
                   type inet:port-number;
                   default 4500;
                   description "X.500 distinguished name.";
                       "Encapsulation destination port.";
               }
                                enum id_key

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

               }
                        description "IPsec SPD name type";
               reference
                   "RFC 3947 and RFC 8229.";
           }

           grouping lifetime {
               description "lifetime current state data";
                   "Different lifetime values limited to an IPsec SA.";
               leaf time {type yang:timestamp; {
                   type uint32;
                   default 0;
                   description
                       "Time in seconds since the element IPsec SA was added.
                        For example, if this value is added";}
                        leaf idle {type yang:timestamp; default 0; description "Time 180 seconds it
                        means the element is IPsec SA expires in idle state";} 180 seconds since
                        it was added. The value 0 implies infinite.";
               }
               leaf bytes {
                   type uint32;
                   default 0;
                   description "Lifetime in
                       "If the IPsec SA processes the number of bytes number";}
                       expressed in this leaf, the IPsec SA expires and
                       should be rekeyed. The value 0 implies
                       infinite.";
               }
               leaf packets {type {
                   type uint32;
                   default 0;
                   description "Lifetime in
                       "If the IPsec SA processes the number of packets number";}
                }

                /*################## SAD
                       expressed in this leaf, the IPsec SA expires and SPD common basic groupings ####################*/

                grouping port-range  {
                        description "Port range grouping";
                        leaf start { type inet:port-number; description "Start Port Number";
                       should be rekeyed. The value 0 implies
                       infinite.";
               }
               leaf end idle {
                   type inet:port-number; uint32;
                   default 0;
                   description "End Port Number"; }
                       "When a NSF stores an IPsec SA, it
                        consumes system resources. In an idle NSF this
                        is a waste of resources. If the IPsec SA is idle
                        during this number of seconds the IPsec SA
                        should be 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
                    expressed in RFC 4301. For example: 1500 (Start
                    Port Number)-1600 (End Port Number). A port range
                    is used in the Traffic Selector.";

               leaf start {
                   type inet:port-number;
                   description
                       "Start port number.";
               }
               leaf end {
                   type inet:port-number;
                   description
                       "End port number.";
               }
               reference "Section 4.4.1.2 in RFC 4301.";
           }

           grouping tunnel-grouping {
               description "Tunnel mode grouping";
                   "The parameters required to define the IP tunnel
                    endpoints when IPsec SA requires tunnel mode. The
                    tunnel is defined by two endpoints: the local IP
                    address and the remote IP address.";

               leaf local{ local {
                   type inet:ip-address;
                   mandatory true;
                   description
                       "Local IP address' tunnel endpoint"; endpoint.";
               }
               leaf remote{ remote {
                   type inet:ip-address;
                   mandatory true;
                   description
                       "Remote IP address' tunnel enpoint"; endpoint.";
               }
               leaf bypass-df df-bit {
                   type boolean; enumeration {
                       enum clear {
                           description
                               "Disable the DF (Don't Fragment) bit
                                from the outer header. This is the
                                default value.";

                       }
                       enum set {
                           description
                               "Enable the DF bit in the outer header.";
                       }
                       enum copy {
                           description
                               "Copy the DF bit to the outer header.";
                       }
                   }
                   default clear;
                   description "Bypass
                       "Allow configuring the DF bit when encapsulating
                        tunnel mode IPsec traffic. RFC 4301 describes
                        three options to handle the DF bit"; bit during
                        tunnel encapsulation: clear, set and copy from
                        the inner IP header.";
                   reference
                       "Section 8.1 in RFC 4301.";
               }
               leaf bypass-dscp {
                   type boolean;
                   default true;
                   description "Bypass DSCP";
                       "If DSCP (Differentiated Services Code Point)
                        values in the inner header have to be used to
                        select one IPsec SA among several that match
                        the traffic selectors for an outbound packet";
                   reference
                       "Section 4.4.2.1. in RFC 4301.";
               }
               leaf dscp-mapping {
                   type yang:hex-string;
                   description
                       "DSCP mapping"; values allowed for packets carried over
                        this IPsec SA.";
                   reference
                       "Section 4.4.2.1. in RFC 4301.";
               }
               leaf ecn {
                   type boolean;
                   default false;
                   description "Bit ECN"; } /* RFC 4301 ASN1 notation.
                       "Explicit Congestion Notification (ECN). If true
                        copy CE bits to inner header.";
                   reference
                       "Section 5.2.1 and Annex C*/ C in RFC 4301.";
               }

           }

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

               leaf local-subnet {
                   type inet:ip-prefix; description
                   mandatory true;
                   description
                       "Local IP address subnet"; subnet.";
               }
               leaf remote-subnet {
                   type inet:ip-prefix;
                   mandatory true;
                   description
                       "Remote IP address subnet"; subnet.";
               }

                        leaf-list upper-layer-protocol
               leaf inner-protocol {
                   type ipsec-upper-layer-proto; ipsec-inner-protocol;
                   default any;
                   description "List of Upper Layer Protocol";}
                       "Inner Protocol that is going to be
                       protected with IPsec.";
               }
               list local-ports {
                   key "start end";
                   uses port-range;
                   description
                       "List of local ports. When the upper-layer-protocol inner
                        protocol is ICMP this 16 bit value respresents represents
                        code and type as mentioned in RFC 4301"; type.";
               }
               list remote-ports {
                   key "start end";
                   uses port-range;
                   description
                       "List of remote ports. When the upper-layer-protocol upper layer
                       protocol is ICMP this 16 bit value respresents represents
                       code and type as mentioned type.";
               }
               reference
                   "Section 4.4.1.2 in RFC 4301";
                        } 4301.";
           }

                /*################## SPD ipsec-policy-grouping ####################*/

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

               leaf spd-entry-id anti-replay-window {
                   type uint64; description "SPD entry id "; }
                        leaf priority {type uint32;
                   default 0; description "Policy priority";}
                        leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }

                        list names {
                                key "name";
                                leaf name-type { type ipsec-spd-name; description "SPD name type."; }
                                leaf name { type string; 32;
                   description "Policy name"; }
                                description "List of policy names";
                       "A 64-bit counter used to determine whether an
                        inbound ESP packet is a replay.";
                   reference
                       "Section 4.4.2.1 in RFC 4301.";
               }
               container condition {
                                description "SPD condition - RFC4301";
                                list traffic-selector-list {
                                        key "ts-number";
                                        leaf ts-number { type uint32; description "Traffic selector number"; }
                                        leaf direction traffic-selector { type ipsec-traffic-direction;
                   description "in/out"; }
                       "Packets are selected for
                        processing actions based on the IP and inner
                        protocol header information, selectors,
                        matched against entries in the SPD.";
                   uses selector-grouping;
                                        ordered-by user;
                                        description "List of traffic selectors";
                                }
                   reference
                       "Section 4.4.4.1 in RFC 4301.";
               }
               container processing-info {
                   description
                       "SPD processing. If the required processing - RFC4301";
                        action is protect, it contains the required
                        information to process the packet.";
                   leaf action{ action {
                       type ipsec-spd-operation; mandatory true; ipsec-spd-action;
                       default discard;
                       description "Bypass
                           "If bypass or discard, container
                           ipsec-sa-cfg is empty";} empty.";
                   }
                   container ipsec-sa-cfg {
                       when "../action = 'PROTECT'"; 'protect'";
                       description
                           "IPSec SA configuration included in the SPD
                           entry.";
                       leaf pfp-flag {
                           type boolean;
                           default false;
                           description
                                "Each selector has with a pfp flag."; Populate From
                                 Packet (PFP) flag. If asserted for a
                                 given selector X, the flag indicates
                                 that the IPSec SA 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) in the SPD entry.";
                       }
                       leaf extSeqNum ext-seq-num {
                           type boolean;
                           default false;
                           description "TRUE
                                "True if this IPsec SA is using extended
                                 sequence numbers. True 64 bit counter, FALSE
                                 False 32 bit"; }
                                        leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare &amp; audit"; bit.";
                       }
                       leaf statefulfragCheck seq-overflow {
                           type boolean;
                           default false;
                           description "Indicates
                               "The flag indicating whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to
                               overflow of the SA to be created."; }
                                        leaf security-protocol { type ipsec-protocol; description "Security protocol sequence number
                               counter should prevent transmission
                               of additional packets on the IPsec SA: Either AH
                               SA (false) and, therefore needs to
                               be rekeyed, or ESP."; whether rollover is
                               permitted (true). If Authenticated
                               Encryption with Associated Data
                               (AEAD) is used this flag MUST BE
                               false.";
                       }
                       leaf mode stateful-frag-check {
                           type ipsec-mode; boolean;
                           default false;
                           description "transport/tunnel";
                               "Indicates whether (true) or not (false)
                                stateful fragment checking applies to
                                the IPsec SA to be created.";
                       }

                                        container ah-algorithms {
                                                when "../security-protocol = 'ah'";
                                                leaf-list ah-algorithm
                       leaf mode {
                           type integrity-algorithm-t; ipsec-mode;
                           default transport;
                           description "Configure Authentication Header (AH).";
                               "IPsec SA has to be processed in
                                transport or tunnel mode.";
                       }
                       leaf trunc-length protocol-parameters {
                           type uint32; description "Truncation value for AH algorithm"; } ipsec-protocol-parameters;
                           default esp;
                           description "AH algoritms ";
                                "Security protocol of the IPsec SA:
                                Only ESP is supported but it could be
                                extended in the future.";
                       }
                       container esp-algorithms {
                           when "../security-protocol "../protocol-parameters = 'esp'";
                           description "Configure
                                "Configuration of Encapsulating
                                Security Payload (ESP)."; (ESP) parameters and
                                algorithms.";
                           leaf-list authentication integrity {
                               type integrity-algorithm-t; integrity-algorithm-type;
                               default 0;
                               ordered-by user;
                               description "Configure
                                   "Configuration of ESP authentication"; }
                                                /* authentication
                                   based on the specified integrity
                                   algorithm. With AEAD algorithms,
                                   the authentication integrity node is not used */
                                   used.";
                               reference
                                   "Section 3.2 in RFC 4303.";
                           }
                           leaf-list encryption {
                               type encryption-algorithm-t; encryption-algorithm-type;
                               default 20;
                               ordered-by user;
                               description "Configure
                                   "Configuration of ESP encryption"; encryption
                                   algorithms. The default value is
                                   20 (ENCR_AES_GCM_16).";
                               reference
                                   "Section 3.2 in RFC 4303.";
                           }
                           leaf tfc_pad tfc-pad {
                               type uint32; boolean;
                               default 0; false;
                               description "TFC
                                   "If Traffic Flow Confidentiality
                                    (TFC) padding for ESP encryption"; encryption
                                    can be used (true) or not (false)";
                               reference
                                   "Section 2.7 in RFC 4303.";
                           }
                           reference
                               "RFC 4303.";
                       }
                       container tunnel {
                           when "../mode = 'TUNNEL'"; 'tunnel'";
                           uses tunnel-grouping;
                           description "tunnel grouping container";
                              "IPsec tunnel endpoints definition.";
                       }

                                        description " IPSec SA configuration container";
                   }
                   reference
                       "Section 4.4.1.2 in RFC 4301.";
               }
               container spd-lifetime-soft spd-mark {
                       description "SPD lifetime hard state data";
                                uses lifetime;
                           "The Mark to set for the IPsec SA of this
                            connection. This option 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.";
                       leaf action {type lifetime-action; mark {
                           type uint32;
                           default 0;
                           description "Action lifetime";}
                               "Mark used to match XFRM policies and
                                states.";
                       }

                        container spd-lifetime-hard
                       leaf mask {
                           type yang:hex-string;
                           default 00:00:00:00;
                           description "SPD lifetime hard state data. The action after the lifetime is
                               "Mask used to remove the SPD entry.";
                                uses lifetime; match XFRM policies and
                               states.";
                       }

                        // State data for an IPsec SPD entry
                        container spd-lifetime-current {
                                uses lifetime;
                                config false;
                                description "SPD lifetime current state data";
                        }
                } /* grouping ipsec-policy-grouping */

        }
    <CODE ENDS>

Appendix B.  Appendix B: YANG model
               }
           }
       }

       <CODE ENDS>

Appendix B.  Appendix B: YANG model for IKE case

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

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

           import ietf-crypto-types {
               prefix ct;
               reference "draft-ietf-netconf-crypto-types-01:
                   "draft-ietf-netconf-crypto-types-09:
                   Common YANG Data Types for Cryptography"; Cryptography.";
           }

           import ietf-ipsec-common {
               prefix ic;
               reference "Common Data model for SDN-based IPSec configuration";
                   "RFC XXXX: module ietf-ipsec-common, revision
                    2019-07-07.";
           }

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

           organization "IETF I2NSF (Interface to Network Security Functions) Working Group";

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

           Author: Rafael Marin Lopez
                Dept. Information 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

           "This module contains IPSec IKE case model for the SDN-based
            IPsec flow protection service. An NSF will implement this
            module.

           Copyright (c) 2019 IETF Trust and Communications Engineering (DIIC)
                Faculty of Computer Science-University the persons identified as
           authors of Murcia
                30100 Murcia - Spain
                Telf: +34868888501
                e-mail: rafa@um.es

                Gabriel Lopez Millan
                Dept. Information the code.  All rights reserved.

           Redistribution and Communications Engineering (DIIC)
                Faculty 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 Computer Science-University the IETF Trust's Legal Provisions
           Relating to IETF Documents
           (http://trustee.ietf.org/license-info).

           This version of Murcia
                30100 Murcia - Spain
                Tel: +34 868888504
                email: gabilm@um.es

                Fernando Pereniguez Garcia
                Department this YANG module is part of Sciences 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 Informatics
                University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
                30720 San Javier - Spain
                Tel: +34 968189946
                email: fernando.pereniguez@cud.upct.es
                "; '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-07-07" {
               description "Data "Revision 5";
               reference
                   "RFC XXXX: YANG model for IKE case.";

                revision "2019-03-11"
           }

           typedef ike-spi {
               type uint64 { range "0..max"; }
               description "Revision 1.1";
                   "Security Parameter Index (SPI)'s IKE SA.";
               reference "";
                   "Section 2.6 in RFC 7296.";
           }

           typedef type-autostartup autostartup-type {
               type enumeration {
                   enum ADD {description "IPsec add {
                       description
                           "IKE/IPsec configuration is only loaded into
                            IKE implementation but IKE/IPsec SA is not started.";}
                            started.";
                   }
                   enum ON-DEMAND {description "IPsec on-demand {
                       description
                           "IKE/IPsec configuration is loaded and
                           into IKE implementation. The IPsec policies
                           are transferred to the NSF's kernel";} 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).";
                   }
                   enum START start {
                       description "IPsec "IKE/IPsec configuration is loaded
                       and transferred to the NSF's kernel, and the
                       IKEv2 based IPsec SAs are established";} established
                       immediately without waiting any packet.";
                   }
               }
               description
                   "Different policies of when to start an IKEv2 based set IPsec SA";
                }

                typedef auth-protocol-type {
                        type enumeration {
                                enum SA configuration
                    into NSF's kernel when IKEv2 { description "Authentication protocol based on IKEv2"; } implementation has
                    started.";
           }

           typedef pfs-group {
               type uint32;
               description "IKE authentication protocol version";
                   "DH groups for IKE and IPsec SA rekey.";
               reference
                   "Section 3.3.2 in RFC 7296. Transform Type 4 -
                    Diffie-Hellman Group Transform IDs in IANA Registry
                     - Internet Key Exchange Version 2 (IKEv2)
                    Parameters.";
           }

           typedef pfs-group auth-protocol-type {
               type enumeration {
                   enum NONE {description "NONE";}
                                enum 768-bit-MODP {description "768-bit MODP Group";}
                                enum 1024-bit-MODP {description "1024-bit MODP Group";}
                                enum 1536-bit-MODP {description "1536-bit MODP Group";}
                                enum 2048-bit-MODP {description "2048-bit MODP Group";}
                                enum 3072-bit-MODP {description "3072-bit MODP Group";}
                                enum 4096-bit-MODP {description "4096-bit MODP Group";}
                                enum 6144-bit-MODP {description "6144-bit MODP Group";} ikev2 {
                       value 2;
                       description
                           "IKEv2 authentication protocol. It is the
                            only defined right now. An enum 8192-bit-MODP {description "8192-bit MODP Group";} is used for
                            further extensibility.";
                   }
               }
               description "PFS group for IPsec rekey";
                   "IKE authentication protocol version specified in the
                    Peer Authorization Database (PAD). It is defined as
                    enumerate to allow new IKE versions in the
                    future.";
               reference
                   "RFC 7296.";
           }

                /*################## PAD  ####################*/

           typedef auth-method-type {
                        /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */
               type enumeration {
                   enum pre-shared {
                       description
                           "Select pre-shared key message as the
                           authentication method"; method.";
                       reference
                           "RFC 7296.";
                   }
                   enum eap {
                       description
                           "Select EAP as the authentication method"; method.";
                       reference
                           "RFC 7296.";
                   }
                   enum digital-signature {
                       description
                           "Select digital signature method";} method.";
                       reference
                           "RFC 7296 and RFC 7427.";
                   }
                   enum null {description "null authentication";}
                        }
                        description "Peer authentication method";
                }

                typedef signature-algorithm-t {
                        type ct:signature-algorithm-ref; // We must reference to "signature-algorithm-ref" but we temporary use hash-algorithm-ref
                       description "This typedef enables referencing to any digital signature algorithm";
                           "Null authentication.";
                       reference
                           "RFC 7619.";
                   }

               }

                grouping auth-method-grouping {
                        description "Peer authentication method data";

                        container auth-method {
               description
                   "Peer authentication method container";

                                leaf auth-m { type auth-method-type; description "Type of authentication method (pre-shared, eap, digital signature, null)"; }

                                container eap-method {
                                        when "../auth-m = 'eap'";
                                        leaf eap-type { type uint8; description "EAP method type"; }
                                        description "EAP method description used when auth method is eap"; specified in the Peer
                    Authorization Database (PAD).";
           }

           container pre-shared {
                                        when "../auth-m[.='pre-shared' or .='eap']";
                                        leaf secret ipsec-ike { type yang:hex-string; description "Pre-shared secret value";}
               description "Shared secret value";
                                }
                   "IKE configuration for a NSF. It includes PAD
                    parameters, IKE connections information and state
                    data.";

               container digital-signature pad {
                                        when "../auth-m[.='digital-signature' or .='eap']";
                                        leaf ds-algorithm {type signature-algorithm-t;
                   description "Name
                      "Configuration of Peer Authorization Database
                       (PAD). The PAD contains information about IKE
                       peer (local and remote). Therefore, the digital signature algorithm";}
                                        leaf raw-public-key {type yang:hex-string; description "RSA raw public key" ;}
                                        leaf key-data { type string; description "RSA private key data - PEM"; }
                                        leaf key-file Security
                       Controller also stores authentication
                       information for this NSF and can include
                       several entries for the local NSF not 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 string; description "RSA private
                       key file name "; }
                                        leaf-list ca-data { type string; description "List of trusted CA certs - PEM"; }
                                        leaf ca-file { type string; "name";
                       ordered-by user;
                       description "List
                           "Peer Authorization Database (PAD) entry. It
                            is a list of trusted CA certs file"; }
                                        leaf cert-data { type string; description "X.509 certificate data - PEM4"; }
                                        leaf cert-file { type string; description "X.509 certificate file"; }
                                        leaf crl-data { type string; description "X.509 CRL certificate data in base64"; } PAD entries ordered by the
                            Security Controller.";
                       leaf crl-file name {
                           type string;
                           description " X.509 CRL certificate file"; }
                                        leaf oscp-uri { type inet:uri; description "OCSP URI";}
                                        description "RSA signature container";
                                }
                        }
                               "PAD unique name to identify this
                                entry.";
                       }

                grouping identity-grouping {
                        description "Identification type. It is an union identity";
                       choice identity {
                           mandatory true;
                           description "Choice
                               "A particular IKE peer will be
                               identified by one of identity."; these identities.
                               This peer can be a remote peer or local
                               peer (this NSF).";
                           reference
                               "Section 4.4.3.1 in RFC 4301.";
                           case ipv4-address{
                               leaf ipv4-address {
                                   type inet:ipv4-address;
                                   description
                                       "Specifies the identity as a
                                        single four (4) octet IPv4 address. An example is, 10.10.10.10. ";
                                        addressExample: 10.10.10.10.";
                               }
                           }
                           case ipv6-address{
                               leaf ipv6-address {
                                   type inet:ipv6-address;
                                   description
                                       "Specifies the identity as a
                                        single sixteen (16) octet IPv6
                                        address. An example is FF01::101, 2001:DB8:0:0:8:800:200C:417A .";
                                        2001:DB8:0:0:8:800:200C:417A.";
                               }
                           }
                           case fqdn-string {
                               leaf fqdn-string {
                                   type inet:domain-name;
                                   description
                                       "Specifies the identity as a Fully-Qualified Domain
                                        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 rfc822-address-string {
                                   type string;
                                   description
                                       "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., e.g., NULL, CR,
                                        etc.).";
                                   reference
                                       "RFC 822.";
                               }
                           }
                           case dnx509 {
                               leaf dnX509 dnx509 {
                                   type string;
                                   description
                                       "Specifies the identity as a distinguished name in the X.509 tradition.";
                                        ASN.1 X.500 Distinguished
                                        Name. An example is
                                        C=US,O=Example
                                        Organisation,CN=John Smith.";
                                   reference
                                       "RFC 2247.";
                               }
                                leaf id_key { type string; description "Key id";
                           }
                                leaf id_null
                           case gnx509 { type empty; description "RFC 7619" ; }
                               leaf user_fqdn gnx509 {
                                   type string;
                                   description "User FQDN";
                                       "ASN.1 X.509 GeneralName. RFC
                                        3280.";
                               }
                           }
                           case id-key {
                               leaf my-identifier id-key {
                                   type string; mandatory true;
                                   description "id
                                       "Opaque octet stream that may be
                                        used to pass vendor-specific
                                        information for authentication"; proprietary
                                        types of identification.";
                                   reference
                                       "Section 3.5 in RFC 7296.";
                               }
                           }

                /*################ end PAD ##################*/

                /*################## IKEv2-grouping ##################*/
                grouping ike-proposal
                           case id-null {
                        description "IKEv2 proposal grouping";

                        container ike-sa-lifetime-hard {
                                description "IKE SA lifetime hard";
                                uses ic:lifetime;
                        }

                        container ike-sa-lifetime-soft {
                                description "IPsec SA lifetime soft";
                                uses ic:lifetime;
                               leaf action {type ic:lifetime-action; description "Action lifetime";}
                        }

                        leaf-list ike-sa-authalg id-null {
                                   type ic:integrity-algorithm-t; empty;
                                   description "Auth algorigthm for
                                       "ID_NULL identification used
                                        when IKE SA";}
                        leaf-list ike-sa-encalg identification payload
                                        is not used." ;
                                   reference
                                       "RFC 7619.";
                               }
                           }
                       }
                       leaf auth-protocol {
                           type ic:encryption-algorithm-t; auth-protocol-type;
                           default ikev2;
                           description "Auth algorigthm for IKE SAs";}
                        leaf dh_group
                               "Only IKEv2 is supported right now but
                                other authentication protocols may be
                                supported in the future.";
                       }
                       container peer-authentication { type uint32; mandatory true;
                           description "Group number for Diffie Hellman Exponentiation";}
                               "This container allows the Security
                                Controller to configure the
                                authentication method (pre-shared key,
                                eap, digitial-signature, null) that
                                will use a particular peer and the
                                credentials, which will depend on the
                                selected authentication method.";
                           leaf half-open-ike-sa-timer auth-method {
                              type uint32; auth-method-type;
                              default pre-shared;
                              description "Set the half-open IKE SA timeout duration" ;
                                   "Type of authentication method
                                   (pre-shared, eap, digital signature,
                                    null).";
                              reference
                                  "Section 2.15 in RFC 7296.";
                           }
                           container eap-method {
                               when "../auth-method = 'eap'";
                               leaf half-open-ike-sa-cookie-threshold eap-type {
                                   type uint32; uint8;
                                   mandatory true;
                                   description "Number of half-open IKE SAs that activate
                                       "EAP method type. This
                                       information provides the cookie mechanism." ; }
                                       particular EAP method to be
                                       used. Depending on the EAP
                                       method, pre-shared keys or
                                       certificates may be used.";
                               }

                grouping ike-child-sa-info {
                               description "IPsec SA Information";
                        leaf-list pfs_groups { type pfs-group;
                                   "EAP method description "If non-zero, require perfect forward secrecy used when requesting new SA. The non-zero value
                                   authentication method is the required group number"; 'eap'.";
                               reference
                                   "Section 2.16 in RFC 7296.";
                           }
                           container child-sa-lifetime-soft pre-shared {
                                description "IPsec SA lifetime soft";
                                uses ic:lifetime;
                               when
                                   "../auth-method[.='pre-shared' or
                                    .='eap']";
                               leaf action {type ic:lifetime-action; description "action lifetime";}
                        }

                        container child-sa-lifetime-hard secret {
                                   nacm:default-deny-all;
                                   type yang:hex-string;
                                   description "IPsec SA lifetime hard.
                                       "Pre-shared secret value. The action will be
                                        NSF has to terminate the IPsec SA.";
                                uses ic:lifetime; prevent read access
                                        to this value for security
                                        reasons.";
                               }
                               description
                                   "Shared secret value for PSK or
                                    EAP method authentication based on
                                    PSK.";
                           }

                /*################## End IKEv2-grouping ##################*/
                           container ikev2 digital-signature {

                        description "Configure the IKEv2 software";

                        container pad
                               when
                                "../auth-method[.='digital-signature'
                               or .='eap']";
                               leaf ds-algorithm {
                                   type uint8;
                                   description "Configure Peer Authorization Database (PAD)";
                                list pad-entry {
                                        key "pad-entry-id";
                                        ordered-by user;
                                        description "Peer Authorization Database (PAD)";
                                        leaf pad-entry-id { type uint64; description "SAD index. ";}
                                        uses identity-grouping;
                                       "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 pad-auth-protocol { type auth-protocol-type; description "IKEv2, etc. ";}
                                        uses auth-method-grouping;
                                }
                                       'cert-data' and 'private-key'
                                       will contain this information.";
                                   reference
                                       "IKEv2 Authentication Method -
                                        IANA Registry - Internet Key
                                        Exchange Version 2 (IKEv2)
                                        Parameters.";
                               }

                        list ike-conn-entry {
                                key "conn-name";
                                description "IKE peer connection information";
                                leaf conn-name

                               choice public-key { type string;
                                   mandatory true; description "Name of IKE connection";}
                                   leaf autostartup raw-public-key {
                                       type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";}
                                leaf initial-contact {type boolean; default false; binary;
                                       description "This IKE SA
                                         "A binary that contains the
                                         value of the public key.  The
                                         interpretation of the content
                                         is defined by the only currently active between digital
                                         signature algorithm. For
                                         example, an RSA key is
                                         represented as RSAPublicKey as
                                         defined in RFC 8017, and an
                                         Elliptic Curve Cryptography
                                         (ECC) key is represented
                                         using the authenticated identities";}
                                leaf version {
                                        type enumeration {
                                                enum ikev2 {value 2; description "IKE version 2";}
                                        }
                                        description "IKE version"; 'publicKey'
                                         described in RFC 5915.";
                                   reference
                                         "RFC XXX: Common YANG Data
                                         Types for Cryptography.";
                                   }
                                   leaf ike-fragmentation cert-data {
                                       type boolean; ct:x509;
                                       description "Whether to use IKEv2 fragmentation as per RFC 7383 (TRUE or FALSE)";
                                           "X.509 certificate data -
                                            PEM4.";
                                       reference
                                           "RFC XXX: Common YANG Data
                                           Types for Cryptography.";
                                   }
                                uses ike-proposal;

                                container local {
                                   description "Local peer connection information";
                                       "If the Security Controller
                                        knows that the NSF
                                        already owns a private key
                                        associated to this public key
                                        (the NSF generated the pair
                                        public key/private key out of
                                        band), it will only configure
                                        one of the leaf local-pad-id { type uint64; description " ";} of this
                                        choice. The NSF, based on
                                        the public key value can know
                                        the private key to be used.";
                               }

                                container remote {
                                        description "Remote peer connection information";
                               leaf remote-pad-id private-key {
                                   nacm:default-deny-all;
                                   type uint64; binary;
                                   description " ";}
                                }

                                uses ic:encap;

                                container spd {
                                        description "Configure
                                       "A binary that contains the Security Policy Database (SPD)";
                                        list spd-entry {
                                        value of the private key. The
                                        interpretation of the content
                                        is defined by the digital
                                        signature algorithm. For
                                        example, an RSA key "spd-entry-id";
                                                uses ic:ipsec-policy-grouping;
                                                ordered-by user; 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.";
                               }
                               leaf-list ca-data {
                                   type ct:x509;
                                   description
                                       "List of SPD entries";
                                        } trusted Certification
                                       Authorities (CA) certificates
                                       encoded using ASN.1
                                       distinguished encoding rules
                                       (DER).";
                                   reference
                                       "RFC XXX: Common YANG Data
                                       Types for Cryptography.";
                               }

                                container ike-sa-state {
                                        container uptime {
                                                description "IKE service uptime";
                               leaf running crl-data {
                                   type yang:date-and-time; ct:crl;
                                   description "Relative uptime";}
                                      "A CertificateList structure, as
                                       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.";
                               }
                               leaf since crl-uri  {
                                   type yang:date-and-time; inet:uri;
                                   description "Absolute uptime";}
                                       "X.509 CRL certificate URI.";
                               }
                               leaf initiator oscp-uri {
                                   type boolean; inet:uri;
                                   description "It is acting as initiator in
                                       "OCSP URI.";
                               }
                               description
                                   "Digital Signature container.";

                           } /*container digital-signature*/
                       } /*container peer-authentication*/
                   }
               }

               list conn-entry {
                   key "name";
                   description
                       "IKE peer connection information. This list
                       contains the IKE connection for this connection";} peer
                       with other peers. This will be translated in
                       real time by IKE Security Associations
                       established with these nodes.";
                   leaf initiator-ikesa-spi {type uint64; name {
                       type string;
                       mandatory true;
                       description "Initiator's IKE SA SPI";}
                           "Identifier for this connection
                            entry.";
                   }
                   leaf responder-ikesa-spi {type uint64; autostartup {
                         type autostartup-type;
                         default add;
                         description "Responsder's IKE SA SPI";}
                             "By-default: Only add configuration
                              without starting the security
                              association.";
                   }
                   leaf nat-local {type initial-contact {
                       type boolean;
                       default false;
                       description "YES, if local endpoint
                           "The goal of this value is behind a NAT";} to deactivate the
                           usage of 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.";
                   }
                   leaf nat-remote {type boolean; version {
                       type auth-protocol-type;
                       default ikev2;
                       description "YES, if remote endpoint
                          "IKE version. Only version 2 is behind a NAT";} supported
                          so far.";
                   }
                   leaf nat-any {type fragmentation {
                       type boolean;
                       default false;
                       description "YES, if both local and remote endpoints are behind a NAT";}

                                        uses ic:encap;

                                        leaf established {type uint64;
                           "Whether or not to enable IKE
                            fragmentation as per RFC 7383 (true or
                            false).";
                       reference
                           "RFC 7383.";
                   }
                   container ike-sa-lifetime-soft {
                       description "Seconds
                           "IKE SA lifetime soft. Two lifetime values
                            can be configured: either rekey time of the
                            IKE SA has been established";} or reauth time of the IKE 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 uint64; {
                           type uint32;
                           default 0;
                           description "Seconds before
                               "Time in seconds between each IKE SA gets rekeyed";}
                               rekey.The value 0 means infinite.";
                      }
                      leaf reauth-time {type uint64; {
                           type uint32;
                           default 0;
                           description "Seconds before
                             "Time in seconds between each IKE SA gets re-authenticated";}
                                        list child-sas {
                             reauthentication. The value 0 means
                             infinite.";
                      }
                      reference
                          "Section 2.8 in RFC 7296.";
                   }
                   container spis{
                                                        description "IPsec SA's SPI '";
                                                        leaf spi-in {type ic:ipsec-spi; ike-sa-lifetime-hard {
                       description "Security Parameter Index for inbound IPsec SA";}
                           "Hard IKE SA lifetime. When this
                            time is reached the IKE SA is removed.";
                       leaf spi-out {type ic:ipsec-spi; over-time {
                           type uint32;
                           default 0;
                           description "Security Parameter Index for
                               "Time in seconds before the corresponding outbound IPsec SA";} 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 "State data about
                          "Authentication algorithm for establishing
                          the IKE CHILD SAs"; SA. 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.";
                   }
                                        config false;
                   leaf-list encalg {
                       type ic:encryption-algorithm-type;
                       default 12;
                       ordered-by user;
                       description "IKE state data";
                                } /* ike-sa-state */
                          "Encryption or AEAD algorithm for the IKE
                          SAs. 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 encryption value assumed is
                          NULL.";
                   } /* ike-conn-entries */

                        container number-ike-sas{
                   leaf total {type uint32; dh-group {
                       type pfs-group;
                       default 14;
                       description "Total
                           "Group number of IKEv2 SAs";}
                                leaf half-open {type uint32; description "Number of for Diffie-Hellman
                           Exponentiation used during IKE_SA_INIT
                           for the IKE SA key exchange.";
                   }
                   leaf half-open-ike-sa-timer {
                       type uint32;
                       description
                           "Set the half-open IKEv2 SAs";} IKE SA timeout
                            duration.";
                       reference
                           "Section 2 in RFC 7296.";
                   }

                   leaf half-open-cookies {type half-open-ike-sa-cookie-threshold {
                       type uint32;
                       description
                           "Number of half open half-open IKE SAs with that activate
                            the cookie activated" ;}
                                config false;
                                description "Number of IKE SAs";
                        }
                }  /* container ikev2 */
        }

        <CODE ENDS>

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

        <CODE BEGINS> file "ietf-ipsec-ikeless@2019-03-11.yang"

        module ietf-ipsec-ikeless {

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

                prefix "ipsec-ikeless";

                import ietf-yang-types { prefix yang; }

                import ietf-ipsec-common {
                        prefix ic;
                        reference "Common Data model for SDN-based IPSec configuration";
                }

                organization "IETF I2NSF (Interface to Network Security Functions) Working Group";

                contact
                " Rafael Marin Lopez
                Dept. Information and Communications Engineering (DIIC)
                Faculty of Computer Science-University of Murcia
                30100 Murcia - Spain
                Telf: +34868888501
                e-mail: rafa@um.es

                Gabriel Lopez Millan
                Dept. Information and Communications Engineering (DIIC)
                Faculty of Computer Science-University of Murcia
                30100 Murcia - Spain
                Tel: +34 868888504
                email: gabilm@um.es

                Fernando Pereniguez Garcia
                Department of Sciences and Informatics
                University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
                30720 San Javier - Spain
                Tel: +34 968189946
                email: fernando.pereniguez@cud.upct.es
                ";

                description "Data model for IKE-less case";

                revision "2019-03-11" {
                        description "Revision"; mechanism." ;
                       reference "";
                }

                /*################## SAD grouping ####################*/
                grouping ipsec-sa-grouping {
                        description "Configure Security Association (SA). Section 4.4.2.1
                           "Section 2.6 in RFC 4301"; 7296.";
                   }
                   container local {
                       leaf sad-entry-id {type uint64; local-pad-entry-name {
                           type string;
                           description "This value identifies
                               "Local peer authentication information.
                                This node points to a specific entry in
                                the SAD";} PAD where the authorization
                                information about this particular local
                                peer is stored. It MUST match a
                                pad-entry-name.";
                       }
                       description
                           "Local peer authentication information.";
                   }
                   container remote {
                       leaf spi remote-pad-entry-name {
                           type ic:ipsec-spi; string;
                           description "Security Parameter Index.
                               "Remote peer authentication information.
                                This may not be unique for node points to a specific entry in
                                the PAD where the authorization
                                information about this particular SA";}
                        leaf seq-number { type uint64;
                                remote peer is stored. It MUST match a
                                pad-entry-name.";
                       }
                       description "Current sequence number of IPsec packet.";
                           "Remote peer authentication information.";
                   }
                        leaf seq-number-overflow-flag
                   container encapsulation-type
                   { type boolean;
                       uses ic:encap;
                       description "The flag indicating whether overflow of
                           "This container carries configuration
                           information about the sequence number counter should prevent transmission source and destination
                           ports of additional packets on encapsulation that IKE should use
                           and the SA, or whether rollover type of encapsulation that
                           should use when NAT traversal is required.
                           However, this is permitted."; just a best effort since
                           the IKE implementation may need to use a
                           different encapsulation as
                           described in RFC 8229.";
                       reference
                           "RFC 8229.";
                   }
                   container spd {
                       description
                           "Configuration of the Security Policy
                           Database (SPD). This main information is
                           placed in the grouping
                           ipsec-policy-grouping.";
                       list spd-entry {
                           key "name";
                           ordered-by user;
                           leaf anti-replay-window name {
                               type uint16 { range "0 | 32..1024"; } string;
                               mandatory true;
                               description "Anti replay window size";
                                   "SPD entry unique name to identify
                                   the IPsec policy.";
                           }
                        leaf spd-entry-id {type uint64;
                           container ipsec-policy-config {
                               description
                                   "This value links the SA with container carries the SPD entry";}
                                   configuration of a IPsec policy.";
                               uses ic:selector-grouping;

                        leaf security-protocol { type ic:ipsec-protocol; ic:ipsec-policy-grouping;
                           }
                           description "Security protocol
                               "List of entries which will constitute
                               the representation of the SPD. Since we
                               have IKE in this case, it is only
                               required to send a IPsec SA: Either AH or ESP."; policy from
                               this NSF where 'local' is this NSF and
                               remote the other NSF. The 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.";
                       }
                       reference
                           "Section 2.9 in RFC 7296.";
                   }
                   container sad-lifetime-hard child-sa-info {
                       leaf-list pfs-groups {
                           type pfs-group;
                           default 0;
                           ordered-by user;
                           description "SAD lifetime hard state data.
                               "If non-zero, it is required perfect
                                forward secrecy when requesting new
                                IPsec SA. The action associated non-zero value is terminate.";
                                uses ic:lifetime;
                                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.";
                       }
                       container sad-lifetime-soft child-sa-lifetime-soft {
                           description "SAD
                               "Soft IPsec SA lifetime hard state data"; soft.
                                After the lifetime the action is
                                defined in this container
                                in the leaf action.";
                           uses ic:lifetime;
                           leaf action {type ic:lifetime-action; description "action lifetime";}
                        }

                        leaf mode {
                               type ic:ipsec-mode; ic:lifetime-action;
                               default replace;
                               description
                                   "When the lifetime of an IPsec SA
                                    expires an action needs to be
                                    performed over the IPsec SA that
                                    reached the lifetime. There are
                                    three possible options:
                                    terminate-clear, terminate-hold and
                                    replace.";
                           reference
                               "Section 4.5 in RFC 4301 and Section 2.8
                                in RFC 7296.";
                           }
                       }
                       container child-sa-lifetime-hard {
                           description
                               "IPsec SA lifetime hard. The action will
                                be to terminate the IPsec SA.";
                           uses ic:lifetime;
                           reference
                               "Section 2.8 in RFC 7296.";
                       }
                       description "SA Mode";
                           "Specific information for IPsec SAs
                           SAs. It includes PFS group and IPsec SAs
                           rekey lifetimes.";
                   }
                   container state {
                       config false;

                       leaf statefulfragCheck initiator {
                           type boolean;
                           description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to
                               "It is acting as initiator for this SA.";
                                connection.";
                       }
                       leaf dscp initiator-ikesa-spi {
                           type yang:hex-string; ike-spi;
                           description "DSCP value";
                               "Initiator's IKE SA SPI.";
                       }
                       leaf path-mtu responder-ikesa-spi {
                           type uint16; ike-spi;
                           description "Maximum size of an IPsec packet that can be transmitted without fragmentation";
                               "Responder's IKE SA SPI.";
                       }

                        container tunnel
                       leaf nat-local {
                                when "../mode = 'TUNNEL'";
                                uses ic:tunnel-grouping;
                           type boolean;
                           description "Container for tunnel grouping";
                               "True, if local endpoint is behind a
                                NAT.";
                       }

                        uses ic:encap;

                        // STATE DATA for SA
                        container sad-lifetime-current
                       leaf nat-remote {
                                uses ic:lifetime;
                                config false;
                           type boolean;
                           description "SAD lifetime current state data";
                               "True, if remote endpoint is behind
                               a NAT.";
                       }
                       container stats encapsulation-type
                       { // xfrm.h
                                leaf replay-window {type uint32; default 0; description " "; }
                                leaf replay {type uint32; default 0;
                           uses ic:encap;
                           description "packets detected out of
                               "This container provides information
                               about the replay window source and dropped because they are replay packets";}
                                leaf failed {type uint32; default 0; description "packets detected out destination
                               ports of encapsulation that IKE is
                               using, and the replay window ";}
                                config false;
                                description "SAD statistics"; type of encapsulation
                               when NAT traversal is required.";
                           reference
                               "RFC 8229.";
                       }

                        container replay_state { // xfrm.h
                       leaf seq {type uint32; default 0; established {
                           type uint64;
                           description "input traffic sequence number when anti-replay-window != 0";}
                               "Seconds since this IKE SA has been
                                established.";
                       }
                       leaf oseq {type uint32; default 0; current-rekey-time {
                           type uint64;
                           description "output traffic sequence number";}
                               "Seconds before IKE SA must be rekeyed.";
                       }
                       leaf bitmap {type uint32; default 0; current-reauth-time {
                           type uint64;
                           description "";}
                               "Seconds before IKE SA must be
                                re-authenticated.";
                       }
                       description
                           "IKE state data for a particular
                            connection.";
                   } /* ike-sa-state */
               } /* ike-conn-entries */

               container number-ike-sas {
                   config false;
                   leaf total {
                       type uint64;
                       description "Anti-replay Sequence Number state";
                           "Total number of active IKE SAs.";
                   }
                   leaf half-open {
                       type uint64;
                       description
                           "Number of 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 IKE SAs. In
                       particular, it provides the current number of
                       IKE SAs.";
               }
           }  /* container ipsec-ike */
       }

       <CODE ENDS>

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

       <CODE BEGINS> file "ietf-ipsec-ikeless@2019-07-07.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 { prefix yang; }

           import ietf-ipsec-common {
               prefix ic;
               reference
                   "Common Data model for SDN-based IPSec
                    configuration.";
           }

           import ietf-netconf-acm {
                  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
               "Data model for IKE-less 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, 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 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-07-07" {
               description "Revision 05";
               reference "RFC XXXX: YANG model 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 replay_state_esn spd { // xfrm.h
                                leaf bmp-len {type uint32; default 0;
                   description "bitmap length for ESN"; }
                       "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 oseq name {
                           type uint32; default 0; string;
                           mandatory true;
                           description "output traffic sequence number";
                               "SPD entry unique name to identify this
                                entry.";
                       }
                       leaf oseq-hi direction {
                           type uint32; default 0; ic:ipsec-traffic-direction;
                           description "";
                               "Inbound traffic or outbound
                                traffic. In the IKE-less case the
                                Security 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 seq-hi reqid {
                           type uint32; default 0; description ""; }
                                leaf replay-window {type uint32; uint64;
                           default 0;
                           description ""; }
                                leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; }
                                config false;
                                description "Anti-replay Extended Sequence Number (ESN) state";
                        }

                }
                /*################## end SAD grouping ##################*/

                /*################# Register grouping #################*/
                typedef sadb-msg-type {
                        type enumeration {
                                enum sadb_acquire { description "SADB_ACQUIRE"; }
                                enum sadb_expire { description "SADB_EXPIRE"; }
                        }
                        description "Notifications (PF_KEY message types) that must be forwarded by the NSF
                               "This value allows to link this
                                IPsec policy with IPsec SAs with the controller
                                same reqid. It is only required in
                                the IKE-less case"; model since, in the IKE
                                case this link is handled internally
                                by IKE.";

                       }

                typedef sadb-msg-satype {
                         type enumeration {
                                enum sadb_satype_unspec

                       container ipsec-policy-config {
                           description "SADB_SATYPE_UNSPEC";
                               "This container carries the
                               configuration of a IPsec policy.";
                           uses ic:ipsec-policy-grouping;
                       }
                                enum sadb_satype_ah {
                       description "SADB_SATYPE_AH";
                           "The SPD is represented as a list of SPD
                            entries, where each SPD entry represents an
                            IPsec policy.";
                   }
                                enum sadb_satype_esp /*list spd-entry*/
               } /*container spd*/

               container sad {
                   description "SADB_SATYPE_ESP"; }
                                enum sadb_satype_rsvp
                       "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 name {
                           type string;
                           description "SADB_SATYPE_RSVP";
                               "SAD entry unique name to identify this
                                entry.";
                       }
                                enum sadb_satype_ospfv2
                       leaf reqid {
                           type uint64;
                           default 0;
                           description "SADB_SATYPE_OSPFv2";
                               "This value allows to link this
                                IPsec SA with an IPsec policy with
                                the same reqid.";
                       }
                                enum sadb_satype_ripv2

                       container ipsec-sa-config {
                           description "SADB_SATYPE_RIPv2"; }
                                enum sadb_satype_mip
                               "This container allows configuring
                               details of an IPsec SA.";
                           leaf spi { description "SADB_SATYPE_MIP"; }
                                enum sadb_satype_max
                               type uint32 { description "SADB_SATYPE_MAX"; } range "0..max"; }
                               mandatory true;
                               description "PF_KEY Security Association types";
                                   "Security Parameter Index (SPI)'s
                                    IPsec SA.";

                           }

                grouping base-grouping {
                        description "Configuration for the  message header format";
                        list base-list {
                                         key "version";
                           leaf version ext-seq-num {
                               type string; boolean;
                               default true;
                               description "Version of PF_KEY (MUST be PF_KEY_V2)";
                                   "True if this IPsec SA is using
                                    extended sequence numbers. True 64
                                    bit counter, FALSE 32 bit.";
                           }
                           leaf msg_type seq-number-counter {
                               type sadb-msg-type; uint64;
                               default 0;
                               description "Identifies
                                    "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 type of message";
                                    initial Sequence Number field
                                    in ESP headers.";
                           }
                           leaf msg_satype seq-overflow {
                               type sadb-msg-satype; boolean;
                               default false;
                               description "Defines
                                   "The flag indicating whether
                                    overflow of the type sequence number
                                    counter should prevent transmission
                                    of Security Association"; 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 msg_seq anti-replay-window {
                               type uint32;
                               default 32;
                               description "Sequence number of this message."; }
                                         description "Configuration for
                                   "A 32-bit counter and a specific message header format";
                        } 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.";
                           }
                /*################# End Register grouping #################*/

                /*################## IPsec configuration ##################*/
                container ietf-ipsec {
                        description "IPsec configuration";
                           container spd {
                                                description "Configure the Security Policy Database (SPD)";
                                                list spd-entry traffic-selector {
                                                   key "spd-entry-id";
                               uses ic:ipsec-policy-grouping;
                                                   ordered-by user; ic:selector-grouping;
                               description "List of SPD entries";
                                                }
                                   "The IPsec SA traffic selector.";
                           }

                        container sad {
                                description "Configure the IPSec Security Association Database (SAD)";

                                list sad-entry {
                                        key "sad-entry-id";

                                        uses ipsec-sa-grouping;

                                        container ah-sa {
                                                when "../security-protocol = 'ah'";
                                                description "Configure Authentication Header (AH) for SA";
                                                container integrity {
                                                        description "Configure integrity for IPSec Authentication Header (AH)";
                           leaf integrity-algorithm protocol-parameters {
                               type ic:integrity-algorithm-t; ic:ipsec-protocol-parameters;
                               default esp;
                               description "Configure Authentication Header (AH).";
                                   "Security protocol of IPsec SA: Only
                                   ESP so far.";
                           }
                           leaf key mode {
                               type string; ic:ipsec-mode;
                               description "AH key value";}
                                                }
                                   "Tunnel or transport mode.";
                           }
                           container esp-sa {
                               when "../security-protocol "../protocol-parameters =
                            'esp'";
                                                description "Set IPSec
                               description
                                   "In case the IPsec SA is
                                    Encapsulation Security Payload (ESP)";
                                    (ESP), it is required to specify
                                    encryption and integrity
                                    algorithms, and key material.";

                               container encryption {
                                   description "Configure
                                       "Configuration of encryption or
                                        AEAD algorithm for IPSec
                                        Encapsulation Secutiry Security Payload (ESP)";
                                        (ESP).";

                                   leaf encryption-algorithm {
                                     type ic:encryption-algorithm-t; ic:encryption-algorithm-type;
                                     description "Configure
                                           "Configuration of ESP encryption";
                                            encryption. With AEAD
                                            algorithms, the integrity
                                            node is not used.";
                                   }

                                   leaf key {
                                       nacm:default-deny-all;
                                       type yang:hex-string;
                                       description
                                           "ESP encryption key value";} value.";
                                    }
                                   leaf iv {type {
                                       nacm:default-deny-all;
                                       type yang:hex-string;
                                       description
                                           "ESP encryption IV value"; value.";
                                   }
                               }
                               container integrity {
                                   description "Configure authentication
                                       "Configuration of integrity for
                                        IPSec Encapsulation Secutiry Security
                                        Payload (ESP)"; (ESP). This container
                                        allows to configure integrity
                                        algorithm when no AEAD
                                        algorithms are used, and
                                        integrity is required.";
                                    leaf integrity-algorithm {
                                       type ic:integrity-algorithm-t; ic:integrity-algorithm-type;
                                       description "Configure
                                           "Message Authentication Header (AH)."; Code
                                           (MAC) algorithm to provide
                                           integrity in ESP.";
                                   }
                                   leaf key {
                                       nacm:default-deny-all;
                                       type yang:hex-string;
                                       description
                                           "ESP integrity key value";} value.";
                                   }
                                                /* With AEAD algorithms, the integrity node
                               }
                           } /*container esp-sa*/

                           container sa-lifetime-hard {
                               description
                                   "IPsec SA hard lifetime. The action
                                   associated is not used */ terminate and
                                   hold.";
                               uses ic:lifetime;
                           }
                           container sa-lifetime-soft {
                               description
                                   "IPSec SA soft lifetime.";
                               uses ic:lifetime;
                               leaf combined-enc-intr action {
                                   type boolean; ic:lifetime-action;
                                   description "ESP combined mode algorithms. The algorithm
                                       "Action lifetime:
                                        terminate-clear,
                                        terminate-hold or replace.";
                               }

                           }
                           container tunnel {
                               when "../mode = 'tunnel'";
                               uses ic:tunnel-grouping;
                               description
                                    "Endpoints of the 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 specified in encryption-algorithm";} 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.";
                           }
                           container replay-stats {
                               description
                                   "State data about the anti-replay
                                    window.";
                               leaf replay-window {
                                   type uint64;
                                   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 the replay window.";
                               }
                               leaf seq-number-counter {
                                   type uint64;
                                   description
                                       "A 64-bit counter when this
                                        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";
                                } entries that conforms the SAD.";
                   } /*list sad-entry*/
               } /*container sad*/
           }/*container ipsec-ikeless*/

           /* container ietf-ipsec */

                /*################## RPC and Notifications ##################*/

                // These RPCs are needed by a Security Controller in IKEless case */
           notification spdb_expire sadb-acquire {
               description "A SPD entry has expired";
                   "An IPsec SA is required. The traffic-selector
                    container contains information about the IP packet
                    that triggers the acquire notification.";
               leaf index ipsec-policy-name {
                   type uint64; string;
                   mandatory true;
                   description "SPD index. RFC4301 does not mention an index however real implementations (e.g. XFRM or PFKEY_v2 with KAME extensions provide a
                       "It contains the SPD entry name (unique) of
                        the IPsec policy index to refer a policy. "; }
                }

                notification sadb_acquire {
                        description "A that hits the IP packet
                        required IPsec SA SA. It is required ";
                        uses base-grouping;
                        uses ic:selector-grouping; // To indicate assumed the concrete traffic selector
                        Security Controller will have 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 in the policy so the Security
                        Controller can also know the type of IPsec
                        SA that must be generated.";
               }
               container traffic-selector {
                    description
                        "The IP packet that triggered this acquire. the acquire
                         and requires an IPsec SA. Specifically it
                         will contain the IP source/mask and IP
                         destination/mask; protocol (udp, tcp,
                         etc...); and source and destination
                         ports.";
                    uses ic:selector-grouping;
                }
           }

           notification sadb_expire sadb-expire {
               description "A "An IPsec SA expiration (soft or hard)";

                        uses base-grouping; hard).";
               leaf spi { type ic:ipsec-spi;  description "Security Parameter Index";}
                        leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; }

                        leaf encryption-algorithm ipsec-sa-name {
                   type ic:encryption-algorithm-t; string;
                   mandatory true;
                   description "encryption algorithm
                       "It contains the SAD entry name (unique) of
                        the IPsec SA that has expired.  It is assumed
                        the Security Controller will have a copy of the
                        IPsec SA information (except the cryptographic
                        material and state data) indexed by this name
                        (unique identifier) so it can know all the
                        information (crypto algorithms, etc.) about
                        the IPsec SA that has expired SA"; in order to
                        perform a rekey (soft lifetime) or delete it
                        (hard lifetime) with this unique identifier.";
               }
               leaf authentication-algorithm soft-lifetime-expire {
                   type ic:integrity-algorithm-t; boolean;
                   default true;
                   description "authentication algorithm of
                       "If this value is true the lifetime expired SA"; is
                        soft. If it is false is hard.";
               }
               container sad-lifetime-hard lifetime-current {
                   description "SAD lifetime hard state data";
                                uses ic:lifetime;
                        }
                       "IPsec SA current lifetime. If
                        soft-lifetime-expired is true this container sad-lifetime-soft {
                                description "SAD is
                        set with the lifetime information about current
                        soft state data"; lifetime.";
                   uses ic:lifetime;
               }

                        container sad-lifetime-current
           }
           notification sadb-seq-overflow {
               description "SAD lifetime current "Sequence overflow notification.";
               leaf ipsec-sa-name {
                   type string;
                   mandatory true;
                   description
                       "It contains the SAD entry name (unique) of
                        the IPsec SA that is about to have sequence
                        number overflow and rollover is not permitted.
                        It is assumed the Security Controller will have
                        a copy of the IPsec SA information (except the
                        cryptographic material and state data";
                                uses ic:lifetime; data) indexed
                        by this name (unique identifier) so the it can
                        know all the information (crypto algorithms,
                        etc.) about the IPsec SA that has expired in
                        order to perform a rekey of the IPsec SA.";
               }
           }
           notification sadb_bad-spi sadb-bad-spi {
               description "Notifiy
                   "Notify when the NSF receives a packet with an
                    incorrect SPI (i.e. not present in the SAD)"; SAD).";
               leaf state spi {
                   type ic:ipsec-spi; uint32 { range "0..max"; }
                   mandatory "true"; true;
                   description
                       "SPI number contained in the erroneous IPsec packet";
                        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
   in tunnel mode (gateway-to-gateway) with ESP, and authentication
   based on X.509 certificates using IKEv2.

                        Security Controller
                              |
                 /---- Southbound interface -----\
                /                                 \
               /                                   \
              /                                     \
             /                                       \
            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

     Figure 7: 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 a XML configuration file sent by the Security
   Controller to establish a IPsec Security association between two NSFs
   in transport mode (host-to-host) with ESP.

                             Security Controller
                                       |
                        /---- Southbound interface -----\
                       /                                 \
                      /                                   \
                     /                                     \
                    /                                       \
                 nsf_h1                                    nsf_h2
                 (:100)===== IPsec_ESP_Transport_mode =====(:200)
                               (2001:DB8:123:/64)

                 Figure 8: 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 of notifications.

   Below we show several XML files that represent different types of
   notifications defined in the IKE-less YANG model, which are sent by
   the NSF to the Security 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 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 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 of sadb-bad-spi notification.

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